From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Brian Hurt <bhurt@janestcapital.com>
Cc: Vincent Hanquez <tab@snarc.org>, OCaml <caml-list@inria.fr>
Subject: Re: [Caml-list] Teaching bottomline, part 3: what should improve.
Date: Wed, 23 May 2007 15:36:51 +0200 [thread overview]
Message-ID: <1179927411.24233.5.camel@localhost.localdomain> (raw)
In-Reply-To: <46543875.9010305@janestcapital.com>
Am Mittwoch, den 23.05.2007, 08:49 -0400 schrieb Brian Hurt:
> Vincent Hanquez wrote:
> > On Wed, May 23, 2007 at 09:16:44AM +1000, skaller wrote:
> >
> > > On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
> > >
> > >
> > > > * Error messages of the type system are somewhat obscure. The reflex of
> > > > many students is "OCaml wants it to be of type XXX", rather than "there
> > > > is a contradiction in what I wrote". It would be nice if there was a way
> > > > to ask OCaml to display additional information on type errors.
> > > >
> > > This is a long standing peeve of mine. Lets face it: Ocaml just lies.
> > > If it has inferred a type, then finds a contradiction, it should
> > > report both the location of the contradication AND all of the source
> > > lines that contributed to the inference.
> > >
> >
> > I agree, this is one of the worst thing about ocaml type inference,
> > and you sometimes end up to have to put explicit type to functions to
> > find the offending lines (usually hundreds lines before the actual line
> > that's printed), defeating the whole thing...
> >
> > Cheers,
> >
>
> Hundreds of lines? I've seen ten's of lines, but never hundreds.
I can confirm that: hundreds. This happens especially for mismatching
class types, because the compiler tries to break the mismatch down.
But beginners shouldn't use classes.
> Of course, I generally type annotate at the level of functions at
> least (using .mli files is to be encouraged, IMO). So type errors
> generally don't escape functions. And I keep functions reasonably
> short- tens of lines long at most...
There is certainly a point. The length of type errors depends on your
programming style. A teacher can give hints how to make everything
easier to handle. (Although it is also a valid point in education to let
the students find their limits.)
Gerd
--
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de
Phone: +49-6151-153855 Fax: +49-6151-997714
------------------------------------------------------------
next prev parent reply other threads:[~2007-05-23 13:37 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-22 22:10 David Teller
2007-05-22 22:22 ` [Caml-list] " William D. Neumann
2007-05-23 13:07 ` David Teller
2007-05-22 22:26 ` Erik de Castro Lopo
2007-05-22 23:16 ` skaller
2007-05-23 2:46 ` David Thomas
2007-05-23 9:19 ` Vincent Hanquez
2007-05-23 12:49 ` Brian Hurt
2007-05-23 13:36 ` Gerd Stolpmann [this message]
2007-05-23 14:06 ` skaller
2007-05-23 14:54 ` Florian Hars
2007-05-23 15:11 ` Brian Hurt
2007-05-23 21:48 ` Vincent Hanquez
2007-05-24 8:04 ` Markus E.L.
2007-05-24 8:32 ` Vincent Hanquez
2007-05-24 9:51 ` skaller
2007-05-24 11:22 ` Vincent Hanquez
2007-05-23 13:55 ` David Teller
2007-05-22 23:19 ` skaller
2007-05-23 10:41 ` Richard Jones
2007-05-23 13:04 ` David Teller
2007-05-24 13:51 ` Richard Jones
2007-05-24 14:00 ` Robert Fischer
2007-05-24 14:00 ` Jon Harrop
2007-05-24 14:20 ` Robert Fischer
2007-05-24 14:34 ` David Teller
2007-05-24 14:21 ` skaller
2007-05-22 23:39 ` Jon Harrop
2007-05-23 18:54 ` Richard Jones
2007-05-23 19:27 ` Robert C Fischer
2007-05-23 19:34 ` Brian Hurt
2007-05-23 19:54 ` Robert Fischer
2007-05-23 21:46 ` Jon Harrop
2007-05-23 22:14 ` Jacques Garrigue
2007-05-24 1:38 ` Revolution Jon Harrop
2007-05-24 2:40 ` [Caml-list] Revolution skaller
2007-05-24 3:21 ` Chris King
2007-05-24 14:24 ` David Teller
2007-05-24 13:40 ` [Caml-list] Teaching bottomline, part 3: what should improve Brian Hurt
2007-05-23 19:29 ` Jon Harrop
2007-05-23 20:20 ` David Teller
2007-05-24 14:18 ` Jon Harrop
2007-05-24 14:23 ` skaller
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=1179927411.24233.5.camel@localhost.localdomain \
--to=info@gerd-stolpmann.de \
--cc=bhurt@janestcapital.com \
--cc=caml-list@inria.fr \
--cc=tab@snarc.org \
/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