[parenscript-devel] Expressionize

[Red Daly]

Thanks for the reply.

On Thu, Aug 19, 2010 at 10:19 AM, Vladimir Sedach <vsedach at gmail.com> wrote:
>> The 'expressionize' function seems to be at the core of implicit
>> returns.  It seems to be a promising approach to morphing Javascript
>> into an everything-is-an-expression language.
>
> Yes. After I wrote implicit return it became obvious that could be
> generalized into "expressionize."
>
>> Unfortunately right now
>> it is poorly documented and not used everywhere it could be.
>
> I'm pretty sure it also has some pretty big bugs. More importantly, I
> don't think it works as advertised if you try to use it in arbitrary
> places right now.
>

Yes, though it's a good start and it's already gotten us working
implicit return.  It does work with only a few forms, because
expressionize will do things like use the lambda passed into it
multiple times.  It also works with forms before they are compiled by
the special-form transformers (i.e. you pass in Parenscript forms, not
JS-as-sexps forms).

>> Hopefully we can discuss where this feature is heading publicly and
>> finish up expressionizing parenscript.
>>
>> Right now LET does not seem to take advantage of expressionize the
>> same way functions do.  LET fails to turn TRY into an expression,
>> while implicit return works.  What would we need to do to add this?
>
> At first thought all the places where the Parenscript special forms
> need expressions are already annotated with the COMPILE-EXPRESSION
> function. So one possible way is to just expressionize all statements
> that end up getting compiled by COMPILE-EXPRESSION into lambdas that
> get called in-place. This is what most other Lisp to JS compilers seem
> to do. This would look like
>
> (+ 1 (dolist ()...)) => (+ 1 (funcall (lambda () (var x) (dolist ()...
> finally x = _) (return x)))
>
> If we're willing to tolerate Scheme calling convention (argument
> evaluation order is unspecified), this could be transformed into more
> idiomatic JS:
>
> (+ 1 (dolist () ...)) =>
>
> (var x)
> (dolist () ... finally x = _)
> (+ 1 x)

Indeed.  I don't think it would be impossible to guarantee the
evaluation order either, but it will take some thought.  For example,
forms like this:

(let ((x (+ (call-me-first) (try (unsafe) (:catch (e) "failure")))))
   x)

Would need to compile to

var called_first = callMeFirst();
var result1;
try {
  result1 = unsafe();
} catch (e) {
  result 1 = "failure";
}
var x = called_first + result1;

I'm not really sure where the right place to implement this is.
Perhaps we can implement a pseudo-expression special form.  But I
don't know in what stage of processing we would need to process
expressions with pseudo-expressions.  Any idea on how we could
potentially implement this?

Another alternative is to introduce a pseudo-lambda special form, in
which case it is necessary to code walk the generated code to check
for things like 'arguments', 'this', return and break statements.  I
think this approach is quite doable, though it may require a better
code walker than we have already.

>
> I think I brought up this idea (undefined argument evaluation order)
> before in relation to some other feature, but I can't find a mention
> of that now.
>
> Vladimir


Red


>
>> (ps:ps (let ((x (ps:try xxx
>>                           (:catch (x) 5))))
>>                  x))
>> "var x233 = try {
>>    xxx;
>> } catch (x) {
>>    5;
>> };
>> x233;"
>>
>>
>> below works:
>>
>>> (ps:ps (lambda ()
>>                  (ps:try xxx
>>                          (:catch (x) 5))))
>> "function () {
>>    try {
>>        return xxx;
>>    } catch (x) {
>>        return 5;
>>    };
>> };"
>>
>>
>> Thanks for the insights,
>> Red
>>
>> _______________________________________________
>> 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
>