From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p668VaHd023582 for ; Wed, 6 Jul 2011 10:31:36 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAAGUcFE5N6B+lmWdsb2JhbABTEKgFAQEBAQEICwsHFCWIegLEGoY2BIdAj3qLCzw X-IronPort-AV: E=Sophos;i="4.65,485,1304287200"; d="scan'208";a="112630353" Received: from fe02x03-cgp.akado.ru (HELO akado.ru) ([77.232.31.165]) by mail1-smtp-roc.national.inria.fr with ESMTP; 06 Jul 2011 10:31:31 +0200 X-Drweb-SpamState: no X-Drweb-SpamScore: -200 X-DrWeb-SpamReason: @!Recipients (-100); (-100) X-Drweb-SpamState-Num: 0 X-Spam-Level: Received: from [10.0.66.9] ([10.0.66.9] verified) by fe02-cgp.akado.ru (CommuniGate Pro SMTP 5.2.13) with ESMTPS id 219286589; Wed, 06 Jul 2011 12:31:30 +0400 Date: Wed, 6 Jul 2011 12:31:29 +0400 (MSD) From: malc X-X-Sender: malc@linmac To: Jacques Garrigue cc: caml-list@inria.fr In-Reply-To: <0E8CCD89-8740-4462-97AD-8555FDA4EBE6@math.nagoya-u.ac.jp> Message-ID: References: <098226D8-77AA-4F80-97A5-F72F47C6A98E@math.nagoya-u.ac.jp> <0E8CCD89-8740-4462-97AD-8555FDA4EBE6@math.nagoya-u.ac.jp> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [Caml-list] Type inference and marshalling On Wed, 6 Jul 2011, Jacques Garrigue wrote: > On 2011/07/06, at 14:11, malc wrote: > > > On Wed, 6 Jul 2011, Jacques Garrigue wrote: > > > >> On 2011/07/05, at 22:59, malc wrote: > >> > >>> Perhaps someone could explain why following behaves the way it does: > >>> > >>> ~$ ocaml > >>> Objective Caml version 3.11.2 > >>> > >>> # let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in ic i;; > >>> Warning Y: unused variable j. > >>> val f : in_channel -> unit = > >> > >> The return type of input_value being 'a, which gets generalized by the > >> relaxed value restriction, i gets the polymorphic type "forall 'a. 'a". > >> So you can use it both as an int and an int64. > >> ==> input_value is an unsafe function, you should always write a type > >> annotation on its return type. > > > > Sure i'm well aware of that, but to me "let j = i + 1" means that i has > > type int and after that "LargeFile.seek ic i" makes no sense yet is > > accepted by the type checker. > > But this is just the definition of let polymorphism... Thing is - the original code looked something like this: let offset = input_value ic in Printf.printf "%d" offset; LargeFile.seek_in other_ic offset; And it also worked... and caught me by surprise.. > If the type of a let-bound value contains variables, they can be generalized > (with some restriction for soundness). > So i can perfectly have several types. > What makes no sense here is the return type of input_value, > yet this cannot be avoided since there is currently no mechanism > in ocaml to actually check the type of the value received. > > I have no simple solution for this with the current standard library. > A potential way to avoid this problem would be to force the user to > provide a monomorphic type: > > module type T = sig type t end > > let input_value ic (type a) (t : (module T with type t = a)) : a = > Pervasives.input_value ic > > let f ic = > let i = > input_value ic (module struct type t = int end : T with type t = int) in > let _ = i + 1 in seek_in ic i;; > > This is verbose, but some syntactic sugar could be easily provided. > In the long term, safe input primitives are the solution. > -- mailto:av1474@comtv.ru