Re: ILC2005: McCarthy denounces Common Lisp, "Lisp", XML, and Rahul

Lars Brinkhoff <lars.spam@xxxxxxxxxx> writes:

>>>>> Peter Seibel <peter@xxxxxxxxxxxxxxx> writes:
>>>>>> Indeed, one of Baker's big points was that when the Lisp
>>>>>> community came to the fork in the road between Interlisp (with
>>>>>> it's structure editor) and Maclisp (with programs ultimately
>>>>>> stored as text in files), they made a mistake by taking the
>>>>>> Maclisp fork.
> [...]
> Peter Seibel <peter@xxxxxxxxxxxxxxx> writes:
>> Joe Marshall <prunesquallor@xxxxxxxxxxx> writes:
>>> On the other hand, I think that it would have been a better idea to
>>> store the structure in files rather than the text. The text should
>>> have been created on the fly for editing purposes.
>> Yes. I'm 100% with you there.
>
> However, is Common Lisp source code, especially with reader macros,
> compatible with structured source files? I've thought about this (for
> several minutes!), and it doesn't seem trivial.

It ought to be. Reader macros have to return objects (or nothing), so
going from text to structure should work if the text is syntactically
valid.

Going the other way might be an issue. When I write a reader macro
for special objects, I try to make sure that the print method for
those objects uses the reader macro. This won't work if the reader
macro returns list structure, though.

-----

In thinking about this more, I'm less sure of what the `right thing'
is. If we are going to store structured data in files, it has to have
some structured representation. A binary format like a fasl file is
easy to load, but not very portable, and you need a running lisp
system to make sense of it.

For a moment, let's pretend XML is useful. We could store structured
data serialized to XML. That would have the advantage of being both
portable and (somewhat) human readable. You could, in a pinch, edit
the structure with VI or Notepad. A validating parser could ensure
that the structure is correct before deserializing it. External tools
could manipulate the structure without interpreting it; for example,
you could use XSLT programs to do simple syntactic code
transformations like renaming identifiers. Enough fantasy. XML is a
bloated mess and a more readable and concise alternative is at hand:
s-expressions.

So Lisp text files already *are* structured. Since the structure
markup uses ascii characters, it is easy to edit the structure as text
without needing a Lisp system to intermediate. A validating parser
for s-expressions is easy to write, and some external tools (like
emacs) can manipulate the structure without interpreting it.

So what's wrong with the MacLisp approach?

~jrm




.

Relevant Pages

  • Re: DBMS and lisp, etc.
    ... boundaries in your system even if your crude backing store does not actually ... to toss out a real benefit of the DBMS and design around it at this point. ... structure and the simply "print" to save it, and then "read" to load it. ... you may want to look into some implementation specific bits of your Lisp, ...
    (comp.lang.lisp)
  • Re: Road to Clojure Survey
    ... self are reader macros. ... a lot of reader macros in lisp, then you can type lisp code as fast as ... yet his reader does not intern symbols. ... Reader macros are designed to build user level DSL. ...
    (comp.lang.lisp)
  • Re: APL-like operators defined in Lisp?
    ... Lisp begginer): ... (declare (ignore char)) ... Normally, reader macros should _read_, not compute. ... You can turn it any way you want, but lisp sexps are the best way to ...
    (comp.lang.lisp)
  • Re: PostLisp, a language experiment
    ... but Forth and Lisp are more fun to compare. ... > language (which, again, it tends to support, but is not geared toward ... Learning Scheme _and_ Lisp is of limited ... >> Forth macro is a reader macro, and reader macros in Forth are a lot ...
    (comp.lang.lisp)
  • Re: LISP & "The Art of Unix Programming"
    ... > have accessible state, the programs simply store it and let the individual ... > dictated by the Unix environment. ... The situation would be different if the lisp images were ... permament store. ...
    (comp.lang.lisp)