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

[Jerzy Karczmarczuk]

Mark Phillips wrote:


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

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

Don't forget that modern Lisp and Scheme implementations *compile*
their stuff. You are *not* speaking about the actual executable
code, but about the *code source*, which for historical reasons
is list based.
True, in Lisp/Scheme you can easily write very powerful macros
which transform the source code before compilation. This makes
the language extensible: without changing the superficial syntax
it is possible to write very complicated constructions.

All that is possible only in an interpreted environment, or if
a compiled program includes some substantial part of the compiler.
It is possible with some versions of Scheme, but I cannot imagine
the same simply done with Haskell or Clean.

Clean and Haskell (and many other languages) have chosen a different
conceptual approach, calling it "step backward" is not rational,
actually for the last 15 years at least, I have never heard this
claim from somebody *serious* (OK, let me keep my definition who
is and who isn't serious...)

We have pattern matching. We have strong typing. The last point
means that if you wanted to be able to produce via macros a new
code during the execution of the original, *your program* should
include the type checker! In these languages there is a global
analysis stage during the compilation, in Lisp this is absent.


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

I am not a language developer, just a user and a teacher. So,
my answer should be completed by those who are 'insiders'. Still,
I don't believe that in general those 'facilities' would do
much good. What do you *REALLY* want? Give some examples. Do
you want self-modifying codes? It was possible in Snobol. People
were abhorred by it, the resulting programs were extremely
difficult to debug. "Potentially more efficient" code? How?
The abstractions such as closure construction are there already,
and the efficiency of *lazy* programs is a very, very complex
problem, needing a lot of global analysis.

You mention that Clean is based on the graph reduction
techniques. This - as far as I understand - is far from trying
to give to the user program the possibility to tinker with
the compiled code. It is far less readable than assembler...

Well, my three euro-cents...


Jerzy Karczmarczuk
Caen, France