From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 8142EBC69 for ; Wed, 29 Aug 2007 16:58:18 +0200 (CEST) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7TEwGQi022809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Aug 2007 16:58:18 +0200 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id l7TEwGSf010605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 Aug 2007 16:58:16 +0200 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id l7TEwGEo010602 for caml-list@inria.fr; Wed, 29 Aug 2007 16:58:16 +0200 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-096-037.pools.arcor-ip.net (dslb-088-073-096-037.pools.arcor-ip.net [88.73.96.37]) by webmail.in-berlin.de (IMP) with HTTP for ; Wed, 29 Aug 2007 16:58:16 +0200 Message-ID: <1188399496.46d589880d7a3@webmail.in-berlin.de> Date: Wed, 29 Aug 2007 16:58:16 +0200 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] how to upset the ocaml type system.... References: <20070828131850.GA32264@pulp.rsise.anu.edu.au> <20070829005634.GA7888@yquem.inria.fr> <46D55122.2090709@univ-savoie.fr> In-Reply-To: <46D55122.2090709@univ-savoie.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at concorde with ID 46D58988.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 ocaml:01 christophe:01 raffalli:01 christophe:01 raffalli:01 univ-savoie:01 rauglaudre:01 inference:01 -rectypes:01 subtypes:01 ocaml:01 toplevel:01 toplevel:01 Zitat von Christophe Raffalli : > Daniel de Rauglaudre a écrit : > > Hi, > > > > On Tue, Aug 28, 2007 at 11:18:50PM +1000, Pietro Abate wrote: > > > > > >> the other day I was looking for a fringe case to show me the worst > >> complexity of the type inference algorithm... > >> > > > > Interesting. To see the resulting time, I changed the code into: > > > > let f = > > let x1 = fun x -> (x,x) in > > let x2 = fun y -> x1 ( x1 y ) in > > let x3 = fun y -> x2 ( x2 y ) in > > let x4 = fun y -> x3 ( x3 y ) in > > let x5 = fun y -> x4 ( x4 y ) in > > x5 ( fun z -> z ) ;; > > > > > This is strange, it is problematic even with -rectypes while this is > not necessary if the subtypes are shared ... I already so ocaml > printing some types with sharing, so why is this not the case here ? > (I am using 3.09.2) [...] Sorry, if I can't follow why this discussion was started. Is this a purely-academic talk, or does it have any relevance for programmers who want to solve a programming problem? Where could the problem behind this kind of functions occure in practical programming? I tested the above code and it needed a lot of time to execute in the toplevel. I stopped this then, before the toplevel were ready. I never had such a behavior of so long needed time for any kind of code. So I doubt that this is a problem that matters in the realworld. But possibly I'm wrong. Can you please elaobrate on this? Is this more than a academic mental exercise? Ciao, Oliver