"Vladimir Sedach" vsedach@gmail.com writes:
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. :)
I think the general use case is a sort of Parenscript library that is quite fixed and only uses identifiers in itself. The name references inside this library can presumably be all resolved at the host lisp's compile time.
Then there are numerous small bits of JavaScript shoved into each page as event attributes or <script>s or whatever. It is unlikely that these things will modify the PPP (if they did, then you would have to have one PPP per page). But most of their references will probably be resolvable at compile time to identifiers in the library.
I'm not sure that name-mangling (helpful by-product: spell-checking of identifiers) would really use the "lisp code templates to generate a string" functionality.
However, for me, a compiler from parenscript to a sort of templatised lisp would be immensely useful. For example, I use a dynamic-hider thing, that makes a div with an onclick event: `(toggle-hiding ,other-html-element-id). If this could be compiled to a lisp template so that the string in other-html-element-id could be inserted directly into the output without calling the ParenScript compiler for each page generation, that would be great. It would make my web-application much, much faster.
[...]