From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: skaller@users.sourceforge.net
Cc: malc@pulsesoft.com, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] partial application warning unreliable?
Date: Fri, 09 Dec 2005 11:15:23 +0900 (JST) [thread overview]
Message-ID: <20051209.111523.100788477.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <1134092611.8940.57.camel@rosella>
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 :-(
Jacques Garrigue
next prev parent reply other threads:[~2005-12-09 2:15 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 [this message]
2005-12-09 2:56 ` skaller
2005-12-09 15:26 ` malc
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=20051209.111523.100788477.garrigue@math.nagoya-u.ac.jp \
--to=garrigue@math.nagoya-u.ac.jp \
--cc=caml-list@yquem.inria.fr \
--cc=malc@pulsesoft.com \
--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