s-expressions and XML was Re: terra incognita
David Brownell wrote: > > > > At the end of the day code and data just aren't that much > > > > like each other. Maybe this is why Lisp never took over the > > > > world, cool though it is. -Tim > > Personally, I think the deal with LISP was that it's a bit too advanced > a programming language for most folk. Plus it was never pitched > for commercial applications -- it was aimed at folk who really didn't > have an issue with syntax, and whose problems didn't revolve around > databases and report generation. Even the M-expression notation > didn't get around that. There are many similarities between LISP and XSLT, excepting of course that XML et al. have been solidly backed by commercial folk, at least that is the claim. Perhaps the differences are more to do with marketing than technology. Regarding objects vs. data (which is where we started), the prime distinction is between opacity and translucency. When objects are well described, and their state can be described by the getter setter properties in their interfaces, as data objects they can be translucent. Object _methods_ however are generally opaque -- the implementation hides behind an interface. Contrast LISP and XSLT, whose method implementations can be fired across the wire (in a perfect world) for remote execution. It should not be lost, however, that java bytecode can similarly be treated as data. I am sure that Guy Steele is well aware of these issues. > > > > > It is very interesting that you say this. I've seen a few people > > > from the Lisp camp complain that XML is simply a more verbose > > > yet less powerful reinvention of Lisp S-expressions with a lot of > > > extra complexity added in (like namespaces, attributes and entity > > > references). [Dale Obasanjo ] this is somewhat true. If XML/SGML hadn't attributes one could simply replace: <foo> <bar/> <baz/> <bop> <bing/> </bop> </foo> with the s-expression (granted there are a couple of ways to do this): (foo bar baz (bop bing)) XML might be more generally represented using something akin to an s-expression notation by introducing delimeters for an unordered set '[' and ']' and then we can represent: <foo aaa="111" bbb="222" ccc="333"> <bar ddd="444"/> <baz/> <bop eee="555"> <bing/> </bop> </foo> as: (foo [aaa="111" bbb="222" ccc="333"] (bar [ddd="444"]) baz (bop [eee="555"] bing ) ) and we see that XML starts to look not so verbose after all. (this is my standard argument to LISP folk) > > > > You have to take that with a grain of salt though. > > There are folks in the Lisp camp who say that about > > *every* new programming technology. "What's the big > > deal about X? It's just a poorly reinvented version > > of feature Y in Common Lisp." [Joe English] > > Those criticisms (less powerful, more verbose etc) have > more than a grain of truth to them though. > > Consider: send an S-Expression over TCP and (eval) ... > that's "write once, run everywhere" about 30 years before > certain marketroids decided it was a good idea. And > that's just one many examples ... :) exactly. but again, recall where Java comes from. what is interesting to me is whether XSLT is really the programming language we are all seeking, or whether we might [move on/go back] to (something like) DSSSL which is essentially the same thing in s-expression syntax. Jonathan
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format