[parenscript-devel] New Parenscript release.

[Clinton Ebadi]

Vladimir Sedach <vsedach at gmail.com> writes:

> Hi Clinton,
>
> As I posted previously, I'm strongly opposed to the presence of dot
> syntax in Parenscript. If UCW really needs the dot syntax (I don't see
> any reason for that, but that's a UCW issue), you are better off
> writing a code-walker that would do the dot transformation on the
> symbols it encounters, rather than forking Parenscript.

Your changes break all extant parenscript code. Parenscript has been
around for four years and been stable for almost as long; it is not ok
to break compatibility in mature libraries without either a new major
version or name.

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.

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).

>> ((slot-value list 'push) new-element) is not Common Lisp. If anything it
>> should be (funcall (slot-value list 'push) new-element)
>
> Funcall is already there; I'm going to take this as a vote to remove
> the Scheme-like function calling convention (I also think it's a good
> idea).

Why? Javascript has more in common with Scheme than Common Lisp and the
((...) ...)  syntax maps onto js syntax that is perfectly acceptable. A
(contrived) example:

  (defun make-adder (x)
   (return (lambda (y) 
            (return (+ x y)))))
  ((make-adder 3) 5)

Requiring `funcall' would artificially restrict parenscript syntax. If
anything having `funcall' at all is harmful; Javascript has a unified
variable and function namespace so it serves no purpose.

>> I'm not sure that (slot-value ...) is even a good idea, because
>> JavaScript's objects can have new slots added willy nilly.
>>
>> How about two new forms? One for the current use of
>> slot-value, and one for method calls?
>
> Something like slot-value is needed (see below about @), but why is
> everyone obsessing about special syntax for method calls? JavaScript
> does not have any special syntax for method calls aside from the
> arglist curly braces (which is just the JS equivalent of funcall).

@ would be an acceptable special form for method calling, but I think
the `chain' macro is closer to what it should do (I don't see much of an
advantage to merging foo.bar/foo[bar] syntax; breakout to an explicit
(slot-value ...) or (aref ...) when foo[bar] is desired is not an
onerous burden when weighed against making all chained method calls more
awkward).

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.

>> Someone suggested using @ for method calls. Is that available already?
>
> Yes. I'm going to interpret this as a vote to remove 'slot-value' and
> keep just the '@' because 'slot-value' does not behave anything like
> its CL equivalent. I think this idea has some merit.

Parenscriot `slot-value' performs more or less identically to Lisp
`slot-value' -- if CLOS were prototype based. Javascript objects are not
Lisp objects and people writing parenscript should know that. Personally
I'd rename `slot-value' to `slot-ref', but this is just an aesthetic
issue (breaking compatibility being undesirable as I mentioned before).

-- 
<Morty_md> My mind boggled.
* tim_m shakes morty's mind, hoping for a different combination of letters
<Morty_md> Sometimes my mind yahtzees instead.