[parenscript-devel] Reimplementing (.method object ...) syntax
vsedach at gmail.com
Wed Sep 23 09:29:23 UTC 2009
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
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.
On Thu, Sep 17, 2009 at 10:34 PM, Clinton Ebadi
<clinton at unknownlamer.org> wrote:
> 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 . In particular I
> have done a first stab at reimplementing the (.method ...) syntax in the
> patch viewable at . 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
> 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)?
>  git://git.hcoop.net/git/clinton/parenscript.git
>  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
More information about the parenscript-devel