From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jeremy.yallop@ed.ac.uk>
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
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38])
	by yquem.inria.fr (Postfix) with ESMTP id 369AFBC6B
	for <caml-list@yquem.inria.fr>; Wed, 27 Jun 2007 13:09:16 +0200 (CEST)
Received: from bdmail1.accesst.com (pop.bulldoghome.com [83.245.1.230])
	by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5RB9FYj025109
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO)
	for <caml-list@yquem.inria.fr>; Wed, 27 Jun 2007 13:09:16 +0200
Received: from host-84-9-232-87.bulldogdsl.com ([84.9.232.87] helo=[192.168.123.191])
	by bdmail1.accesst.com with esmtpa (Exim 4.50)
	id 1I3VGg-0003aD-BY; Wed, 27 Jun 2007 12:01:02 +0100
Message-ID: <46824622.2080508@ed.ac.uk>
Date: Wed, 27 Jun 2007 12:12:34 +0100
From: Jeremy Yallop <jeremy.yallop@ed.ac.uk>
User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070618)
MIME-Version: 1.0
To: David Allsopp <dra-news@metastack.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] let rec and polymorphic functions
References: <20070627100004.9E0DABC73@yquem.inria.fr> <001801c7b8a5$672a2b80$6a7ba8c0@treble>
In-Reply-To: <001801c7b8a5$672a2b80$6a7ba8c0@treble>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Miltered: at discorde with ID 4682455B.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)!
X-Spam: no; 0.00; ad-hoc:01 polymorphism:01 printf:01 recursive:01 rhs:01 val:01 recursive:01 val:01 rhs:01 rec':01 ocaml:01 ocaml:01 compiler:01 recursion:01 polymorphism:01 

David Allsopp wrote:
> That does explain it - which I didn't know. Consider this which is also
> broken (and simpler because it has nothing to do with the ad-hoc
> polymorphism of printf)
> 
> let rec id x = x
> and _ = id 0
> in
>   id (); (* *** *)
>   id 1;;
> 
> Gives a type error for *** because id is already inferred as int -> int
> because of the monomorphic nature of the recursive definition. 

Right.  In particular, it gives a type error because `id' is used at the 
type int -> int within its own definition (the rhs of every binding in 
the group), so that's the type that it's given for the rest of the 
program (the part following "in").

> This is
> over-guarded but I never got an answer on a previous post as to why. The
> equivalent SML does type polymorphically:
> 
> let fun id x = x
> val _ = id 0
> in
>   id ();
>   id 1
> end;

This isn't really "the equivalent SML", since the definition of `id x' 
and the application `id 0' aren't in the same recursive group.  The 
equivalent in SML would be something like

    let val rec id = fn x => x
            and _  = id 0
        in
           id ();
           id 1
    end

although this actual program isn't valid; SML only allows syntactic 
function expressions on the rhs of `let rec'.  If you throw in a "fn" to 
avoid the restriction you'll find that SML behaves essentially the same 
as OCaml:

     let val rec id = fn x => x
             and x = fn _ => id 0
         in
           id ();
           id 1
     end



OCaml seems a little inconsistent here, actually.  The application `id 
0' is only valid as the rhs of let rec because the compiler can 
determine that there's no actual recursion involved.  There doesn't seem 
to be a reason not to apply a similar analysis to type checking, 
allowing more polymorphism for functions in the same recursive group 
that aren't actually part of a cycle.

Jeremy.