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 <>:

>> 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.