Primitive types and Prelude shenanigans

Dylan Thurston dpt@math.harvard.edu
Tue, 27 Feb 2001 13:00:26 -0500


On Fri, Feb 16, 2001 at 05:13:10PM +0000, Marcin 'Qrczak' Kowalczyk wrote:
> Fri, 16 Feb 2001 04:14:24 -0800, Simon Peyton-Jones <simonpj@microsoft.com> pisze:
> > Here I think the right thing is to say that desugaring for boolean
> > constructs uses a function 'if' assumed to have type
> >         if :: forall b. Bool -> b -> b -> b
> 
> What if somebody wants to make 'if' overloaded on more types than
> some constant type called Bool?
> 
>     class Condition a where
>         if :: a -> b -> b -> b

(Note that Hawk does almost exactly this.)

> Generally I don't feel the need of allowing to replace if, Bool and
> everything else with custom definitions, especially when there is no
> single obvious way.

Why not just let

  if x then y else z

be syntactic sugar for

  Prelude.ifThenElse x y z

when some flag is given?  That allows a Prelude hacker to do whatever
she wants, from the standard

  ifThenElse :: Bool -> x -> x -> x
  ifThenElse True x _ = x
  ifThenElse True _ y = y

to something like

  class (Boolean a) => Condition a b where
     ifThenElse :: a -> b -> b -> b

("if" is a keyword, so cannot be used as a function name.  Hawk uses
"mux" for this operation.)

Compilers are good enough to inline the standard definition (and
compile it away when appropriate), right?

Pattern guards can be turned into "ifThenElse" as specified in section
3.17.3 of the Haskell Report.  Or maybe there should be a separate
function "evalGuard", which is ordinarily of type
  evalGuard :: [(Bool, a)] -> a -> a
(taking the list of guards and RHS, together with the default case).

It's less clear that compilers would be able to produce good code in
this case.

But this would have to be changed:

  An alternative of the form

    pat -> exp where decls

  is treated as shorthand for:

    pat | True -> exp where decls

Best,
	Dylan Thurston