Re: [stack] map fusion

On Fri, Aug 1, 2008 at 12:33 PM, Daniel Ehrenberg <[email protected]> wrote:
> On Fri, Aug 1, 2008 at 7:01 AM, William Tanksley, Jr
> <[email protected]> wrote:
>>> This seems to be yet another argument against n-ary combinators where
>>> the quotation is not called a fixed number of times.
>>
>> _This_ I don't understand. What does that mean?
>>
>> I would have said "this is an argument against combinators which
>> repeatedly call function inputs that do not have a statically known
>> stack effect."

However, they *do* have a statically known stack effect.

> Am I being too restrictive? Are you being too
>> restrictive?
>
> I agree with William. In a high level language, it'd generally be
> better if the compiler can figure out its optimizations itself without
> needing changes in the language design.

> Here, it should be easy to
> check whether the quotation given affects values lower down on the
> stack.

Yes it is (in most scenarios).

> In its fusion optimization, the compiler can just use this
> information, rather than change the kind of program that the user
> writes.

That is a valid point. However, one of the benefits of being able to
manipulate the concatenative program syntactically while preserving
meaning is now lost.

> (Maybe map* would be good for documentation purposes or something, but
> this is not a good justification for it.)

There is a precedence for such a naming system in Scheme. Effectively
"map*" is a version with side-effects. We could perhaps call it
"map!". For Cat which was intended for use as an intermediate language
at least, the goal of being able to apply simply term rewriting to the
syntax of a program (e.g. identify "[f] map [g] map" and rewrite it
without analysis) was really quite appealing.

- Christopher