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.