Re: [stack] a concatenative language for the Semantic Web

On 5/21/07, William Tanksley, Jr <[email protected]> wrote:

Hi Billy,


>  > 1) There is only one "operator" (a dispatch function called op) in the
>  > language; everything else is treated as a constant.  For instance,
>  > whereas in Joy you would write
>
>  I think one of Apter's experimental languages used something like
>  this; a bare word simply pushes the function on the stack, while an
>  exclamation mark executes the function at the TOS.

I'd like to take a look at it... that does sound like the same idea.
Earlier on in the design of Ripple, I thought I would use op as the
actual application operator, where each instance of op applies a
function to a single argument.  So instead of instead of (1 2 /add) or
(1 2 add op) you would have written (1 2 //add), or (1 2 add op op),
which makes explicit how many arguments the 'add' function is to
consume, and is nicely symmetrical with the fully-parenthesized
applicative expression ((add 2) 1) -- written in reverse and with the
opening parens replaced with op.  Ripple would have been an
applicative language, then, but still nominally concatenative (I
think), and in any case still a stack language.  I chose the current
semantics of op so as to make nullary functions less of a pain and to
make the code more compact.  I still like the applicative style,
though, and I think at some point I'll write an evaluator which uses
it, just to see what it's like to program in.


>  > 3) There is no single global stack in Ripple.  Instead, Ripple is
>  > geared towards "streams" of stacks in order to deal with RDF's
>  > multivalued relations.   Filters may consume more than one stack, and
>  > produce any number of stacks.  E.g.
>
>  Wow. This seems very significant.

I was wondering if it was new.  I'm not aware another stack language
which resembles mine in that respect, but then again I have yet to
take a closer look at some of the more exotic languages discussed on
this list (as well as very many non- functional stack languages like
Forth).


>  > The three stacks continue down the evaluation "pipeline" individually,
>  > and further operations are applied to each of them in turn.
>
>  In turn, or in parallel?

For now, in turn.  The order of output of stacks in a stream is
technically undefined, but evaluation occurs in a single thread, so
it's actually completely predictable.  Concurrent and distributed
computing with Ripple is definitely on the TODO list.


>  I'll be reading more about this.

Your critique couldn't be more welcome :-)


>  -Billy

Josh