Well, almost everything uses call rather than call(, because it is more flexible in a subtle way. The difference is that call allows what the shadowy Factor council likes to refer to as "row polymorphism", that is, quotations passed to call can refer to items lower on the stack. For example, you can use this to define reduce in terms of each: you can pass any quotation you want to each, as long as its stack effect is that it reduces the height of the stack by one. Another example is that the quotation for with-scope can have any stack effect.
One solution to the whole set of incompatiblities between call and call( would be to eliminate call in favor of call(, eliminating the combinator inlining system in the process. In my opinion, this would make the whole language much cleaner and nicer. No combinator inlining semantics to remember when writing your program; you can just think about how the compiler works when optimizing your code. Everything would work with dynamic quotations just like static ones. Unlike call, call( has a runtime fallback and doesn't require that quotations are inlined. Call( gives better error messages because it is actually explicitly specified what the intended stack effect of quotations is. However, no concatenative language has yet been designed which is both dynamically typed and supports call( with row polymorphism. Andreas Rossberg specified a static type system for a concatenative language with row polymorphism (http://lambda-the-ultimate.org/node/1899#comment-23169), but that alone wouldn't be enough for Factor. It has to be worked out how this feature would interact with the rest of Factor, not to mention the need for convenient and intuitive syntax. It would also be nice to have type inference here, though that's not necessary. This would be an interesting project for a theoretically-inclined contributor who is OK with a high chance of failure (or even in the event of some kind of success, a chance that the result will not be included in the core Factor language). I would be very pleased to see someone work on a project like this. Coming back to your original point, it would cause a lot of duplication to have 'paren' versions of several combinators: bi@(, cleave(, map(, with-variable(--there's no end! So this wouldn't be a very good idea. It's not *too* verbose, I think, to just write '[ _ call( x -- y ) ] bi@ rather than bi@( x -- y ), in my opinion, and it expresses the programmer's intent very clearly. Dan On Fri, Feb 26, 2010 at 11:57 AM, Jon Harper <jon.harpe...@gmail.com> wrote: > Here's where the code is : http://rosettacode.org/wiki/Active_object#Factor > I really need dynamic quotations because quotations are inputted by the user. > > I was surprised that no combinator defines a similar word to call(. > For example, I thought there would be a bi@( word. Maybe even for all > combinators : cleave(, keep(, etc. However that makes many many new > words.. So add-stack-effect seemed like a good compromise. It's true > though that dynamic quotations are rarely needed and I guess that's > why those words aren't defined. > > Also, I was wondering why the slot changer uses "call" instead of > "call( x -- x )". I find it easier to understand when extra arguments > are currified in the quotation rather than left on the stack behind > the object with "with" anyway. And that makes it work with dynamic > quotations. > > Jon Harper > > > > On Fri, Feb 26, 2010 at 6:31 PM, Samuel Tardieu <s...@rfc1149.net> wrote: >> >> >> 2010/2/26 Daniel Ehrenberg <micro...@gmail.com> >> >>> Well, I think you could also do this: >>> >>> build-dynamic-quotation '[ _ call( x -- y ) ] bi@ >> >> Sure, this is equivalent.But we wanted to be able to "tag" several >> quotations with different stack effects, hence the separate word. >> >>> >>> However, you should reconsider whether you really need to build a >>> dynamic quotation. Remember, building a quotation with curry and >>> compose and fry doesn't necessarily make it dynamic. >> >> Agreed. I'll let Jon explain in which context he did it. I only assisted in >> answering a specific question :) >> >> Sam >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Factor-talk mailing list >> Factor-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/factor-talk >> >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
