Vladimir Sedach vsedach@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).