Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Instead of
            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
    • > Instead of
      > 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.