From: skaller <skaller@users.sourceforge.net>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: caml-list@yquem.inria.fr, malc@pulsesoft.com
Subject: Re: [Caml-list] partial application warning unreliable?
Date: Fri, 09 Dec 2005 13:56:23 +1100 [thread overview]
Message-ID: <1134096983.8940.115.camel@rosella> (raw)
In-Reply-To: <20051209.111523.100788477.garrigue@math.nagoya-u.ac.jp>
On Fri, 2005-12-09 at 11:15 +0900, Jacques Garrigue wrote:
> From: skaller <skaller@users.sourceforge.net>
> > 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.
> The trouble is that any change to this behaviour would not be
> principal (from the type inference point of view).
I'm not sure I understand that (what a principal type is .. ;(
> 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.
Yes. The only case I can think of where this would
cause a problem is raising an exception -- since that
is allowed ALSO in non-statement position.
Of course some legacy code may break. And that is, IMHO,
a good thing. Some C programmers even write:
extern int f(int);
(void) f(1);
to make the casting away of the return value explicit,
clearly believing that silently throwing away a return
value is a bug in ISO C. In Ocaml we have
ignore (f 1);
if we really want side effects but not the return value.
Its use should be mandatory. IMHO.
> This is not the default, but this could indeed be done with
> -warn-error S.
Hmm ..
When you see some code in a statement, you cannot
report an error if the type is 'a, because it may later
be specialised to type unit, and the error would then
be premature.
And secondly I asked:
> If I turn off F, will I get S instead?
and Damien replied:
"Warnings are orthogonal: disabling F does not make you get more S
warnings. It has no impact on S."
so you'd need to -warn-error SF not just S ;(
You surely wouldn't want -warn-error to actually change
the way the inference engine worked!
> 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 :-(
Is this particular problem specific to class methods?
It seems to be a general typing problem to me, BUT,
with objects you can call a method before seeing it,
which you cannot do with ordinary functions.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
next prev parent reply other threads:[~2005-12-09 2:56 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 [this message]
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=1134096983.8940.115.camel@rosella \
--to=skaller@users.sourceforge.net \
--cc=caml-list@yquem.inria.fr \
--cc=garrigue@math.nagoya-u.ac.jp \
--cc=malc@pulsesoft.com \
/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