Re: datatype constructor as syntax
Thant Tessman <[email protected]>
| Newsgroups | gmane.comp.lang.ml.mlton.user |
|---|---|
| Message-ID | <[email protected]> |
On Jan 2, 2014, at 9:44 AM, Andreas Rossberg <[email protected]> wrote: > On Jan 2, 2014, at 15:28 , Thant Tessman <[email protected]> wrote: >> On Jan 2, 2014, at 12:51 AM, Andreas Rossberg <[email protected]> wrote: >>>> On top of that, when I enter this interactively in SML/NJ, there is no warning. However, I just tried it with MLton, and it does indeed produce a warning: >>> >>> It is mandatory that inexhaustive bindings produce a warning, _except_ on the toplevel (try “let val bar j = i in j end” for contrast). >> >> I thought of that, but SML/NJ gives no warning even when the construction isn't at the top level: > > Hm, indeed. Technically that’s a bug. (Though perhaps an intentional one?) Yes, this is the heart of my question. Pattern matching makes beautiful sense in the case of product types (tuples and records). Is it as defendable in the case of sum types? The fact that SML gave up a context-free grammar along with allowing for such constructs in support of it is, to me, circumstantial evidence against it. For argument's sake, I posit that it should be solely the job of the case statement to 'disassemble' a sum type. (Or specializations thereof such as the 'if' statement.) Am I missing something? -thant To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk