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

[Mark Phillips]

Hi,

Thanks for your thoughtful comments.

> > 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
> 
> It's appropriate to look at the components of this advantage.  Some of
> these may be grafted on a modern functional language, or the effect may be
> achieved with other means.

Thanks for the analysis below.  I am curious about how you see
the programming language landscape however.  Do you think that
the approach of Clean is fundamentally incompatible with the
approach of Lisp, and the advantages of Clean (etc) outweigh
those of Lisp so we should use Clean (or Haskell etc) and
add on some of the extra functionality of Lisp as best we can?
Or perhaps you think the best of both worlds could have been
combined, but weren't, so let's add on extra functionality as
best we can?  Or perhaps your ideas are different from either
of these.  Just curious.

> (0) a simple syntax for textual representations of data
> (1) a corresponding and well-supported built-in data-type (trees,
>     basically)
> (2) i/o procedures translating the (textual) external into the (concrete)
>     internal representation and v.v.
> 
> (3) source code in the ``data-syntax'' from above
> (4) parse-trees represented --as far as the programmer is concerned-- by
>     the concrete data-type from above
> 
> (5) programmable syntax-extensions -- macros transforming the parse-tree
>     of the input form with the full force of the programming language
> 
> Items (0,1,2) are extremely useful, giving the principal advantage of XML
> without the pain.  And they aren't even incompatible with modernity,
> although Clean's type system would complicate things a bit.  This is
> mainly a question of library design.  (A prefab parser construction kit
> would help with (2).)
> 
> Items (3,4) ease meta-programming:  writing partial evaluators, debuggers,
> etc.  But that can be achieved with data abstraction (and perhaps less
> convenience), too, without exposing the concrete syntax of the language or
> the concrete data-type of the parse-tree.  The logic language Goedel went
> that way.

Could you please expand on what you mean by this - thanks.  Do you
feel the exposing of concrete syntax and parse-tree data-type is
not so important?

> Item (5) enables syntactic abstraction.  Macros are used to create special
> forms with a special evaluation rule (there's less need for that in a lazy
> language) and in general to embed problem-specific ``little languages''
> into the host programming language, i.e. Lisp.  This may be achieved with
> <input pattern> --> <output template> transformation rules (in the spirit
> of Scheme's SYNTAX-RULES) rather than with hand-coded expanders, but it
> will complicate the compilation process anyway.  (I don't believe that
> macros preclude global program analysis, though.)
> 
> rthappe
> 
> 
> 
> 
> _______________________________________________
> clean-list mailing list
> clean-list@cs.kun.nl
> http://www.cs.kun.nl/mailman/listinfo/clean-list

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup