Traditionally, code walking has required ad hoc code to understand every “special form.” It is better to have a well-defined, object-oriented interface to the Abstract Syntax Tree, scopes, and definitions. This is why objects are better than S-expressions as a representation for program source code.
I have never heard anyone point to s-expressions as the reason code walkers are hard to write in Lisp (and they are, at least in CL).
This is true. But David Moon is fairly famous, having worked on Lisp, CLOS, Dylan (http://en.wikipedia.org/wiki/David_Moon) and he was immortalized in the hacker koan:
One day a student came to Moon and said, "I understand how to make a better garbage collector. We must keep a reference count of the pointers to each of the cons." Moon patiently told the student the following story:
"One day a student came to Moon and said, 'I understand how to make a better garbage collector...'"
So I'm inclined to give him the benefit of the doubt, at least for now. ;-)
Tietelman was also famous and ran his own Lisp machine company, InterLisp, and probably had wads of cash and the social clout to push whatever he wanted. His Lisp with English-like syntax had a Futile And Ill Life.
Norvig as pointed out that Python can end up looking like Lisp with the parenthesis replaced with indentations (http://norvig.com/python-lisp.html). I think this comes even closer.
CMU/Apple Dylan; they wasted a perfectly good CLOS successor and a kickass user-interface framework not to mention a great type-system, on a non-Lisp syntax. The rest, as they say, was history. An obscure and long forgotten history.
I think the real problem is that people who understand Lisp understand that Lisp programs are Lisp data structures, and want them to look that way. People who don't get it won't be drawn to the language for its unconventional object system or condition handling. People who are won't be scared off by unconventional syntax.
I don't understand why they'd throw up everything in the air just because they screwed up the syntax. Wouldn't it have been easy to make a proper s-expression front-end to the environment and keep the rest of the good stuff?
Dylan started with an s-expression syntax. For several years, it looked like Scheme with CLOS bolted on top. The language eventually switched to a conventional infix notation. It actually looks pretty good to my s-expression-addled eyes, except that "end" blocks explicitly describe the block being ended, e.g., "end if", "end class", "end function". (To any Dylan experts in the audience: if that's optional, feel free to correct me.)
Dylan has not exactly failed, since it still has an active development team which makes regular releases, but it has not achieved popularity. Dylan has macros, a real condition system, and a CLOS-type object system --- a way better feature list than Ruby's or Python's, IMO.
"There are two special considerations for newlines in the syntax. The purpose of this is to allow nesting structure to be indicated by indentation rather than by any kind of explicit bracketing."
Is there an implementation available anywhere to play with? Or is this still in the design and discussion phase? I'd love to play around with this, it seems like a clear, solid distillation of a lot of ideas.
When David presented this during the ILC last week at MIT, he said this is simply a hobby and experiment and that he doesn't have plans to release an implementation.
He also said that if someone wants to implement it, they should. He just doesn't want to be that someone, since he can't spend enough time on it to get it right.
Traditionally, code walking has required ad hoc code to understand every “special form.” It is better to have a well-defined, object-oriented interface to the Abstract Syntax Tree, scopes, and definitions. This is why objects are better than S-expressions as a representation for program source code.
I have never heard anyone point to s-expressions as the reason code walkers are hard to write in Lisp (and they are, at least in CL).