On Mon, Dec 12, 2011 at 10:47, Giacomo Tesio
While I got your point, I'm still wondering about functions as constructor of other functions thus it would be possible to match to the function name like we do for type constructors. I can't have an insight about why this is wrong. Why can't we treat functions as constructors?
This makes (f) and (id f) different, when referential transparency requires that they be the same. Anything capable of spotting that difference *must* be in IO. A concrete reason for this is laziness: *everything* is a function, including literals — and I do not mean by this things like the implicit fromIntegral/fromRational on numeric literals. Everything is a function which is evaluated to WHNF when needed. So now you have an additional issue: if you're pattern-matching something — which is the normal way to force evaluation — you have to know whether we're expecting normal pattern matching, which does evaluation to a data constructor, or your function-pattern matching, which evaluates to some kind of distinguished "function constructor". Additionally, there is the question of where you draw the line. Do you consider a binding to be a "function constructor"? Only a top level binding? Only an imported binding? Only an import from a "system" module? Only a primop? I can see arguments for all of them, and no obvious argument for why one of them is better than the others. Moreover, the deeper you go in this stack, the greater the chance that different compilers, or different versions of the same compiler, produce different results; this is again a violation of referential transparency. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms