Re: [stack] Fwd: [Factor-talk] cleave, 2cleave, and spread
"William Tanksley, Jr" <[email protected]>
| Newsgroups | gmane.comp.lang.concatenative |
|---|---|
| Message-ID | <[email protected]> |
John Nowak <[email protected]> wrote: > William Tanksley, Jr wrote: > > Slava, the author/primary author of the Factor language, writes: > > - cleave takes one value, and an array of quotations. It applies each > > quotation to the value; the value is removed from the stack > > afterwards. > > - 2cleave takes two values, and an array of quotations. it applies > > each quotation to the two values; the two values are removed from the > > stack afterwards. > While cleave/2cleave do seem to form a possible base, they are > impossible to type. That's a good point; obviously, that's not yet an issue with Factor, and when it becomes an issue, they probably won't be able to use untyped arrays with it (as you clarify later). I'm not sure that it's impossible to type, by the way; it seems like it should be possible if the arrays are typed. > That's not to say cleave isn't convenient, but for > convenience alone you can always offer it as a macro that translates a > statically-known list of functions to the same thing in terms of some > simpler core set. What would such a thing look like -- either the macro or the "simpler core set"? (Just curious.) Actually, I think we may be on the same page here. Cleave and friends do nicely get rid of stack shuffles and clarify dataflow -- but they don't always look clear to me, and I think the problem may be fundamental. There are just too many nested layers. Does anyone have any ideas for a possibly more clear -- and statically safe -- way to cleave dataflow? Obviously, implicit iteration (ala J/K) is one. > I'd argue that using cleave with arrays not known at > compile-time is very difficult for a human to reason about anyway and > likely should be avoided in all cases. I entirely agree -- although since I enjoy dynamic typing when it's appropriate, I'd like to modify that to "arrays not knowable at compile time". I don't object to the compiler being clueless; I only object to the programmer being so. > - John -Wm