On Tue, Apr 20, 2010 at 1:04 PM, Vladimir Sedach <vsedach@gmail.com> wrote:

> 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?

Here's an example of what the current intermediate form looks like:

(compile-statement '(defun blep (ss x y)
(when foo?
(let ((pair (bar)))
(unless (null pair)
(destructuring-bind (a b) pair
(unless (or (null a) (null b))
(let ((val (baz a b)))
(unless (null val)
(when (blah val)
(unless (blee)
t)))))))))))

=>

(JS:DEFUN BLEP (SS X Y)
(JS:BLOCK
(JS:IF FOO?
(JS:BLOCK (JS:VAR PAIR (JS:FUNCALL BAR))
(JS:IF (JS:!== PAIR NIL)
(JS:BLOCK (JS:VAR A (JS:AREF PAIR 0)) (JS:VAR B (JS:AREF PAIR 1))
(JS:IF (JS:! (JS:|\|\|| (JS:=== A NIL) (JS:=== B NIL)))
(JS:BLOCK (JS:VAR VAL (JS:FUNCALL BAZ A B))
(JS:IF (JS:!== VAL NIL)
(JS:BLOCK
(JS:IF (JS:FUNCALL BLAH VAL)
(JS:BLOCK
(JS:IF (JS:! (JS:FUNCALL BLEE))
(JS:BLOCK (JS:RETURN T)))))))))))))))

As you can see, all you need is to define some functions and macros,
and the resulting code is ready to be EVALed or compiled.

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

Thanks for the pointer. I didn't know you based your parser on JWACS'.
I took a look at JWACS when starting, but decided to base mine on
Marijn Haverbeke's parse-js (http://marijn.haverbeke.nl/parse-js/);
it seemed easier to modify.

Vladimir

>> 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>:
>> > +1, as they say...
>> >
>> > ++Thanks,
>> >
>> > John :^P
>> >
>> > On Mon, Apr 19, 2010 at 12:42 AM, Daniel Gackle <danielgackle@gmail.com>
>> > wrote:
>> >> For those of us who are curious, could you talk a bit about the work
>> >> you did
>> >> on the compiler?
>> >> Thanks Vladimir,
>> >> Daniel
>> >
>> > _______________________________________________
>> > parenscript-devel mailing list
>> > parenscript-devel@common-lisp.net
>> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>> >
>>
>> _______________________________________________
>> parenscript-devel mailing list
>> parenscript-devel@common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel@common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>

_______________________________________________
parenscript-devel mailing list
parenscript-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel