I often find myself at odds with this choice. The reason is that I use
Haskell as a host for embedded languages, and these often come with
their own control flows. So I find myself wanting to write my own
definition of the if-then-else construct that works on terms of some
other type, e.g. tests on values of type Exp Bool instead of Bool, and
at the same time make sure that the user doesn't use the built-in
if-then-else. Sure, I can (and do) call my own version if_, ifElse or
something else along those lines, but it's sure to be a constant
source of programmer errors, writing if-then-else instead of if_ by
habit.
A thought that has crossed my mind on several occasions is, why not
make the syntactic if-then-else construct rebindable, like the do
notation? I think I know the answer already -- the do notation is
syntactic sugar for >>= and company so it's easy to translate it into
non-prelude-qualified versions of functions with those names. This is
not the case for if-then-else. But it could be, the prelude could
define a function if_ (or whatever) that the if-then-else construct is
made to be sugar for, and thus also amenable to rebinding by not
prelude-qualifying.
Wouldn't this cause a conflict with specialized knowledge the compiler has
about if-then-else, e.g. for optimizations?
Tom
--
Tom Schrijvers
Department of Computer Science
K.U. Leuven
Celestijnenlaan 200A
B-3001 Heverlee
Belgium
tel: +32 16 327544
e-mail: [EMAIL PROTECTED]
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
