Bjorn Lisper <[EMAIL PROTECTED]> writes:
}}>cos+sin-- intent: \x->((cos x)+(sin x))
}}>cos(sin) -- intent: \x->cos(sin(x))
}} have equivalents in Fortran 90 and HPF, although with arrays rather than
}} functions. For instance, one can write "A+B" to mean an array with value
Bjorn Lisper <[EMAIL PROTECTED]> writes:
> >cos+sin-- intent: \x->((cos x)+(sin x))
> >cos(sin) -- intent: \x->cos(sin(x))
> have equivalents in Fortran 90 and HPF, although with arrays rather than
> functions. For instance, one can write "A+B" to mean an array with value
Tim Sweeney wrote:
> However, a higher-order notion of function application seems sensible in
> many cases. For example, consider the following expressions, which Haskell
> rejects, despite an "obvious" programmer intent:
Casting was done quite extensively by Algol68 (though not of this form).
A
Tim Sweeney:
>Is this "higher order function application" a useful notion, and does any
>research exist on the topic?
The answer to the first question is "yes, when it matches the intuition of
the programmer". Your two first examples:
>cos+sin-- intent: \x->((cos x)+(sin x))
>cos
Something like this was proposed by Satish Thatte a while back; he called it
"implicit scaling". See
S. Thatte. A type system for implicit scaling. Science of computer
programming, 17:217--245, 1991.
S. Thatte. Type inference and implicit scaling. In European Symposium on
Programming. Springer
> Tim> 6. Applying a function f:t->u to a list x::[t] translates to
> Tim> "map f x".
This can be done in mathematica via function attribute (Listable if my
memory is correct). IIRC It's defined by default only for functions that
only make sense on pure numbers/symbols (eg Sin) and it's v
"Ch. A. Herrmann" wrote:
>
> the problem is that we loose much of the strength the Haskell type
> system provides and a lot of programming errors will remain
> undetected.
Moreover, it is completely incompatible with polymorphic typing and type
inference, because you overload notation. Consider
Hello,
On Wed 23 Aug, Tim Sweeney wrote:
> Is this "higher order function application" a useful notion,
Eeek!, no IMHO
> and does any research exist on the topic?
I suspect not, though I must admit I'm no expert on what's being researched
in the world.
What scares me about this is that even
Hi Tim,
Tim> 6. Applying a function f:t->u to a list x::[t] translates to
Tim> "map f x".
the problem is that we loose much of the strength the Haskell type
system provides and a lot of programming errors will remain
undetected.
What you can do is write a preprocessor that provides a
ni
