caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: checker@d6.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] labels and optional arguments in 3.06
Date: Fri, 15 Nov 2002 10:09:24 +0900	[thread overview]
Message-ID: <20021115100924V.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <4.3.2.7.2.20021114102309.041f3dd8@localhost>

From: Chris Hecker <checker@d6.com>

> >This problem
> >only appears when you have labelled arguments AND optional arguments
> >AND you don't want to label the labelled arguments in your function
> >application.
> 
> I would restate this (to conveniently make it sound less radical/more 
> radical in my favor :).  If you are using labels primarily for 
> documentation, but you rarely if ever apply them on calls, and then you 
> want to use optional arguments, you are suddenly forced to always use 
> labels on those calls.  This could force you to label zillions of calls in 
> your huge codebase when you add an optional argument to a label-documented 
> function, but wait, that goes completely against the intent of optional 
> arguments (that you don't know they're there unless you care)!  Therefor, 
> one is incented to not use labels at all.

Sorry, you're wrong.
The problem only appears when you actually want to pass an optional
argument. If you are adding this optional argument afterwards, this
will not disturb existing function calls that do not use this optional
argument. Labels may only be needed on new code.
No, really, you're making a big fuss for a tiny case.

On a different subject, there is a nice property in writing labels in
applications: this means that you can make these arguments optional
afterwards, without any need to change old code. While the type
checker allows you to ommit the labels, you then loose that property.

> >A fully symmetric definition is much harder to obtain, and to
> >implement.
> 
> It's not worth it if it doesn't "just work" in all cases (except
> cases with  duplicate labels).

That's exactly the problem: my "simple" (already complicated)
definition doesn't handle all cases.

Jacques Garrigue
-------------------
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-11-15  1:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-13 23:33 Chris Hecker
2002-11-14  1:05 ` Jacques Garrigue
2002-11-14  2:45   ` Chris Hecker
2002-11-14  3:34     ` Jacques Garrigue
2002-11-14  4:57       ` Chris Hecker
2002-11-14  8:23         ` Jacques Garrigue
2002-11-14 18:31           ` Chris Hecker
2002-11-15  1:09             ` Jacques Garrigue [this message]
2002-11-15  2:21               ` Chris Hecker
2002-11-14  7:40   ` Alessandro Baretta

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=20021115100924V.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=checker@d6.com \
    /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).