Re: Maybe macros Marc Nieper-WiÃkirchen 26 Jun 2020 18:57 UTC
Am Fr., 26. Juni 2020 um 20:48 Uhr schrieb John Cowan <firstname.lastname@example.org>: >> Note that we can get rid of maybe-and maybe-or if we change the >> semantics of SRFI 189 and set Nothing := #f. > > > A significant advantage of not doing this in a dynamically typed system is that Maybes are disjoint from everything that isn't a Maybe. Allowing the Maybe and boolean types to overlap means that code dispatching on Maybe vs. non-Maybe types has to decide what to do with Nothing/#f. In statically typed systems, such actions are normally not possible. Scala has both an Option type with an explicit Nothing and nullable types (where null inhabits every type), and the result is a mess. I don't have a strong opinion about fusing Nothing with #f as I see benefits (for example `if', `and', `or' can be used directly with Maybes without any overhead, which is always good for a language that is much harder to optimize than C) but also disadvantages because the semantic model becomes a bit less clear. I am not sure, though, whether we want to encourage code that does dynamic dispatching between a Maybe and boolean types. Dynamic dispatching makes sense for something like the Scheme number tower where the types are related in a hierarchie, but a procedure that wants to behave polymorphically with respect to Maybes and booleans should be split into two. > Only #f is technically falsy in the sense that conditionals treat it as false. The others are signal objects, and sometimes #f is too. Each is suited to a different situation, and this SRFI provides interoperation between them. While #f is the only technically falsy value, the other values are, depending on the context, logically likewise singular values.