[parenscript-devel] Breakage notifications
Daniel Gackle
danielgackle at gmail.com
Tue Feb 10 00:10:58 UTC 2009
While it's annoying whenever code breaks, this seems like a good change to
me. Special-casing symbols with dots seems like an unnecessary leakage of JS
into PS. It's hard to build macros on top of forms like that and so on.
Daniel
p.s. I have several proposed changes to PS that I've been too busy to post
about, but will soon. They are things we've added to our own app as a layer
on top of PS that have been working out very well, but require a couple of
changes to the PS compiler.
On Mon, Feb 9, 2009 at 4:06 PM, Vladimir Sedach <vsedach at gmail.com> wrote:
> Hi Lesie,
>
> The change in question (details below) is particularly nasty, and I
> initially wanted to post about it, but then decided to see how many
> people would complain. Sorry you had to be the first!
>
> Details about the breakage:
>
> (.method object args) is no longer treated differently by Parenscript.
> Now you need to write ((@ object method) args) or alternatively
> ((slot-value object 'method) args). There are three main reasons for
> this:
>
> 1. ".method" and "method" are two different symbols in CL. This breaks
> the package prefix and obfuscation features of PS (among other
> things).
>
> 2. Special-casing forms that begin with a symbol that begins with a
> dot means that you need to special-case code walkers, and special-case
> your CL code if you intend to run the same code on the browser and
> server.
>
> 3. The special-casing was handled by a special
> intermediary-representation form that introduced duplication, that
> turned out to have bugs in it (that was the last straw for me).
>
> Vladimir
>
> PS - One thing that I just realized is that forms like ((slot-value
> object 'method) args) will cause an error when you try to eval them in
> CL because the car of a form can only be a symbol denoting a function
> or macro, or a literal lambda form (I think that's all but I'm too
> lazy to search the Hyperspec for where it states that). The solution
> for PS-CL code sharing is to introduce a PS funcall macro that doesn't
> do anything (that's now in the repository).
>
>
> On Mon, Feb 9, 2009 at 8:15 AM, Leslie P. Polzer
> <sky at viridian-project.de> wrote:
> >
> > Vladimir,
> >
> > I have a small request: could you post a short note to the list
> > when you commit an incompatible change? 79630.. gave me a bit of
> > an headache until I took a look at the revlog.
> >
> > Thanks,
> >
> > Leslie
> >
> > --
> > LinkedIn Profile: http://www.linkedin.com/in/polzer
> > Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
> > Blog: http://blog.viridian-project.de/
> >
> >
> > _______________________________________________
> > parenscript-devel mailing list
> > parenscript-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
> >
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20090209/17d1d89f/attachment.html>
More information about the parenscript-devel
mailing list