Re: [stack] function "adjoinment"?

"William Tanksley, Jr" <[email protected]> Mon, 1 Feb 2010 06:33:49 -0800
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
Matt Hellige <[email protected]> wrote:

> John Nowak <[email protected]> wrote:
> > We're familiar with the notion of function composition:
> > However, is anyone familiar with a notion of function "adjoinment"?
> > Given a function F that takes a tuple A to a tuple B, and a function G
> > that takes a tuple C to a tuple D, the adjoinment of F and G would be
> > a function that takes the concatenation of A and B to the
> > concatenation of C and D. In other words:
> > (a -> b) -> (c -> d) -> (a++b -> c++d)
> > where ++ is concatenation and a,b,c,d are tuples/stacks
>

I'm so bad at reading this kind of notation. But I think I see what you're
describing.

I wonder if it would be possible to type this operator in a system of
> extensible records like Daan Leijen's Morrow? That would be a neat
> trick.


Hmm... That's very interesting. I'd not noticed that one "fly by" on
lambda-the-ultimate. And this is a particularly interesting twisting of
Leijen: if I read you correctly, you're suggesting making all stack
functions take the same number of arguments, and then special-casing each
one by extending its record.

Given that practical concatenative languages tend to have style guidelines
that say "no more than 7 arguments per function", it's actually vaguely
conceivable that this would work (actually, I've never seen a style
guideline that says 7; they tend to say 3, as 7 is the utter limit of human
memory). Whatever limit you choose, you'd have to provide means for
overriding that limit.

Finally, it also reminds me of operads. I've speculated a bit about a
> general syntax for operadic composition, but don't really have
> anything useful to say.


It does indeed look like operad theory might be useful here. I've never seen
that before, so I'll leave it up to you -- the intros I found are _very_
mathematical.

Matt


-Wm


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