[parenscript-devel] Lexical scoping bug

[Vladimir Sedach]

> 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 at synchromesh.com>:
>> > +1, as they say...
>> >
>> > ++Thanks,
>> >
>> > John :^P
>> >
>> > On Mon, Apr 19, 2010 at 12:42 AM, Daniel Gackle <danielgackle at 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 at common-lisp.net
>> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>> >
>>
>> _______________________________________________
>> parenscript-devel mailing list
>> parenscript-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>