More F# neat features
-
Option types[^] In ideal world that would eliminate the use of
Null(which was a billion dollar mistake[^] as admitted by its inventor Tony Hoare). Unfortunatelly, the world is not ideal, and when you use types from .NET framework,Nullstill needs to be taken into account[^]. Backwards compatibility at its best :)Sorry, but I (and I believe that many other people) fail to understand why/how "None" is different from "Null". Since it represents a non-value, why is it better? I probably didn't understand correctly, but for me there's no difference between "Option" in F# to Nullable types in C# and its "??" operator.
I see dead pixels Yes, even I am blogging now!
-
Sorry, but I (and I believe that many other people) fail to understand why/how "None" is different from "Null". Since it represents a non-value, why is it better? I probably didn't understand correctly, but for me there's no difference between "Option" in F# to Nullable types in C# and its "??" operator.
I see dead pixels Yes, even I am blogging now!
It is safer and harder to ignore. If a method returns an option - you get an option type as a result and then match cases for 'Some' and 'None'. If a method returns i.e. a string, nothing tells you that Null is a possible result. Sure, you can check each and every return value for Null, but with options it is easier and safer: if a "not exists" is a valid value, you get an option type; if it isn't, there is nothing to check - the reference points to a valid object. Haskell Maybe monad[^] serves a similar purpose and in C++ there is Boost.Optional[^] library,
-
It is safer and harder to ignore. If a method returns an option - you get an option type as a result and then match cases for 'Some' and 'None'. If a method returns i.e. a string, nothing tells you that Null is a possible result. Sure, you can check each and every return value for Null, but with options it is easier and safer: if a "not exists" is a valid value, you get an option type; if it isn't, there is nothing to check - the reference points to a valid object. Haskell Maybe monad[^] serves a similar purpose and in C++ there is Boost.Optional[^] library,
That still makes no sense; you still have to either always check for None or know that None may be a result of an operation. To use the cliche, it's six one way, half-dozen the other. In other words, there is still no free lunch, just overhead.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
It is safer and harder to ignore. If a method returns an option - you get an option type as a result and then match cases for 'Some' and 'None'. If a method returns i.e. a string, nothing tells you that Null is a possible result. Sure, you can check each and every return value for Null, but with options it is easier and safer: if a "not exists" is a valid value, you get an option type; if it isn't, there is nothing to check - the reference points to a valid object. Haskell Maybe monad[^] serves a similar purpose and in C++ there is Boost.Optional[^] library,
Would introducing a
Maybe<T>struct into the framework accomplish the same thing? Obviously, there would have to be widespread support throughout the APIs, and tons of things would break, but I'm just thinking aloud here.Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
That still makes no sense; you still have to either always check for None or know that None may be a result of an operation. To use the cliche, it's six one way, half-dozen the other. In other words, there is still no free lunch, just overhead.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
you still have to either always check for None or know that None may be a result of an operation
No, you don't. If a method can return None, the return type will be an option. If it cannot return None, the return type will be whatever the type is and you don't need to (or can, for that matter) check for None. An example in a pseudo-language:
// declarations
option(string) find_string();string get_string();
...
// usagestring s = get_string(); can't be None - no need to check
option(string) os = find_string(); // can be None, we'd better check
if (os.is_None())
report_not_found();
else
s = os.get_value(); -
Would introducing a
Maybe<T>struct into the framework accomplish the same thing? Obviously, there would have to be widespread support throughout the APIs, and tons of things would break, but I'm just thinking aloud here.Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
Judah Himango wrote:
Would introducing a Maybe struct into the framework accomplish the same thing?
I don't think it can be introduced at this point, but that's what should have been done, IMHO.
-
Joe Woodbury wrote:
you still have to either always check for None or know that None may be a result of an operation
No, you don't. If a method can return None, the return type will be an option. If it cannot return None, the return type will be whatever the type is and you don't need to (or can, for that matter) check for None. An example in a pseudo-language:
// declarations
option(string) find_string();string get_string();
...
// usagestring s = get_string(); can't be None - no need to check
option(string) os = find_string(); // can be None, we'd better check
if (os.is_None())
report_not_found();
else
s = os.get_value();Your example is bogus. You still HAVE to know if a return value can be None.
string s = get_string(); can't be null - no need to check
string os = find_string(); // can be null, we'd better check
if (os == null)
report_not_found();
else
s = os;Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Your example is bogus. You still HAVE to know if a return value can be None.
string s = get_string(); can't be null - no need to check
string os = find_string(); // can be null, we'd better check
if (os == null)
report_not_found();
else
s = os;Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
You still HAVE to know if a return value can be None.
The return type tells me if a return value can be None.
string s = find_string(); // compile error - the return type is option, not string
-
Judah Himango wrote:
Would introducing a Maybe struct into the framework accomplish the same thing?
I don't think it can be introduced at this point, but that's what should have been done, IMHO.
Interesting. At least for future projects, that may be something to keep in mind -- introduce a Maybe<T> and use that when there might be nulls.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Option types[^] In ideal world that would eliminate the use of
Null(which was a billion dollar mistake[^] as admitted by its inventor Tony Hoare). Unfortunatelly, the world is not ideal, and when you use types from .NET framework,Nullstill needs to be taken into account[^]. Backwards compatibility at its best :)My language works better:-
NSString* x = nil;
[x upperCaseString]; // Never crashes
Yes in Objective C it is OK to call methods (send messages) to nil object(s). ;P
-
Joe Woodbury wrote:
You still HAVE to know if a return value can be None.
The return type tells me if a return value can be None.
string s = find_string(); // compile error - the return type is option, not string
-
Option types[^] In ideal world that would eliminate the use of
Null(which was a billion dollar mistake[^] as admitted by its inventor Tony Hoare). Unfortunatelly, the world is not ideal, and when you use types from .NET framework,Nullstill needs to be taken into account[^]. Backwards compatibility at its best :)Also a C++ feature if you use Boost[^] :-) I prefer the Haskell implementation[^], though - mainly because (unlike F# and OCaml) it's not a special case builtin type, although it feels like one, because it can utilise Haskell's type classes to fit in liek a builtin type.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
so instead of looking up the return values for a function that returns a pointer, which could be null & which you should check, you state that it would be better to do what exactly?
bulg wrote:
so instead of looking up the return values for a function that returns a pointer, which could be null & which you should check, you state that it would be better to do what exactly?
Declare the function to return an option type and then if you try to assign the return value directly to a pointer without checking for null, you get a compile error.
-
Would introducing a
Maybe<T>struct into the framework accomplish the same thing? Obviously, there would have to be widespread support throughout the APIs, and tons of things would break, but I'm just thinking aloud here.Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
That would violate basic principles of Boolean logic, developed by George Boole, in which everything either is or isn't. Fortunately his wife, Mary, extended his work to incorporate a third state in logic, "maybe" (some texts refer to this value as "that depends"). I say 'fortunately' because, without this logical extension, it would have been impossible for women to become programmers. Limiting them to simple choices between "true" and "false" is cruel, and ultimately crippling. Programming would have been consigned to pale, nervous, socially backward, and very lonely men if George had got the final word. But what were the odds of that happenning?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
My language works better:-
NSString* x = nil;
[x upperCaseString]; // Never crashes
Yes in Objective C it is OK to call methods (send messages) to nil object(s). ;P
Heh, interesting. Do you also send messages to ask for data, e.g. var result = Foo.Bar? What happens when you ask for a result from a nil object?
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Would introducing a
Maybe<T>struct into the framework accomplish the same thing? Obviously, there would have to be widespread support throughout the APIs, and tons of things would break, but I'm just thinking aloud here.Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
it's called Nullable<T> which itself is a value type and therefore cannot be null.
-
That would violate basic principles of Boolean logic, developed by George Boole, in which everything either is or isn't. Fortunately his wife, Mary, extended his work to incorporate a third state in logic, "maybe" (some texts refer to this value as "that depends"). I say 'fortunately' because, without this logical extension, it would have been impossible for women to become programmers. Limiting them to simple choices between "true" and "false" is cruel, and ultimately crippling. Programming would have been consigned to pale, nervous, socially backward, and very lonely men if George had got the final word. But what were the odds of that happenning?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Roger Wright wrote:
But what were the odds of that happenning?
one would say 50%, given the possible boolean logic results. obviously it was 0%.
-
it's called Nullable<T> which itself is a value type and therefore cannot be null.
Doesn't work for this situation.
Nullable<T>only works with value types; the only reason we'd introduceMaybe<T>is for reference types.Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon Judah Himango
-
Roger Wright wrote:
But what were the odds of that happenning?
one would say 50%, given the possible boolean logic results. obviously it was 0%.
That depends... ;P
"A Journey of a Thousand Rest Stops Begins with a Single Movement"