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
