NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Nitpicks and comments (Score:1)
d does e
I get
d does a
b does e
(from the call to fact).
Inferring
a == d
b == e
leaves
1 in a in Num
1 in b in Num
0 in c in Eq
a does b
a does c
which may not be as tight as you'd like but expresses the constraints reasonab
Re:Nitpicks and comments (Score:1)
> d does e
> I get
> d does a
> b does e
> (from the call to fact).
That's right, good eye.
> 1 in a in Num
> 1 in b in Num
[...]
> which may not be as tight as you'd like but
> expresses the constraints reasonably. It allows,
> for instance,
> a == [1..5]
Actually it doesn't. "a in Num" means that a is a ring. If you say 4 + 3 (which are both in a here), you get 7, which is not in a, so a is not in Num.
What I'm currently stumpted on is if you say fact(3). The caller is supposed to provide the instances present in the constraints. But 3 is in Int, Float, Bigint, Z_4 (integers mod 4), etc. Which one do you pick? Also, what do you pick for your return value? Why would you have to provide the Eq[c] instance, when you don't even know what c represents.
But, upon looking at the constraints, this is all you can really infer without monotypes. So I'm hoping there's a way around it.
Reply to This
Parent