<mfp>
it's not really pointer tagging (using the LSBs in the pointers to encode the constructors, Big_int and Ratio in this case), but it's the same idea
<mfp>
well, Obj.magic is just the means to do that with the current compiler/runtime, but this is something the compiler could do (if it were an optimizing one)
marteo has joined #ocaml
<sdschulze>
I'm still not sure how your code addresses the problem that a new big_int is generated on every recursion.
<sdschulze>
thereby generating garbage
<mfp>
it avoids consing if the num fits in an int
<mfp>
hence generating no garbage in that case
<sdschulze>
ah, ok
<sdschulze>
but still a lot in other cases
<mfp>
yes
<sdschulze>
No, with Big_int, the problem is that internally, the GMP stuff is imperative.
<sdschulze>
It's just boxed by the Big_int package.
<sdschulze>
in order to save the sign or something
Yoric has joined #ocaml
<sdschulze>
The Java implementation of the pidigits benchmark also boxes, but it modifies in-place, generating no garbage.
mattam has quit [Ping timeout: 258 seconds]
<mfp>
(Big_int doesn't use GMP BTW)
<sdschulze>
ok, only MP then
<sdschulze>
Wouldn't it be nice if there were some kind of attribute that made any data default to being stack-allocated?
<sdschulze>
(and being copied to the heap if really necessary)
<mfp>
you need escape analysis in order to make that safe, esp. in the presence of closures
<mfp>
the GMP-based prog doesn't compile because somebody didn't apt-get install libgmp-ocaml-dev, leaving only the big_int one around and making OCaml seem 4X slower
verte has quit [*.net *.split]
|marius| has quit [*.net *.split]
Tianon has quit [*.net *.split]
shachaf has quit [*.net *.split]
bitbckt has quit [*.net *.split]
thieusoai has quit [*.net *.split]
boscop has quit [*.net *.split]
drk-sd has quit [*.net *.split]
orbitz has quit [*.net *.split]
noj has quit [*.net *.split]
rudi_s has quit [*.net *.split]
verte has joined #ocaml
|marius| has joined #ocaml
boscop has joined #ocaml
thieusoai has joined #ocaml
Tianon has joined #ocaml
shachaf has joined #ocaml
drk-sd has joined #ocaml
orbitz has joined #ocaml
noj has joined #ocaml
rudi_s has joined #ocaml
bitbckt has joined #ocaml
<mehdid>
mfp: do you know if those pages are still maintained?
<sdschulze>
Is there a good reason why floats are boxed in tail-recursion?
<tautrimas>
Hello. I was hoping somebody knows a quick answer: how to open a hyperlink in the default system's browser from Ocaml?
<sdschulze>
tautrimas: depends primarily on the operating system, probably
<tautrimas>
sdschulze: but then how to solve this problem? I'm contemplating the option to leave the url for the user to copy paste into his browser. Is there no library suitable for this?
<tautrimas>
adrien: I've written the GUI game and need it portable to windows also
chee is now known as fourthroatedcat
<tautrimas>
btw, I'm using TK
<adrien>
I don't know of anything portable so you'll probably want to match against Sys.os_type, if Unix, try xdg-open, if it's not available, you might try $BROWSER but it's not necessarily a graphical one (might be links) so fall back on firefox, if Windows, you'll probably have to deal with the registry
<tautrimas>
adrien: hey, maybe windows have also some specific command for the default browser? I'll google it. Thanks for xdg-open so far!
<adrien>
btw, anyone know of an easy windows registry library? ocaml-win32 does not on mingw.org (mingw-w64 should work) and is pretty big but iirc a few ocaml apps use the windows registry
<adrien>
tautrimas: afaik it's stored in the registry, I have no idea where it is stored though
<adrien>
np
<ygrek>
cf. ShellExecute
<adrien>
right, you can let windows "resolve" that by itself but you'll want a binding to it anyway
alexyk has quit [Ping timeout: 265 seconds]
tautrimas has quit [Remote host closed the connection]
boscop has quit [Ping timeout: 240 seconds]
boscop has joined #ocaml
alexyk has joined #ocaml
ftrvxmtrx has quit [Read error: Connection reset by peer]
alexyk has quit [Ping timeout: 246 seconds]
EliasAmaral has quit [Ping timeout: 265 seconds]
ftrvxmtrx has joined #ocaml
EliasAmaral has joined #ocaml
EliasAmaral is now known as dark
jakedouglas has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
psnively has joined #ocaml
psnively has left #ocaml []
ygrek has joined #ocaml
ftrvxmtrx has quit [Ping timeout: 248 seconds]
Yoric has joined #ocaml
Tianon has quit [Read error: Connection reset by peer]
ftrvxmtrx has joined #ocaml
Tianon has joined #ocaml
Tianon has quit [Changing host]
Tianon has joined #ocaml
Yoric has quit [Ping timeout: 276 seconds]
fourthroatedcat is now known as chee
ulfdoz has quit [Read error: Operation timed out]
psnively has joined #ocaml
psnively has left #ocaml []
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
<sdschulze>
In Lisp, you can "magically" construct the list.
<sdschulze>
(Lists are mutable there, anyway, so it would be possible even in derived code.)
<sgnb>
you can define your own mutable type of lists, that's not the point
<sdschulze>
In the thread, Xavier points out that implementing List.map tail-recursively and without List.reverse is possible, but only using dark magic, and he doesn't want to do that.
awwaiid has quit [Ping timeout: 276 seconds]
<sgnb>
if you want, you can define a list-like datatype that is mutable without resorting to dark magic
<sgnb>
standard lists not being mutable is a feature IMHO
<sdschulze>
Sure it is.
<sdschulze>
Lists are very handy to abuse for a lot of stuff.
<sgnb>
in lisp, there is basically no datatypes... everything is mutable lists (or maybe vectors)
<sgnb>
but in ocaml, you can define your own datatype with quite some flexibility
<sgnb>
you shouldn't think with a lisp mind there
<sdschulze>
And functional languages often support them quite intimately.
<sgnb>
more than functional, ocaml is also statically and strongly typed
<sdschulze>
You mean immutable lists are a benefit for the programmer or for the compiler/run-time environment?
<sdschulze>
Because this is a counter-example for the latter.
<sgnb>
of course they are
<sdschulze>
for both?
<sgnb>
it's much easier to reason about and the runtime is optimized for that
listmap has joined #ocaml
<sgnb>
as a general rule of thumb, mutating datastructures is evil
<listmap>
sgnb: maybe it's evil but then evil is fast..
<sgnb>
sometimes it is indeed... but not always
<sdschulze>
The poison is sweet, at least.
<sgnb>
and I prefer to write correct programs rather that fast ones
kingking has joined #ocaml
<sdschulze>
It's what Java does. :)
<sgnb>
Java uses mutable datatypes everywhere!
<sdschulze>
sgnb: to reason about in terms of static analysis?
<sgnb>
I was just thinking in terms of proof
<sdschulze>
Shouldn't we all be using Haskell then?
<listmap>
I'm curious - is there a general proof for the fact that using immutable data structures create more correct code?
<sgnb>
don't get me wrong: I'm not against data being possibly mutable, I'm just glad they are not by default
<sgnb>
(and Haskell seems a bit too much extremist for me... and too ugly syntax-wise)
<sgnb>
listmap: what kind of proof do you expect
<sdschulze>
The other option is: (* If you fiddle around with the internals of this data structure, God will kill a kitten!!!!! *)
<sgnb>
program for some years in C, then in OCaml and you'll understand
<sdschulze>
It still depends if you want to proof something by a machine or by a human.
<listmap>
Been there done that. But my question was more Hashtbl vs Map in Ocaml
<sgnb>
I was thinking about human proofs
<sgnb>
and for Hashtbl vs Map, it depends on what you are doing
<sgnb>
Map are more convenient (and probably efficient), if your data structure is changing a lot across recursive calls (for example)
<sdschulze>
Hm, a cons cell is probably the most elegant data structure ever, but the question is if it's still the most realistic one today.
<sgnb>
but I also often use Hashtbl when I only need to add things
<sgnb>
a cons cell is like a functional void*
<sdschulze>
I once got it trouble when I wanted to do mutually recursive data types with Map.
<listmap>
I can't see the drawback of using Hashtbl instead of Map - only difference is that the GC will be working much more with Map, right? And add/remove in a Map is more stable.
<sdschulze>
though PMap fixes it
<sdschulze>
but you have to install Batteries
psnively has joined #ocaml
<sgnb>
listmap: if you are writing a recursive evaluator for some language with variables, Map are much more fit than hashtables IMHO
<sgnb>
with hashtables, you'd have to explicitly remove variables from the table when a variable goes out of scope, which is quite clumsy (and error-prone)
<sgnb>
whereas with maps, it would just be "obviously" correct
<sdschulze>
The main reason why I use objects and hashtables at all is mutual recursion.
<sgnb>
sdschulze: do you have a concrete example? I didn't hear this argument before
<sdschulze>
Wait, yeah.
<sdschulze>
I even posted it here once, and got an answer -- but it seemed quite complicated.
<sgnb>
(but I must admit I didn't face myself such situation in real life)
<sdschulze>
That's about what was suggested to me.
<sdschulze>
But I just used a polymorphic hashtable. :)
<sdschulze>
Are C-style pre-declarations so much impossible?
<sdschulze>
of functions, that is
<sgnb>
the explicit signature needed in recursive modules are kind of C-style pre-declarations, aren't they?
<sdschulze>
So I should do that any time I want to do some strange kind of mutual recursion?
<sgnb>
at least for class/module mutual recursions... but there are other "standard tricks" for other situations
<sdschulze>
What about my other example above, with module structure interfering with call structure?
<sdschulze>
(I think that's the difference between some people call "structural programming" vs. "modular programming". In structural programming, problems are slices down to smaller parts and functions are grouped abstract/special. In modular programming, functions are grouped in what kind of stuff they do. OOP is similar to the latter.)