# [repost] *** [was Re: [stack] Digest Number 28]

## Louis Madon — 2000-06-07 21:49:39

    [I originally posted this yesterday but it doesn't appear to have gone

    through. I apologize if anyone is seeing this for the second time].

    Hello all,

    I just discovered the list. Its nice to see that Joy seems to be of

    interest to a number of people. I've also

    been inspired by Joy and have in fact been working on a Joy

    implementation for some time now.  Anyway, I'll just jump

    into the current discussion with my 2 cents ...

     > From: Mark van Gulik [mailto:ghoul6@h...]

    > > wtanksley@b... said:

    > > Forth includes a different construct which is useful for forming other

    > > languages: the ability for a word to parse ahead of itself in the source

    > > where it occurs.  This ability is unique to concatenative languages (it's

    > > completely unresonable in a language which has to be parsed before it's

    > > executed).

    >

    > This may be true at the moment, but my short term plans (within the next

    > year or so) for Avail involve something similar.  In order to allow

    > arbitrary language syntaxes to be supported directly in Avail, I want to

    > support an unusual implementation of macros.  Like the (multi)methods of

    > Avail, these constructs will be strongly typed.  The difference is that

    > instead of taking values as arguments at runtime, the macros take parse

    > trees at compile time.  It will be horrendously difficult to get the parser

    > to work this way (although the current parser was already horrendously

    > difficult to write).

    >

    > [..]

     Do you really think that having a totally extensible language syntax is

    a Good Thing? It adds a lot of conceptual mass to the language

    (syntactic macro systems tend to be complex) and it makes the

    distinction between core syntax and extended syntax blurry.  If I really

    needed to embed another language I would rather just parse strings, eg:

      "For x in <10,20,30> do Print x;" mylang_call

      => 10 20 30

    Here, the mylang_call function takes a string, compiles it into a

    program and executes it. There is a clear separation between the core

    language and the embedded syntax thanks to the quotes. Moreover, at

    least in my version of Joy which will support partial evaluation, the

    mylang_call function will get executed at compile time since all its

    inputs are available; so there is no additional runtime cost.

     > > Why not?  You don't even have to use the list operators if you don't want

    > > to.

    >

    > Yes, but can one then *implement* some list-processing program without using

    > a built-in notion of lists?  In Smalltalk I would say yes.  In Joy, I think

    > the answer is no.

     But Smalltalk has a built-in notion of objects which are at least as

    complex as lists so thats not a fair comparison. In any language you

    need some kind of association primitive. For example pairs, pointers,

    closures, lists or objects. Moreover, once you have any one of these as

    a primitive, you then have a basis for constructing any other kind of

    aggregate type.

    Having said that, I do believe that Joy implements too much at the

    primitive level (lists, sets, strings, etc) though. In my Joy-like

    language, the fundamental association primitive is the dynamic function

    (aka updatable, variable or mutable functions, a notion from Abstract

    State Machine

    theory - see http://www.eecs.umich.edu/gasm and in particular take a

    look at Martin Odersky's paper "Programming with variable functions" at

    http://www.eecs.umich.edu/gasm/papers.html#varfun).

    Joy already has functions ofcourse and as such there is already a way of

    doing association: from inputs to outputs (ie. a function is a map). The

    catch is that the association is static so therefore you can't build

    aggregates incrementally. A dynamic function solves this by allowing

    updates at points in its domain (ie. a mutable map). In fact, not only

    does this solve the association problem, but it provides an elegant way

    to introduce stateful computation into a functional language (there is

    already a derivative of Haskell that does this - see

    http://www.uni-ulm.de/~s_jschmi/AsmGofer).

     > >>Since "meta" in this context means "unusual" or

    > >>"atypical" (often with

    > >>circularity as the triggering criterion), is it "a good thing" for a

    > >>language to rely on metaprogramming for the simplest of tasks?

    > >

    > > "meta" has never, to my knowledge, meant that.  "meta" means "above" or

    > > "beyond".  When you metaprogram, you're writing programs which manipulate

    > > and create other programs.

    >

    > Actually, the boundary of metaprogramming is very fuzzy.  Metaprogramming

    > can mean writing programs that (1) create programs, (2) look at other

    > programs as data, (3) look at types as data, (4) look at variables as

    > objects, (5) look at running processes and coroutines as data, (6) allow

    > extension of base syntax via macros, (7) provide tools to reason about

    > programs.

    >

    > You may disagree that some of these uses of the term are truly

    > metaprogramming, but I'm sure some of them take you a while to classify.

    > That's an indication of a fuzzy boundary.  In your description of

    > metaprogramming as "...writing programswhich manipulate...other programs",

    > the circularity I mentioned is obvious, but sometimes it's more subtle.  In

    > essence every compiler, interpreter, and even IDE is a metaprogram.

     I agree, therefore metaprogramming hardly qualifies as "unusual". The

    fact that Joy supports it so transparently is one of the things that

    attracts me to it.

    --

    Louis.