I prefer a Parenscript that departs from the exact semantics of Javascript and a Parenscript compiler that performs more advanced analysis.  In this case, introducing the concept of a "whole Parenscript program" would be beneficial to Parenscript developers.  It will not only allow a more sophisticated code generator (for minifying, prefixing, etc.) but could also make it easier to extend the compiler, generate documentation for a Parenscript program, and otherwise manipulate Parenscripts programmatically.

I suspect that there are manageable solutions to problems like inconsistent "name manglings" across different compilations.  A package system that keeps track of variable and function declarations can resolve identifier references and rewrite them accordingly, leaving global or unresolved identifiers alone.  A few months ago I implemented the first steps of a package system for Parenscript that does some semantic analysis to accomplish prefixing as described.[1]  I did not attempt to solve the "inline scripts" issue, but that problem seems far from impossible.

Of course users have varying use cases.  I write lengthy programs in standalone .paren files. Others may use Parenscript quite lightly to embed scripts in HTML. We can probably find solutions that make everyone's life easier.

I am generally of the opinion that Parenscript should be as close to Lisp as possible. It is absurd that even in 2007 there is still so much fuss over programming languages. It would be great if a separate Parenscript language did not need to exist.

-Red

[1] remnants of that work are in the darcs repository for the Suave project in the /suavescript/ directory: http://common-lisp.net/project/suave/