Re: [stack] concatenativity and joy's non-opaque quotations

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 <[email protected]> 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.
>