[parenscript-devel] Reimplementing (.method object ...) syntax

[Vladimir Sedach]

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 at 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 at 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=18eb199841541edad87956b2380fd012e5a60769
>>
>> --
>> Jessie: but today i was a nerd
>> Jessie: i even read slashdot.
>>
>> _______________________________________________
>> parenscript-devel mailing list
>> parenscript-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>>
>