[plt-dev] coding ideas from JaneStreet

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 <samth at ccs.neu.edu> wrote:
> On Tue, Apr 13, 2010 at 1:09 PM, Robby Findler
> <robby at eecs.northwestern.edu> 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
> samth at ccs.neu.edu
>