Not to hijack the thread, but I thought I was the only one that used unix notation for statements like {in,}equalities. I like it!<br><br><div class="gmail_quote">On Mon, Mar 2, 2009 at 11:13 PM, Andrew Hunter <span dir="ltr"><<a href="mailto:ahunter@cs.hmc.edu">ahunter@cs.hmc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Several times now I've had to define an EDSL for working with<br>
(vaguely) numeric expressions. For stuff like 2*X+Y, this is easy,<br>
looking pretty much like:<br>
<br>
> data Expr = Const Integer | Plus Expr Expr | Times Expr Expr<br>
><br>
> instance Num Expr where<br>
> fromInterger = Const<br>
> (+) = Plus<br>
> (*) = Times<br>
<br>
&c. This lets me get a perfectly nice AST, which is what I want.<br>
When I want to be able to express and work with inequalities and<br>
equalities, this breaks. Suppose I want to write 2*X + Y < 3. I<br>
either have to:<br>
<br>
a) Hide Prelude.(<) and define a simple < that builds the AST term I want.<br>
b) Come up with a new symbol for it that doesn't look totally awful.<br>
<br>
Neither of these work decently well. Hiding Eq and Ord operators,<br>
which is what I effectively have to do for a), is pretty much a<br>
nonstarter--we'll have to use them too much for that to be practical.<br>
<br>
On the other hand, b) works...but is about as ugly as it gets. We<br>
have lots and lots of symbols that are already taken for important<br>
purposes that are syntactically "near" <,<=,==, and the like: << and<br>
>> and >>= for monads, >>> for arrows, etc. There...are not good<br>
choices that I know of for the symbols that don't defeat the purpose<br>
of making a nice clean EDSL for expressions; I might as well use 3*X +<br>
Y `lessthan` 3, which is just not cool.<br>
<br>
Does anyone know of a good solution, here? Are there good<br>
substitutions for all the six operators that are important<br>
(<,>,>=,<=,==,/=), that are close enough to be pretty-looking but not<br>
used for other important modules?<br>
<br>
Better yet, though a little harder, is there a nice type trick I'm not<br>
thinking of? This works for Num methods but not for Ord methods<br>
because:<br>
<br>
(+) :: (Num a) => a -> a -> a<br>
(<) :: (Ord a) => a -> a -> Bool<br>
<br>
i.e. the return type of comparisons is totally fixed. I don't suppose<br>
there's a good way to...well, I don't know what the *right* answer is,<br>
but maybe define a new typeclass with a more flexible type for < that<br>
lets both standard types return Bool and my expressions return Expr?<br>
Any good solution would be appreciated.<br>
<br>
Thanks,<br>
AHH<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br>