Re: [Caml-list] Expansion of type-constructors in ctype.ml

["Christoph Höger" <christoph.hoeger@tu-berlin.de>]

Am 25.08.2015 um 16:02 schrieb Jacques Garrigue:
> Do you mean that modifying moregen and eqtype (but not unify)
> in a conservative way would be enough to solve your problem?

At least until now, it seems to solve it. I can compile my ~12k classes
in ~20min now. I expect the number of classes to decrease while I
optimize the output of my compiler and their size to increase while I
add more features. So the best bet is that the performance will stay the
same, unless I encounter some more performance problems.

Btw: Is there a place/format to discuss concrete proposed patches? This
list seems to be more on the user's side.

> Then indeed we could do that.
> At least your code for eqtype seems fine. For moregen, this is not sufficient, due to non-local side effects.
> By the way, we should keep your example around to prevent regressions.

Feel free to add the example wherever you want. I can also open a bug in
mantis if you think that is appropriate. Do you have any insights on
what could be done for moregen?

> You should read the following paper:
> http://www.math.nagoya-u.ac.jp/~garrigue/papers/injectivity.pdf

Thanks. Will do.

> may_pos and may_neg are both unset (i.e. nothing is set) => no need to recurse
> inj is set => must recurse
> otherwise => must expand

Sounds like inj is what I want for my concrete case. I recon there is no
flag yet to manually set it. Do you know of a trick to force the
inference mechanism to do so?

And by "no need to recurse" you mean that this argument could be left
out (i.e. replaced by unit)?



-- 
Christoph Höger

Technische Universität Berlin
Fakultät IV - Elektrotechnik und Informatik
Übersetzerbau und Programmiersprachen

Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin

Tel.: +49 (30) 314-24890
E-Mail: christoph.hoeger@tu-berlin.de