Ok, I can see this design working:
The ParenScript compiler, instead of emitting a Javascript string, produces Lisp code to emit the Javascript string, where all identifier references are resolved when the code runs. So as you define new code in ParenScript, the necessary identifier information gets emitted along with the generated Javascript generator code, as code that updates that PPP in an eval-when clause of :compile-toplevel :load-toplevel :execute.
Does that make sense? What does everyone think? This is going to take a lot of work, but I think the compiler could use some refactoring anyway. :)
Vladimir
On 6/21/07, John Fremlin john@fremlin.org wrote:
"Red Daly" reddaly@gmail.com writes: [...]
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.
Heartily agree.
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.
In fact, I don't see it as being a problem as most inline scripts are probably just calling functions already defined.
If there were a sort of "parenscript program or package" class (PPP for now, until someone comes up with a proper name), then when you ask for parenscript to be generated, you have to pass in an instance of this class.
Inline scripts would just mention which PPP they were related to so that name-mangling, function inlining(!) and consequent dead code elimination(!), global constant propagation(!), and so on could occur correctly.
Another useful thing would be to be able to add lots of functions to the PPP and then have parenscript dump out only the ones that were actually referenced, avoiding the current practice of massive JavaScript library downloads.
[...]
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.
Hear, hear.
In this case the business of the PPP dumping out just referenced functions would be quite handy, so that you wouldn't have to download the entire, inevitably massive, CL compatibility library for small functions.
[...]
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel