Subject: Re: Lisp source code as lists (rather than something richer)
From: Erik Naggum <erik@naggum.no>
Date: 1998/12/09
Newsgroups: comp.lang.lisp
Message-ID: <3122163252938555@naggum.no>

* Tim Bradshaw <tfb@aiai.ed.ac.uk>
| But lists are kind of the minimal sufficient structure for this -- it's
| seemed to me for a long time that it would really be better to represent
| your source code as something richer, so you might have `blocks' and
| `function-calls' or something, and these would be real data types in the
| language (and you'd be able to say (function-call-operator ...)).  You'd
| still have macros, but these would work as transformations on these data
| types in a more object-oriented way.  (Perhaps Dylan does this?).

  this is actually what SGML does.  SGML has "named parentheses".  think
  about it.  it is a monumentally wrong way to go.

| That seemed to me like a generally much more modern way of doing things,
| since it has a richer set of types.  It would make things like code
| walkers much easier, and you could probably share these types with the
| compiler too, so that would be a win perhaps.

  yup.  all the good old SGML propaganda comes back to life with this one.

| But I think I was wrong.

  yup.  and your argumentation is very close to what I used when I finally
  made up my mind that SGML would be way too costly to ever give any return
  on investment, either mine or in general.  sadly, I haven't seen any hard
  evidence that I'm wrong yet.

| The problem with having this whole bestiary of sorts-of-things-in-the-
| -language is that once you've defined them, then you've defined what
| sorts of things you can have in the language.  And you might be wrong,
| because there might be other sorts of things that you can have in the
| language, or in some extension of it, which you haven't thought of yet,
| and which it would now be hard to even conceive of.  So although
| everything would be nicer in the short term, you have really limited the
| way the language can develop because you've limited the sorts of macros
| that can be written.

  yup.  very good.  you have argued excellently against SGML's DTD concept
  without (I hope!) having suffered the pain of dealing with updates and
  changing requirements.

  incidentally, HTML "solved" this problem by requiring unknown elements
  (that's what the stuff with start-tag, contents, and end-tags is actually
  called) should cause the contents to be in-lined in the containing
  element, recursively.  this, of course, was the single most idiotic thing
  HTML could ever have done.  that _one_ decision led to the decision to
  use _comments_ for script languages, because there was no way to say "if
  you don't now this element, ignore it" -- there could have been, but they
  blew that chance, and that comments were such a crummy place to put
  things led to all kinds of other mind-bogglingly stupid ideas, like CSS.

  if you need an example of how horrible a language that names all it
  substructure components would be, take a good long look at SGML and HTML
  and XML, especially at how they are actually used in real life.  I trust
  I don't need to tell you to go away and never look back.

[ explanation elided ]
| Does that seem reasonable?

  yup.  sure does to me.

#:Erik
-- 
  The Microsoft Dating Program -- where do you want to crash tonight?