On Tue, Apr 13, 2010 at 11:54 AM, Sam Tobin-Hochstadt <[email protected]> wrote: > On Tue, Apr 13, 2010 at 12:42 PM, Robby Findler > <[email protected]> wrote: >> On Tue, Apr 13, 2010 at 10:47 AM, Sam Tobin-Hochstadt <[email protected]> >> wrote: >>> On Tue, Apr 13, 2010 at 9:08 AM, Robby Findler >>> <[email protected]> wrote: >>>> On Tue, Apr 13, 2010 at 7:15 AM, Sam Tobin-Hochstadt <[email protected]> >>>> wrote: >>>>> On Tue, Apr 13, 2010 at 4:42 AM, Paulo J. Matos <[email protected]> >>>>> wrote: >>>>>> >>>>>> Awesome, this one of my favourite features missing in Scheme. Hopefully >>>>>> we will see this soon in TS, Sam? >>>>> >>>>> Yes, we will hopefully soon see the form Eli describes. But it won't >>>>> give you exhaustiveness checking in general for `match', that's much >>>>> harder. >>>> >>>> I'm still looking into this, but my initial reading of the paper >>>> behind the current match implementation [1] seems to suggest that the >>>> compilation process can detect when it has to insert "else" clauses >>>> which should be at least a good start on this problem, no? >>> >>> `match' always inserts an else clause. The only way to write a >>> guaranteed exhaustiveness in Scheme in general is to write a catch-all >>> pattern yourself. I don't think `match' should warn if you don't do >>> that, since programmers will in general know more about the >>> exhaustiveness of their patterns than `match' can. For example, >>> should there be a warning for this code? >>> >>> #lang scheme >>> >>> (define/contract (f x) >>> ((or/c number? string?) . -> . number?) >>> (match x >>> [(? number?) ...] >>> [(? string?) ...])) >> >> No. If match can't tell it isn't exhaustive, it should be quiet; so it >> can just assume that predicates cover everything (and insert an error >> to be sure) This one, on the other hand: >> >> (match x >> [`(x ,(? number?)) ...] >> [`(,_ ,(? string?)) ...] >> >> should signal an error or warning or something since the >> non-two-element-list case is not covered. > > What if we change the contract to: > > ((list/c any/c any/c) . -> . any/c) > > Now the error case is unreachable, but `match' doesn't know that. > This also suggests that almost every single use of `match-let' should > trigger a warning.
We would presumably just follow ml in this case. > Ultimately, I think the choices are between a warning that is issued > almost always (except when there's a catchall clause), and a warning > that basically never happens, leading people to false confidence in > the completeness of their patterns. Neither of those seem like good > points in the design space. Instead, if you want coverage checking, > you should use a more restrictive pattern matcher, such as `cases' > from the PLAI library. Your arguments haven't really been convincing on a technical basis for this point (but you certainly do know more about pattern compilation than I do). FWIW. Robby _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
