[clean-list] "code is data" and Clean

[Marco Kesseler]

>Hi,
>
>One of the key advantages of LISP (as far as I can tell) is
>that its relatively simple (yet powerful) syntax means that
>LISP _code_ looks just like the _data_ it works on.  Because
>of this, it is possible to manipulate LISP code in the same
>way, using the same powerful functions, that are used with
>data.  This ability enables one to write even more powerful
>functions, and potentially more efficient ones.
>
>In LISP, code is just lists inside lists (a tree-like 
>structure).  Because of the simple (yet flexible) syntax
>for code, it makes writing code-manipulating functions quite
>easy to do.  LISP proponents seem to argue that newer functional
>languages (like Haskell and Clean etc) are actually a step 
>backwards because - with their more convoluted syntax - they've
>thrown away the ability to easily write code-manipulating-code.

First of all: forgive me any misconceptions I might have about LISP. 
I know about LISP (syntax and semantics) and have read articles about 
it, but I have never used it for programming. Nevertheless:

I think that some Clean proponents would argue that code manipulation 
is "not done". They would consider the need to do such a thing to be 
a weakness in a programming language like Clean. Not to say that LISP 
is "weak". Clean and LISP are strong in different areas, just like 
Perl and C are. Or Java and C++ for that matter.  Things to consider:

- There is little need to rewrite code in order to arrive at powerful 
functions. You can write powerful functions directly in Clean. The 
fact that this is highly appreciated in LISP does rather (in my 
humble opinion) demonstrate some sort of weakness in LISP's simple 
syntax.

- Clean does not interpret expressions. It compiles them. And Clean 
is a strongly typed language. This means that many errors are caught 
at compile-time. In this respect Clean's design philosophy is 
fundamentally different from LISP's. 

- Clean has no standard "eval"-like function that interprets and 
evaluates some piece of data. So it is not _merely_ a matter of 
matching function syntax and data syntax. One could however, easily 
write an interpreter for any LISP-like (or Clean-like) language in 
Clean as well (but also see the next points, before you argue that 
this is not quite what LISP offers).

- Rewriting expressions for the sake of efficiency is rather 
considered a task of the compiler. It is true that some of this is 
still somewhat a promise. I think that Clean (as Haskell) could do 
with better forms of compile-time evaluation of expressions (but that 
is being worked on as far as I know). Ultimately, optimising an 
interpreter for a given input program would deliver a compiled 
version of that program. Whether that goal is close is an entirely 
different matter.

- I think that Clean would come closer to LISP if it started to 
incorporate some form of runtime (re)compilation of expressions. This 
seems somewhat related to the current efforts that are put in Dynamic 
types (also in the sense that the runtime infrastructure is getting 
into place). But note that just as the use of Dynamic types may 
introduce runtime typing errors, the use of runtime compilation would 
introduce runtime compiler errors, which seems somewhat opposite to 
catching errors as early as possible.

>What I would like to know from the clean community (and perhaps
>developers) is: how much validity is there to this point?
>
>Is it a case of "Clean has thrown away the ability to easily
>write code manipulating code in exchange for some other goodies
>which we value more".  If so, what are these other goodies and
>why are they worth more than code-manipulating-code ability.

Personally, I am not sure I would call runtime code manipulation a 
"goody".

>But I wonder whether Clean really has thrown away the code
>manipulating code capability.  I have never programmed in
>Clean (I've used Haskell), but I did read something about
>Clean working with "computational graphs" or something like
>that.  Ie, where LISP works with code as hierachical lists of
>lists (ie a tree), does Clean work with code as a graph?  In
>which case Clean is potentially more powerful (and more
>computationally efficient) in this regard than LISP!!  Because
>trees are a special case of a graph, and what's more, a tree
>with "isomorphic sub-trees" can sometimes be expressed more
>succinctly as a graph.

Clean uses graph rewriting internally for its implementation, and its 
semantics are defined in terms of graph-rewriting. Clean's syntax is 
not. So Clean rewrite  expressions aren't graphs. They are rules for 
manipulating them. And as such, they cannot manipulate themselves.

>Well, I don't know Clean (or LISP) well enough to be able to
>discern whether my ideas are on the right track or not.  Any
>assistance with my thinking would be greatly appreciated.

I hope this helps (and makes sense).

regards,
Marco