sexpressions, sexpr, sex!

[Frank DiCostanzo]

On Thu, 22 Jun 1995, Andrew Bromage wrote:

> Disclaimer: My opinion.

hmm, who elses would it be?
> 
> One thing that bugs me about s-expressions is that each cons cell has
> only two children.  Data usually comes in bigger chunks than that, so
> storing larger structures (which we will need) in an s-expression
> wastes memory needlessly.

ok, forget about cons cells. thats right, forget them.  when an sexpr is 
read in from, it can be placed in an array, a linked-list, a hash table, a 
tree, it doesn't matter. the only important thing is that at some 
abstract layer, you have a nestable sequence of symbols.  furthermore, they 
generally won't stay in that format at all but will be compiled into 
either machine code or some interpretive middle language.  sexpr is just 
a syntax, it has no semantic importance at all (give or take).

4 + 5

is semantically equivelent (or can be) to 

(+ 4 5)

i have noticed that symbolic expression languages tend towards being 
somewhat functional (vs procedural at least) but thats just because it 
seems more natural.

> (Question: Cons is the only primitive data constructor, right?  That's 
> if you don't count getprop and putprop.  I assume that this isn't just
> a Lispism because my version of Prolog (NU-Prolog) has these.)

are you talking about lisp? if so, no. that was the case at some point i 
believe but at this point there are structures, arrays, etc.

> 	- Too many parenthesis.  (I know, I know...)

completely valid argument. i find that most people dispise them at first but
but after awhile, grow to love them (cognitive dissonance at work? i 
don't know)

> 	- The cons operation is right-associative.  Being
> 	  brought up on lambda calculus-based languages, I
> 	  find this counter-intuitive.

if you view sexpr strictly as a sequence of symbols, then this is not an 
issue.  you can have (+ 4 5 6 7) work either (+ (+ (+ 4 5) 6) 7) or 
(+ 4 (+ 5 (+ 6 7))) depending purely upon how you write the + function.
 
> 	- The lack of infix and postfix operators.  Much
> 	  programming is mathematical, and so something that
> 	  looks more like mathematical notation makes sense.

agreed. no matter how much programming i do with sexpr i always have 
trouble putting in mathematical notation because i think about them 
inside out. a solution for lisp is to write a macro inside of which 
mathematical formulas are converted behind the scenes into sexpr so you 
could type in something like (where 'e' stands for 'expression'):
(e 6 + 7 - (t * 7))
but that still means you have to separate everything by spaces so that 
the symbol reader doesn't confuse things.  it would be a short project to 
modify the text reader to accept 'normal' notation within a form then you 
could just type
{6+7-(t*7)}
and having those braces around it is no more weird looking than some of 
the strange things one does in other languages (note: i'm being obscure 
here so as not to get flamed about a particular syntax)

> All-in-all, s-expressions _look_ like they were intended for machine
> consumption.

could be, could be. i think they were made that way because lisp was 
based on lambda function notation (i'm not totally sure but i think it 
was lambda calculus based.  i doubt common lisp has much to do with that 
anymore and i don't know a thing about elisp)

> Once again, I am fully prepared to be talked out of any/all of the
> above if necessary.

if someone is getting tired of this thread, they might say something and 
it could be brought off line


 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.