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]