[Openmcl-devel] ccl manual (was Re: trace on recursive functions)
ralex at cs.colorado.edu
Sat Dec 12 08:11:12 PST 2009
Sorry, but I will have to disagree. Sanity, or personal preference, is one thing - I think few people actually love xml - but for each person capable to write a woking s-expression there are 1,000,000 able to write a working HTML/XML expression. The market has spoken.
I do not know what the fear of xml in Lisp users is ultimately based on but independent of personal preference I can tell you that the use of s-expressions as some kind of meta language was not working all that well for regular computer users as well as lisp programmers. Don't get me wrong. S-expressions, when they stand for executable code, e.g, a Lisp function are a wonderful thing. But when you make some kind of meta language such as this:
:track-mouse t :title "Objects" :margin 0
(:agent-3d-view :name "scene"
(:cube :texture "crate.png")
(:sphere :x 2.0)
(:sphere :x 3.0 :texture "earth.png")
(:cube :size 3.0 :z -3.5 :texture "crate.png")
(:cube :x 5 :roll 45.0)
(:sky-dome :pitch 90)))
You set yourself up for tricky interpretation questions. This may seem perfectly clear to you but our experience was that non-lisp and even some lisp programmer really had a hard time writing these kind of expressions. In Lisp the interpretation of these kinds of forms, even at a syntactic level is highly ambiguous: does the first element need to be a :colon thing, are parameters evaluated (they could be), are there some characters that are not allowed, can I use unicode, .... There are many "constraints" in XML that come in quite handy to at least make the syntax of XML pretty well defined where as in s-expressions just about anything goes as long a the Lisp reader can handle it. At the end of the day this more relaxed syntactic interpretation is not helping. On the other hand, teaching game design to middle school kids, I find that many 11 year old kids have no problem writing correct XML expressions.
Now we could engage into a long and highly opinionated discussion. I prefer not to. My only point is that concrete empirical evidence suggest that s-expressions are NOT a good way to capture end-user data in spite of what most Lisp programmers appear to believe. Many argue that the beauty of s-expression as data is how simple it is to process it in Lisp, and of course this is true. But again, while this is great to the lisp programmer it is of little concern to the end-users.
At any rate before you flame me with arguments on why xml is so terrible or s-expressions are so great have a look at x-expressions: http://www.cs.colorado.edu/~ralex/papers/PDF/X-expressions.pdf
The philosophy was to simple make the best out of XML in Lisp by unifying s-expressions and markup. This was not the result of our great love for xml but based on the realization that perhaps Common Lisp with it amazing power including MOP, readers and object printers, could be the ONE programming language that most elegantly deals with XML by allowing its programmers to focus on Lisp/CLOS while making the entire XML i/o an almost automagical side effect that you don't have to care for if you don't want to.
On Dec 11, 2009, at 7:36 PM, Ron Garret wrote:
> I can't stand it any more.
> There's a technology called S-expressions you might want to look into. S-expressions are kind of like XML, but with a much saner syntax. You don't have to manually match up your end tags, which makes S-expressions much easier to compose and to read than XML. There are a lot of tools for manipulating S-expressions, including an editor called Emacs, and another one called Hemlock. It is borderline trivial to transform S-expressions into XML, or any other format you like. S-expressions have even been used as the base syntax for a full-featured programming language called Lisp. If you haven't looked at it you really should. It's quite nifty.
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel