Indexing submodule for bigarray

[Octachron]

The objective of this pull request is to introduce a shorthand notation for bringing in scope the bigarray index operators and only them:

(* Using the new Indexing submodule: *) 
open Bigarray.Indexing (* only bigarray index operators are in scope *)

(* Current alternatives:  *)
open Bigarray (* bigarray identifiers and index operators are in scope *)
(* or *) 
let (.{}) , (.{}<-) , ( .{,} ) , ( .{,}<-), , ( .{,,} ) , ( .{,,}<-), , ( .{,..,} ) , ( .{,..,}<-) = let open Bigarray in
     (.{}) , (.{}<-) , ( .{,} ) , ( .{,}<-), , ( .{,,} ) , ( .{,,}<-), , ( .{,..,} ) , ( .{,..,}<-) 
(* only bigarray index operators are in scope *)

Since index operators need to be in scope to be useful, contrarily to non-operator identifiers, it makes sense to regroup them in a specific Indexing submodule. This new submodule would provide an easier access to index operators for people concerned by namespace pollution.

This submodule is also included in the global Bigarray module in order to preserve compatibility and ease of use of the Bigarray module.

As a side effect, I find the documentation of the new submodule clearer than the previously fragmented documentation for index operators.

[Drup]

The usual idiom is an Infix submodule, why not reuse that ?

[Octachron]

I find the name Indexing more precise than the generic Infix: index operators are a quite distinct family of (?infix?) operators, a specific name sounded like good idea. But yes, I hesitated between Infix, Index_ops and Indexing ( as suggested by @dbuenzli) for the submodule name.

[dbuenzli]

FWIW I still think that Indexing gives a better idea of what is going on whenever your read module opens and this should be established as a naming pattern. The xref to mantis is here.

[Drup]

And if there are both infix and indexing operators, should we put them in different modules (and then open both) ? Is the distinction useful at all ? I personally don't think it is, and we might as well bundle them up together.

[dbuenzli]

Is the distinction useful at all ?

Well for one thing an indexing operator is not an infix operator, it's a suffix operator. So if you'd like a common module for your all your operators it should certainly not be named Infix. Ops or Operators would be a better name for that.

But then if you only redefine indexing operators, I think it's better to have them in an Indexing module. It makes it more precise the kind of syntactic constructs you are overriding and clear to the reader he should pay attention to whatever insane imperative crap is going be hidden behind these redefinitions.

[mshinwell]

I think the addition of a submodule to hold the operators should be regarded as essential.
The patch doesn't seem to have correct indentation on the operators module (or is it displayed wrongly in github)?

As far as the name goes, I'm not sure there is value in dividing the various operators between modules. I think maybe "Operators" (or "Opers"?) is the best name. "Ops" I do not think is appropriate, since it is usually an abbreviation for "operations".

[damiendoligez]

I'd vote for Operators but I would much rather delegate this naming decision to the stdlib committee if you can wait a few months (and miss the 4.03 release).

[mshinwell]

I'm going to argue strongly in favour of a fix in 4.03. The change to remove the syntax for these operators has been very disruptive.

[Octachron]

I am fine with the name Operators for the submodule, even if I have a slight preference for the more precise Indexing name.

@mshinwell, if the change has been very disruptive, would you be in favor of the deprecation warning
suggested in mantis?

[mshinwell]

Well, maybe the warning could reference "Bigarray.Operators" or whatever its called...

[Octachron]

It seems that the problem solved itself since #69 will be reverted. I am thus closing this pull request.