List.cons function

[vicuna]

Original bug ID: 5960
Reporter: @lpw25
Assigned to: @gasche
Status: resolved (set by @gasche on 2013-03-30T18:21:08Z)
Resolution: suspended
Priority: normal
Severity: feature
Version: 4.00.1
Fixed in version: 4.03.0+dev / +beta1
Category: standard library
Related to: #6659
Monitored by: @dbuenzli

Bug description

A List.cons function would be mildly useful:

let cons hd tl = hd :: tl

[vicuna]

Comment author: @gasche

The pros of the change are to make life marginally nicer for people using cons in a higher-order context, where they're pained by constructors not being functions already.

The downsides are the risk of breaking code among people that do a local open of List in a scope where they have a cons identifier, or that unwisely assigned the signature module type of List to some module of theirs proposing an list-like structure (Frama-C is occasionally guilty of such things for example).

My gut feeling would be that it is not worth it.

[vicuna]

Comment author: @lpw25

My gut feeling would be that it is not worth it.

Your probably right. I was surprised that it didn't already exist, but it is hardly a major inconvenience to write (fun hd tl -> hd :: tl).

[vicuna]

Comment author: @gasche

The standard library is between two rocks and a hard place these days.

Adding stuff to it would be nice, but long-term maintainers frown over the idea of how far they could have to go and, more importantly, how much code they would have to maintain. There is this known (but not yet fully realized, I'm afraid) idea that it could become only the "library of the compiler", with external users using Batteries, Core or something else outside the compiler's scope as a base for development; to support this view we're not supposed to add too much stuff to it.

But on the same side, additions to it (even if they're purely meant to help with the internal codebase, not the users) are generally not welcome, because it can introduce the breakages I mentioned and others (for example, the (much welcome) Hashtbl change of 4.00 made life quite hard for Batteries developpers).

So you've got the strict conservative policies of an extenral library that users depend on and don't expect to change too much, and at the same time the strict minimalist policies of an internal library that has to be maintained in-house.

[vicuna]

Comment author: @yakobowski

Frama-C does not redefine List, thanks for him :-) Real troubles arise when {Set,Map,Hashtbl}.S change, not when something is added at toplevel in a module such as List:

• nobody sane would 'open' List, because it contains important names such as length/iter/map
• I have personally never seen a functor that takes List or a submodule of it as argument.

All joking apart, please do not use the potential breakage of packages such as Frama-C as a reason for not improving the standard library. That List.cons is missing is a minor inconvenience, but it remains an inconvenience that should ultimately be addressed. Writing (fun hd tl -> hd :: tl) instead of List.cons results in harder to read code (what is this closure doing? This requires a bit of parsing), and in longer lines.

[vicuna]

Comment author: @protz

The downsides are the risk of breaking code among people that do a local open of List in a scope where they have a cons identifier, or that unwisely assigned the signature module type of List to some module of theirs proposing an list-like structure (Frama-C is occasionally guilty of such things for example).

Which is an argument for not ever ever modifying the standard library. I don't think we should do that.

Just for the record, List.mapi and iteri were added in the 4.00 series, so apparently there's nothing against adding stuff in the List module. And by the way, I just ran in this particular shortcoming a few days ago, so unless someone speaks up, I'll probably commit the suggested change sometime this week.

Cheers,

jonathan

[vicuna]

Comment author: @gasche

A compelling argument. Go ahead!

[vicuna]

Comment author: @lpw25

This issue is marked as "won't fix", but Jonathan said that he would actually "fix" it, although he doesn't seem to have got around to it yet.

What should the correct status of this issue be? Is it too late to add the "cons" function for 4.01.0 (it's a feature but a very small one)?

[vicuna]

Comment author: @gasche

I don't have much of an opinion, but changed the status so that it doesn't block things (I don't know if anybody cares, but well).

[vicuna]

Comment author: @dbuenzli

Today it seems, after all these years, I could no longer handle this. So I made a pull request:

#151

A few arguments w.r.t discussion (most of them already made by Boris):

• Everybody's pet extended lib thing has it with the same signature and name, so it should hardly be contreversial.

• People opening the List module shouldn't be doing that in the first place, it leads to unreadable code. So I have no problem if they are being punished. Also they would be in trouble if they wanted to switch to one of these extended lib.

• It may hardly be an inconvience to write (fun hd tl -> hd :: tl). But it is a huge inconvenience to read, it's noisy, bloats our 80 columns lines and is still one more function the brain has to parse and check. We really need to stop thinking in terms writing code (easy) and start to think in terms of reading code (harder).

[vicuna]

Comment author: @zoggy

Just an idea: Since we can now associate attributes (like ocaml.deprecated) to values, we could use attributes like ocaml.since and add a command line argument to tell which ocaml "version" of the library should be available.

With something like
ocamlc -until 4.02
the values introduced after 4.02 would be unavailable, avoiding conflicts.

[vicuna]

Comment author: @alainfrisch

the values introduced after 4.02 would be unavailable, avoiding conflicts.

It's ok for attributes to control warnings, optimizations, etc, but it seems a bad idea to have them impact well-typedness.

[vicuna]

Comment author: @lpw25

It's ok for attributes to control warnings, optimizations, etc, but it seems a bad idea to have them impact well-typedness.

I agree. However having a [@since ..] attribute and -until command-line option that emitted a warning if something was used which had a since that was later than the until seems reasonable.

[vicuna]

Comment author: @gasche

I just added List.cons to trunk -- it should be included in 4.03.