# concatenativity and joy's non-opaque quotations

## John Nowak — 2008-03-31 12:24:15

    One of the properties of concatenative languages often relayed to me

    is that you can "factor out" portions of code to yield a new

    definition. For example, both versions of 'a' below are equivalent:

        a = b c d e

        f = c d

        a = b f e

    However, because Joy's lists are also Joy's anonymous quotations, this

    seems not to be the case. It is impossible to safely perform such a

    factoring unless you know that the quotation will never be inspected

    in such a way that would reveal the difference.

    It seems the simple solution would be to separate quotations and lists

    (yielding opaque quotations) and then provide an 'eval' procedure for

    evaluating lists as if they were quotations. Languages like Scheme

    take such an approach.

    Have non-opaque quotations proved useful in practice? Are they useful

    in a way that couldn't be easily copied by having both 'i' and 'eval'?

    - John

    P.S. It seems I've deleted my old visualizations of Joy-like code. I

    may recreate them if I have the time, but I'm less than convinced of

    their utility at the moment.

## Daniel Ehrenberg — 2008-03-31 13:53:08

    Non-opaque quotations are really useful for metaprogramming. For

    example, for my "inverse" pattern matching library in Factor, I do a

    bunch of manipulations on a quotation as an array (Factor's quotations

    are specially typed arrays, not lists)--reversing it, iterating

    through it, etc, in order to process it into a different quotation.

    More concretely, because quotations are just arrays, you can really

    easily prettyprint them, which is useful in an interactive development

    environment. There's no straightforward way to prettyprint Scheme

    lambdas, say. But if you are not planning on allowing such

    manipulations in Fifth at runtime, making quotations lists doesn't

    have this advantage. Also, a particular macro system could be built to

    handle this, to turn quotations into a list at macro expand time.

    In practice, this issue with, I guess, impure concatenativity is

    never, ever, ever a problem, and to me it doesn't seem to be a

    particularly important theoretical problem either. It is, however,

    useful to give quotations and lists separate types (and keep

    quotations non-opaque), because then you can tell them apart whenever

    it's relevant for the type system to distinguish them. It's not useful

    if you can call a long list of integers. An alternative to "eval" for

    executing lists is ">quotation i", where >quotation is a word which

    turns a list into a quotation. The two models are equivalent.

    Dan

     On Mon, Mar 31, 2008 at 8:24 AM, John Nowak <john@...> wrote:

    >

    > One of the properties of concatenative languages often relayed to me

    >  is that you can "factor out" portions of code to yield a new

    >  definition. For example, both versions of 'a' below are equivalent:

    >

    >  a = b c d e

    >

    >  f = c d

    >  a = b f e

    >

    >  However, because Joy's lists are also Joy's anonymous quotations, this

    >  seems not to be the case. It is impossible to safely perform such a

    >  factoring unless you know that the quotation will never be inspected

    >  in such a way that would reveal the difference.

    >

    >  It seems the simple solution would be to separate quotations and lists

    >  (yielding opaque quotations) and then provide an 'eval' procedure for

    >  evaluating lists as if they were quotations. Languages like Scheme

    >  take such an approach.

    >

    >  Have non-opaque quotations proved useful in practice? Are they useful

    >  in a way that couldn't be easily copied by having both 'i' and 'eval'?

    >

    >  - John

    >

    >  P.S. It seems I've deleted my old visualizations of Joy-like code. I

    >  may recreate them if I have the time, but I'm less than convinced of

    >  their utility at the moment.

    >

## John Nowak — 2008-03-31 22:40:35

    On Mar 31, 2008, at 9:53 AM, Daniel Ehrenberg wrote:

     > But if you are not planning on allowing such

    > manipulations in Fifth at runtime, making quotations lists doesn't

    > have this advantage. Also, a particular macro system could be built to

    > handle this, to turn quotations into a list at macro expand time.

     This is the approach I'm taking.

     > In practice, this issue with, I guess, impure concatenativity is

    > never, ever, ever a problem, and to me it doesn't seem to be a

    > particularly important theoretical problem either. It is, however,

    > useful to give quotations and lists separate types (and keep

    > quotations non-opaque), because then you can tell them apart whenever

    > it's relevant for the type system to distinguish them.

     I don't have much choice but to keep them separate. I toyed briefly

    with the idea of typing certain things as the intersection of their

    list and quotation types, but it doesn't seem particularly useful.

    Much cleaner to just deal with macros.

    - John