This is a subject that keeps coming up over the years in the Dylan community (and why, in part, Mikel is slowly working on an s-expression reader for the curren

This is a subject that keeps coming up over the years in the Dylan community (and why, in part, Mikel is slowly working on an s-expression reader for the current compiler). It is impossible to know what might have happened if Dylan had kept the s-expression syntax and how that syntax might have evolved. When the switch was made, the language didn't have all of the features that it soon had in the infix syntax. The macro system is just a single example of this. (And Dylan was one of, if not, the first infix language to have a macro system like it does. See http://people.csail.mit.edu/jrb/Projects/dexprs.pdf http://people.csail.mit.edu/jrb/Projects/dexprs.pdf for a discussion of it and some extensions.) In the s-expression syntax, you defined a new method by: (define-method odd? ...) In the infix syntax, you do: define method odd? ... ... end; However, you can supply adjectives as well, which weren't present in the s-expression syntax: define sealed inline method odd? ... ... end; Personally, I don't really care if I'm using the infix syntax or an updated form of the s-expression syntax. But to deal with the features present in the infix syntax, it would have to be a somewhat modified version of the old s-expression syntax. Given the history of the last 20+ years since Dylan was created, there are a lot of other things that could've been done differently in the syntax as well: * Something more terse and compact. * Not requiring semicolons. * Using braces or whitespace instead of 'end' statements. * Stuck with s-expressions since Lisp is more acceptable today (ala Clojure). * <Your bikeshed here.> One of the Dylan designers, David Moon, went on design (but not implement) a new language with some differing takes on the syntax: http://users.rcn.com/david-moon/PLOT3/ http://users.rcn.com/david-moon/PLOT3/ ... it is interesting, but without an implementation. There's also the question of whether Dylan failed due to the syntax. There were a lot of factors that led to Dylan not seeing the adoption that was desired: * Java was a big factor. * The financial troubles at Apple. * The collapse of Harlequin. Harlequin had an implementation of Dylan that lives on today as Open Dylan, but had a very advanced IDE on Windows and a pretty solid foundation. * The business model of Harlequin. Harlequin sold expensive commercial development tools. Lispworks lives on with that business model, but it can't be said to be a massive success. * The team at CMU switched to Java and away from their Gwydion Dylan implementation. (This was partly due to research dollars.) And the failings of the Apple Dylan product itself didn't help. It was late to market, buggy, slow, and lacked PowerPC support in the initial release. Much of the above wasn't due to or related to the syntax. Yet despite all of that, Dylan still has a special place in my heart and that of many others. We've put out new releases, fixed a lot of bugs, improved platform portability and more in the last few years. Now we're looking towards the future and considering potentially larger changes.