From: "Christoph Höger" <christoph.hoeger@tu-berlin.de>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Expansion of type-constructors in ctype.ml
Date: Mon, 24 Aug 2015 08:22:59 +0200 [thread overview]
Message-ID: <55DAB843.5010800@tu-berlin.de> (raw)
In-Reply-To: <0D467B24-3C94-4640-8264-85BE5312EB55@math.nagoya-u.ac.jp>
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
Am 24.08.2015 um 00:18 schrieb Jacques Garrigue:
> This is indeed a pretty difficult problem, as you must be careful of not
> changing the semantics of unification.
> Until recently, the only solution was to expand the type, as there was
> no static information cacheing whether an argument was used in the
> body or not.
> However, since relatively recent changes about variance information
> (the switch to 7 flags…), we actually have at least an approximation
> of which unifications must be done imperatively, and which needn’t
> be done at all.
> So it might be doable at least for part of the parameters.
That sounds interesting. What are the relevant variance flags?
> I would have to see the code to tell you more.
> As stated above, the real problem is the length of the cycles in the expanded
> graph.
I really do not think that this is related to any cycles. It is just
about large unfolded types. I attached a script to generate a meaningful
example. When I try to run ocamlbuild m_9.cmo, it takes ~30s already. A
preliminary patched version of the ocaml compiler can handle this
particular example in pretty much no time at all.
regards,
Christoph
--
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
[-- Attachment #2: create.zsh --]
[-- Type: text/plain, Size: 462 bytes --]
#!/usr/bin/env zsh
for ((i = 1 ; i < 10 ; i++)) ; do
echo "class ['a] c (a : 'a) = object" > m_$i.ml
echo " method m_1 = (new M_$((i-1)).c) a#foo" >> m_$i.ml
echo " method m_2 = (new M_$((i-1)).c) a#foo" >> m_$i.ml
echo " method m_3 = (new M_$((i-1)).c) a#foo" >> m_$i.ml
echo " method m_4 = (new M_$((i-1)).c) a#foo" >> m_$i.ml
echo "end" >> m_$i.ml
done
echo "class ['a] c (a : 'a) = object method m_1 = a#foo method m_2 = a#foo end" > m_0.ml
next prev parent reply other threads:[~2015-08-24 6:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-22 7:42 Christoph Höger
2015-08-22 9:23 ` Jeremy Yallop
2015-08-22 11:41 ` Christoph Höger
2015-08-23 22:18 ` Jacques Garrigue
2015-08-24 6:22 ` Christoph Höger [this message]
2015-08-24 10:15 ` Christoph Höger
2015-08-25 14:02 ` Jacques Garrigue
2015-08-25 15:47 ` Christoph Höger
2015-08-26 1:26 ` Jacques Garrigue
2015-11-05 11:29 ` Goswin von Brederlow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55DAB843.5010800@tu-berlin.de \
--to=christoph.hoeger@tu-berlin.de \
--cc=caml-list@inria.fr \
--cc=garrigue@math.nagoya-u.ac.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox