Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005960OCamlOCaml standard librarypublic2013-03-26 12:132013-06-16 15:49
Reporterlpw25 
Assigned Togasche 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusresolvedResolutionsuspended 
PlatformOSOS Version
Product Version4.00.1 
Target VersionFixed in Version 
Summary0005960: List.cons function
DescriptionA List.cons function would be mildly useful:

let cons hd tl = hd :: tl
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0009017)
gasche (developer)
2013-03-30 15:43

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.
(0009018)
lpw25 (developer)
2013-03-30 19:01

> 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).
(0009019)
gasche (developer)
2013-03-30 19:21
edited on: 2013-03-30 19:21

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.

(0009022)
Boris Yakobowski (reporter)
2013-04-01 21:11
edited on: 2013-04-02 00:45

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.

(0009023)
protz (manager)
2013-04-01 23:17

> 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
(0009024)
gasche (developer)
2013-04-02 06:43

A compelling argument. Go ahead!
(0009509)
lpw25 (developer)
2013-06-16 15:34

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)?
(0009510)
gasche (developer)
2013-06-16 15:49

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).

- Issue History
Date Modified Username Field Change
2013-03-26 12:13 lpw25 New Issue
2013-03-30 15:43 gasche Note Added: 0009017
2013-03-30 15:43 gasche Status new => feedback
2013-03-30 19:01 lpw25 Note Added: 0009018
2013-03-30 19:01 lpw25 Status feedback => new
2013-03-30 19:21 gasche Note Added: 0009019
2013-03-30 19:21 gasche Status new => resolved
2013-03-30 19:21 gasche Resolution open => won't fix
2013-03-30 19:21 gasche Assigned To => gasche
2013-03-30 19:21 gasche Note Edited: 0009019 View Revisions
2013-04-01 21:11 Boris Yakobowski Note Added: 0009022
2013-04-01 23:17 protz Note Added: 0009023
2013-04-02 00:45 Boris Yakobowski Note Edited: 0009022 View Revisions
2013-04-02 06:43 gasche Note Added: 0009024
2013-06-16 15:34 lpw25 Note Added: 0009509
2013-06-16 15:46 gasche Resolution won't fix => suspended
2013-06-16 15:49 gasche Note Added: 0009510


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker