[parenscript-devel] CASE keys in Parenscript vs. Lisp
Hello. I've noticed that Parenscript has a different semantics from Lisp as regards keys of CASE clauses. Lisp assumes an implicit QUOTE in this context, so that a symbol used as CASE clause key matches a test-key which is EQL to the symbol, as opposed to its value. Parenscript, on the other hand, translates CASE forms to switch statements where symbol keys are used as identifiers. E. g. (let* ((foo 'bar) (bar 'foo) (x bar)) (case x ((foo) 1) ((bar) 2))) translates to (function () { var foo = 'bar'; var bar = 'foo'; var x = bar; switch (x) { case foo: return 1; case bar: return 2; }; })(); Note that the former evaluates to 1, the latter to 2. Now, is this a bug, or a feature? The section on CASE in the Parenscript Manual is actually misleading, whatever the answer. — B. Smilga.
This I would definitely call a bug. Since the position PS takes right now is that it doesn't have symbols as run-time objects, I made the decision to disallow them as keys in CASE clauses. Only keyword symbols (which are translated to strings), numbers and string literals are allowed. The behavior exhibited in your case is perfectly ok JavaScript though, so the SWITCH special form still supports having variables and others things as keys. I made a note in the reference manual (in the repo, I'll update the version on the PS website with the next release), and also fixed some other bugs I found in CASE and SWITCh statements. Thank you for bringing this issue up! Vladimir On Mon, Sep 3, 2012 at 8:09 AM, Boris Smilga <boris.smilga@gmail.com> wrote:
Hello.
I've noticed that Parenscript has a different semantics from Lisp as regards keys of CASE clauses. Lisp assumes an implicit QUOTE in this context, so that a symbol used as CASE clause key matches a test-key which is EQL to the symbol, as opposed to its value. Parenscript, on the other hand, translates CASE forms to switch statements where symbol keys are used as identifiers. E. g.
(let* ((foo 'bar) (bar 'foo) (x bar)) (case x ((foo) 1) ((bar) 2)))
translates to
(function () { var foo = 'bar'; var bar = 'foo'; var x = bar; switch (x) { case foo: return 1; case bar: return 2; }; })();
Note that the former evaluates to 1, the latter to 2.
Now, is this a bug, or a feature? The section on CASE in the Parenscript Manual is actually misleading, whatever the answer.
— B. Smilga.
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Trying to upgrade to the latest PS, I have a problem with this CASE fix: it rejects symbol macros that expand to numbers. It's quite handy to use symbol macros this way for compile-time constants, so I hope the desired behavior can be restored. Daniel On Mon, Sep 3, 2012 at 7:22 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
This I would definitely call a bug. Since the position PS takes right now is that it doesn't have symbols as run-time objects, I made the decision to disallow them as keys in CASE clauses. Only keyword symbols (which are translated to strings), numbers and string literals are allowed.
The behavior exhibited in your case is perfectly ok JavaScript though, so the SWITCH special form still supports having variables and others things as keys.
I made a note in the reference manual (in the repo, I'll update the version on the PS website with the next release), and also fixed some other bugs I found in CASE and SWITCh statements.
Thank you for bringing this issue up!
Vladimir
On Mon, Sep 3, 2012 at 8:09 AM, Boris Smilga <boris.smilga@gmail.com> wrote:
Hello.
I've noticed that Parenscript has a different semantics from Lisp as regards keys of CASE clauses. Lisp assumes an implicit QUOTE in this context, so that a symbol used as CASE clause key matches a test-key which is EQL to the symbol, as opposed to its value. Parenscript, on the other hand, translates CASE forms to switch statements where symbol keys are used as identifiers. E. g.
(let* ((foo 'bar) (bar 'foo) (x bar)) (case x ((foo) 1) ((bar) 2)))
translates to
(function () { var foo = 'bar'; var bar = 'foo'; var x = bar; switch (x) { case foo: return 1; case bar: return 2; }; })();
Note that the former evaluates to 1, the latter to 2.
Now, is this a bug, or a feature? The section on CASE in the Parenscript Manual is actually misleading, whatever the answer.
— B. Smilga.
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Do you mean something like this: (symbol-macrolet ((x 1)) (let ((blah 1)) (case blah (0 3) (x 7) (t 13)))) Where the key x is supposed to expand to 1? In CL that code evaluates to 13, but since there's no way symbols can be used as keys I suppose using symbol macros that expand to numbers makes a lot of sense. Let me know if the above example is the behavior you think should be provided (ie the form should return 7), and I'll make a patch. Vladimir On Thu, Sep 13, 2012 at 10:15 PM, Daniel Gackle <danielgackle@gmail.com> wrote:
Trying to upgrade to the latest PS, I have a problem with this CASE fix: it rejects symbol macros that expand to numbers. It's quite handy to use symbol macros this way for compile-time constants, so I hope the desired behavior can be restored.
Daniel
On Mon, Sep 3, 2012 at 7:22 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
This I would definitely call a bug. Since the position PS takes right now is that it doesn't have symbols as run-time objects, I made the decision to disallow them as keys in CASE clauses. Only keyword symbols (which are translated to strings), numbers and string literals are allowed.
The behavior exhibited in your case is perfectly ok JavaScript though, so the SWITCH special form still supports having variables and others things as keys.
I made a note in the reference manual (in the repo, I'll update the version on the PS website with the next release), and also fixed some other bugs I found in CASE and SWITCh statements.
Thank you for bringing this issue up!
Vladimir
On Mon, Sep 3, 2012 at 8:09 AM, Boris Smilga <boris.smilga@gmail.com> wrote:
Hello.
I've noticed that Parenscript has a different semantics from Lisp as regards keys of CASE clauses. Lisp assumes an implicit QUOTE in this context, so that a symbol used as CASE clause key matches a test-key which is EQL to the symbol, as opposed to its value. Parenscript, on the other hand, translates CASE forms to switch statements where symbol keys are used as identifiers. E. g.
(let* ((foo 'bar) (bar 'foo) (x bar)) (case x ((foo) 1) ((bar) 2)))
translates to
(function () { var foo = 'bar'; var bar = 'foo'; var x = bar; switch (x) { case foo: return 1; case bar: return 2; }; })();
Note that the former evaluates to 1, the latter to 2.
Now, is this a bug, or a feature? The section on CASE in the Parenscript Manual is actually misleading, whatever the answer.
— B. Smilga.
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Yes, that's it. Sorry for the ambiguity. I actually rely on this behavior in more than one place; it basically gives you #DEFINE for magic numbers. Thanks, Dan On Thu, Sep 13, 2012 at 7:40 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
Do you mean something like this:
(symbol-macrolet ((x 1)) (let ((blah 1)) (case blah (0 3) (x 7) (t 13))))
Where the key x is supposed to expand to 1? In CL that code evaluates to 13, but since there's no way symbols can be used as keys I suppose using symbol macros that expand to numbers makes a lot of sense.
Let me know if the above example is the behavior you think should be provided (ie the form should return 7), and I'll make a patch.
Vladimir
On Thu, Sep 13, 2012 at 10:15 PM, Daniel Gackle <danielgackle@gmail.com> wrote:
Trying to upgrade to the latest PS, I have a problem with this CASE fix: it rejects symbol macros that expand to numbers. It's quite handy to use symbol macros this way for compile-time constants, so I hope the desired behavior can be restored.
Daniel
On Mon, Sep 3, 2012 at 7:22 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
This I would definitely call a bug. Since the position PS takes right now is that it doesn't have symbols as run-time objects, I made the decision to disallow them as keys in CASE clauses. Only keyword symbols (which are translated to strings), numbers and string literals are allowed.
The behavior exhibited in your case is perfectly ok JavaScript though, so the SWITCH special form still supports having variables and others things as keys.
I made a note in the reference manual (in the repo, I'll update the version on the PS website with the next release), and also fixed some other bugs I found in CASE and SWITCh statements.
Thank you for bringing this issue up!
Vladimir
On Mon, Sep 3, 2012 at 8:09 AM, Boris Smilga <boris.smilga@gmail.com> wrote:
Hello.
I've noticed that Parenscript has a different semantics from Lisp as regards keys of CASE clauses. Lisp assumes an implicit QUOTE in this context, so that a symbol used as CASE clause key matches a test-key which is EQL to the symbol, as opposed to its value. Parenscript, on the other hand, translates CASE forms to switch statements where symbol keys are used as identifiers. E. g.
(let* ((foo 'bar) (bar 'foo) (x bar)) (case x ((foo) 1) ((bar) 2)))
translates to
(function () { var foo = 'bar'; var bar = 'foo'; var x = bar; switch (x) { case foo: return 1; case bar: return 2; }; })();
Note that the former evaluates to 1, the latter to 2.
Now, is this a bug, or a feature? The section on CASE in the Parenscript Manual is actually misleading, whatever the answer.
— B. Smilga.
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Ok, I pushed a patch. Let me know if that works ok. Vladimir On Thu, Sep 13, 2012 at 10:52 PM, Daniel Gackle <danielgackle@gmail.com> wrote:
Yes, that's it. Sorry for the ambiguity. I actually rely on this behavior in more than one place; it basically gives you #DEFINE for magic numbers.
Thanks, Dan
On Thu, Sep 13, 2012 at 7:40 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
Do you mean something like this:
(symbol-macrolet ((x 1)) (let ((blah 1)) (case blah (0 3) (x 7) (t 13))))
Where the key x is supposed to expand to 1? In CL that code evaluates to 13, but since there's no way symbols can be used as keys I suppose using symbol macros that expand to numbers makes a lot of sense.
Let me know if the above example is the behavior you think should be provided (ie the form should return 7), and I'll make a patch.
Vladimir
On Thu, Sep 13, 2012 at 10:15 PM, Daniel Gackle <danielgackle@gmail.com> wrote:
Trying to upgrade to the latest PS, I have a problem with this CASE fix: it rejects symbol macros that expand to numbers. It's quite handy to use symbol macros this way for compile-time constants, so I hope the desired behavior can be restored.
Daniel
On Mon, Sep 3, 2012 at 7:22 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
This I would definitely call a bug. Since the position PS takes right now is that it doesn't have symbols as run-time objects, I made the decision to disallow them as keys in CASE clauses. Only keyword symbols (which are translated to strings), numbers and string literals are allowed.
The behavior exhibited in your case is perfectly ok JavaScript though, so the SWITCH special form still supports having variables and others things as keys.
I made a note in the reference manual (in the repo, I'll update the version on the PS website with the next release), and also fixed some other bugs I found in CASE and SWITCh statements.
Thank you for bringing this issue up!
Vladimir
On Mon, Sep 3, 2012 at 8:09 AM, Boris Smilga <boris.smilga@gmail.com> wrote:
Hello.
I've noticed that Parenscript has a different semantics from Lisp as regards keys of CASE clauses. Lisp assumes an implicit QUOTE in this context, so that a symbol used as CASE clause key matches a test-key which is EQL to the symbol, as opposed to its value. Parenscript, on the other hand, translates CASE forms to switch statements where symbol keys are used as identifiers. E. g.
(let* ((foo 'bar) (bar 'foo) (x bar)) (case x ((foo) 1) ((bar) 2)))
translates to
(function () { var foo = 'bar'; var bar = 'foo'; var x = bar; switch (x) { case foo: return 1; case bar: return 2; }; })();
Note that the former evaluates to 1, the latter to 2.
Now, is this a bug, or a feature? The section on CASE in the Parenscript Manual is actually misleading, whatever the answer.
— B. Smilga.
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
It did. Thanks! On Thu, Sep 13, 2012 at 8:31 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
Ok, I pushed a patch. Let me know if that works ok.
Vladimir
Yes, that's it. Sorry for the ambiguity. I actually rely on this behavior in more than one place; it basically gives you #DEFINE for magic numbers.
Thanks, Dan
On Thu, Sep 13, 2012 at 7:40 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
Do you mean something like this:
(symbol-macrolet ((x 1)) (let ((blah 1)) (case blah (0 3) (x 7) (t 13))))
Where the key x is supposed to expand to 1? In CL that code evaluates to 13, but since there's no way symbols can be used as keys I suppose using symbol macros that expand to numbers makes a lot of sense.
Let me know if the above example is the behavior you think should be provided (ie the form should return 7), and I'll make a patch.
Vladimir
On Thu, Sep 13, 2012 at 10:15 PM, Daniel Gackle <danielgackle@gmail.com
wrote:
Trying to upgrade to the latest PS, I have a problem with this CASE fix: it rejects symbol macros that expand to numbers. It's quite handy to use symbol macros this way for compile-time constants, so I hope the desired behavior can be restored.
Daniel
On Mon, Sep 3, 2012 at 7:22 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
This I would definitely call a bug. Since the position PS takes right now is that it doesn't have symbols as run-time objects, I made the decision to disallow them as keys in CASE clauses. Only keyword symbols (which are translated to strings), numbers and string
are allowed.
The behavior exhibited in your case is perfectly ok JavaScript
so the SWITCH special form still supports having variables and others things as keys.
I made a note in the reference manual (in the repo, I'll update the version on the PS website with the next release), and also fixed some other bugs I found in CASE and SWITCh statements.
Thank you for bringing this issue up!
Vladimir
On Mon, Sep 3, 2012 at 8:09 AM, Boris Smilga <boris.smilga@gmail.com
wrote:
Hello.
I've noticed that Parenscript has a different semantics from Lisp as regards keys of CASE clauses. Lisp assumes an implicit QUOTE in
On Thu, Sep 13, 2012 at 10:52 PM, Daniel Gackle <danielgackle@gmail.com> wrote: literals though, this
context, so that a symbol used as CASE clause key matches a test-key which is EQL to the symbol, as opposed to its value. Parenscript, on the other hand, translates CASE forms to switch statements where symbol keys are used as identifiers. E. g.
(let* ((foo 'bar) (bar 'foo) (x bar)) (case x ((foo) 1) ((bar) 2)))
translates to
(function () { var foo = 'bar'; var bar = 'foo'; var x = bar; switch (x) { case foo: return 1; case bar: return 2; }; })();
Note that the former evaluates to 1, the latter to 2.
Now, is this a bug, or a feature? The section on CASE in the Parenscript Manual is actually misleading, whatever the answer.
— B. Smilga.
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
participants (3)
-
Boris Smilga -
Daniel Gackle -
Vladimir Sedach