jemfinch` changed the topic of #ocaml to: nob: it's not an option keyword. It's a datatype. 'a option. It can be either "None" or "Some data" -- it represents either data that's not there (None) or data that's there (Some data)
__DL__ has quit [Remote closed the connection]
funroll-loops has joined #ocaml
funroll-loops has quit ["null"]
smkl has quit [carter.openprojects.net irc.openprojects.net]
jemfinch has quit [carter.openprojects.net irc.openprojects.net]
Jiriki has quit [carter.openprojects.net irc.openprojects.net]
jemfinch has joined #ocaml
Jiriki has joined #ocaml
smkl has joined #ocaml
Yurik has joined #ocaml
<Yurik>
re
malc has joined #ocaml
Cryptor has joined #ocaml
__DL__ has joined #ocaml
Cryptor has quit ["Leaving"]
Yurik has quit [Remote closed the connection]
owll has joined #ocaml
malc has quit ["no reason"]
owll has quit ["Client Exiting"]
two-face has joined #ocaml
<two-face>
hi
<smkl>
hello
<two-face>
hey smkl, you're not often there
<two-face>
smkl: i've seen that you are part of many sourcforge projects, i'm impressed
<smkl>
it's just there are not many discussions here
<smkl>
i'm only in two sf projects
<two-face>
smkl: ocaml sdl and a game iirc
<smkl>
yes
<two-face>
how long have you been using ocaml ?
<smkl>
about 4 years
<two-face>
impressive
<jemfinch>
smkl: why do you use ocaml instead of sml?
<two-face>
smkl: are you still convinced? i guess so
<smkl>
jemfinch: at first i started to use ocaml because of objects. ocaml also had better implementation, most notably sml/nj has too heavy for 16 megs of memory and FFI
<jemfinch>
do you use ocaml's objects often? I've found them...unsavory.
<smkl>
i use them for things like GUI
owll has joined #ocaml
<jemfinch>
I've not time to program at the moment.
<jemfinch>
but when I get some more, I'm pretty sure I'm going to switch to SML (probably sml-nj)
<smkl>
the problem with objects in ocaml is that they are typed and typing objects is complex
<smkl>
well, sml has perhaps a bit better library, but almost all differences between sml and ocaml are syntactic (and ocaml has more features). probably the biggest difference is that sml won't change anymore
<jemfinch>
I think there's a big difference in the FFI, too -- isn't it impossible to call sml-nj from C?
<jemfinch>
(most quality sml implementations also include call/cc too)
<smkl>
when i last checked it was practically impossible to call C from sml-nj
<two-face>
iirc sml-nj has licensing issues
<jemfinch>
I don't think it does.
<jemfinch>
it's included in debian stable's main.
<jemfinch>
so it has to be at least dfsg free.
<two-face>
this is wrong
<jemfinch>
it's too bad mlton doesn't work for anything but x86 linux.
<jemfinch>
"it's included in debian stable's main."
<two-face>
it was removed from unstable anyway
<jemfinch>
or it's been held back in stable.
<jemfinch>
since it's *really* old.
<smkl>
sml/nj is not in testing or unstable (probably because nobody uses it and it is hard to package)
<two-face>
let me check
<smkl>
there are "working" versions of sml/nj which should be quite new
<jemfinch>
smkl: it shouldn't be *that* hard to package -- freebsd has it in ports.
<two-face>
i can't find it in the morgue
<jemfinch>
smkl: I wish they were packaged in deiban -- they're in freebsd ports.
<two-face>
anyone willing to package it is free to do it
<smkl>
i don't think it's that simple
<two-face>
oh no, i recall
<two-face>
i know why
<two-face>
it was removed because it is PITA to package
<smkl>
i guess that is because it's implementation is based on nonstandard binaries, like some lisp
<two-face>
prolly
<jemfinch>
SML is implemented in lisp?
<smkl>
it is still 100x easier than haskell b compiler, though. hbc also has no licence (lazy evaluation of licencing)
<jemfinch>
isn't ghc most often used for haskell anyway?
<smkl>
jemfinch: no, sml/nj implementation is just like some lisp implementations
<smkl>
jemfinch: yes, and for good reason: nobody can get hbc to work etc.
<jemfinch>
smkl: why do you mean by "sml-nj implementation is just like some lisp implementations"?
<smkl>
i mean, it has this kind of huge and odd binary image
<jemfinch>
which is uses to recompile itself?
* jemfinch
doesn't like that.
<smkl>
sml/nj has interactive prompt with native code, that probably causes it. or that it is not based on standard C runtime
<jemfinch>
what do you mean by "not based on standard C runtime"?
<smkl>
for example ocaml links into the c runtime. sml/nj has some asm code to startup the binary iirc
<jemfinch>
oh, interesting.
<jemfinch>
does sml-nj do ELF?
<smkl>
well, i think the generated binaries have to be ELF, otherwise they couldn't be executed. but internally some other format is used. also it is bit hard to build standalone executables
jemfinch has quit [Remote closed the connection]
jemfinch has joined #ocaml
<jemfinch>
smkl: sometimes it just seems like sml supports a few more "fun" things than O'Caml -- like call/cc, or the ability to serialize the entire heap and reload it...
<smkl>
call/cc has interesting foundations, but there are not many cases where it is useful. you cannot save the heap in ocaml, but you can serialize values (being able to save the heap is one of the things caused by using non-standard binaries)
<two-face>
bye
two-face has left #ocaml []
<jemfinch>
smkl: call/cc seems especially useful for userlevel threading stuff -- the kind of threads that O'Caml bytecode has but that can't be gotten in native code because O'Caml doesn't provide call/cc.
<smkl>
yes, that is one thing. of course you can use a monad, but that is more explicit. but ML is not really good for massive concurrency anyway, because message sends are not primitive. concurrent languages are often distributed too
<smkl>
s/message sends/messaging/
<jemfinch>
why do you mean by "message sends are not primitive"?