Skip to main content
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