From: Oleg <oleg@okmij.org>
To: caml-list@inria.fr
Subject: [Caml-list] Type annotations [Was: Are record types generative?]
Date: Fri, 26 Jan 2018 20:03:25 +0900 [thread overview]
Message-ID: <20180126110325.GA3461@Magus.localnet> (raw)
# Perhaps the subthread on type annotations should get its own
# subject...
> On Tue, Jan 23, 2018 at 6:14 PM, Hendrik Boom wrote:
>
> I'm starting to think that the ability to write OCaml programs without
> mentioning the types is a drawback in the language, because it makes
> programs hard to understand.
I strongly recommend students to type-annotate all functions they
write. In fact, they should start writing code by writing out its
type. If they don't have a good idea what interface the function
should have, it's very likely that they haven't really thought the
problem through. In that case, they should think more about what it is
they want to do, rather than jumping into writing code they have only
a vaguest idea of.
I follow the same advice myself. For example, suppose I want to write
an accumulating map, which maps elements of a list and accumulates
something along the way (this function proved very handy, at least in
MetaOCaml implementation). The first this is to decide on the
interface:
let rec map_accum :
('accum -> 'a -> 'b * 'accum) -> 'accum -> 'a list -> 'b list * 'accum =
after which the code is easy to write
fun f acc -> function
| [] -> ([],acc)
| h::t ->
let (h,acc) = f acc h in
let (t,acc) = map_accum f acc t in
(h::t, acc)
One clear benefit of the explicit annotation is that the type errors
become much more meaningful and precise (which is especially important
for students).
Granted, sometimes the type of some complicated callback could be
too complicated to spell out (which is often the indication that one
should give it a name). In that case, the underscore is handy:
let rec map_accum :
_ -> 'accum -> 'a list -> 'b list * 'accum = ...
In short, if we know that a function is to take three arguments and
return an int, why not to write it down. It also helps reading the
code later on (without clicking on various identifiers: I can read much
faster than I can click).
next reply other threads:[~2018-01-26 10:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-26 11:03 Oleg [this message]
2018-01-26 14:41 ` Cedric Cellier
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=20180126110325.GA3461@Magus.localnet \
--to=oleg@okmij.org \
--cc=caml-list@inria.fr \
/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