caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: Alain Frisch <alain.frisch@lexifi.com>
Cc: Mailing List OCaml <caml-list@inria.fr>
Subject: Re: [Caml-list] How to rename a record field
Date: Fri, 7 Sep 2018 19:13:49 +0900	[thread overview]
Message-ID: <F86E0B35-B2DE-4FFF-96A9-840DADCBA5E2@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <990e9e46-1e1b-7d5d-b776-f8c23739f91a@lexifi.com>

On 2018/09/07 17:36, Alain Frisch wrote:
> 
> On 07/09/2018 01:45, Jacques Garrigue wrote:
>> Interesting idea.
>> This should be easily doable, for instance by extending the Asttypes.arg_label type.
> 
> One could also just keep the information on the value binding itself:
> 
>  val foo: ?x:int -> ?y:float-> int -> int
>     [@@ocaml.deprecated_argument x "Please use y instead!"]
>     [@@ocaml.deprecated_missing_argument x "Please pass y, it will soon be mandatory"]
> 
> 
> Or indeed allow adding attributes on (labeled?) arguments, or interpret attributes on their types.  But internally, the information could always be attached to the value binding, which should be simpler than storing it in the type.

This is not so clear. 
The binding information could be hard to bring to the application type inference, while if it is contained in the label, it is already available where it is needed.

Also, attaching  the deprecation to the binding means that we can only refer to the first optional argument with the same name. In theory, there could be several, but I agree that this is going to be extremely rare.

>> By deprecating the absence, do you mean having a warning when the argument is ommited?
>> Wouldn’t it mean having two distinct deprecation annotations for optional arguments?
> 
> Yes, of course.  "Old" attributes (that will be discarded at some point) should be reported when they are passed a value; "new" attributes (that might become non-optional) should be reported when they are omitted.  It remains to be seen what to do with applications with the ?x syntax (i.e. passing an option).


I suppose ?x should raise a warning too, since it is intended to allow both pasing and not passing, and one of the two is wrong.

Jacques

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

  reply	other threads:[~2018-09-07 10:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 11:36 Enrico Tassi
2018-09-06 11:48 ` Gabriel Scherer
2018-09-06 13:03   ` Enrico Tassi
2018-09-06 13:17     ` Jacques Garrigue
2018-09-06 14:18       ` Enrico Tassi
2018-09-06 23:34         ` Jacques Garrigue
2018-09-06 16:20 ` Alain Frisch
2018-09-06 16:21   ` Alain Frisch
2018-09-06 23:45     ` Jacques Garrigue
2018-09-07  8:36       ` Alain Frisch
2018-09-07 10:13         ` Jacques Garrigue [this message]
2018-09-07 12:49           ` Alain Frisch

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=F86E0B35-B2DE-4FFF-96A9-840DADCBA5E2@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=alain.frisch@lexifi.com \
    --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).