Back to Questions
2.1k
views3
comments
Anonymous discriminated unions/enumerations might be useful
f#plugin

Stealing an example from the bottom of the WordPress coding standards page, this:

1
2
3
4
5

function eat( $what, $speed = 'slowly' ) {
    ...
}

eat( 'mushrooms', 'slowly' );

is better than this:

1
2
3
4
5
6

function eat( $what, $slowly = true ) {
    ...
}

eat( 'mushrooms' );
eat( 'mushrooms', true ); // what does true mean?

because with the latter, it's not very clear what the purpose of the second argument is.

But in the .NET community most of us value strong typing, so we would never pass an argument of finite and few values as a string; instead, we would make an enumerable type:

1
2
3

type eatingSpeed =
   | Slow
   | Fast

Sometimes this is excruciatingly tedious, especially if these types are only of interest to one particular function. This is especially true when we're modeling a complex system or a document model with a lot of exposed functions, for instance, a plugin API.

A solution, which might be conveniently in line with the frequent request for anonymous types, is anonymous discriminated unions and anonymous enumerations. Consider how cool this might be:

1
2
3
4

let eat speed food =
   match speed with new type
   | Slowly -> Seq.iter(nibble) food
   | Fast -> Seq.iter(gobble) food

eat Slowly "bacon and eggs"

Also if there's ever a need for more options, there's only one point of code that needs to be changed, as opposed to two or three (or, if the argument was a boolean, having to switch its type entirely):

1
2
3
4
5

let eat speed food =
   match speed with new type
   | Slowly -> Seq.iter(nibble) food
   | Fast -> Seq.iter(gobble) food
   | ReallyFast -> Seq.iter(omnomnom) food

Type inference takes care of any situations in which you might need to pass the "speed" argument from one function to another, but for a situation in which the type needs to be exposed, it could be annotated either as an argument to the keyword or as a CLI attribute:

1
2
3

let eat speed food =
   match speed with [＜TypeName("EatingSpeed")>] new type // or more conveniently, match speed with new type ("EatingSpeed")
   ...

By the way, how do you format code on this forum? I still haven't figured it out.

.

Active patterns can be viewed as "anonymous DU's" in some sense, so that's one option:

1
2
3
4
5
6
7

 
let (|Slow|Fast|) speed = ...

let eat speed food = 
   match speed with
   | Slow -> ...
   | Fast -> ...

Also, there are named arguments - they don't work for let-bound fn's, but for "programming in the large" where it matters, I think you're getting what you need here with:

1
2
3
4
5

 
type EatSpeed = | Slow | Fast
  member this.eat(what:string, ?speed: EatSpeed = Slow) = ...
...
eat( "mushrooms", speed=Fast)

So you still have to define EatSpeed (which is good), and you solve your issue of "not very clear what the purpose of the second argument is".

By on 6/18/2010 8:37 AM ()

They might be useful (but really, is it that much work to add the line

type EatingSpeed = | Slowly | Fast

to the code? I think this is a rare case to want this; I recall wanting it only a handful of times in the past five years). It isn't immediately clear how this would work with name-resolution (what is the scope of 'Fast'?), or more general pattern matching (can I match a tuple of (Slowly,x)?), or probably a few other issues I haven't thought of. Anonymous types like this present a variety of new tooling questions/challenges (what does the hover-tooltip say over 'Fast'?), though none insurmountable. To quote Eric Lippert:

[link:blogs.msdn.com]

I am asked "why doesn't C# implement feature X?" all the time. The answer is always the same: because no one ever designed, specified, implemented, tested, documented and shipped that feature. All six of those things are necessary to make a feature happen. All of them cost huge amounts of time, effort and money. Features are not cheap, and we try very hard to make sure that we are only shipping those features which give the best possible benefits to our users given our constrained time, effort and money budgets.

In addition, every feature 'adds concept count', makes every book on F# a page heavier, etc. New features start of with -1000 points. So yeah, this feature might be nice, but I doubt we would add a feature just to save a line of code in this rare case.

Regarding code formatting, see [link:cs.hubfs.net]

By on 6/17/2010 6:17 PM ()

It isn't immediately clear how this would work with name-resolution (what is the scope of 'Fast'?), or more general pattern matching (can I match a tuple of (Slowly,x)?), or probably a few other issues I haven't thought of. Anonymous types like this present a variety of new tooling questions/challenges (what does the hover-tooltip say over 'Fast'?)

Ah, I never thought about all that. I sorta naively thought that if anonymous types (records, in specific) would ever be implemented, this might come almost as a freebie.

Thanks for the link on formatting.

By on 6/18/2010 5:50 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper