caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Pierre Weis <pierre.weis@inria.fr>
To: dmason@sarg.ryerson.ca (Dave Mason)
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Naming conventions
Date: Wed, 8 May 2002 19:12:03 +0200 (MET DST)	[thread overview]
Message-ID: <200205081712.TAA04979@pauillac.inria.fr> (raw)
In-Reply-To: <200205081359.g48DxNO09861@sarg.ryerson.ca> from Dave Mason at "May 8, 102 09:59:23 am"

[...]
> But, the original question was about objects.  In Java there is a
> style that is fairly convenient, whereby mutators for objects return
> the object itself instead of void (unit).  This allows doing:
[...]

Oh, please, no!

We had once these style of primitives in Caml and found it really
error prone: you just confuse procedures and functions!

A procedure is called for its side effects, hence it does not return
any meaningful value, and hence it reflects this fact in its return
type that should be unit.

Thanks to this convention, there is a special warning to help the
programmer not to forget an argument to a procedure call inside a
sequence of side-effects: if f has type int -> int -> unit and you
compile the sequence

begin 
 f 1;
 print_newline ()
end

then you will have a warning for the incomplete call f 1 (telling you
that this expression should have type unit).

If your procedures wrongly return a value which is not unit, then you
will have warnings everywhere; hence, you will disable warnings;
hence, you will miss partially applied procedure calls.

When programming in the large, such silently ignored side-effects are
a nightmare to find out, particularly if the given procedure has a lot
of arguments (imagine forgetting just the last argument to mult_nat, that
is just providing eight out of nine of the required arguments! It is
easy to find if the compiler points it out for you, otherwise you can
read the program over and over again without noticing the missing
arg).

So no. This ``fairly convenient style'' is not your friend; it is in
fact as convenient as programming without a type-checker: seemingly
``cool'' at the beginning, but really harder in the long run.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2002-05-08 17:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-08 13:33 Krishnaswami, Neel
2002-05-08 13:59 ` Dave Mason
2002-05-08 17:12   ` Pierre Weis [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-05-08 13:31 Gregory Morrisett
2002-05-08 13:10 Paul Stodghill
2002-05-08 14:04 ` Ken Wakita

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=200205081712.TAA04979@pauillac.inria.fr \
    --to=pierre.weis@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=dmason@sarg.ryerson.ca \
    /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).