[parenscript-devel] New Parenscript release.

[Vladimir Sedach]

> And even then things should only be changed if they provide a net
> benefit; removing dot-syntax from parenscript makes one of the most
> common javascript idioms cumbersome and verbose. Parenscript is /not/
> Common Lisp -- it is entirely acceptable for it to have slightly
> different syntax.

PS is a translator from Common Lisp to JavaScript. The project stopped
being an s-expression syntax for JS quite a while ago.

> What if there were a special form to explicitly allow a Lisp symbol
> through unmodified? This would be a bit different than the current
> |:foo| syntax (the :-escape applies to whatever portion of the
> split symbol it prefixes e.g. |:foo.Bar.:baaZ| -> foo.bar.baaZ).

This isn't the issue with foo.bar syntax. The problem is that putting
foo.bar in Parenscript (as opposed to outside the PS compiler) fails
in the presence of symbol macros for either foo or bar. Even ignoring
other possible undesirable consequences, this makes it a big pain to
implement 'let' with real lexical scoping efficiently or readably, and
makes code inspection by conventional tools impossible. The whole
issue is centered around symbol identity and the abuse of symbol
names.

> Prefix syntax makes method calling a bit awkward and (.method ...)
> syntax makes method calls a bit more CLOSish in appearance. I am neutral
> on its value, but since parenscript has supported this for years and a
> lot of code is relying on it the cost of removing it is high.

The dot syntax is a design mistake that makes what should be trivial
code transformation hard. This has consequences for both the PS
compiler (keeping it would make it more complicated than it needs to
be) and just as importantly as for the code being compiled. If someone
wants to upgrade their project to use the latest version of
Parenscript, I think it's ok to ask them to fix what are essentially
bugs in their code. The only regrettable thing is that these bugs were
encouraged by previous versions of Parenscript as desirable
programming style.

Vladimir