Subject: Re: another fun one
From: Vassily Litvinov (vass@cs.washington.edu)
Date: Mon Apr 09 2001 - 12:19:31 PDT
Upon contemplating on it a bit, I came up with an alternative explanation
that doesn't involve blaming our greatest-of-all type system and
the-most-clever-backquote sugar directly.
First, error reporting definitely sucks. To start with, out of six
constraints reported as "couldn't be solved," one is trivial, three others
appear as "available," one can be easily derived, and only one is the real
indicator of the problem. Then, all this "available constraints" business
at the moment doesn't make sense even to me.
This comes as no surprise, as we are in the classic situation "here's a
bunch of constraints that cannot be solved. Go find the problem." I
spent only a very small amount of time on presenting the constraints, but
non at all on explaining them. Other groups (like recursively-constrained
types, ESC, Aiken et al.) had to spend a lot of effort producing
meaningful error messages in a similar situation.
Second, we have no experience with ITC. Likewise someone facing F-bounded
quantification for the first time can easily get lost. The particular
kind of error in the includes() implementation is quite common in stdlib
(I think) and, IMHO, not so difficult to grasp.
BTW I have brief discussions of other typical errors I encountered in
stdlib a while back in
~vass/Info/ts-impl-check/LOG-implerrors
I don't know if these are valid arguments; we should definitely try to see
if we can improve on the type system.
Vass
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Mon Apr 09 2001 - 12:20:07 PDT