From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: malc <av1474@comtv.ru>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Type inference and marshalling
Date: Wed, 6 Jul 2011 16:44:12 +0900 [thread overview]
Message-ID: <0E8CCD89-8740-4462-97AD-8555FDA4EBE6@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <alpine.LNX.2.00.1107060909230.1433@linmac>
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 = <fun>
>>
>> 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...
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.
Jacques Garrigue
next prev parent reply other threads:[~2011-07-06 7:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-05 13:59 malc
2011-07-05 14:18 ` Wojciech Meyer
2011-07-05 14:54 ` Mathias Kende
2011-07-05 23:24 ` Jacques Garrigue
2011-07-06 5:11 ` malc
2011-07-06 7:44 ` Jacques Garrigue [this message]
2011-07-06 8:31 ` malc
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=0E8CCD89-8740-4462-97AD-8555FDA4EBE6@math.nagoya-u.ac.jp \
--to=garrigue@math.nagoya-u.ac.jp \
--cc=av1474@comtv.ru \
--cc=caml-list@inria.fr \
/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