Timeline for Does it make sense to have both the concept of 'null' and 'Maybe'?
Current License: CC BY-SA 3.0
19 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jan 4, 2017 at 10:23 | answer | added | gnasher729 | timeline score: 1 | |
Dec 31, 2016 at 7:51 | comment | added | JDługosz | Yes! I recall the inventer of relational databases later published a paper on “4 value logic” pretty much as you indicate. See en.wikipedia.org/wiki/Four-valued_logic | |
Dec 31, 2016 at 6:24 | comment | added | amalloy |
@EricLippert Even in the specific case of m ~ Maybe , there is some use in having a double wrapping. Suppose you use a map as a cache, caching results of calls to a function of type a -> Maybe b . Then Nothing means "this result is not cached", and Just Nothing means "This result has been cached, and the answer is Nothing ". But of course I do agree that using Maybe (Maybe a) for this particular problem is no good.
|
|
Dec 30, 2016 at 23:13 | comment | added | Eric Lippert | 3-valued logics become tricky; here's just one issue. Consider a function G that returns T, F or X, and an expression "T or G()". Does G() have to be evaluated? If X means "I don't know whether it is T or F, but it is one of them", then no; the expression is known to be T regardless of the value returned. If X means "an error should be propagated" then yes, it does have to be evaluated. For C# we simply punted; you cannot use nullable booleans and short-circuiting operators together. | |
Dec 30, 2016 at 22:19 | comment | added | einpoklum |
In the context of your question, 3-valued logic could be taken to mean logic on type Maybe<boolean> as opposed to plain boolean (not being language-specific here of course).
|
|
Dec 30, 2016 at 21:17 | comment | added | Eric Lippert | @AndrejBauer: That's a good point; I should have been more clear in calling that out. | |
Dec 30, 2016 at 20:25 | comment | added | Andrej Bauer |
@EricLippert: it is false that "M (M x) and M x should have the same semantics". Take M = List for instance: lists of lists are not the same thing as lists. When M is a monad, there is a transformation (namely the monad multiplication) from M (M x) to M x which explains the relationship between them, but they do not have "the same semantics".
|
|
Dec 30, 2016 at 19:07 | vote | accept | Stijn | ||
Dec 30, 2016 at 16:22 | answer | added | coredump | timeline score: 3 | |
Dec 30, 2016 at 16:04 | comment | added | Euge |
Yes, I wouldn't use Maybe Maybe either. But, in fact, just as Maybe a is the same as $a + 1$, semantically, Maybe Maybe a is the same as $a+1+1$, and isomorphic to UserInput a type from @Andej answer. You could define your own monad instance for this type too and therefore use different monad combinators.
|
|
Dec 30, 2016 at 15:33 | comment | added | Stijn | @EricLippert Thank you for your comments. Interesting bit of info about VB. | |
Dec 30, 2016 at 15:24 | comment | added | Eric Lippert | You might consider looking at the design of early versions of Visual Basic, which had Nothing (reference to no object), Null (database null semantics), Empty (a variable not initialized), and Missing (an optional parameter was not passed). This design was complicated and in many ways inconsistent, but there is a reason why those concepts were not conflated with each other. | |
Dec 30, 2016 at 15:19 | comment | added | Eric Lippert |
Do not make a maybe-maybe-foo that has different semantics than a maybe-foo. Maybe is a monad, and one of the monad laws is that M M x and M x should have the same semantics.
|
|
Dec 30, 2016 at 15:12 | history | tweeted | twitter.com/StackCompSci/status/814851550724157440 | ||
Dec 30, 2016 at 14:25 | answer | added | Euge | timeline score: 4 | |
Dec 30, 2016 at 14:23 | answer | added | Andrej Bauer | timeline score: 14 | |
Dec 30, 2016 at 14:16 | comment | added | Andrej Bauer |
It does not make sanse to have null . It is a thoroughly broken idea.
|
|
Dec 30, 2016 at 13:42 | review | First posts | |||
Dec 30, 2016 at 18:53 | |||||
Dec 30, 2016 at 13:41 | history | asked | Stijn | CC BY-SA 3.0 |