[parenscript-devel] four patches to PS-LOOP etc.

[Vladimir Sedach]

Hi Boris,

I've done the work to make labels not be emitted if they're never
broken to, and have committed your patches. Thank you again for
submitting them; I especially liked patch 4 - it's a very clean
solution.

In addition, I've also fixed some other outstanding issues with
returns from loops, and a few new bugs I found. This clears all the
things I wanted to do before the next Parenscript release. Whoever is
reading, I welcome you to try out the latest version from the
repository (git clone
http://common-lisp.net/project/parenscript/git/parenscript) and report
any issues you find. I plan on making the next release in the next
couple of weeks.

Thank you,
Vladimir

On Sun, Jul 29, 2012 at 4:16 PM, Vladimir Sedach <vsedach at gmail.com> wrote:
> Hi Boris,
>
> The generated code is much harder to read - there's a block declared
> there that does nothing, and you have to figure out that it does
> nothing if you're trying to read the code. It's deceptive.
>
> I'd like to make a generalized solution involving only BLOCK itself,
> so that other code that generates BLOCKs can take advantage.
>
> Vladimir
>
> On Sat, Jul 28, 2012 at 9:36 AM, Boris Smilga <boris.smilga at gmail.com> wrote:
>> On 21 Jul 2012, at 14:01, Vladimir Sedach wrote:
>>>
>>> [...] Because patch 0003 causes all LOOPs to be
>>>
>>> wrapped in blocks, and loop is used in various places, this means that
>>> this code:
>>>
>>> (defun hello-world (&key ((:my-name-key my-name) 1))
>>>     my-name)
>>>
>>> Used to look like:
>>>
>>> function helloWorld() {
>>>     var _js2 = arguments.length;
>>>     for (var n1 = 0; n1 < _js2; n1 += 2) {
>>>         switch (arguments[n1]) {
>>>         case 'my-name-key':
>>>             myName = arguments[n1 + 1];
>>>         };
>>>     };
>>>     var myName = 'undefined' === typeof myName ? 1 : myName;
>>>     return myName;
>>> };
>>>
>>> And now looks like:
>>>
>>> function helloWorld() {
>>>     nilBlock: {
>>>         var _js2 = arguments.length;
>>>         for (var n1 = 0; n1 < _js2; n1 += 2) {
>>>             switch (arguments[n1]) {
>>>             case 'my-name-key':
>>>                 myName = arguments[n1 + 1];
>>>             };
>>>         };
>>>     };
>>>     var myName = 'undefined' === typeof myName ? 1 : myName;
>>>     return myName;
>>> };
>>>
>>> I need a bit of time to think about the right way to fix that
>>> (probably by fixing block not to emit if the body contains no return,
>>> since it is all lexical) [...]
>>
>>
>> Another approach would be to introduce a special PS-LOOP keyword (called
>> NOBLOCK or something in the same vein) which would make LOOP expand to PROGN
>> rather than to BLOCK.  Then we could add the keyword to the internal LOOPs
>> and get the PROGNs back.  This is simpler than checking for RETURNs, though
>> not necessary more elegant.
>>
>> That said, I don't quite see from the example above why the issue needs
>> fixing in the first place.  You can't really mean that the block introduces
>> local scope for myName etc.? — JavaScript doesn't have block scope.  So what
>> is your idea?
>>
>> Yours,
>>  — B. Smilga.
>>
>>
>>
>> _______________________________________________
>> parenscript-devel mailing list
>> parenscript-devel at common-lisp.net
>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel