[Mono-dev] Program Option Parsing Library

Jonathan Pryor jonpryor at vt.edu
Sun Jan 13 19:17:04 EST 2008

On Sun, 2008-01-13 at 12:00 -0800, Jay Logue wrote:
> Looking good!
> > One final note: due to the above Action change, I'm using Action`2,
> > which is specific to .NET 3.5.  Localization is via Func`3, which is
> > specific to .NET 3.5.
> I guess I don't really understand why its important to use Action and 
> Func here, verses custom types (e.g. void OptionAction<T>(T v, 
> OptionContext c) ).

The combinatorial properties of intermixing delegate types.  In the
(fast approaching) functional paradigm world we're migrating to, the
fewer distinct types which represent the same concept, the better.  

(Otherwise you'll need increasing amounts of "glue" in order to fit two
otherwise compatible delegate instances together, when ideally they'd
either be directly callable or the compiler could work it's type
inferencing magic and write the glue code for you.  This is because you
can't simply assign one delegate instance to another delegate instance
when they share identical argument lists & return types, instead you
need to use a `new' expression to convert one to the other.)


	Func<string,string> f = s => s;
	Converter<string,string> g = f; // error CS0029
	Converter<string,string> h = new Converter<string,string>(f);
	  // OK

Now try to imagine doing that within generics code.  (I don't think you

Make no mistake: there's *lots* of work going on (e.g. [0]) in bringing
ever greater amounts of functional concepts to C#, and multiple distinct
types which merely alias each other will hinder combining separately
developed pieces of code, instead of making things easier.

[0] http://blogs.msdn.com/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx

I really wish they'd added Func and the Action overloads to .NET 2.0...

> On a related note, could the translation delegate be simplified to 
> Converter<string, string> and just used to translate the format string?

That makes a great amount of sense, actually.  Consider it done.

On a final note, Alp Toker was kind enough to offer space on ndesk.org
for hosting, so (along with a few namespace & type name changes --
s/Mono.Documentation.Options/NDesk.Options.OptionSet/g) you can find
future changes at:


 - Jon

More information about the Mono-devel-list mailing list