Why not LISP (was: HLL and misa)

[Francois-Rene Rideau]

>>    Now there's the problem of reflectivity:
>> LISP is great because of it's easy reflective nature;
>> meta-programs are easily done in LISP. But people take for granted
>> the trivial implementation of this reflectivity, and there it hurts:
>> people assume too much about it, and their programs become too low-level,
>> too little portable or efficiently compilable/adaptable/translatable.
> 
> it would seem however, that languages that make use of a hierarchical 
> system of class construction would group linked lists together with 
> arrays, etc under an abstract type called sequences.  that would 
> obviously fall under a more abstract class like 'collection'.  if the 
> accessors were written for those more abstract classes and were inherited 
> by linked lists, etc, would that not allow linked lists, etc to be used 
> at whatever level?  i'm refering to hierarchies starting with smalltalk 
> but there are many others.
   I never was in favor of class "hierarchies". I think I already expressed
how I despise inheritance, but as a clever implementation hack for some
voluntarily restricted programs. Now, this seems another question to me.
I was talking about reflectivity; hierarchies needn't reflectivity to
exist, as shows lame C++.

> 	I was arguing that these heirarchies need to be based more on 
> behavioral, not structural, relationships.
   Exactly. But then, they are not hierarchies anymore: they are sets
of algebras with morphisms in between.


>>    What we need is higher-order use of constructors/deconstructors.
> right


>>    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.


>>    To conclude, I see really no advantage in the s-exps.
>> I quite prefer letting the user be free of the syntax he uses,
>> arbitrarily connecting syntax from semantics.
>
> although this is a different topic from the one i was talking about 
> above, i would like to speak for s-expr (perhaps in the minority)
>
> 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, 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).


> 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 ?


> this means that s-expr can be stored as objects and therefore source code 
> is stored as objects for which routines can be used to inspect and 
> modify, a much more abstract and manipulatible medium than text streams.
   Yes, but one needn't s-exps to do that; s-exps are only a possible
low-level representation for it; if you specify that it will be done that
way, you'll be stuck whenever you want to have another representation
more suited to your needs.


> 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).


> 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.


--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"