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

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