caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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

  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;
as well as URLs for NNTP newsgroup(s).