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

RT Happe rthappe@web.de
Tue, 4 Mar 2003 22:19:59 +0100 (CET)


On Tue, 4 Mar 2003, Mark Phillips wrote:

> 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

Being fairly incompetent and inexperienced, I'd better keep my thoughts to
myself.  (First principles aren't a good sybstitute for experience.)
Briefly, I believe a syntactically extensible language featuring
static analysis (type inference and all that) would be feasible and useful,
but more likely descend from Scheme than from Clean.  E.g. I heard PLT
Scheme offers ``soft typers'' as analytic tools (but wisely keeps the
runtime type information, I suppose).

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

If your goal is manipulation of (textual) Clean programs (rather than
extending Clean), a library implementing abstract data types (`module',
`type declaration', `start graph', ...) with the necessary host of
operations (read/write program, match terms, ...) would do the job, too.
[ Prolog is very much like Lisp w.r.t. the relation of source code and
data.  In particular, Prolog represents facts and rules (subprograms) by
Prolog structures aka terms.  Its descendant Goedel takes the ADT approach
instead:  it offers library modules for converting the textual form of
programs into/from the opaque representation, and for operating on the
representants. ]

rthappe

PS on the merits of syntactic extensibility

Those who wonder when and why powerful macros may be useful may want to
have a look at some examples:

  Simple but non-trivial examples from the ``Scheme Requests for
  Implementation''     http://srfi.schemers.org/final-srfis.html
  SRFI 2 -- AND-LET*: an AND with local bindings (...)
  SRFI 5 -- A compatible let form with signatures and rest arguments
  SRFI 9 -- Defining Record Types

  The Scheme Shell, a Unix shell embedded in Scheme, makes heavy use of
  macros (process forms, awk special form, ...), but typically provides
  both the procedural substrate and the convenient macroidal interface
  built on top.  The reference manual and the design paper are in the
  [docu] section of  http://www.scsh.net/.

  Paul Graham -- On Lisp;  http://www.paulgraham.com/onlisp.html
    preaches and demonstrates the ``bottom-up'' way of evolving the
  language towards the application;  a bit over the top at times.

  On ``metalinguistic abstraction'' in general (with the help of
  interpreters here, not macros):
  Abelson/Sussman -- Structure and Interpretation of Computer Programs
  http://mitpress.mit.edu/sicp/
  http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html#%_chap_4