Re: [stack] a constructive-concatenative language

I've been too busy to do any more than scan your message, but I did
notice with interest your claim that you preserve concatenativity
without using a stack. I might get some time to check that claim after
the holidays.

In the meantime, I fwd'ed this to a friend who's got more time, and
this is what he said:

> This is a near-complete re-invention of Backus' FL language, including
> syntax.  The only things I can spot which are readily different are
> the selection syntax and that you no longer need to use 'o' to
> indicate composition.
>
> Not that this is anything wrong, of course -- FL has always been one
> of those languages which has piqued my curiosity.  I've often pondered
> how hard it'd be to write an interpreter for my own dialect of FL too.

[...]

> * In FP/FL, all functions consume one datum.  Passing multiple
> arguments to a function occurs via tuples, expressed in <a,b,c>
> syntax.
>
> * In FP/FL, integer literals are functions which return the nth item
> of a tuple.  Thus, 3:<a,b,c> yields the value c (this is read "third
> of <a,b,c>".  To actually specify a numeric literal, you prefix it
> with some character (I cannot remember which: I think ~).
>
> * ID is used for the identity function -- it returns its argument.
>
> * [f,g,h] is the construction operator in FP/FL; hence:
> [f,g,h]:<1,2,3> == <f:<1,2,3>, g:<1,2,3>, h:<1,2,3>>.  Hence,
> computing the average of its parameter, a function can be written: avg
> = /:[+,length].  Using substitution, avg:<1,2,3> =
> /:[+,length]:<1,2,3> = /:[+:<1,2,3>, length:<1,2,3>] = /:<6, 3> = 2.
>
> I'm sure there are other attributes of FP/FL that I am missing or have
> forgotten.
>
> The point is, however, that Nowak's language and FP/FL are extremely
> similar.  I'm not sure to what extent that FP/FL have influenced his
> thinking, but if it's an independent design, that speaks volumes for
> Backus' ideas.  Perhaps traditional functional languages have it all
> wrong -- perhaps functions of tuples of arguments solves the dataflow
> problem when compiling to a stack architecture better than curried
> functions.
>
> However, Nowak's language has a few innovations of its own, which must
> not be ignored.  I do not recall seeing anything like {a,b,c} syntax
> in FP/FL, for example.  The elimination of 'o' for function
> composition perhaps forms the single biggest contribution.  That
> _forces_ anything you program in it to be concatenative, by
> definition.
>
> I'm not a fan of him using infix mathematics in his language, only
> because it's nearly impossible to statically disambiguate postfix and
> infix forms of operators.
>
> I do have to admit, however, that I've been considering a language
> which is structured similarly to APL/J.  The idea that you read from
> left to right, but evaluate from right to left is very appealing to
> me, particularly from an applicative point of view.  So far as I can
> tell, the only core primitives in the language would be function
> definition (=), and the McCarthy conditional construct (a->b;c), and
> function application (a(b)).  Everything else pretty much is
> effectively "standard library" material.
>
> However, I'll need to re-evaluate my "toy" language idea to see how
> making all functions operate on tuples of arguments changes it.