Greetings,
I recently upgraded parenscript after a few months and was disheartened to see that (.method ...) syntax was removed (and to a lesser extent foo.bar and foo[bar] syntax). I read the mailing list threads pertaining to the new lexical let implementation and compiler improvements, but after skimming the source code I don't see why (.method ...) could not be supported.
As such I have started a symbol-syntax branch at [0]. In particular I have done a first stab at reimplementing the (.method ...) syntax in the patch viewable at [1]. I do not yet have a grasp of the subtleties in the new compiler, but I think the patch looks basically correct. I figured you guys could tell me if I missed anything.
Are there any objections to the patch? I've found that (funcall (@ foo bar) ...) and (chain foo bar (baz ...)) syntax to be fairly unwieldy for something as common as a method call, and don't see why (.method ...) should not be considered a fundamental syntax of parenscript (parenscript is parenscript and not lisp; enforcing consistency with lisp syntax at the expense of conciseness is not desirable in my opinion).
I'll probably reimplement foo.bar.baz syntax properly (by splitting the symbol apart and translating to nested (js:slot-value ...) nodes?). I'm not convinced that it is worth having foo[bar] syntax however (but drewc disagrees so I may reimplement it anyway for our use in ucw/lisp-on-lines). Is there anything fundamentally preventing this from working properly (in the face of symbol renaming and such)?
[0] git://git.hcoop.net/git/clinton/parenscript.git [1] http://git.hcoop.net/?p=clinton/parenscript.git;a=commitdiff;h=18eb199841541...
Hi Clinton,
The big problem with the .method call syntax (and object.property) was that the mechanism for interpreting them was part of the PS compiler. Both dot conventions are syntax extensions to Lisp code, so I strongly believe that the only right way to implement them is as reader macros. Otherwise the dot symbols remain as opaque identifiers instead of the compound forms they really are.
I see two better alternatives that would work with the various symbol renamings the PS compiler does now: something like an :around method on the PS compilation interface (ps, ps*, etc) that would code-walk the given code and expand the dot symbols, or something that is part of the symbol-macro mechanism.
I don't like the latter because it again moves the burden of interpretation to the compiler, and I don't like either because they still leave the code opaque to other CL code walking tools.
The .method syntax can be implemented as a reader macro by introducing a new PS special form (if someone can come up with a more elegant solution, please let me know). Object.property can be, but if you do it wholesale you run the risk of breaking other unrelated CL code that contains those symbols in your software.
An excellent place to put these kinds of syntax extensions is in the Parenscript source file mechanism that's advocated (and is provided in a limited form in the current PS release) by Red Daly - one of his intentions was to be able to have the ability to extend the syntax in just such ways. This introduces a dichotomy between Parenscript source that you have in separate files, and Parenscript source that you have embedded in and mixed with other CL code, which is why I don't like the idea.
I think I'll try implementing both dot symbol conventions as reader macros and see how that turns out. In hindsight this is something that would probably have been a good idea to put in when I first removed the conventions, and certainly for the recent release, but the idea didn't occur to me until now.
Thank you, Vladimir
On Thu, Sep 17, 2009 at 10:34 PM, Clinton Ebadi clinton@unknownlamer.org wrote:
Greetings,
I recently upgraded parenscript after a few months and was disheartened to see that (.method ...) syntax was removed (and to a lesser extent foo.bar and foo[bar] syntax). I read the mailing list threads pertaining to the new lexical let implementation and compiler improvements, but after skimming the source code I don't see why (.method ...) could not be supported.
As such I have started a symbol-syntax branch at [0]. In particular I have done a first stab at reimplementing the (.method ...) syntax in the patch viewable at [1]. I do not yet have a grasp of the subtleties in the new compiler, but I think the patch looks basically correct. I figured you guys could tell me if I missed anything.
Are there any objections to the patch? I've found that (funcall (@ foo bar) ...) and (chain foo bar (baz ...)) syntax to be fairly unwieldy for something as common as a method call, and don't see why (.method ...) should not be considered a fundamental syntax of parenscript (parenscript is parenscript and not lisp; enforcing consistency with lisp syntax at the expense of conciseness is not desirable in my opinion).
I'll probably reimplement foo.bar.baz syntax properly (by splitting the symbol apart and translating to nested (js:slot-value ...) nodes?). I'm not convinced that it is worth having foo[bar] syntax however (but drewc disagrees so I may reimplement it anyway for our use in ucw/lisp-on-lines). Is there anything fundamentally preventing this from working properly (in the face of symbol renaming and such)?
[0] git://git.hcoop.net/git/clinton/parenscript.git [1] http://git.hcoop.net/?p=clinton/parenscript.git;a=commitdiff;h=18eb199841541...
-- Jessie: but today i was a nerd Jessie: i even read slashdot.
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
I've played around with the read-macro idea, and I don't think it will work. Dot is already a reader macro for dotted lists, and I don't have any ideas for how to do object.slot portably.
Vladimir
On Wed, Sep 23, 2009 at 3:29 AM, Vladimir Sedach vsedach@gmail.com wrote:
Hi Clinton,
The big problem with the .method call syntax (and object.property) was that the mechanism for interpreting them was part of the PS compiler. Both dot conventions are syntax extensions to Lisp code, so I strongly believe that the only right way to implement them is as reader macros. Otherwise the dot symbols remain as opaque identifiers instead of the compound forms they really are.
I see two better alternatives that would work with the various symbol renamings the PS compiler does now: something like an :around method on the PS compilation interface (ps, ps*, etc) that would code-walk the given code and expand the dot symbols, or something that is part of the symbol-macro mechanism.
I don't like the latter because it again moves the burden of interpretation to the compiler, and I don't like either because they still leave the code opaque to other CL code walking tools.
The .method syntax can be implemented as a reader macro by introducing a new PS special form (if someone can come up with a more elegant solution, please let me know). Object.property can be, but if you do it wholesale you run the risk of breaking other unrelated CL code that contains those symbols in your software.
An excellent place to put these kinds of syntax extensions is in the Parenscript source file mechanism that's advocated (and is provided in a limited form in the current PS release) by Red Daly - one of his intentions was to be able to have the ability to extend the syntax in just such ways. This introduces a dichotomy between Parenscript source that you have in separate files, and Parenscript source that you have embedded in and mixed with other CL code, which is why I don't like the idea.
I think I'll try implementing both dot symbol conventions as reader macros and see how that turns out. In hindsight this is something that would probably have been a good idea to put in when I first removed the conventions, and certainly for the recent release, but the idea didn't occur to me until now.
Thank you, Vladimir
On Thu, Sep 17, 2009 at 10:34 PM, Clinton Ebadi clinton@unknownlamer.org wrote:
Greetings,
I recently upgraded parenscript after a few months and was disheartened to see that (.method ...) syntax was removed (and to a lesser extent foo.bar and foo[bar] syntax). I read the mailing list threads pertaining to the new lexical let implementation and compiler improvements, but after skimming the source code I don't see why (.method ...) could not be supported.
As such I have started a symbol-syntax branch at [0]. In particular I have done a first stab at reimplementing the (.method ...) syntax in the patch viewable at [1]. I do not yet have a grasp of the subtleties in the new compiler, but I think the patch looks basically correct. I figured you guys could tell me if I missed anything.
Are there any objections to the patch? I've found that (funcall (@ foo bar) ...) and (chain foo bar (baz ...)) syntax to be fairly unwieldy for something as common as a method call, and don't see why (.method ...) should not be considered a fundamental syntax of parenscript (parenscript is parenscript and not lisp; enforcing consistency with lisp syntax at the expense of conciseness is not desirable in my opinion).
I'll probably reimplement foo.bar.baz syntax properly (by splitting the symbol apart and translating to nested (js:slot-value ...) nodes?). I'm not convinced that it is worth having foo[bar] syntax however (but drewc disagrees so I may reimplement it anyway for our use in ucw/lisp-on-lines). Is there anything fundamentally preventing this from working properly (in the face of symbol renaming and such)?
[0] git://git.hcoop.net/git/clinton/parenscript.git [1] http://git.hcoop.net/?p=clinton/parenscript.git;a=commitdiff;h=18eb199841541...
-- Jessie: but today i was a nerd Jessie: i even read slashdot.
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Clinton Ebadi -
Vladimir Sedach