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-
. Springer Verlag LNCS 432, 1990.
Unfortunately neither appear to be available online.
- Andrew.
> -Original Message-
> From: Tim Sweeney [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 23, 2000 7:37 AM
> To: [EMAIL PROTECTED]
> Subject: Higher-order function appli
> 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 sc
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
\x->(cos(x)+sin(x))", we say:
for all types t,u,v,
for all functions f,g :: t->u,
for all functions h ::u->u->v,
h (f,g) = \x->h(f(x),g(x)).
Is this "higher order function application" a useful notion, and does any
research exist on the topic?
-Tim
10 matches
Mail list logo
