Why not LISP (was: HLL and misa)

[Frank DiCostanzo]

On Mon, 19 Jun 1995, Francois-Rene Rideau wrote:

> > I agree and disagree.
> >[of use of different constructors for different structures...]
>    You seem to be reinventing *typed* lambda-calculus !!!

not reinventing, just supporting :)

>    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 was arguing that these heirarchies need to be based more on 
behavioral, not structural, relationships.


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

>    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.  this allows for 
things like lisps macro facility, etc in which the program can write code 
itself in a (fairly) easy and straightforward way.
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.
from a syntactical perspective, s-expr are far less likely to have syntax 
errors such as precedence errors.
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.

 Frank DiCostanzo
 frdF93@hamp.hampshire.edu

At the McDonalds restaurant I did write on the restroom wall,
  "For a good time call swell.hampshire.edu."
		- J.G.