<Smerdy>
They were much more practical in the first years of ML's existence for the mainstream world.
<Smerdy>
So they have a head start.
<Smerdy>
But one team of Frenchmen who maintain a non-open source-ish kind of grip on the one compiler can only keep up for so long.
<Smerdy>
So I feel that SML is pulling ahead, by virtue of having a standard that anyone can choose to work from.
<mflux>
having an actual standard is quite a benefit
<terpstra>
i see
<mflux>
but then again ocaml has oo and somewhat big support for an assorted set of system libraries
* terpstra
is formulating a testcase to check if the compiler supports his needs. =)
<terpstra>
I don't need OO
<Smerdy>
mflux, system library interfaces are a cinch with any good FFI, which MLton and SML/NJ have enough of,
<terpstra>
although I find the Map, Big_Int, and so on modules useful
<mflux>
smerdy, it's nicer to have someone else do the work ;).
<Smerdy>
BigInt is in the SML Basis specification now.
<mflux>
if it was so simple, the libraries would exist already
<Smerdy>
The SML/NJ library has standard container functors like OCaml has.
<Smerdy>
mflux, it _is_ simple. I maintain one myself.
<mflux>
and it isn't just a matter of hooking the function calls.. 'ocamlifying' the interface is part of the deal too
<Smerdy>
Yup, and it's not much work.
<mflux>
for example sdl for ocaml is a nice conversion
<mflux>
so do sdl, gtk and curses have bindings for sml?
<terpstra>
can I paste 5 lines of code in here?
<Smerdy>
Let's put it this way: It's reasonable for one person to produce a nice interface to a system library in a reasonable amount of time.
<Smerdy>
If everyone takes up one missing library, we're set in no time.
<mflux>
big 'if' ;)
<Smerdy>
terpstra, yes
<terpstra>
this works in ocaml:
<terpstra>
module type S = sig val foo: int -> int end
<terpstra>
module A = struct let foo a = a+1 end
<terpstra>
module B = struct open A let bar a = a*a end
<terpstra>
module F(C : S) = struct let baz a = C.foo a + 1 end
<terpstra>
module M = F(A)
<terpstra>
changing M = F(B) does not
<terpstra>
you say that will work in SML?
<Smerdy>
Yes
* terpstra
apt-get installs mltron :-)
<Smerdy>
mlton
<Smerdy>
You probably want SML/NJ, also. MLton has no repl yet.
<Smerdy>
It's only a whole-program compiler.
<terpstra>
repl?
<Smerdy>
Like what you get when you run 'ocaml'
<terpstra>
oh, I never use that
CoolPops has joined #ocaml
<terpstra>
files are called .sml? not .ml?
<Smerdy>
Yes
<terpstra>
eeek
<terpstra>
mlton says i need semicolons everywhere
<Smerdy>
OCaml and SML are not the same language....
<terpstra>
they both end in ML :-)
<terpstra>
ack
<terpstra>
I suppose I need to read a tutorial to modify my testcase. :P
<CoolPops>
I want to pass a file stream from my c app (opened with fopen) for use with ocaml functions such as fprintf. Returning a simple Val_int() does not work (segfault). I looked into using some other functions, but it seems the ones avail to me in alloc.h are not going to cut it. Any suggestions?
* CoolPops
meant Val_long
<terpstra>
Smerdy, if you can tell me that mlton has unsigned 32 bit integers I will convert immediately =)
<Smerdy>
It does.
<terpstra>
YES!!!
<terpstra>
(native?)
* terpstra
has been so pissed off at ocaml that he couldn't fit 3*2^30+1 in a native type
<Smerdy>
Yes.
<terpstra>
ok, sml definitely sounds like what to use
<Smerdy>
SML doesn't standardize on int size. I'm only talking about MLton here.
<Smerdy>
SML/NJ has tag bits, like OCaml.
<terpstra>
the unsigned part is what really matters to me
<terpstra>
unsigned ints have the guarantee that multiplication is mod 2^n, signed don't
<Smerdy>
Unsigned ints are standardized, though not their sizes, I believe.
<terpstra>
just like C then
<terpstra>
Smerdy, do you recommend any SML tutorials?
<mflux>
terpstra, perhaps you should benchmark the difference of ocaml's int32 and ml's offering ;)
<mflux>
although, ocaml will still have only signed integers
<Smerdy>
mflux, isn't OCaml's boxed?
<mflux>
yes, but it features some automatic unboxing
<terpstra>
mflux, I might; I am doing some stuff which is pretty CPU intensive
<terpstra>
although the ocaml part was more for prototyping the C...
<Smerdy>
Silly decision. Both OCaml and MLton produce C comparable performance.
<terpstra>
not for what i'm doing ...
<Smerdy>
Have you verified that for yourself?
<terpstra>
yes
<Smerdy>
With MLton?
<terpstra>
the stuff i am working with is very cache sensitive
<terpstra>
not with mlton no
<terpstra>
i was impressed with ocaml's Set implementation (with 3* of the STL's speed), but for FFTs... there's no comparison
<terpstra>
erm within 3* that is
<Smerdy>
On the contrary, that sort of thing is quite simplistic.
<Smerdy>
It's reasonable to expect no detectable performance difference.
<Smerdy>
Could be some obvious optimizations are missed.
<terpstra>
Smerdy, i will compare with mlton as soon as I have it ported
<terpstra>
Smerdy, unless you can teach ml to do the transform in-place ...
<terpstra>
cache reallly matters
<mflux>
terpstra, how about using some ready-made fft library and hook that with ml/ocaml
<mflux>
some of them are really optimized
<mflux>
or is that just a benchmark, not what you need?
<terpstra>
there are no ready-made fft libraries that operate over finite fields
<terpstra>
except the ntl which really sucks
<mflux>
hmh, mlton's profiling seems to be better than ocaml's
<terpstra>
does sml have 'lazy_t' ?
<terpstra>
i see that sml is 'strict', but sometimes lazy is handy
eugos has left #ocaml []
<terpstra>
wow, mlton is a very slow compiler
vezenchio has quit [Read error: 60 (Operation timed out)]
<terpstra>
is mlton written in ml? :-)
<Smerdy>
Yes
<Smerdy>
It's a whole program compiler.
<Smerdy>
Do you understand what that means?
<terpstra>
i assume it means to combine all source files and optimize them all together in one big pass?
<mflux>
it means that compiling code is O(n^2)?-)
<Smerdy>
terpstra, yes.
<terpstra>
... not to sound skeptical, but ... just how big is the biggest mlton program?
<Smerdy>
terpstra, so it means lots of inlining, and potentially lots of code size blow-up.
<Smerdy>
Beats me. It's a pretty young compiler. It's easiest to do this for now.
<terpstra>
what is 'boxing'
<terpstra>
something to do with gc?
<Smerdy>
Store something as a pointer to a value instead of the value itself.
<terpstra>
why would ml do that?
_fab has joined #ocaml
<terpstra>
wow - sml is a lot different than ocaml
<Smerdy>
To use a consistently sized representation for all values
<terpstra>
ahh, that makes some sense
_fab has left #ocaml []
kuribas has joined #ocaml
<terpstra>
Smerdy, uh oh - in sml i can't make my own infix versions of '+' or '-'?
<Smerdy>
No, you can.
<terpstra>
how does that jive with operator *type* overloading?
<Smerdy>
Neither OCaml nor SML has any overloading.
* terpstra
hrms, "I suppose it comes later in the tutorial."
<terpstra>
Sure, SML can do 4.4+3.3 and 2+5
docelic has joined #ocaml
kuribas has quit ["Leaving"]
<Smerdy>
Except for built-in ad-hoc stuff like that.
<Smerdy>
If you shadow the definition of +, then you lose the overloading.
<terpstra>
well, I need to be able to make my own version of + like: val (+): Ring.Sig.t -> Ring.Sig.t -> Ring.Sig.t
<Smerdy>
You can't.
<Smerdy>
And there's no good reason to want to.
<Smerdy>
You can use a new name for that function.
<terpstra>
there definitely are
<Smerdy>
Nope.
<Smerdy>
You're thinking in terms of other languages.
<Smerdy>
In ML, there's no signficant reason to want to.
<terpstra>
dude, the integers are a special case of a ring, rings should have the + operator. =) If integers need an operator, _they_ should use something else. ;)
<Smerdy>
Just always use the specific function wherever you would have used the overloaded name.
<terpstra>
i don't want to be writing code like (mul (add x y) z c)
<Smerdy>
Why? What do you lose?
<terpstra>
readability
<Smerdy>
So make up ++, **, etc.
<terpstra>
transcribability from equations and theorems
<terpstra>
those will be infix?
<Smerdy>
Or even use local bindings of + in the places where you use your ring.
<Smerdy>
You can declare any identifier to be infix in SML.
<terpstra>
ie: z ** (x ++ y) ** c ?
<terpstra>
how does it determine precedence then?
<Smerdy>
You specify it in the infix or infixr declaration.
<terpstra>
i see
<terpstra>
i'll wait until i've read the section before saying more then