some more about Re: Why not LISP (was: HLL and misa)

[Frank DiCostanzo]

On Tue, 20 Jun 1995, Francois-Rene Rideau wrote:

[philosophical differences on reflectivity and hierarchical class 
organization deleted]
 > 
> >>    A very *bad* thing about s-exps is higher-order extensibility:
> >> if semantics is expressed from a low-level implementation this way, it means
> >> the semantics cannot be dynamically extended. Because TUNES objects get
> >> migrated from worlds to worlds, and can be considered in completely
> >> different contexts, this cannot be in the TUNES HLL.
> > 
> > why can't symantics be extended? perhaps i don't understand this part...
> > what is so low level about a list of symbols? in my mind it is one of the 
> > more abstract of constructs.
>    Because its being a list of symbol is a structural, not semantical,
> property, and as you said earlier, objects shouldn't be classified according
> to such structures, but to their semantics, you shouldn't use lists of
> symbols as such. Now, even though these lists may be a convenient way to
> edit *some* aspect of objects, their being a low-level representation
> means that extending the semantics of the considered objects won't be
> possible while keeping this representation.
> 

are we talking about the same thing? when i talk about s-expr i am
refering to their use to describe language constructs like let, if, 
function calls, etc.  NOT to describe how objects in general should be 
stored in memory, etc.  Obviously, objects in memory should be stored in 
some abstract and black box method and i would never suggest that lists 
are the best representation for that, much less one proscribed by any 
language definition.

> > the biggest advantage as i see it to s-expr is that they can be 
> > represented in a way that the computer can manipulate.
>    You're talking about low-level data representation
nope,nope,nope

> , which is fairly
> independent from both syntax and semantics. While I agree such structure
> can be used and is simple to implement (though I'm sure it's not the best
> if you have human time and computer space available), I see no point at
> forcing human beings to use s-exps (but for preliminary testing).

granted, as a matter of taste, s-expr as a language syntax is not for all. 
i also completely agree that implementation complexity should be one of
the lowest considerations when evaluating a system (ignoring that rule
created UNIX!).  so when i refer to it being easy to manipulate, i am
thinking that it is easier for the human to instruct the computer about
how it should be manipulated. i find that dealing with lists (the concept
of an ordered set of symbols - not the idea of linked nodes) to be 
conceptually pleasant.

> > this allows for 
> > things like lisps macro facility, etc in which the program can write code 
> > itself in a (fairly) easy and straightforward way.
>    Macros and extensions to a language's grammar can be done not only in
> Lisp. Why restrict to s-exp ?

i see no restriction to s-expr... however it certainly, as i mentioned above,
is a great deal easier for the programmer to extend to language in complex
ways.  i would like to know of another language that would allow me to
write programs that can extend the language interactively with the
compiler, within the same environment, and not use s-expr.  in lisp, i can
add to the compiler itself to dynamically alter and add to the language 
using the full power of the language to do so.  sorry for the 
evangilizing but i just don't see how that could be done using an 
arbitrary syntax (perhaps i don't need to know)

> > from a syntactical perspective, s-expr are far less likely to have syntax 
> > errors such as precedence errors.
>    I disagree. Without a s-exp structure editor, you do even more errors
> (try using lisp without emacs -- counting parentheses). What people need is
> structure-aware editors, not s-exps. Such editors can be much nicer
> than just parenthesis matchers (for instance, with types, much more can
> be taken into account than with the finite LISP type system).

i agree that a good structural editor would be damn spiffy.  however the
errors i had in mind could not really be caught by such a editor.  i
misnamed them when i said syntax errors, because these errors can be
perfectly legal - i'm thinking about errors due to precedence such as * vs
+ and other operators where the programmer has to remember what happens
first..  these kind of syntacically correct errors are the thing that
cause me the most grief.

> > lastly, i feel that it would be a relatively trivial operation to 
> > generate a parser that produced s-expr allowing someone to place any 
> > syntax they wanted on top of them, using the s-expr as a simple,
> > consistent base.
>    Again, its being some simple implementation doesn't make it a good choice
> as a high-level specification. On the contrary, its being an implementation
> issue makes it a *very bad* choice as a high-level specification.

again, agree about the implementation thing but thats not what i had in 
mind. i was suggesting that the parser could be part of the language.  
this would allow individuals to create their own syntaxes. as long as 
the grammer were around to reflect on the syntax, that language would be 
fully portable and integratable with eveyone elses syntax. that way, you 
can program with your syntax and i'll use s-expr :)

frank

p.s. i'm on the tunes list so replying to that alone will reach me and all 
the interested misa people- i got your response three times!