Re: datatype constructor as syntax
Andreas Rossberg <[email protected]>
| Newsgroups | gmane.comp.lang.ml.mlton.user |
|---|---|
| Message-ID | <[email protected]> |
On Jan 8, 2014, at 05:42 , Thant Tessman <[email protected]> wrote: > 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: >>>> 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? You need to separate two independent topics here: - Context-dependence of constructor status: this is a problem that is no better in case expressions than in bindings. So banning patterns from just bindings doesn’t help at all. The solution used by e.g. both OCaml and Haskell is to enforce a syntactic distinction: constructors have to be upper-case, plain values lower-case. It’s a bit of a hack (especially wrt symbolic names), but works quite well in practice. - Exhaustiveness of patterns in bindings: SML does not ban inexhaustive case expressions or inexhaustive functions, so why should it do so for bindings? It does require warnings in all cases (with the single lame exception I mentioned), which seems to be a reasonable solution. Moreover, destructuring sum types in bindings is useful for singular sums (of which you can have quite a few in practice, since they are needed e.g. to define recursive types), as well as in interactive use. I would have preferred SML to use the OCaml/Haskell solution for differentiating constructors, but random restrictions on patterns seem neither useful nor desirable. /Andreas 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