[parenscript-devel] Feature request: prefixed names

Vladimir Sedach vsedach at gmail.com
Thu Jun 21 18:45:00 UTC 2007

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. :)


On 6/21/07, John Fremlin <john at fremlin.org> wrote:
> "Red Daly" <reddaly at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel

More information about the parenscript-devel mailing list