Re: [stack] Concatenative Research

On Mon, Jan 31, 2011 at 6:11 PM, Justin <[email protected]> wrote:

>
>
> > What may be interesting and useful would be to return to typed variables
> > (named values variety) and something like a SQL "natural join".
>
> I don't know what you mean. Could you give an example? (I don't have a good
> mental model of databases.)
>


The truely irritating thing about both stack languages, and the more
traditional languages with named parameters, is that the order of the
parameters and the names don't really matter.

Given any program P in a stack or traditional language, you can reorder
and/or rename the parameters of every function anyway you choose... and come
up with another program that does EXACTLY the same thing, so long as you
carry through the renaming through the the body of each function and the
reordering into every invocation of the function.

In stack languages without parameter names, your program will _look_
radically different as there will be a flock of stack manipulation operators
different.

ie. In a very strong sense, parameter names and parameter order is fluff and
irrelevant to the actual computation being performed!

Thus my mathematical gut feeling is, one should be able to eliminate it
_all_ in some representation.

I could be unconstructive an give you a lmgtfy link about natural joins, but
let me rather discard the SQLish analogy and try say what I mean in a
stackish language.

Well, a lot of stack languages (Factor is a very good example) give the
stack effect for each function as something like...

fn: T1, T2, T3... -> T4, T5... where I mean fn is a function that pops
parameters of type ..., T3, T2, T1 off the stack, in that order and pushes
objects of type T4, T5, .. onto the stack in that order.

Well, lets add some names...

fn: i1 T1, i2 T2, ...-> o4 T4, o5 T5, ...

Where I am naming my input parameters i1, i2, ... and my output values as
o4, o5, ...

Now a fragment of any stack language code tends to look like....

  fn1 stackOp1 stackOp2, ... fn2

where all the stackOps rearrange the stack as it was left by fn1 and it's
predecessors, so as to feed fn2 correctly.

However, it you were to look at the stack effect declarations for fn1, and
fn2, it would probably be obvious from the types alone, as which stackOps
you would need between fn1 and fn2!

And if the types alone weren't enough to tell you, the names certainly
would!

Thus in principle one could create a language where you could write a
fragment as fn1 fn2 and the compiler could infer what stackOps (or calling
parameters and their order) are required.

-- 
John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : [email protected]
New Zealand

=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================


[Non-text portions of this message have been removed]