From: John Max Skaller <skaller@maxtal.com.au>
To: Pierre Weis <Pierre.Weis@inria.fr>
Cc: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>, caml-list@inria.fr
Subject: Re: Syntax for label, NEW PROPOSAL
Date: Thu, 16 Mar 2000 08:30:18 +1100 [thread overview]
Message-ID: <38D000EA.AE061D22@maxtal.com.au> (raw)
In-Reply-To: <20000315145830.22463@pauillac.inria.fr>
Pierre Weis wrote:
> Clearly, there is something wrong now! We may remark that the error
> message is not that clear, but this is a minor point, since error
> messages are never clear enough anyway!
This is not a 'minor' point, but the most significant obstacle
in the way of adoption of languages (like ocaml) that do a lot of type
inference. Incomprehensible -- indeed plain wrong -- error messages
crop up regularly with ocaml, and vie with the kind of gibberish
errors instantiating C++ templates usually give for
'most obscuficated error message' competition :-)
The recent addition of better error messages in the case
of missing cases of matches has been a _major_ improvement IMHO:
it has already saved me significant time; since I often enhance
the set of cases of a variant, and need to chase down every
match and update it.
I'm not using -modern mode and the main reason is the scary
error messages. Even the polymorphic variants are scary, since one
looses the ability to 'spell check' variant tags. I actually tried
to take a fairly large, fundamental, type in Vyper (the type of most
language terms and runtime values) and use polymorphic variants
to classify them (the classes overlap, which ordinary variants
cannot handle), and gave up, because I couldn't understand the
error messages.
Recent discussions in the Python types-SIG concerning
type inference showed a strong indication (mainly from ex-ML
users) NOT to use any kind of type inference that could lead
to incomprehensible error messages.
I personally use errors to drive development.
I expect a compiler to tell me the line that next needs editing.
Ocaml is fairly good here now, but I still cringe in fear
when i get too incompatible object types and pages of
method signatures the compiler claims are different.
Why can't it tell me the differences more often?
I does well sometimes telling me that one sig has a method the
other lacks.
--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
next prev parent reply other threads:[~2000-03-17 9:01 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-14 16:53 Syntax for label Don Syme
2000-03-14 18:05 ` Pierre Weis
2000-03-15 3:15 ` Syntax for label, NEW PROPOSAL Jacques Garrigue
2000-03-15 6:58 ` Christophe Raffalli
2000-03-15 21:54 ` Julian Assange
2000-03-15 11:56 ` Wolfram Kahl
2000-03-15 13:58 ` Pierre Weis
2000-03-15 15:26 ` Sven LUTHER
2000-03-17 7:44 ` Pierre Weis
2000-03-15 17:04 ` John Prevost
2000-03-17 10:11 ` Jacques Garrigue
2000-03-15 17:06 ` Markus Mottl
2000-03-15 19:11 ` Remi VANICAT
2000-03-17 8:30 ` Pierre Weis
2000-03-17 14:05 ` Jacques Garrigue
2000-03-17 16:08 ` Pierre Weis
2000-03-18 10:32 ` Syntax for label, NEW SOLUTION Christophe Raffalli
2000-03-19 2:29 ` Jacques Garrigue
2000-03-20 18:25 ` Christophe Raffalli
2000-03-22 8:37 ` Claudio Sacerdoti Coen
2000-03-21 23:29 ` John Max Skaller
2000-03-29 8:42 ` Semantic of label: The best (only ?) solution to merge both mode Christophe Raffalli
2000-03-29 9:53 ` Christophe Raffalli
2000-03-30 9:49 ` John Max Skaller
2000-03-30 9:39 ` John Max Skaller
2000-03-31 4:34 ` Jacques Garrigue
2000-04-01 1:53 ` John Max Skaller
2000-04-02 19:24 ` Christophe Raffalli
2000-04-04 5:50 ` Jacques Garrigue
2000-04-03 7:57 ` backward compatibility Christophe Raffalli
2000-03-15 21:30 ` John Max Skaller [this message]
2000-03-16 2:55 ` Syntax for label, NEW PROPOSAL Jacques Garrigue
2000-03-17 15:13 ` Pierre Weis
2000-03-17 17:33 ` Wolfram Kahl
2000-03-18 11:59 ` Jacques Garrigue
2000-03-21 16:51 ` Pascal Brisset
2000-03-23 11:14 ` Nicolas barnier
2000-03-24 9:54 ` labels & ocaml 3 & co David Mentré
2000-03-24 12:19 ` David Mentré
2000-03-21 22:22 ` Unsigned integers? John Max Skaller
2000-03-22 16:22 ` Sven LUTHER
2000-03-23 2:08 ` Max Skaller
2000-03-23 7:50 ` Sven LUTHER
2000-03-24 2:50 ` Jacques Garrigue
2000-03-24 15:59 ` Xavier Leroy
2000-03-25 4:03 ` John Max Skaller
2000-03-24 14:50 ` Xavier Leroy
2000-03-22 17:05 ` Jean-Christophe Filliatre
2000-03-22 19:10 ` Markus Mottl
2000-03-23 2:41 ` Max Skaller
2000-03-22 19:47 ` Xavier Leroy
2000-03-23 12:55 ` John Max Skaller
2000-03-16 8:50 ` Syntax for label, NEW PROPOSAL Pascal Brisset
2000-03-17 11:15 ` Sven LUTHER
2000-03-18 0:04 ` Syntax for label, ANOTHER " Steven Thomson
2000-03-15 20:39 ` Syntax for label (and more) Xavier Leroy
2000-03-17 10:03 ` Christian RINDERKNECHT
2000-03-17 17:19 ` Christophe Raffalli
2000-03-21 1:29 ` Markus Mottl
2000-03-15 20:40 Syntax for label, NEW PROPOSAL Don Syme
2000-03-17 9:48 ` Jacques Garrigue
2000-03-17 17:34 ` Dave Mason
2000-03-18 0:26 ` Jacques Garrigue
2000-03-23 13:07 ` Sven LUTHER
2000-03-17 17:03 Don Syme
2000-03-17 19:24 ` John Prevost
2000-03-17 21:33 Damien Doligez
2000-03-18 21:07 ` Frank Atanassow
2000-03-18 22:40 ` John Prevost
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=38D000EA.AE061D22@maxtal.com.au \
--to=skaller@maxtal.com.au \
--cc=Pierre.Weis@inria.fr \
--cc=caml-list@inria.fr \
--cc=garrigue@kurims.kyoto-u.ac.jp \
/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