New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reversing the Unix and Bigarray dependency #6139
Comments
Comment author: @alainfrisch I'd actually argue for making Bigarray part of the stdlib. AFAIK, it is supported on all platforms (at least for the core features, I'm unsure about map_file, precisely) and it has a special status w.r.t. the compiler (syntax and optimizations). |
Comment author: @avsm Putting it in base, sans map_file, would be great. It's been very easy to port to all kinds of embedded platforms (as long as they have a malloc), and it has win32 support. |
Comment author: @dbuenzli FWIW I'd also like to have them in the stdlib. I did sometimes avoid them at legitimate places because of their special status (namely sources/destinations for codecs, though in the current state it would still be hard to support an efficient interface that allows to e.g. source from either an in_channel, a string or a bigarray). |
Comment author: @damiendoligez If you want to maintain compatibility at all costs, you can rename your new version of the Bigarray module to something like Bigarray_core, then make a new Bigarray that just reexports all the functions plus map_file. |
Comment author: @johnwhitington Can I add my voice to the calls for reversing the dependency and putting Bigarray into the stdlib? It would be very useful. Not really a strong argument, but recall that Bigarray has special syntax even without loading bigarray.cma: $ ocaml Bigarray.Array1.create;;Error: Reference to undefined global `Bigarray' let x = 0;;val x : int = 0 x.{2};;Error: This expression has type int but an expression was expected of type So in some sense, it's already in the stdlib. |
Comment author: @alainfrisch
What's the opinion of other proponents of the integration of Bigarray into stdlib? My preference would be to simply move the map_file functions into Unix (and not provide a compatibility module). It requires to fix client code, but the required change is trivial. |
Comment author: @avsm Yes, I'd prefer the simpler approach of moving Bigarray into the stdlib, and the map_file function into Unix. I'm happy to help fix up the resulting problems with an OPAM bulk build over the 4.2 release cycle. |
Comment author: @dbuenzli Also in favour of the last two comments. Let's put OCaml's type system and ocamlot to good use. |
Comment author: @dbuenzli Has this a chance of occurring for 4.02 ? |
Comment author: @johnwhitington Was consensus reached on this? It would be a useful improvement. |
Comment author: @alainfrisch I don't think there has been any more discussion on this. Probably not for 4.03. |
Original bug ID: 6139
Reporter: @avsm
Assigned to: @gasche
Status: resolved (set by @gasche on 2018-04-09T14:37:32Z)
Resolution: fixed
Priority: normal
Severity: feature
Target version: later
Fixed in version: 4.07.0+dev/beta2/rc1/rc2
Category: otherlibs
Related to: #6885
Monitored by: @hhugo @gasche @diml @glondu @jmeber @hcarty @dbuenzli @Chris00
Bug description
With the splitting out otherlibs/ from the compiler distribution, I wanted to also see if we could remove the hard dependency on the Unix library from Bigarray. Currently, there is just one function (map_file) which causes Bigarray to depend on Unix.
Bigarray is increasingly used in the more exotic backends (js_of_ocaml, Mirage, ocamljava) as a convenient way to access externally allocated memory safely and fast. It would therefore make compilation much easier if the map_file were moved into the Unix module, thus introducing a Unix->Bigarray dependency rather than Bigarray->Unix. It's hard to override Bigarray via package management as it's installed in the standard library area and therefore picked up by default unless overridden for every case where it's used.
I'm happy to come up with a patch if there's general agreement that is a good idea. I can't see how not to break the existing interface, although telling people who to switch their existing use should be quite easy.
(two concrete reason I want this is to purge the last of POSIX from Mirage/Xen, which uses Bigarray, and also to more easily compile Core to Javascript for an interactive Real World OCaml toplevel).
The text was updated successfully, but these errors were encountered: