[External] : Re: Telling the totality story

[Brian Goetz]

On 3/4/2022 5:37 AM, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Brian Goetz" <brian.goetz at oracle.com>
>     *To: *"Remi Forax" <forax at univ-mlv.fr>
>     *Cc: *"amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>     *Sent: *Friday, March 4, 2022 3:23:58 AM
>     *Subject: *Re: [External] : Re: Telling the totality story
>
>
>
>             #### Let
>
>             This is where it gets ugly.  Let has no opinions about
>             null, but the game here is to pretend it does.  So in a
>             let statement:
>
>                 let P = e
>
>              - Evaluate e
>              - If e is null
>                - If P is a covering pattern, its binding is bound to null;
>                - else we throws NPE
>              - Otherwise, e is matched to P.  If it does not match
>             (its remainder), a MatchException is thrown (or the else
>             clause is taken, if one is present.)
>
>
>         It's not clear to me why a MatchException should be thrown
>         instead of not compiling if not exhaustive.
>
>
>     You're confusing "exhaustive" and "total".  A let must be
>     exhaustive, but exhaustiveness != totality.
>
>         It's mean that there are remainders that does not lead to
>         either a NPE or an error, do you have an example of such
>         remainder ?
>
>
>     Yes.  Suppose we have records Box<T>(T t) and Pair<T, U>(T t, U
>     u), and A is sealed to B|C.  Then if we're matching on a
>     Pair<Box<A>, A>, then
>
>         Pair(null, B)
>         Pair(Box(B), D)  // D is a type from the future
>         Pair(Box(D), B)
>         Pair(Box(D), D)
>         Pair(null, D)
>
>     are all in the remainder.  It is a big stretch to claim either NPE
>     or ICCE is right for any of these, and completely arbitrary to
>     pick one for Pair(null, D).  Also, its much more expensive to try
>     to distinguish between these, and pick the "right" error for each,
>     rather than insert a default clause that throws
>     MatchRemainderException. 
>
>
> The exception are here because the view at runtime and the view at 
> compile time are slightly different
> - an NPE is raised when a value is null but the pattern ask for a 
> deconstruction
> - an ICCE if the compiler has use a sealed type during it's analysis 
> and the sealed type has changed

This was a thread about pedagogy.  You asked a factual question (though 
tangential) for clarification, which is fine, and got an answer.  But 
then you used the answer to spin off into a "let me redesign a feature 
that is unrelated to the thread."  That's not so good.

There actually was a thread about exceptions, where we could have 
discussed this (and we did, I think; these points here mostly seem 
repeated.)  By diverting this thread, it means we may not get back to 
the main point -- something I put time into because I wanted feedback.  
So far, we're three replies-to-replies into the weeds, and no one has 
talked about pedagogy.  And likely, no one will, because once a thread 
has been diverted, it rarely comes back.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220304/f6b4f564/attachment.htm>