[containers-users] [poll] use more labels?

[Simon Cruanes]

Le Sun, 20 Sep 2015, Malcolm Matalka a écrit :
> > Some users want functions to have labels when it makes sense (à la
> > Core), and I kind of like the idea in many cases (especially to label
> > functions with ~f).
> >
> > Apparently, a function declared with labels can be called without them
> > if arguments are in the right order (at the possible price of a
> > warning). That means that it should be possible to add labels in many
> > modules *without* breaking compatibility.
> >
> > What do you think? Are there strong oppositions to this idea?
> >
> > The next release of containers is approaching (in a few weeks max, I
> > think), but this can wait if there is no consensus.
> >
> > Cheers!
> 
> As one of those users, I support this.  However, a few specifics to
> consider.  After some more testing it looks like it would break
> backwards compatibility in some ways.  Specifically:
> 
>  # let f ~x ~y = x + y;;
>  val f : x:int -> y:int -> int = <fun>
>  utop # f 2;;
>  Error: The function applied to this argument has type x:int -> y:int ->
>  int
>  This argument cannot be applied without label
> 
> This is obviously problematic if anyone is partially applying.
> 
> The other issue is that there should be some convention for what should
> get a label and what shouldn't.  Specifically to handle this case:
> 
> utop # f ~x:2 3;;
> Error: The function applied to this argument has type y:int -> int
> This argument cannot be applied without label
> 
> This matters because I often structure code like:
> 
> list |> List.filter ~f:filter |> List.map ~f:map ....
> 
> The convention I have been following in my code is that the 't' that the
> modules operates on is never labeled.

Aww, indeed, I overlooked partial application. So, the problem is not as
simple as I hoped.

I have some code that uses containers a lot, which makes me sensitive to
retro-compatibility problems. On the other hand, this issue is not
urgent, and can probably wait for a major release. Or, I can maintain a
"bleeding edge" version of containers, with some breaking changes, and a
"compat" version that merges those changes much later...

It's hard to write perfect APIs directly, but I dislike keeping bad
decisions forever. I think having containers and containers-lts would
make a lot of sense to both cater for existing code bases, and improve
the quality. There are already deprecated functions in the code, that
would stay in lts for a few versions, but not in bleeding-edge.



-- 
Simon Cruanes

http://weusepgp.info/
key 49AA62B6, fingerprint 949F EB87 8F06 59C6 D7D3  7D8D 4AC0 1D08 49AA 62B6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.ocaml.org/pipermail/containers-users/attachments/20150920/96cccb95/attachment.sig>