<slacker403>
when will ocaml ever get a GCC front end
<slacker403>
so it cant get optimizations
<slacker403>
i jus noticed the ocaml compiled is about half the speed of C
<hcarty>
slacker403: Depending on the operation(s) being performed and the programming methods used I think that is pretty normal
<hcarty>
I am not a compiler or language expert, but my understanding is that a lot of it has to do with the extras OCaml provides
<slacker403>
not sure
<slacker403>
seeems like a gcc front end would make it much faster
<Smerdyakov>
hcarty, my understanding is that it has to do with no program analysis in the OCaml compiler!
<Smerdyakov>
slacker403, just use SML and MLton instead!
<Smerdyakov>
slacker403, and I have a strong feeling there are many ways in which GCC is incompatible with compiling ML-like languages.
<hcarty>
Smerdyakov: Well, I think your background is a little more suited to a detailed analysis of the situation
<mbishop>
From the benchmarks I've seen, MLton and ocamlopt are pretty close (although mlton is a little fasteR)
<Smerdyakov>
mbishop, you mean micro-benchmarks of tiny single source files?
<mbishop>
Hmm, not really, it was single source, but it was a ray tracer :P
<Smerdyakov>
The relevant metric is number of abstractions and their nesting structure.
<Smerdyakov>
("Abstractions" in the most general sense)
<hcarty>
Unless all of the load is in a few heavy number-crunching routines. Then I'm guessing that better handling of such abstractions would matter significantly less.
<Smerdyakov>
Very little of the spectrum of relevant software does heavy number-crunching.
<hcarty>
Well, perhaps outside of science and math that's true
<Smerdyakov>
Science and math make up very little of the spectrum of relevant software.
<hcarty>
Unless one is a scientist or mathematician
<Smerdyakov>
I'm talking about "relevant" on a societal scale.
<slacker403>
Smerdyakov: Mlton SML ? faster?
<Smerdyakov>
slacker403, yes.
<slacker403>
how much faster?
<Smerdyakov>
Probably rarely more than a constant factor.
Nutssh has quit ["Client exiting"]
<Smerdyakov>
But MLton does flow analysis AND analyzes the whole program together. It's not hard to come up with many situations where this will bring a noticeable improvement.
<hcarty>
ocamlc -o test test.ml <-- This executable works without issue
<pango>
stack overflows, on some architectures
<flux>
well, both work for me, but yes, I guess stack overflow
<flux>
the latest release has some fixes regarding detecting stack overflow
<flux>
(on some platforms)
<hcarty>
flux: What version of OCaml are you using?
<flux>
although
<flux>
3.09.2 (ubuntu edgy)
<flux>
depth of 100 is awfully little, though..
<hcarty>
3.09.3 here, CentOS 5, godi-built OCaml
<flux>
hm
<hcarty>
Yeah, 100 iterations should wreck anything
<hcarty>
From what I understand
<zmdkrbou>
does someone know how to get polymorphic maps (in both keys and values, i mean ('a,'b) Mymap.t for instance) from the Map.Make functor (without rewriting everything, as PMap in extlib does) ? (in fact i guess it's not possible but i'm not sure)
<pango>
1st version is broken, because it relies on an unspecified behavior
<hcarty>
pango: But if that were the case, wouldn't I get some sort of error when running the ocamlc compiled binary?
<hcarty>
Both versions work without issue when compiled to bytecode
<flux>
hcarty, the problem is that stack overflow detection doesn't work on your platform with native binaries
<hcarty>
How odd
<hcarty>
I would think it would on x86_32
<flux>
yeah, maybe the distribution behaves somehow differently
<flux>
oh, and the bug report earlier was totally unrelated
<flux>
its test case was: (try f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0; with e -> raise e);
<hcarty>
I wasn't sure if the try call had something to do with it or not. Perhaps the 3.09.3 specific nature was a coincidence
<flux>
hcarty, you can replace the _ in your catch with Not_found and it'll throw Stack_overflow
<pango>
actually, give the "logic" behind the code, I guess the idea was to catch Failure _
<hcarty>
pango: Yes... I see what you are both talking about re: never calling get_it
titusg has joined #ocaml
<pango>
btw there's a shortcut for raise (Failure s): failwith s
<hcarty>
pango: Cool, thanks
<titusg>
Hi, I have a question about TAPL ... I'm confused by a function in the interpreter for ch. 4 ...
<mbishop>
The CWN website is broken
ygrek_ has joined #ocaml
ygrek has quit [Remote closed the connection]
joelr1 has joined #ocaml
<joelr1>
pango: is there a shortcut to creating a list of 1... n in ocaml?
<pango>
no
<joelr1>
ok, thanks
joelr1 has quit []
JeffSmac has joined #ocaml
slipstream-- has joined #ocaml
<mbishop>
I think I have a range function that I typically make for that heh
holo has joined #ocaml
<holo>
hi
the_dormant has joined #ocaml
slipstream has quit [Connection timed out]
<pango>
in languages that feature that idiom, the list is usually never built (purely a syntactical idiom)
<pango>
it may still be practical in lazy languages... But better avoid it otherwise
titusg has quit ["Ex-Chat"]
<ita>
what is wrong with a for loop ? :-)
<pango>
it's imperative... which is not always what you want
<flux>
I wonder why something like "fold with range" isn't very commonplace in functional languages, it would be the perfect replacement for the generic for statement :)
<ita>
pango: the python "range" is often not what you want
piggybox has quit [Read error: 104 (Connection reset by peer)]
sgillespie has joined #ocaml
<sgillespie>
hello
<sgillespie>
quick question on imperative programming
<JeffSmac>
sure
<sgillespie>
lets say i have: let a = ...
<sgillespie>
how can i defer evaluation of a until i need it?
<JeffSmac>
you could use the lazy keyword
<JeffSmac>
and then when you need it, do (Lazy.force a)
<sgillespie>
how does that work?
<JeffSmac>
let me see if i can build a simple example
<sgillespie>
ok
love-pingoo has joined #ocaml
<JeffSmac>
let a = lazy 1 in
<JeffSmac>
print_int (Lazy.force a)
the_dormant has quit []
<sgillespie>
sweet...i will try
<JeffSmac>
good luck
<sgillespie>
works beautifully!
<JeffSmac>
lazy evaluation in ocaml can be tricky, but hopefully it'll be good enough for what you're doing
<sgillespie>
yeah, just simple things
ygrek_ has quit []
ita is now known as ita|zzz
<pango>
now, what's the question on imperative programming? :)
<sgillespie>
I'm obviuosly trying to learn ocaml now...
<sgillespie>
but I'm curious...what features of Ocaml do you like the best??
<sgillespie>
pango: ...that was it
<JeffSmac>
garbage collection, type checking, the way types are constructed
<JeffSmac>
pattern matching
<sgillespie>
what about ocaml vs. haskell?
<pango>
deferred evaluation is not an imperative trait
<ita|zzz>
sgillespie: fast compiler, the guys on irc
<JeffSmac>
haskell is harder to learn, but is bettter if you need lazy evaluation
<sgillespie>
I thought haskell was much easier to learn...I'm having a hell of a time with ocaml
<JeffSmac>
hehe well
<JeffSmac>
what's hard about ocaml then?
<JeffSmac>
are you trying to make it work exactly like haskell? That could be throwing you off.
<sgillespie>
if i wanted things to work like haskell, i would use haskell...I actually chose ocaml because of its imperative features
<JeffSmac>
ah well
<sgillespie>
I think I like the types better here too
<JeffSmac>
can you give us an example of something imperative that you're finding difficult?
<sgillespie>
I think whats difficult for me is that the syntax seems a bit more complex
<sgillespie>
lots of special operators and what not
<JeffSmac>
hm, there are some it's true. perhaps you'd like revised syntax better.
<JeffSmac>
in some ways anyway
<JeffSmac>
but probably we dont want to go there right now :)
<sgillespie>
ha...yeah...I think I need to keep it simple for right now
<sgillespie>
are their other caml implementations?
<hcarty>
sgillespie: The (sort of) lack of overloading is a big shock coming in to OCaml
<JeffSmac>
for some people it can be. It was for me since id' come from programming c++
<hcarty>
I've grown to like it as well... +. was an annoyance until it caught several bugs at compile time rather than run time
<JeffSmac>
Me too.
<JeffSmac>
There's no hidden casting, etc.
<sgillespie>
yes, that certainly has a different feel.
<sgillespie>
another frustration I had with haskell
<JeffSmac>
haskell allows overloading?
the_dormant has joined #ocaml
<sgillespie>
I was referring to 'no hidden casting'
<JeffSmac>
ah
<sgillespie>
but I don't think that haskell allows overloading either...
<sgillespie>
its been a few months so I'm having trouble remembering things
piggybox has joined #ocaml
<sgillespie>
question
<JeffSmac>
sure
<sgillespie>
is this valid?
<sgillespie>
let rec a = 5 and b = a in...
<sgillespie>
apparently not
<sgillespie>
is there a way to make this happen..
<sgillespie>
like schemes let*
<JeffSmac>
since they are not mutually recursive functions you can just do...
<JeffSmac>
let a = 5 in let b = a in ..
<sgillespie>
what if they are??
<JeffSmac>
then you do
<JeffSmac>
let a = (some function) and b = (some function) in ....
<JeffSmac>
I think mabye what caml is trying to keep you from doing is...
<JeffSmac>
let a = b and b = a in...
<JeffSmac>
which would be nasty
<JeffSmac>
er, let rec a = b and b = a in...
<JeffSmac>
jeez i forgot the "rec" keyword in all my examples...
<JeffSmac>
let rec a = (some function) and b = (some function) in ...