On 8/25/2011 4:16 PM, Dave Abrahams wrote:
on Thu Aug 25 2011, Eric Niebler <eric-AT-boostpro.com> wrote:
I simply don't see the problem with:
f(x) ==> curry f(x, y) or f(x)(y) ==> curry f(x, y, z) or etc. ==> evaluate
Can you say specifically what you think the problem is?
It just rubs me the wrong way that sometimes passing arguments to a function has no execution semantics, but if you happen to complete an argument list, suddenly it's called.
OK. You say tomahto.
This is how its done in Haskell, for instance (although Haskell doesn't use parens around argument lists).
Well, no, it's not exactly how it's done in Haskell, because in Haskell f is lazy, and that's what makes the difference.
You probably know this, but I can pass:
(f x y z) -- which would be f(x, y, z) in C++
to another function that will then throw it away, and f will never be invoked.
let oar x y = if x then x else y
if I invoke:
oar True (f x y z) -- analogous to oar(True,f(x y z)) in C++
You can prove this to yourself by invoking putStrLn in f.
Yes, I know. I don't consider that difference particularly relevant to this discussion, though. If (f x y x) type-checks as Int you pass it as an argument to a function that takes an Int, it type-checks. If you pass (f x y) as an argument to a function that takes a unary-function-that-returns-Int, it type-checks.
Yes, it has always been my view that bind was unambiguously better for non-lazy languages, and at least more flexible even for lazy ones.
Better and more flexible in what ways?
It's better because it avoids confusion about when things are invoked.
Meh.
It's more flexible because it allows the 2nd argument to be bound before the first argument is available.
You snipped the part of my message where I said that that problem is easily solvable, and now you're pretending I never said it. :-/ -- Eric Niebler BoostPro Computing http://www.boostpro.com