From: malc <malc@pulsesoft.com>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: skaller@users.sourceforge.net, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] partial application warning unreliable?
Date: Fri, 9 Dec 2005 18:26:43 +0300 (MSK) [thread overview]
Message-ID: <Pine.LNX.4.61.0512091825550.1089@home.oyster.ru> (raw)
In-Reply-To: <20051209.111523.100788477.garrigue@math.nagoya-u.ac.jp>
On Fri, 9 Dec 2005, Jacques Garrigue wrote:
> From: skaller <skaller@users.sourceforge.net>
>
>> AHA. In trying to fill out your problem to a real test case
>> for a bug report .. I think I have discovered the problem!
>>
>> # class cow = object(self) method moo (s:string)= print_endline s
>> end;;
>> class cow : object method moo : string -> unit end
>>
>> # let y o = o#moo; 1;;
>> val y : < moo : 'a; .. > -> int = <fun>
>>
>> And there we have it .. an uncaught partial application!
>>
>> The reason is clear .. we don't know the arity of the
>> function yet -- we don't even know its type.
>>
>> The type of a statement is currently 'a, which is just
>> plain wrong. The correct type is void, however unit
>> will catch more errors than 'a.
>
> This behaviour has been known for long.
> This is for instance why, in the standard library, List.iter is
> explicitly given type
> ('a -> unit) -> 'a list -> unit
> rather than the inferred
> ('a -> 'b) -> 'a list -> unit
> (which actually it had a long time ago, in Caml Special Light)
>
> The trouble is that any change to this behaviour would not be
> principal (from the type inference point of view).
> That is, we might choose to instantiate 'a to unit when generalizing
> the type of y, but actually #moo might be of type int, which we will
> discover later, when applying it. As long as returning non-unit in a
> statement grades only a warning, we cannot do that.
> So, saying that the type of y above is wrong means that all statements
> should be forced by type checking to return unit and nothing else.
> This is not the default, but this could indeed be done with
> -warn-error S.
>
> Note that, for objects, there was before ocaml 3.05 a warning, turned
> on only in -labels mode, that ensured that every method was known
> before being called. This would have caught the above error. It is now
> commented out :-(
I gather all this means that the only "safe" way to call a unit method
on an implictily typed object is via:
let () = o#moo in ...
--
mailto:malc@pulsesoft.com
next prev parent reply other threads:[~2005-12-09 15:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-08 2:39 skaller
2005-12-08 3:10 ` [Caml-list] " Jacques Garrigue
2005-12-08 7:11 ` skaller
2005-12-08 14:41 ` Damien Doligez
2005-12-08 23:51 ` malc
2005-12-09 1:43 ` skaller
2005-12-09 2:15 ` Jacques Garrigue
2005-12-09 2:56 ` skaller
2005-12-09 15:26 ` malc [this message]
2005-12-10 0:49 ` Jacques Garrigue
2005-12-10 1:40 ` malc
2005-12-09 12:21 ` Andreas Rossberg
2005-12-09 17:17 ` skaller
2005-12-09 17:52 ` Andrej Bauer
2005-12-09 18:54 ` Andreas Rossberg
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=Pine.LNX.4.61.0512091825550.1089@home.oyster.ru \
--to=malc@pulsesoft.com \
--cc=caml-list@yquem.inria.fr \
--cc=garrigue@math.nagoya-u.ac.jp \
--cc=skaller@users.sourceforge.net \
/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;
as well as URLs for NNTP newsgroup(s).