Open dmcclean opened 7 years ago
LGTM, but personally I'd make binop
ignore it's arguments rather than pattern match on them.
Good idea. I was trying to maintain the same strictness behavior as the unary operations, but a strict wildcard would be more concise.
Not really sure, but I'd perhaps suggest making the unary operations lazier instead.
binop _ _= AbstractNumber
unop _ = AbstractNumber
instance Num AbstractNumber where
(+) = binop
(*) = binop
negate = unop
abs = unop
signum = unop
fromInteger = unop
I have a EDSL with lots of terms that are polymorphic over any
Floating
type. I wish to perform some abstract interpretation over them looking at properties other than what they do to the numbers (things like signal names and other metadata). Right now I have to pick aFloating
type essentially arbitrarily, even though I end up ignoring it.Since there isn't a
Num
instance for()
, I propose a type like:Is this a good fit for this package? If so I can draft a PR.