On Mon, Apr 19, 2010 at 11:03 AM, Vladimir Sedach
<vsedach@gmail.com> wrote:
This work was removing the last of the old-style hacks from the
compiler to clearly separate PS into three parts: the compiler itself,
the special forms code, and the printer. This reduces code size and
dependencies significantly, but the ultimate goal (which has mostly
been achieved) is to provide an intermediary S-exp representation of
JavaScript code that is directly and efficiently executable as Common
Lisp code.
What is the motivation for using lists as the intermediate form rather than CLOS objects? I suppose that s-expressions makes it easy to use tree-walking functions out of the box, but there seem to be disadvantages when it comes to separating syntax from semantics, e.g. addressing the 'else' form of an if via (third if-statement) vs. (if-statement-else if-statement).
I have not seen the intermediary form and I am sure you have good reasons, but it is not the direction I would have gone. Could you explain the choice perhaps with some motivating examples, to enlighten us all?
In the future I'll be moving the printer code to a separate project,
which will also have a parser from JavaScript to this intermediary
representation. That project will serve as a useful base for JS code
transformation tools, and I am planning to write a JS->CL compiler on
top.
Go, Vladimir, go! That's an ambitious project but I would love to see it happen!
Please not that there is a project with a viable javascript parser and printer already. See
http://github.com/gonzojive/js-parser
I adapted the code from JWACS (Javascript With Advanced Continuations Support) into a new project for parsing javascript. The original JWACS included a pretty printer and an obfuscating printer that would obfuscate non-toplevel variables. It also had a Javascript-like grammar with a few extra syntax additions.
The syntax tree represents javascript with structures rather than lists for everything, but you should be able to avoid writing the parser yourself, at the very least.
One user-visible change I made in the latest patches is to encourage
use of CL equality predicates ('==' and '===' are still there but
marked as deprecated).
Vladimir
Red
2010/4/19 John Pallister <john@synchromesh.com>: