Re: Top 10 Worst C# Features

[Peter Chapin <PChapin@vtc.vsc.edu>]

In article <d4vhcnF9eulU1@mid.individual.net>, 
niklas.holsti@tidorum.invalid says...

> I have long wished for an easier way to return multiple results from a 
> call, especially when the set of results that is really available 
> depends on the run-time outcome of the call, for example on whether the 
> called operation succeeded or failed in some way.

Functional languages have thought about this. Most provide a way of 
defining a kind of variant record with very lightweight syntax so 
defining a new record for each use isn't onerous.

As an example Scala (for instance) has an Option type in its library 
specifically for use by functions that may not have a valid value to 
return. A function that might or might not return an integer can be 
declared to run an Option[Int] (like a generic instance) that either 
holds the integer in question or has the special value None. This can be 
simulated in Ada without too much pain but what makes functional 
languages different is that it is easy to define and use variations of 
this idea without a lot of ceremony.

> Then it should be possible to call a procedure in a way that opens a 
> block that implicitly starts with a case statement and separates into 
> different branches for different outcomes...

This is done using pattern matching in functional languages which, as 
you observe, complements the features above very nicely. Actually Scala 
provides higher order methods on the Option type that allows you, in 
that case, to operate on data that might or might not be there without 
worrying about checking for its existence until the last minute. This 
pushes error handling out of the main logic of your program without 
using exceptions for that purpose.

I'm not sure how possible it would be to retrofit these ideas into Ada. 
I'm going to guess it would be hard. Ada is not a functional language 
and as soon as you start walking down the path I'm talking about here 
you end up dragging in a lot of the usual functional machinery.

Peter