concatenativity and joy's non-opaque quotations

[John Nowak]

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.

[LittleDan]

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]

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