caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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



  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;
as well as URLs for NNTP newsgroup(s).