Experiencing magic What happens when you let a road planner be on crack at work? You get the Magic Roundabout! I've seen and driven it now. It's clear to me why the locals sometimes refers to this as the Tragic Roundabout, because there's no way an unsuspecting stranger can navigate through this unless totally sober, super alert, there's full daylight, light traffic, ... I recommend a Sunday afternoon. Have a look. BTW, this is the the UK, so if you drive on the right, flip the image. :)
Monday, July 09, 2007
Sunday, July 01, 2007
Massive overload In my last post I had a little DSL embedded in Haskell. Defining the Fibonacci function looked like this:
mdo fib <- fun $ \ n -> cond (n .< 2) 1 (fib(n-1) + fib(n-2)) return fibCompare that with ordinary Haskell:
fib n = if n < 2 then 1 else fib(n-1) + fib(n-2)Why do they look different? Could I make my DSL look exactly like Haskell? First, lets look at the parts that look the same, like fib(n-1). In Haskell, with n of type Int, this just an expression and it has some value (depending on n). In the DSL, with n of type M Int the value of this expression is in fact an abstract syntax tree, namely (something like) M (App (Func (FuncNo 0)) [App (FPrimOp I_Sub) [Arg 0, Con (ILit 1)]]). The reason we can make the same expression mean different things depending on the type is that numerical operators like - are overloaded, and so they do different things for Int and M Int. So what about <, can we overload that too? The < operator is already overloaded and has type (Ord a) => a -> a -> Bool. But the .< operator in the DSL returns M Bool, so there's no way we can use <; the return type is fixed. What to do? Well, there's nothing sacred with the operator <, it's just another name, but defined in the Prelude. We can make our own if we hide the Prelude. So let's do that, but carefully. We want to be able to still use < as before, and for our M Bool return type. So we need to overload the return type as well as the argument type. Overloaded Booleans Before we do that, let's define a class that is analogous to Num, but for Boolean values. We'll need this class soon. The Bool type has a few important functions and values, let's put those in the class.
b -> b not :: b -> b instance Boolean Bool where false = False true = True (&&) = (P.&&) (||) = (P.||) not = P.notFirst we import the Prelude explicitly, this allows us to hide some things we want to redefine. The we define the Boolean class, which gives new meaning to some prelude functions. Finally, we make an instance saying that the new (&&), (||), and not behave as the old ones for good oldfashioned Bool. After this definition we can use the Boolean operators just as before, they are just overloaded now, but for Bool they resolve to their old meaning. Overloaded comparison So back to comparison, Eq first.
class (Boolean b) => Eq a b | a -> b where (==), (/=) :: a -> a -> b x /= y = not (x == y)The new Eq (we need to hide the Prelude one) is now more general; the return type is overloaded as well. Too avoid ambiguities we have a functional dependency. The type of the values we compare will determine the type of the Boolean result. (This isn't necessary, but without this we might need many type annotations.) Nothing is a member of this class, so we need to add the types we need. We really should all types that have equality, but let's do two samples.
instance Eq Int Bool where (==) = (P.==) (/=) = (P./=) instance Eq Double Bool where (==) = (P.==) (/=) = (P./=)And since the whole point of this was to allow special equality for our M values, let's look at that too.
instance Eq (M Int) (M Bool) where (==) = binOp I_EQ (/=) = binOp I_NEA new (simplified) Ord looks similar, both the class and the instances.
class (Eq a b) => Ord a b | a -> b where (<), (<=), (>), (>=) :: a -> a -> bOverloaded conditionals So now for the next challange. The Haskell Fibonacci function uses if, and the DSL uses a special function cond. Well, now we are stuck. These is no way at all to overload the special if syntax in Haskell; it's wired in. This could be viewed as a design mistake in Haskell, but so it is. So could we use the cond function in the Haskell version too? Well, not the original cond, it has type M Bool -> M Int -> M Int -> M Int. We need to overload that too.
class (Boolean b) => Cond a b | a -> b where cond :: b -> a -> a -> aAgain, we add a functional dependency. And again, it will save some ambiguities. The obvious instances:
instance Cond Int Bool where cond x y z = if x then y else z instance Cond (M Int) (M Bool) where cond = terOp I_Cond instance Cond (M Bool) (M Bool) where cond = terOp I_Cond terOp op (M c) (M t) (M e) = M $ App (FPrimOp op) [c, t, e]Oh, and the instance for M Bool that I skipped before.
instance Boolean (M Bool) where false = M $ Con $ LInt 0 true = M $ Con $ LInt 1 x && y = cond x y false x || y = cond x true y not x = cond x false trueAfter this effort we can write the body of the Fibonacci function the same way for both type Int and type M Int, namely
cond (n < 2) 1 (fib(n-1) + fib(n-2))And what about all these new classes and instances. how do we package them to make them easy to use?
module MyPrelude(module Prelude, Boolean(..), Eq(..), Ord(..), Cond(..)) where import qualified Prelude as P import Prelude hiding (Eq(..), Ord(..), (&&), (||), not) ...We hide the stuff we want to override, and re-export the rest of the Prelude. Any module that wants to use this new Prelude now has to say:
module M where import Prelude() import MyPrelude ...After this all regular Haskell code works as before, but we can also take advantage of the new overloadings. Enough for today.