Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006034OCamlOCaml generalpublic2013-06-07 14:222013-06-07 19:01
Reporterlefessan 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusresolvedResolutionsuspended 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0006034: pattern-matching of arrays in lets should not print warnings
DescriptionPattern-matching an array in a let always causes a Warning 8:

# let [| a;b;c |] = Array.init 3 (fun i -> i);;
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
[| |]
val a : int = 0
val b : int = 1
val c : int = 2

and a bad array length triggers a Match_failure:

# let [| a;b;c;d |] = Array.init 3 (fun i -> i);;
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
[| |]
Exception: Match_failure ("//toplevel//", 1, 4).

I would prefer to (1) have a different warning number that is disabled by default and (2) raise Exception: Invalid_argument "index out of bounds"
instead of Match_failure, for the specific case (let [| ... |] = ... ).

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0009429)
gasche (developer)
2013-06-07 14:23

How would having a different behavior just for arrays make sense?
(0009430)
lefessan (developer)
2013-06-07 14:49

Ok, let's come back to the origin: I want to generate a huge set of symbolic names for values coming from an array. Of course, I can do:

let foo = t.(0)
let bar = t.(1)
etc.

but I think it would be much nicer to have:

let [| foo; bar; ... |] = generate_values ...

especially as the users will probably use this idiom a lot in their programs.

At the same time, I don't want to disable warnings for standard pattern-matching, so I am proposing this solution, in case somebody else would find that they have the same problem and would be interested with the same solution.

Of course, I am interested in any other solution, or to generalize to some other types than arrays.

By the way, I am not fond of the solution that I am currently using:
let (foo, bar, ...) = Obj.magic (generate_values ...)
(0009431)
gasche (developer)
2013-06-07 15:29

> At the same time, I don't want to disable warnings for standard pattern-matching, so I am proposing this solution, in case somebody else would find that they have the same problem and would be interested with the same solution.

I once had the same issue for lists:

   let [foo;bar;baz] = List.map wrap [foo'; bar'; baz']

my solution was to develop a syntax extension (uploaded here, courtesy of 2007)
  http://gallium.inria.fr/~scherer/tmp/refutable/ [^]

I think a pragma to locally-disable refutability warning would be much, much nicer than a type-directed approach. That's at arm's length in Alain's extension_points branch.

> By the way, I am not fond of the solution that I am currently using:
> let (foo, bar, ...) = Obj.magic (generate_values ...)

Indeed, it's the ugliest code I've seen today yet :-)
(0009434)
xleroy (administrator)
2013-06-07 16:14

> (2) raise Exception: Invalid_argument "index out of bounds"
> instead of Match_failure, for the specific case (let [| ... |] = ... ).

This would be backward-incompatible. All this breakage and effort for a minor stylistic issue in generated code. I move to close/no-change-required.
(0009436)
lefessan (developer)
2013-06-07 16:30
edited on: 2013-06-07 16:31

> This would be backward-incompatible.

For me, anybody who would put a "try ... with Assert_failure ->" around a non-exhaustive "let" instead of using "match with" in the first place would deserve to see its code broken...

> All this breakage and effort for a minor stylistic issue in generated code.

It is not generated code, but an idiom when creating WxWidgets applications in OCaml, users have to define lots of symbolic variables for widgets identifiers, and writting list of "let toto_id = t.(..)" is both tiring, unreadable and error-prone. I was just looking for a way to make it nicer to read.

> I think a pragma to locally-disable refutability warning would be much, much nicer than a type-directed approach. That's at arm's length in Alain's extension_points branch.

Sounds like a good idea !

(0009439)
xleroy (administrator)
2013-06-07 19:01

> For me, anybody who would put a "try ... with Assert_failure ->" around a non-exhaustive "let" instead of using "match with" in the first place would deserve to see its code broken...

Agreed, but it's an incompatible change nonetheless, and as a matter of policy we don't do this unless there are really strong reasons.

(And no open bugs for a forthcoming release, which is definitely not the case right now. Go back triaging!)

> I think a pragma to locally-disable refutability warning would be much, much nicer than a type-directed approach. That's at arm's length in Alain's extension_points branch.

Indeed. So, it's "resolved/suspended" until we make progress on the "extension points" approach.

- Issue History
Date Modified Username Field Change
2013-06-07 14:22 lefessan New Issue
2013-06-07 14:23 gasche Note Added: 0009429
2013-06-07 14:49 lefessan Note Added: 0009430
2013-06-07 15:29 gasche Note Added: 0009431
2013-06-07 16:14 xleroy Note Added: 0009434
2013-06-07 16:30 lefessan Note Added: 0009436
2013-06-07 16:31 lefessan Note Edited: 0009436 View Revisions
2013-06-07 19:01 xleroy Note Added: 0009439
2013-06-07 19:01 xleroy Status new => resolved
2013-06-07 19:01 xleroy Resolution open => suspended


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker