From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: Gabriel Scherer <gabriel.scherer@gmail.com>
Cc: "Markus W. Weißmann" <markus.weissmann@in.tum.de>, caml-list@inria.fr
Subject: Re: [Caml-list] 3.13.0 stricter on interfaces? (building extlib)
Date: Mon, 28 Nov 2011 14:55:23 +0900 [thread overview]
Message-ID: <AD3FE931-C117-4584-963C-942587D1800E@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <CAPFanBE1vCStAg02PBcEBytB87XMfxR+NjVTeoj4NTy3hDh_aA@mail.gmail.com>
On 2011/11/26, at 19:33, Gabriel Scherer wrote:
> There is a slighlt misinterpretation in your analysis of the issue:
> the problem comes from the fact that OCaml 3.13 standard library has
> added a ?seed optional parameter to the Hashtbl.create
> method. Extlib's interface still assumes <=3.12 interface with no
> parameter (and in particular didn't change this function interface),
> and tries to check the new Hashtbl.create standard function with the
> old (int -> ('a,'b) t) interface.
>
> In particular, this problem does *not* come from a change of behavior
> of the typer, only from libraries changing.
> (And the change is on stdlib's side, not extlib's.)
Indeed, the compiler never erases optional arguments to match
a specific signature.
> The OCaml manual is not very explicit about implicit coercions
> regarding optional arguments:
>
>> Normally the compiler generates a type error if you attempt to pass
>> to a function a parameter whose type is different from the expected
>> one. However, in the specific case where the expected type is
>> a non-labeled function type, and the argument is a function
>> expecting optional parameters, the compiler will attempt to
>> transform the argument to have it match the expected type, by
>> passing None for all optional parameters.
>
> It seems that in some cases it is able to convert from `?x:foo -> bar`
> to `bar`. Indeed:
>
> # (fun (f : int -> int) -> f 3) (fun ?(x=0) y -> x+y);;
> - : int = 3
>
> However, this doesn't seem to work when checking interfaces:
Indeed again, as written in the manual, this specific case only
concerns functions passed as function argument. This is not
the case of exports from a module.
More precisely, in 3.12 this applies only to function arguments
and record fields, in trunk this applies also to variant arguments
(both normal and polymorphic) and to explicit type annotations.
> Here are are a few ways this issue could be resolved:
>
> 1. the stdlib could change to revert to the old interface, adding
> a `create_seed` function
>
> 2. extlib could introduce a conditional compilation trick to support
> either interfaces depending on OCaml version; ugly and painful to
> deal with in ocamldoc
>
> 3. instead of repeating `val create : int -> ('a, 'b) t` in its own
> interface, extlib could include (module type of Hashtbl) (referring
> to stdlib's Hashtbl module). This way, their interface would keep in
> synch with stdlib's change, and they would have to change their
> implementation correspondingly.
There is another solution which works with all versions of OCaml
4. In extHashtbl.ml, add the following line
let create x = create x
This will discard optional arguments.
People who need the full version can get it from the standard library.
Jacques Garrigue
prev parent reply other threads:[~2011-11-28 5:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-26 9:52 "Markus W. Weißmann"
2011-11-26 10:33 ` Gabriel Scherer
2011-11-28 5:55 ` Jacques Garrigue [this message]
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=AD3FE931-C117-4584-963C-942587D1800E@math.nagoya-u.ac.jp \
--to=garrigue@math.nagoya-u.ac.jp \
--cc=caml-list@inria.fr \
--cc=gabriel.scherer@gmail.com \
--cc=markus.weissmann@in.tum.de \
/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