Truly algebraic Variant and Nullable

Paul Backus snarwin at gmail.com
Tue Dec 22 14:46:00 UTC 2020


On Tuesday, 22 December 2020 at 03:56:13 UTC, 9il wrote:
> On Sunday, 20 December 2020 at 11:00:05 UTC, Tobias Pankrath 
> wrote:
>> On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:
>>> Truly algebraic Variant and Nullable with an 
>>> order-independent list of types.
>>
>> Thanks for sharing it!
>>
>> Could you give a (very short) explanation on why sumtype could 
>> not meet your requirements? I am just starting a new D project 
>> and have to choose between sumtype and your solution.
>>
>
> Lets users do comparisons between libraries. Both are very good.
>
> Some mir.algebraic features:
>
> [...]
>
> Mir implements Algebra of (type) sets with reflections 
> (functions) on it.

It seems like in general, the philosophy of sumtype is to provide 
the minimal set of features necessary to cover all possible 
use-cases ("mechanism, not policy"), whereas the philosophy of 
mir.algebraic is to include a large number of convenience 
features out-of-the-box.

The upside of mir.algebraic's approach is that it is easier to 
get started with. The downside is that, if you later discover 
that the convenience features are not quite what you want, you 
will be stuck reimplementing them yourself anyway--and at that 
point, the built-in versions will only get in your way.

They also introduce a lot of incidental complexity to the 
library. Take a look at the documentation [1] and you'll see a 
giant table describing the subtle differences in behavior between 
12 (!) distinct accessor functions. By comparison, sumtype has 
exactly one accessor function, "match" [2], whose full behavior 
is documented in about the same amount of space.

[1] http://mir-core.libmir.org/mir_algebraic.html
[2] https://pbackus.github.io/sumtype/sumtype.match.html


More information about the Digitalmars-d-announce mailing list