in reply to Representing all data as Lists (Perl7?)

I think you are mistaken about Lisp.

While this may not be true for the very first versions of lisp, data in current lisp systems aren't all represented as lists. It's source code that's written as only lists. Actual aggregate data can be lists, vectors, functions, strings, structures, hash tables, and lots of other things.

There are such simplistic languages where most things are of the same type: LOGO has lists only (even functions are lists); most shells have strings only (this is not exactly true, bash can have integers and sparse arrays too); and I don't want to say anything wrong about TCL, awk or sed. These are not powerful languages. (Let's not mention obfu-languages like BF, unlambda, befunge etc, each of which have only one type of data.)

Update: I must admit that Mathematica is somewhat close to your description: every kind of data appear as an array (but not a list; and strings, bigfloats, bigrats, bigints, complex numbers, symbols etc are real atoms, one can only go so far). (Some arrays are internally stored in a compact form though, although they appear to be normal arrays.) This is advanatgeous for a symbolic algebra system, as the pattern matching rules can be simple and fast, and expressions can be transformed dynamically. Also, being a symbolic algebra system implies that the boundary between code and data is not very clear, and this can be made easier with this uniform representation of all data (and code). To some amount, the same is true to Maxima, which is incidentally written in lisp.

Note however, that this is not neccessarily true for all symbolic algebra systems. Maple, for example, has various types of compound expressions, including wierd double arrays for sums and products.

  • Comment on Re: Representing all data as Lists (Perl7?)