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