seafood_ has quit [Read error: 60 (Operation timed out)]
Yoric[DT] has quit ["Ex-Chat"]
Stefan_vK has quit [Read error: 104 (Connection reset by peer)]
jonasb has quit [Read error: 104 (Connection reset by peer)]
tonyIII__ has joined #ocaml
Ched has quit ["Ex-Chat"]
tonyIII_ has quit [Connection timed out]
alexyk has joined #ocaml
Associat0r has joined #ocaml
mfp has quit [Read error: 104 (Connection reset by peer)]
alexyk has quit []
Associat0r has quit [Connection timed out]
mfp has joined #ocaml
vuln has quit [Read error: 104 (Connection reset by peer)]
vuln has joined #ocaml
alexyk has joined #ocaml
<vuln>
Why max_int is different from Int32.max_int?
<thelema>
vuln: max_int might be 31 or 63 bits
<vuln>
max_int is 2.7 times lower than Int32.max_int
<thelema>
my max_int is 4611686018427387903 and my Int32.max_int is 2147483647l
alexyk has quit []
<thelema>
if you're on a 32-bit machine, max_int should be half of Int32.max_int
<thelema>
about 1 billion
<thelema>
1073741823l
<vuln>
ok, gotcha
<thelema>
ocaml uses the low bit of ints for a GC tag, so the GC knows it's not a pointer (which are all word-aligned on most platforms.)
<vuln>
thank you very much :)
Axioplase_ has quit ["Lost terminal"]
seafood has quit []
seafood has joined #ocaml
vuln has quit ["leaving"]
sgnb has quit [Read error: 104 (Connection reset by peer)]
sgnb has joined #ocaml
sporkmonger has quit []
m3ga has joined #ocaml
AxleLonghorn has joined #ocaml
Axioplase has joined #ocaml
seafood has quit []
m3ga has quit ["disappearing into the sunset"]
AxleLonghorn has left #ocaml []
ttamttam has joined #ocaml
ttamttam has left #ocaml []
Palace_Chan has joined #ocaml
_zack has joined #ocaml
jknick has quit ["Lost terminal"]
verte has quit [Read error: 110 (Connection timed out)]
ttamttam has joined #ocaml
_zack has quit ["Leaving."]
Ched has joined #ocaml
juancate has joined #ocaml
hkBst has joined #ocaml
_zack has joined #ocaml
s4tan has joined #ocaml
Joshmuffin has joined #ocaml
<Joshmuffin>
hey
verte has joined #ocaml
Axioplase has quit ["leaving"]
jlouis has joined #ocaml
Joshmuffin has quit ["Ex-Chat"]
ikaros has joined #ocaml
Palace_Chan has quit ["Palace goes to sleep"]
Yoric[DT] has joined #ocaml
sanguinev has quit [Read error: 104 (Connection reset by peer)]
sanguinev has joined #ocaml
l_a_m has quit ["Lost terminal"]
l_a_m has joined #ocaml
|jedai| has quit [Remote closed the connection]
MelanomaSky has joined #ocaml
hkBst has quit [Read error: 104 (Connection reset by peer)]
vpalle has joined #ocaml
ikaros has quit ["Leave the magic to Houdini"]
Alpounet has joined #ocaml
vpalle has quit [Read error: 110 (Connection timed out)]
Camarade_Tux_ has joined #ocaml
Camarade_Tux has quit [Nick collision from services.]
Camarade_Tux_ is now known as Camarade_Tux
munga` is now known as munga
kaustuv has left #ocaml []
Alpounet has quit [Read error: 104 (Connection reset by peer)]
Alpounet has joined #ocaml
<Alpounet>
hi all
<Alpounet>
I've a module defined in x.ml with its interface in x.mli
<Alpounet>
both are compiled
vpalle has joined #ocaml
<Alpounet>
in a test.ml file, I try to define a value of a type defined in the module, by its constructor, and I get a "unbound constructor" error message when trying to compile my test.ml file, however I compile my test.ml file this way : ocamlc maths.cmo -o test test.ml
<petchema>
unless you use "open X", everything defined in module X is called X.something
<Alpounet>
Ah sorry, forgot to say that I open my module
<Alpounet>
moreover, I have a "submodule" in X, and my type is defined in this submodule
<petchema>
then it's called X.Y.something
<Alpounet>
however, in fact, I open the X.Submodule module
<petchema>
Ok... tried adding x.cmo to ocamlc command line ? I don't remember if it's necessary
<rwmjones>
yes it's necessary
<rwmjones>
also the compiler has to be able to find x.cmi on the include path
<petchema>
(modules order matters btw)
<Alpounet>
I have only one module, don't worry
<Alpounet>
But as I said, I compile test.ml with : ocamlc maths.cmo -o test test.ml
<Alpounet>
and the maths.cmi file is in the same directory
<rwmjones>
so X == Maths?
<Alpounet>
yep
<Alpounet>
some maths utility functions
<Alpounet>
with submodules in it
<rwmjones>
well it should just work then. Maybe you're misspelling your constructor or submodule name somehow.
<totom>
hm, so open means "no prefix to access the elements" ?
<rwmjones>
totom, roughly, yes
<totom>
I thought open would just dynamically link the needed methods
<Alpounet>
rwmjones, it should, yes, that's the problem :-p
<petchema>
totom: it's like $PATH, it adds modules to identifiers resolution paths
<rwmjones>
totom, don't confuse dynamic linking with this sort of symbol table manipulation
<totom>
yeah
<rwmjones>
all 'open' does is to pull in the public symbols from a module into the current namespace
<Alpounet>
my maths.ml is compiled in maths.cmo with its interface maths.mli compiled in maths.cmi
<totom>
I didn't even know you could use opened things without a prefix
<Alpounet>
inside maths.ml (and .mli, for the interface), I have a module about vectorial stuffs, with a type : type t = Vec of float*float
<rwmjones>
totom, you can write Maths.foo
<rwmjones>
or open Maths ;; foo
<totom>
rwmjones: yeah, I was using Maths.foo, but I still added the "open"s thinking that was what doing the linking
<Alpounet>
in my test.ml file, I do : "open Maths.Vector"
<rwmjones>
totom, no, the linking is done on the command line, same as in C/C++
<Alpounet>
and then : let v1 = Vec (1., 2.)
<Alpounet>
and here, I get the unbound constructor error
<rwmjones>
so inside maths.mli you have:
<rwmjones>
module Vector : sig (* whatever *) end
<rwmjones>
?
<Alpounet>
yes
<Alpounet>
module Vector : sig type t (* many other stuffs *) end
<rwmjones>
weird then, because that should work afaict
<rwmjones>
Alpounet, you have:
<rwmjones>
module Vector : sig type t = Vec of float * float .... right?
<Alpounet>
I'm stupid... forgot to write the constructor in the mli file ...
<rwmjones>
yup - you made an opaque / abstract type t :-(
<Alpounet>
yes
<rwmjones>
Alpounet, btw if you care about efficiency, that definition of type t is going to be very slow
<rwmjones>
there are two levels of boxing going on
<rwmjones>
a more efficient repr would be something like:
<Alpounet>
I care, indeed.
<rwmjones>
type t = { x : float ; y : float } ;;
<rwmjones>
which is only boxed once
<Alpounet>
Ok, great, thanks.
<Alpounet>
But why are there 2 boxing with my previous definition of the type ?
<rwmjones>
Alpounet, because although it looks as if "Vec of float * float" is a Vec constructor with two arguments, it is in fact a constructor with one argument, of type float * float
<Alpounet>
ok
<rwmjones>
best way to visualise it is to use Std.dump from extlib
<rwmjones>
one sec ...
<rwmjones>
actually that's not the best way to do it
* rwmjones
tries with Obj instead
kaustuv has joined #ocaml
<rwmjones>
# let v = Vec (42.0, 94.0) ;;
<rwmjones>
val v : t = Vec (42., 94.)
<rwmjones>
# let r = Obj.repr v ;;
<rwmjones>
val r : Obj.t = <abstr>
<rwmjones>
# Obj.is_block r ;;
<rwmjones>
- : bool = true
<rwmjones>
# let f1 = Obj.field r 0 ;;
<rwmjones>
val f1 : Obj.t = <abstr>
<rwmjones>
# Obj.is_block f1 ;;
<rwmjones>
- : bool = true
<rwmjones>
# let f11 = Obj.field f1 0 ;;
<rwmjones>
val f11 : Obj.t = <abstr>
<rwmjones>
# Obj.is_block f11 ;;
<rwmjones>
- : bool = true
<Alpounet>
How can I interpret these results ?
<rwmjones>
tricky ... what we need is a visualiser for OCaml runtime values
<rwmjones>
wouldn't be too hard to write with a bit of graphviz
<tsuyoshi>
wait a secvond.. I don't think the byte compiler unboxes floats
vpalle has quit [Read error: 110 (Connection timed out)]
Camarade_Tux has quit [Remote closed the connection]
vuln has joined #ocaml
vuln has quit [Client Quit]
vuln has joined #ocaml
Camarade_Tux has joined #ocaml
<Alpounet>
kaustuv, what does it mean ?
<mfp>
rwmjones: there are 2 levels of boxing in Vec of float * float but not for the reason you gave (... it is in fact a constructor with one argument, of type float * float)
<mfp>
that'd be the case for Vec of (float * float) (3 levels of boxing), but not for Vec of float * float
<mfp>
what's happening is that each float is boxed there, and then you have a block with the tag for the Vec constructor w/ 2 elements (pointers to the boxed floats)
<mfp>
OTOH, in type t = { x : float ; y : float } the floats are unboxed
Cheshire has joined #ocaml
<mfp>
the difference between C of t * t and C of (t * t) is shown clearly in the revised syntax, where these would be IIRC [C of t and t] and [C of (t * t)]
<thelema>
mfp: are you sure about Vec of (float * float) being 3 levels? I'd think it's still a constructor with one argument of type float * float.
<thelema>
would Vec of ((float * float)) have 4 levels of boxing?
<thelema>
I agree with you on the 1 vs 2
<mfp>
it's a constructor with one arg being a tuple with 2 floats which are each boxed
<thelema>
yes, two levels of boxing for Vec of (float * float)
<mfp>
Vec of ((float * float)) is equivalent to Vec of (float * float), I think
<mfp>
but it's not 2, it's three
<mfp>
Vec [ Tuple [ boxed float, boxed float ] ]
<thelema>
huh. you're right.
<thelema>
I guess I thought it would just tag the tuple
<mfp>
the difference between X of (a * b) and X of a * b also shows in pattern matching, since the latter doesn't allow | X t -> t but the former does
<mfp>
"expects 2 argument(s), but is here applied to 1 argument(s)"
<thelema>
yes, I guess variants do have variable numbers of values in their representation, but I expected the compiler to just flatten its argument list into that structure
<mfp>
the runtime representation is very regular and misses obvious optimizations
jlouis has quit ["Lost terminal"]
<mfp>
like not boxing type 'a a = A of 'a
<mfp>
or type x = A of int | B of float <- since the float is boxed, could know whether a value is A n or B fl w/o an extra tag
<thelema>
yes, I admit it does what you tell it to do, I just had the mental optimization that because of prescedence, V of (a * b) == V of a*b
<mfp>
the parentheses to discriminate are indeed counterintuitive
<mfp>
*the use of...
<mfp>
(is)
<thelema>
of course that'd take more code on every receiving function
<thelema>
using boxing vs non-boxing to discriminate variants
juancate has quit [Read error: 110 (Connection timed out)]
<thelema>
anyway,. gotta go. Thanks for the mental fix
<thelema>
I'll take the code and put it in a (post-1.0) branch, if that's OK.
<mfp>
kaustuv: I believe batteries is more or less feature-frozen atm. (thelema or Yoric[DT] will know), but you can add a RfF to the forge's tracker ;)
<kaustuv>
Sure, I don't much care where it ends up.
<tsuyoshi>
kaustuv: how is the performance compared to other kinds of trees?
<thelema>
kaustuv: of course users would appreciate benchmarks for different implementations showing in what situations they perform better.
<tsuyoshi>
well sure but.. have you done any tests versus the stdlib map or cf_rbtree
<kaustuv>
The short answer is that balanced trees and splay trees are intended for different uses. The former is optimized for uniform access, while the latter for non-uniform access.
<olegfink>
hi, could someone comment on debian pkg-ocaml-maint vs. godi (that is, on a non-debian system, what would be a better framework to use for building/installing ocaml libraries?)
<tsuyoshi>
well.. the debian packaging system is designed around having all the software in your system tracked by the package manager
<tsuyoshi>
so I think if you're on a non-debian system godi would be easier
<olegfink>
the debian packaging system is, indeed, but its build system sort-of-works on my machine.
<tsuyoshi>
getting the build dependencies installed for a debian package on a non-debian system could be pretty annoying
<olegfink>
yes, I've never approached dependency installation
<tsuyoshi>
otherwise.. I take the debian version of software and install it on non-debian systems sometimes
<tsuyoshi>
the patches are often useful
<tsuyoshi>
but godi pretty much does everything for you
<olegfink>
aha, thanks.
<kaustuv>
I use godi on debian, for what it's worth.
* olegfink
can't figure out which svn module he needs, so goes for the tarball
<kaustuv>
thelema: merci beaucoup
<thelema>
kaustuv: my plan is to move it out of the top-level namespace and inside Set and Map. Maybe not splayTree (although if that can be hidden somewhere... Batteries.Internals or something...
<thelema>
but extSplayMap.Make() should become Map.MakeSplay()
willb has joined #ocaml
<thelema>
kaustuv: make sense?
<vuln>
Is there any difference between array and vector in Ocaml?
<tsuyoshi>
vuln: no
<vuln>
tsuyoshi: thansk :)
<vuln>
I read something about syncronization in vectors.
<vuln>
What 'they' meant with that?
<kaustuv>
thelema: might be even better to make it not expose the name "Splay". How about Map.Uniform.Make() and Map.Nonuniform.Make()?
<kaustuv>
thelema: Or collapse the .Uniform level because that will be the common case and break no existing code.
<tsuyoshi>
hm I don't know, there isn't really anything called a "vector" in ocaml
<tsuyoshi>
generally a vector is a single-dimensional array, but in ocaml all arrays are single-dimensional
<tsuyoshi>
(aside from bigarrays)
<kaustuv>
vuln: Standard ML has vectors which are arrays without update. Maybe that's what you're remembering
<vuln>
kaustuv: thanks :)
Cheshire has quit [Nick collision from services.]
Cheshire has joined #ocaml
vuln has quit ["leaving"]
Alpounet has quit ["Ex-Chat"]
jeddhaberstro has joined #ocaml
stefk0 has joined #ocaml
stefk0 has left #ocaml []
ikaros has joined #ocaml
Stefan_vK has joined #ocaml
jeddhaberstro has quit []
thelema has quit [Read error: 110 (Connection timed out)]
slash_ has joined #ocaml
s4tan has quit []
sgnb has quit [Read error: 104 (Connection reset by peer)]
sgnb` has joined #ocaml
Associat0r has joined #ocaml
Yoric[DT] has joined #ocaml
Associat0r has quit []
ttamttam has left #ocaml []
acatout has quit [brown.freenode.net irc.freenode.net]
r0bby has quit [brown.freenode.net irc.freenode.net]
sgnb` is now known as sgnb
acatout has joined #ocaml
alexyk has joined #ocaml
alexyk has quit [K-lined]
_zack has quit [Read error: 104 (Connection reset by peer)]
sgnb has quit [Read error: 104 (Connection reset by peer)]
sgnb has joined #ocaml
_zack has joined #ocaml
ikaros has quit ["Leave the magic to Houdini"]
<kaustuv>
thelema_: http://ln-s.net/2ss6 fixes a bug in ExtSplaySet. Also, post-1.0 does not currently compile. Can you leave ISet out of the ExtSet interface for the time being?
thelema has joined #ocaml
_zack has left #ocaml []
<Yoric[DT]>
thelema_: btw, good idea creating post-1.
<Yoric[DT]>
thelema_: btw, good idea creating post-1.0
<thelema_>
kau: you're right - I shouldn't have grabbed that bit of code. It should have stayed in its own branch.
<thelema_>
yor: I worry that people might use that instead of our actual towards-1.0 release. If we get any killer features, we can't put them in post-1.0
* thelema_
fixes post-1.0
Ariens_Hyperion has joined #ocaml
<kaustuv>
it might be better to rename post-1.0 to "sandbox" or something so that it doesn't tempt people who like to cut themselves on the bleeding edge
<thelema_>
kaustuv: I don't think people'll be fooled by such a name change. If it's got something worth tempting instability, people will use it. Which means we need to think hard about putting any killer features into it.
OChameau has quit ["Leaving"]
vovkaii has joined #ocaml
<thelema_>
(I hope you don't mind the implication that splay trees aren't a killer feature)
<kaustuv>
Well, they have very limited uses. I only bothered batterising them because I am porting my theorem prover from extlib to batteries.
<thelema_>
Yoric[DT]: did you forget to check test_file.ml into git?
<Yoric[DT]>
ah, possibly
<Yoric[DT]>
added
<Yoric[DT]>
(and pushed)
<thelema_>
Yoric[DT]: good job putting the tests into the [reinstall] make target.
<thelema_>
I have the feeling we could use some camlp4 to make testing simpler - your tests have a lot of boilerplate.
<Yoric[DT]>
That list is not complete, I'm afraid.
<Yoric[DT]>
Now, not everything is urgent.
* thelema_
should bookmark this link
thelema has quit [Read error: 110 (Connection timed out)]
<hcarty>
Yoric[DT], thelema_: Would map, mapi(j|jk) and to_array functions be accepted for ExtBigarray in Batteries?
<thelema_>
hcarty: I'm quite inclusive in what can/should go into batteries. I lean towards yes.
<thelema_>
After working with Perl/CPAN recently, I realize that high-level primitives (even when not the fastest way to get things done) are very valuable in maximizing programmer efficiency.
<Yoric[DT]>
hcarty: definitely
<hcarty>
Ok, cool. I have the functions written for my own ExtBigarray library. I just need to move the code over to Batteries and add some documentation.
ttamttam has joined #ocaml
<kaustuv>
More batteries post-1.0 stuff: a rough port of Daan Leijen's algebraic pretty-printing library from Haskell to Ocaml
<Yoric[DT]>
We have someone working on pretty-printing.
<Yoric[DT]>
You'd need to get in touch with Jérémie.
<Yoric[DT]>
I'd like to avoid too much duplication of features.
<kaustuv>
This is not the same as the extensible printf stuff
<Yoric[DT]>
Not the same?
<Yoric[DT]>
Ah, then, my bad.
<Yoric[DT]>
Do you have a link on the original lib?
<kaustuv>
Well, I don't know what Jeremie is doing, so I can't be certain. This is not unparsing but pretty printing. I.e., it tries to compute optimal layouts, while unparsing has the programmer specify precise outputs.
<thelema_>
kaustuv: example usage? (wow us with the incredible power of this library)
<kaustuv>
Yes, it can be seen as a replacement for Format, but I think it has a better design. It also doesn't share Format's pathologies. Eg. it can gracefully overflow the margin, doesn't croak on too many nested boxes, etc.
Alpounet has joined #ocaml
<Yoric[DT]>
I actually don't like Format too much.
<thelema_>
Of course there'd have to be some magic to take care of stringifying all the types people might want to print.
slash_ has quit ["leaving"]
ttamttam has quit [Remote closed the connection]
ttamttam has joined #ocaml
jlouis has joined #ocaml
Alpounet has quit [Read error: 110 (Connection timed out)]
Alp_ is now known as Alpounet
<Yoric[DT]>
thelema_: well, it could be built on top of the extendable printf, I'm sure.
<Yoric[DT]>
thelema_: don't hesitate to add tutorial to the list of tasks.
<Yoric[DT]>
kaustuv: sorry, I probably won't have time to look at it this this evening, I'll try and do this tomorrow
<kaustuv>
Yoric[DT]: there is no hurry. I'm batterising stuff for my own benefit and don't really care if they become official or not.
<Yoric[DT]>
ok
<kaustuv>
By the way, I have one criticism of the design of things like ExtMap, ExtList, etc. They don't present a functorial interface from the equivalent module in Pervasives. Thus, there is no "sensible defaults" way to get a batterised version of a module that was initially designed as a drop-in replacement for a Pervasives module.
Associat0r has joined #ocaml
<kaustuv>
Unfortunately, this is not doable parametrically in the current design. ExtSet and ExtMap break the abstraction of Map/Set using magic, in order to implement sexp_of and of_sexp. (I find this implementation tactic questionable, and find it strange that sexpfication is being provided for abstract types anyhow.)
<thelema_>
I agree that there's no way to go from something better than Pervasives to adding what we add, but I'd rather people contribute to batteries than expect batteries to be able to bolt itself onto any stdlib implementation
<kaustuv>
The problem I think is that ExtMap.Map.S and ExtSet.Set.S are very fat interfaces. Most of the functions in them can be derived generically via maps and folds, and the ExceptionLess and Labelled interfaces are completely generic. To avoid trivial duplication, some of this should be functorized.
<kaustuv>
(Most of the *new* functions, I meant.)
<thelema_>
I can agree with you within sets/maps because we're doing multiple implementations.
<thelema_>
but sometimes implementations in terms of folds aren't as efficient as implementations that get to deal with internals directly.
<kaustuv>
Sure, and in those cases the user can override the functions with more efficient ones.
<kaustuv>
Also note that for the kinds of additional functionality Batteries is providing (printing, sexpification, alternative semantics), it is going to be rare to find more efficient implementations.
<Alpounet>
Does Batteries aims at being "industrializable", I mean provide real world efficiency ?
<Alpounet>
I guess it does, but just wan't to be sure :)
<thelema_>
Alpounet: yes, but for what it's worth, I find that industrial solutions don't really have to be that efficient - they just have to work.
<thelema_>
kaustuv: how can the author of the module that's input to a functor to override functions in the output of that functor?
<thelema_>
kaustuv: I agree on printing, sexping, etc.
<kaustuv>
module M = struct module Defaults = Functor() include Defaults let overridden_function x = ... end
<Alpounet>
thelema_, yep... true, but I mean that efficiency would be a real and "permanent" argument for chosing OCaml
vuln has joined #ocaml
<kaustuv>
that is, the author writes a "core" module to call the functor with, and a "client" module uses the result of the functor application
<Alpounet>
for _all_ modules ?
<kaustuv>
Alpounet: "efficiency" in the abstract is as meaningless as "ease of use" and "community support".
<kaustuv>
but I do admit to wanting to see ocaml go back to crushing Haskell in the programming language shootout
<Alpounet>
kaustuv, heh
<thelema_>
kaustuv: I've made some little contributions in exactly that arena.
<Alpounet>
kaustuv, crushing C#, Java and Haskell would be great
<thelema_>
There's always a tension between programmer efficiency / high-level primitives and CPU efficiency. I'm willing to write more library code to attain lots of the first at a cost of as little of the second as possible.
<thelema_>
Ocaml still has for and while loops for a reason.
<Alpounet>
Yep.
<Alpounet>
It would be great to have laziness smartly integrated in OCaml
<hcarty>
thelema_: What is the proper way to create a git patch for submission to Batteries?
<Alpounet>
hcarty, probably reporting the bug and explaining + attaching the patch, using the tracker
<thelema_>
hcarty: as of today, I know what to do with git bundles
<thelema_>
hcarty: I can't tell you how to create them, but kaustuv probably can
<hcarty>
kaustuv: Any tips on creation?
<thelema_>
Alpounet: laziness is smartly integrated into OCaml - you get it when you ask for it, but most of the time it doesn't get in the way of getting stuff done.
<kaustuv>
hcarty: Do you know how to use git-format-patch? If so, you already know everything you need to use git-bundle.
<Alpounet>
thelema_, I meant it would be great to see the compiler put laziness where there could be efficiency gains, you see ?
<hcarty>
kaustuv: I've never submitted a patch using git before, aside from using git-diff to make a patch
<Alpounet>
but not as much as Haskell does.
<Alpounet>
However, it seems quite hard to do
<thelema_>
Alpounet: I don't think ocaml will ever automatically make parts lazy for efficiency gains.
<kaustuv>
hcarty: What I do is rebase a topic branch onto whatever (master, post-1.0, etc.), then run git-bundle create whatever.bdl master..HEAD
<Alpounet>
Why ?
<thelema_>
hcarty: I can also take git-diff patches, if you're really just submitting one set of changes (no history)
<thelema_>
Alpounet: the ocaml compiler is a very "do what you say" compiler, meaning if your program says to do x, y, z - the compiler will create code that does x, y, z - even if y is redundant or useless or whatever.
<hcarty>
kaustuv: Thanks. I think I may stick with git-diff in this case, as it really is just a simple patch
hkBst has quit [Read error: 104 (Connection reset by peer)]
<Alpounet>
thelema_, and there aren't any discussions about efficiency optimizations ?
<thelema_>
there are, but adding such invasive optimizations will 1) make the compiler harder to change in the future, 2) introduce bugs, and 3) make the output of the compiler less predictable
<thelema_>
My personal pet wish is array bounds-check elimination, but it suffers from the same 3 problems. (mostly 1&2)
ttamttam has left #ocaml []
<kaustuv>
Laziness is difficult to reason about, especially space complexity. I am not sure if a compiler should be making programs hard to reason about.
sporkmonger has quit []
<hcarty>
thelema_: Do I need to make any changes to the build system to have extBigarray.mli preprocessed with whatever handles the "#if ocaml_version..." directives?
<thelema_>
hc: I don't think so - double check with Yoric[DT] - he knows better than I.
<hcarty>
Yoric[DT]: Do I need to change anything in the build system to have extBigarray.mli preprocessed by optcomp? (I think that's the name)
<Yoric[DT]>
hcarty: you need a change in the _tags file.
<kaustuv>
hcarty: according to src/core/extlib/_tags, all .mli files have use_optcomp
Alp_ has joined #ocaml
<Alp_>
back, sorry
<Alp_>
Indeed, laziness would introduce hard work
<kaustuv>
btw, Yoric[DT], you can remove extUnixThreads from src/core/extlib/_tags as it appears to be in src/core/extlib_threads now
<Yoric[DT]>
ok, thanks
<kaustuv>
Also, apparently the use_optcomp tag isn't used anywhere, so maybe it can be gc'd from all the _tags files
<Yoric[DT]>
True.
<Yoric[DT]>
I'll try and do this a bit later.
<Yoric[DT]>
For the moment, I'm taking care of Vect.
verte has joined #ocaml
<hcarty>
Yoric[DT]: Darn... I was just about to submit a patch to address the missing Bigarray unsafe functions