Algebraic Data Types in D?

[Timon Gehr via Digitalmars-d]

On 08/01/2014 05:28 PM, Andrei Alexandrescu wrote:
> On 8/1/14, 7:18 AM, Timon Gehr wrote:
>> It might also be possible that this is what is actually wanted:
>>
>> alias Foo = Algebraic!(int,Algebraic!(This[],double)[]);
>>
>> (I.e. This refers to the inner type.)
>>
>> There is always this issue as well:
>> alias ListInt=Algebraic!(Tuple!(),Tuple!(int,ListInt*));
>>
>>
>> How would you use the proposed enhancement to fix this?
>
> I don't think there's an easy way.
> ...

It's hard to fix without Fix! :o)

>
>>>> There is also this kind of approach:
>>>>
>>>> mixin ADT!q{
>>>>   List(T):
>>>>   | Nil
>>>>   | Cons T List!T
>>>> };
>>>
>>> Interesting! Is there code available for that?
>>> ...
>>
>> You can find an incomplete proof-of-concept implementation here:
>> http://dpaste.dzfl.pl/77abae58a087
>> (The 'match' is not particularly great, opEquals is missing, etc.)
>> It was quite hard to get past the compiler.
>
> On a cursory inspection, looks good! The question there is whether you

Actually yes, but I currently have a backlog of work to do, partly due 
to having been involved in a strange debate about the meaning of words.

> or anyone would be interested in taking that to a proposal.
> ...

I wouldn't be opposed to that option. Any volunteers willing to take up 
the effort?

>>> Well one other way to look at it is that striving to do things in a
>>> library pushes introspection forward.
>>> ...
>> ...
>>
>> In any case, having a template Fix operator would sometimes be
>> convenient:
>>  ...
>>
>> the most natural implementation of Fix does not work for obvious reasons:
>>
>> alias Fix(alias F)=F!(Fix!F);
>>
>> Making this work is not completely out of reach though, I think.
>>
>> The best I can currently do to "save" 'Algebraic' is the following:
>> http://dpaste.dzfl.pl/65afd3a7ce52
>
> That's interesting. Fix is worth making to work either as a built-in on
> a library artifact.
> ...

Agreed. The fact that the above 'iso-recursive' approach works now may 
serve as an implication that most relevant assumptions that templates 
may make about their parameters that are broken by a fix operator 
weren't valid before either.

I have a very strong suspicion that Fix cannot be implemented without 
modifying the language a little bit, but I'd be happy to be proven wrong.

>
> Andrei