I thought you were talking about lets. I was referring to this: Standard ML of New Jersey v110.72 [built: Wed Feb 3 11:03:59 2010] - fun snd x = let val (a::b::c) = x in b end; val snd = fn : 'a list -> 'a - snd [1,2,3]; val it = 2 : int - snd [1];
uncaught exception Bind [nonexhaustive binding failure] raised at: stdIn:1.21-1.34 - ^D but we are way beyond "useful conversation" in this thread, so I think I'll just go back to my regularly scheduled programming. Robby On Tue, Apr 13, 2010 at 1:12 PM, Sam Tobin-Hochstadt <[email protected]> wrote: > On Tue, Apr 13, 2010 at 1:09 PM, Robby Findler > <[email protected]> wrote: >>> >>> 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. > > I don't know what this means. For example, the OCaml code: > > match (x : (int,int)) with > (7,z) -> ... > | (_,z) -> ... > > is complete, and therefore no warning would be issued. If you use > general list patterns in OCaml: > > match (x : int list) with > [7,z] -> ... > | [_,z] -> ... > > you'll get a warning about pattern incompleteness. I don't think this > warning is useful, given the contract I specified. > > Further, ML checks the completeness of patterns in `let' using the > type system, which `match' can't do. For example, this code: > > (match-let ([(list x ...) (map add1 some-list]) > ...) > > clearly doesn't cover the case where `map' doesn't produce a list. > That's impossible, but `match-let' doesn't know that, so it would have > to issue a warning. Would you find that warning useful? I don't > think I would. > -- > sam th > [email protected] > _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
