[Haskell-beginners] Pattern matching over functions

[Brandon Allbery]

On Mon, Dec 12, 2011 at 10:47, Giacomo Tesio <giacomo at tesio.it> wrote:

> 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 at gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20111212/60249477/attachment.htm>