Re: datatype constructor as syntax

On Tue, Jan 07, 2014 at 08:42:43PM -0800, Thant Tessman wrote:
> 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?

>From a practical perspective, it is sometimes useful to use datatype
constructors in function bindings with records, to ease type inference.

For example:

	type foo = {bar: int, baz: int, bax: string}
	fun quux {bar, baz, ...} = bar + baz

This will give an error, because foo doesn't have exclusive
use of the fields bar and baz, so the compiler doesn't know
what the ... is really referring to.

So you can do this:

	type foo = {bar: int, baz: int, bax: string}
	fun quux ({bar, baz, ...}: foo) = bar + baz

But some people prefer:

	datatype foo = Foo of {bar: int, baz: int, bax: string}
	fun quux (Foo {bar, baz, ...}) = bar + baz

Also, since (for some reason I don't really understand) you can't make
recursive aliases, but you can make recursive datatypes, it's sometimes
necessary to make a datatype with only one constructor. In this case,
allowing the datatype to be deconstructed in the function argument
is convenient, and perfectly safe.

But aside from all that, I think it's a bit easier to understand the
language when you have only one pattern-matching syntax (constructors
allowed everywhere) to remember, rather than two (one with constructors,
one without).

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