Mr_Awesome has quit [Read error: 110 (Connection timed out)]
johnnowak has joined #ocaml
johnnowak has quit []
ofaurax has quit ["Leaving"]
Morphous has quit [Read error: 110 (Connection timed out)]
Morphous has joined #ocaml
hkBst has quit [Read error: 104 (Connection reset by peer)]
Mr_Awesome_ has quit [Read error: 110 (Connection timed out)]
Mr_Awesome_ has joined #ocaml
mbishop has joined #ocaml
alexyk has quit []
mbishop has quit [Read error: 110 (Connection timed out)]
mbishop has joined #ocaml
alexyk has joined #ocaml
munificent has joined #ocaml
maskd has quit [Read error: 148 (No route to host)]
fy__ has quit ["ChatZilla 0.9.84 [Firefox 3.0.1/2008070208]"]
alexyk has quit []
authentic has quit [kornbluth.freenode.net irc.freenode.net]
sgnb has quit [kornbluth.freenode.net irc.freenode.net]
orbitz has quit [kornbluth.freenode.net irc.freenode.net]
Mr_Awesome_ has quit [kornbluth.freenode.net irc.freenode.net]
Stefan_vK1 has quit [kornbluth.freenode.net irc.freenode.net]
mfp has quit [kornbluth.freenode.net irc.freenode.net]
Smerdyakov has quit [kornbluth.freenode.net irc.freenode.net]
erg has quit [kornbluth.freenode.net irc.freenode.net]
rodge has quit [kornbluth.freenode.net irc.freenode.net]
Demitar has quit [kornbluth.freenode.net irc.freenode.net]
shortc|desk has quit [kornbluth.freenode.net irc.freenode.net]
munificent has quit [kornbluth.freenode.net irc.freenode.net]
jeddhaberstro has quit [kornbluth.freenode.net irc.freenode.net]
caligula has quit [kornbluth.freenode.net irc.freenode.net]
maxote has quit [kornbluth.freenode.net irc.freenode.net]
petchema_ has quit [kornbluth.freenode.net irc.freenode.net]
bohanlon has quit [kornbluth.freenode.net irc.freenode.net]
Jedai has quit [kornbluth.freenode.net irc.freenode.net]
haelix has quit [kornbluth.freenode.net irc.freenode.net]
cygnus_ has quit [kornbluth.freenode.net irc.freenode.net]
hcarty has quit [kornbluth.freenode.net irc.freenode.net]
jburd has quit [kornbluth.freenode.net irc.freenode.net]
sbok has quit [kornbluth.freenode.net irc.freenode.net]
jdev has quit [kornbluth.freenode.net irc.freenode.net]
r0bby has quit [kornbluth.freenode.net irc.freenode.net]
jonafan has quit [kornbluth.freenode.net irc.freenode.net]
jli has quit [kornbluth.freenode.net irc.freenode.net]
mbishop has quit [kornbluth.freenode.net irc.freenode.net]
pango has quit [kornbluth.freenode.net irc.freenode.net]
gaja has quit [kornbluth.freenode.net irc.freenode.net]
mattam has quit [kornbluth.freenode.net irc.freenode.net]
svenl has quit [kornbluth.freenode.net irc.freenode.net]
gim has quit [kornbluth.freenode.net irc.freenode.net]
munificent has joined #ocaml
mbishop has joined #ocaml
jeddhaberstro has joined #ocaml
pango has joined #ocaml
gaja has joined #ocaml
authentic has joined #ocaml
bohanlon has joined #ocaml
sgnb has joined #ocaml
Jedai has joined #ocaml
jli has joined #ocaml
jonafan has joined #ocaml
haelix has joined #ocaml
orbitz has joined #ocaml
svenl has joined #ocaml
caligula has joined #ocaml
petchema_ has joined #ocaml
maxote has joined #ocaml
cygnus_ has joined #ocaml
gim has joined #ocaml
sgnb has quit [kornbluth.freenode.net irc.freenode.net]
authentic has quit [kornbluth.freenode.net irc.freenode.net]
orbitz has quit [kornbluth.freenode.net irc.freenode.net]
caligula has quit [kornbluth.freenode.net irc.freenode.net]
maxote has quit [kornbluth.freenode.net irc.freenode.net]
munificent has quit [kornbluth.freenode.net irc.freenode.net]
jeddhaberstro has quit [kornbluth.freenode.net irc.freenode.net]
petchema_ has quit [kornbluth.freenode.net irc.freenode.net]
bohanlon has quit [kornbluth.freenode.net irc.freenode.net]
Jedai has quit [kornbluth.freenode.net irc.freenode.net]
cygnus_ has quit [kornbluth.freenode.net irc.freenode.net]
haelix has quit [kornbluth.freenode.net irc.freenode.net]
jonafan has quit [kornbluth.freenode.net irc.freenode.net]
jli has quit [kornbluth.freenode.net irc.freenode.net]
pango has quit [kornbluth.freenode.net irc.freenode.net]
mbishop has quit [kornbluth.freenode.net irc.freenode.net]
svenl has quit [kornbluth.freenode.net irc.freenode.net]
gim has quit [kornbluth.freenode.net irc.freenode.net]
gaja has quit [kornbluth.freenode.net irc.freenode.net]
gaja has joined #ocaml
__mattam__ has joined #ocaml
munificent has joined #ocaml
mbishop has joined #ocaml
jeddhaberstro has joined #ocaml
pango has joined #ocaml
authentic has joined #ocaml
bohanlon has joined #ocaml
sgnb has joined #ocaml
Jedai has joined #ocaml
jli has joined #ocaml
jonafan has joined #ocaml
haelix has joined #ocaml
orbitz has joined #ocaml
svenl has joined #ocaml
caligula has joined #ocaml
petchema_ has joined #ocaml
maxote has joined #ocaml
cygnus_ has joined #ocaml
gim has joined #ocaml
jdev has joined #ocaml
r0bby has joined #ocaml
jburd has joined #ocaml
hcarty has joined #ocaml
sbok has joined #ocaml
Mr_Awesome_ has joined #ocaml
Stefan_vK1 has joined #ocaml
mfp has joined #ocaml
Smerdyakov has joined #ocaml
shortc|desk has joined #ocaml
Demitar has joined #ocaml
erg has joined #ocaml
rodge has joined #ocaml
johnnowak has joined #ocaml
alexyk has joined #ocaml
jeddhaberstro has quit []
alexyk has quit []
ygrek has joined #ocaml
munificent has quit [Read error: 110 (Connection timed out)]
vixey has joined #ocaml
__mattam__ is now known as mattam
seafood has joined #ocaml
_zack has joined #ocaml
_zack has quit [Remote closed the connection]
_zack has joined #ocaml
hkBst has joined #ocaml
munga` is now known as munga
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hi
marmotine has joined #ocaml
Camarade_Tux has joined #ocaml
petchema_ has quit [Remote closed the connection]
Camarade_Tux has quit ["Leaving"]
Camarade_Tux has joined #ocaml
fschwidom has joined #ocaml
jonafan_ has joined #ocaml
jonafan has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
ofaurax has joined #ocaml
<kig>
approaching 1:1 tests/code ratio on prelude.ml and i'm only 40% through. this is going to take all weekend :/
seafood has quit []
<kig>
on further inspection, i'm now on line ~1700 and there are 2400 lines of code left, of which i need to test 1900. 511 lines of the 1700 are code. so the 1900 lines of code would require 6270 lines of tests at this ratio, which'll take me two weeks at 500 lines a day. so this is going to take two months instead of two days.
<kig>
(not going to devote more than two days a week)
<flux>
are you sure it's worth it?-)
<flux>
sounds like writing the prelude in Coq and extracting the code is not actually that bad ;-) (well, given one can use coq - but the functions in prelude are pretty simple, right?)
<flux>
have you found bugs?
<kig>
i'm finding a bug every couple dozen test lines
<flux>
so it's pretty much worth it
<kig>
aa, make that a hundred lines. but yeah, it's worth it both in terms of finding bugs, specifying functionality and adding use examples
<kig>
yeah, most of prelude is pretty simple
<kig>
so i get massive test/code ratios by throwing ten lines of tests at a oneliner
<kig>
i'm divided on whether i should turn exceptions to options. it does make for better code but more verbose
<kig>
type 'a excepting = Res of 'a | Ex of exn;; let ex f i = try Res (f i) with e -> Ex e;;
<flux>
unfortunately it also leads to less efficient code, atleast given the exceptional case doesn't happen often
<flux>
but indeed, often option types can be more convenient. it depends.
<flux>
perhaps there could be a language extension that would generate option-typed function out of an exception-returning and vice versa..
<flux>
actually ocamlexc, if it worked, would be sufficient for me
maskd has joined #ocaml
<mrvn>
I sometimes wish exceptions would be part of the type.
<mrvn>
List.find : ('a -> bool) -> 'a list -> ('a x Not_found) or something.
<mattam>
X. Leroy and some other guy had such a system for caml light I think.
ikaros has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
<mattam>
It's been studied a lot under the name of "type and effect systems".
<mrvn>
Most importantly I want the compiler to tell me when a function throws an exception I haven't specified (if I specified a type).
<mattam>
Of course. And type inference should be precise.
<mrvn>
Unlike in C++ where unspecified exceptions gets transformed.
<mattam>
The point of the system is to have that if an expression's type has an empty exception set then it won't throw.
<mattam>
s/to have/to ensure/
<mrvn>
That is just a special case of any given set.
<mattam>
Indeed.
<mrvn>
But you probably often want to have such points in your code where you know no exception can be thrown, every possible exception below will be cought and handled.
<mrvn>
It gets a bit problematic when you have code like this: let wrap f x = try f x with Not_found -> 0
<mrvn>
How do you specify that f can throw anything and wrap only anything but Not_found?
<mrvn>
Or even more complicated. wrap could throw some exceptions only when f throws a certain one.
johnnowak has quit []
johnnowak has joined #ocaml
<mattam>
mrvn: basically you have an equational theory on sets of exceptions which you can decide.
<mattam>
So you have set difference for the first case (and exception variables for exception-polymorphism).
<mattam>
Possibly, you'd want exception set abbreviations as well :)
<mrvn>
And an exception hierachy. So you can say that a function throws all kinds of IO exceptions without listing the specifics.
<mattam>
Yep.
Anarchos has joined #ocaml
marmotine has quit [Remote closed the connection]
rwmjones has joined #ocaml
rwmjones has quit [Client Quit]
marmotine has joined #ocaml
Yoric[DT] has quit [Read error: 60 (Operation timed out)]
rwmjones has joined #ocaml
Associat0r has quit []
thelema has joined #ocaml
Yoric[DT] has joined #ocaml
pango has quit [Remote closed the connection]
_zack has quit ["Leaving."]
_zack has joined #ocaml
pango has joined #ocaml
Anarchos has quit [Read error: 60 (Operation timed out)]
<Smerdyakov>
mrvn, a lot of folks (me included) think it's better just to avoid using exceptions.
<mrvn>
And use type res = Result of 'a | Exception of 'b return types?
<thelema>
as with most tools, exceptions can be misused. I think they're a better foundation for exceptional return types than allocation.
<Smerdyakov>
I'm suggesting using expressive return types in general. You gave one example.
<Smerdyakov>
thelema, "allocation"?
<thelema>
It's good to provide both expressive returns as well as exceptions.
<thelema>
Result x requires allocation
<Smerdyakov>
thelema, in what sense is it good? I'm all for letting people run off and use whatever crazy languages they want, but I prefer languages without exceptions.
<Smerdyakov>
thelema, which means that I prefer to use other people's libraries written in such languages.
<thelema>
I approve of implementing with exceptions and then (as appropriate) catching the exception to return an option type
<thelema>
but the option should be given to avoid allocation where possible
<Smerdyakov>
I also hate using languages that only have implementations where particular pure features are guaranteed to trigger allocation.
<mrvn>
The nice thing about exceptions is that you don't have to handle them at every level but they skip to the next exception handler.
<Smerdyakov>
mrvn, failure monads deal with that handily.
<thelema>
mrv: no, that's a bad thing about exceptions - I expect Smerdyakov will agee with that.
<thelema>
I think it's better to deal with an exceptional condition as close to where it occurs as possible.
<Smerdyakov>
And it's even better to use richer static checking to rule out the possibility of exceptional conditions.
<mrvn>
I agree with you there. Would be nice to have exceptions part of the type.
<flux>
isn't that rather the point of exceptions, not needing to handle them at every level?
<mrvn>
flux: imho yes.
* thelema
counts that as secondary
<Smerdyakov>
mrvn, maybe I wasn't clear. Types should impose conditions on inputs, such that nothing exceptional can happen.
<thelema>
they're a flow-control construct.
<thelema>
read errors will still happen despite any type system.
<mrvn>
Smerdyakov: Which you would have if exceptions where part of the type.
<thelema>
and the worst exception, OutOfMemory
<Smerdyakov>
thelema, those are rare cases.
<flux>
but yes, it would be nice if the type system could see exceptions also. but I imagine that is not a trivial problem, even though solutions - untested - can be thought of with ease :)
<thelema>
Smerdyakov: one might call those "exceptional" cases.
<mrvn>
In say a bittorrent client an error on a socket is quite usual.
<Smerdyakov>
thelema, no one handles out-of-memory exceptions, so we can just take that off the table.
<vixey>
Smerdyakov, really? I've read code that does
<Smerdyakov>
mrvn, yes, interaction with the outside world is a special case that usually makes up relatively little of a body of code.
<vixey>
Smerdyakov, admittedly, it's stuff written for the computers 3 generations ago
<thelema>
interaction with the outside world is something best encapsulated in libraries to deal with its complexities while presenting a simple interface to the programmer.
<thelema>
smer: apparently your world doesn't include much embedded code that has to just keep working.
<mrvn>
thelema: Where do you see the control flow difference with exceptions? if foo then raise Bla else 0 vs. if foo then Exception Bla else 0 has the same flow.
<mrvn>
s/0/Res 0/
<vixey>
mrvn: f (if foo then Exception Bla else 0) vs f (if foo then raise Bla ...) is different though
<vixey>
(even just trying to typecheck it says)
<thelema>
vixey: modulo monadic handling of Exception Bla
<mrvn>
vixey: that is the part about having to handle the option type at every level versus excpetions jumping to the exception handler.
<thelema>
mrvn: actually, they're really similar. the runtime has to check every level for an exception handler, vs. each level checking itself for the exceptional value
<mrvn>
thelema: the difference is between you having to type it and the compiler doing it automatically.
<thelema>
more or less. proper use of monads makes the "having to type it" very minimal: ==<
<mrvn>
using failure monads is also just you doing what the compiler does with execptions automatically.
<mrvn>
You get more control for more work.
<thelema>
except in languages with blazing-fast exceptions and non-disappearing allocations
<thelema>
and I don't see any additional control.
<mrvn>
thelema: you can have 0-n monads for different cases.
<thelema>
and you can't do that with exceptions?
<mrvn>
there is only raise. you have to chain the exception handlers.
<thelema>
you mean when multiple exceptions are raised "simultaneously"?
<thelema>
(exceptions raised in handling another exception)
<mrvn>
thelema: or just different kinds. You can have multiple failure monads but only one exception handler.
<maskd>
wikipedia's article on ocaml says "Aside from type-checking overhead, functional programming languages are, in general, challenging to compile to efficient machine language code, due to issues such as the funarg problem." -- what would be the overhead, since type-checking is done at compile time?
<mrvn>
maskd: scheme does it at runtime
<mrvn>
but perl or python too so that really isn't related to functional language
<Smerdyakov>
maskd, what is "the funarg problem"?
<mrvn>
maskd: Maybe they ment that bindings are usualy boxed so the GC can work on them.
<Smerdyakov>
mrvn, Wikipedia makes it look like it's just handling of first-class functions with lexical scope capture.
<thelema>
from WP: Some efficiency-minded compilers employ a hybrid approach in which the activation records for a function are allocated from the stack if the compiler is able to deduce, through static program analysis, that the function creates no upwards funargs. Otherwise, the activation records are allocated from the heap.
<Smerdyakov>
maskd, that description is overly charitable to OCaml, which is a very primitive compiler compared to the competition.
<Smerdyakov>
maskd, such performance issues are handled quite well by MLton, for example.
<mrvn>
thelema: That assumes that stack allocations are slower than heap allocations.
<thelema>
mrvn: I don't know any case where they aren't.
<thelema>
(especially including overhead for GC vs. popping from stack)
<mrvn>
thelema: true. The GC takes more time than stack frames.
<Smerdyakov>
There situations where copying GC is obviously more performant than stack usage.
<maskd>
Smerdyakov: what performance issues? type checking or the funarg problem?
<thelema>
Smerdyakov: care to elaborate? I can't think of any.
<mrvn>
On the other hand funarg lets you do all sorts of things that are way faster than simulating them in a stack based system.
<Smerdyakov>
maskd, I assumed you were talking only about runtime performance issues.
<Smerdyakov>
thelema, making many function calls, you have per-call overhead for deallocation.
<Smerdyakov>
thelema, if most objects are short-lived, most impose no deallocation cost.
<Smerdyakov>
thelema, (with copying GC)
<mrvn>
Smerdyakov: incrementing the stack pointer is no real cost
<thelema>
with copying GC, the frequency of collection depends on allocation rates, so there is an extra cost to those allocations.
<mrvn>
thelema: O(1)
<mrvn>
and practically as cheap as malloc/free implementations
<thelema>
yes, each collection is O(1), but the rate of collecting depends on allocation rate.
<thelema>
so if you allocate 50M objects, you won't run the same number of O(1) collections as if you allocate 5.
<thelema>
and we're comparing GC vs. incr/decr of SP.
<mrvn>
thelema: it is constant cost per allocation when amortised over all allocations
<thelema>
yes. And there's a constant cost to moving the stack pointer. I claim the stack pointer is faster.
itewsh has joined #ocaml
<thelema>
constant cost per allocation = O(n)
<mrvn>
thelema: The problem is that you are comparing apples with oranges.
<mrvn>
thelema: The cases where you can do it with just the stack pointer in other languages you can also do with just the stack pointer in functional languages given a good compiler.
<thelema>
and that's what good functional languages do.
<mrvn>
Cases where you need heap space you need malloc/free in other languages, which is often more expensive.
<thelema>
I'm just saying that stack allocation is faster than heap allocation.
<thelema>
I agree that stack allocation isn't sufficient for everything.
<thelema>
but even with a copying GC and short-lived objects, stack allocation wins.
<thelema>
especially with all objects short-lived
<thelema>
non-short-lived objects need to be allocated on the heap, not the stack.
<mrvn>
all I'm saying is that overall it is never enough and in a mixture of stack and heap there is nothing in functional languages that makes them worse than others.
<thelema>
don't mistake me for someone who doesn't love FP.
alexyk has joined #ocaml
<mrvn>
"The downwards funarg problem complicates the efficient compilation of tail recursion and code written in continuation passing style. In these special cases, the intent of the programmer is (usually) that the function run in limited stack space, so the "faster" behavior may actually be undesirable."
<mrvn>
Sometimes slower is faster. :)
<mrvn>
From my experience of ocaml the parts where it is slower is usualy heavy iterative computations. Specially when you need machine words. Say md5, sha1 algorithms.
<mrvn>
That's where some short C code comes in handy.
<thelema>
yes, ocaml's heap allocation of machine words does cause problems for such code, but that's rarely a problem
<mrvn>
Boxing objects can be expensive.
<mrvn>
Does ocaml store Int32.t as normal ints on 64bit cpus?
proq has joined #ocaml
<thelema>
no, Int32.t is always boxed
* thelema
takes that back - he doesn't know.
<mrvn>
32bit cpus suck majorly. I have a lot of code for my Fuse filesystem where 62bit ints are just fine. But for 32bit cpus I have to use Int32 or Int64 types.
<Camarade_Tux>
thelema, from the Int32 documentation : 'Performance notice: values of type int32 occupy more memory space than values of type int'
<Camarade_Tux>
they are most probably boxed
<thelema>
that goes along with my first impression, but I didn't know whether there was an optimization for 64-bit cpus
_zack has quit ["Leaving."]
<Yoric[DT]>
Yeah, Int32 are boxed.
<mrvn>
too bad.
* thelema
wouldn't put it past someone to extend the implementation to unboxed on 64-bit platforms
<mrvn>
doesn't seem to complicated to say "type int32 = int" on 64bit systems. Although over/underflow would differ then.
<thelema>
yeah, there'd be more work involved
<thelema>
ocaml doesn't do conditional compilation very well.
<mrvn>
I would need Int_least32 and Int_fast32 types like C has.
* thelema
wouldn't mind more int datatypes
<thelema>
especially if they could be used to nearly auto-generate bindings to C functions
<mrvn>
I'm missing Uint32 the most.
<thelema>
for doing md5 and sha, yes. Just use Int32 and ignore the sign oddities.
<thelema>
I think there is someone who wrote a UInt32 module, though.
<mrvn>
naj, just create some C bindings and use existing libs.
<hcarty>
There is a library on the forge with unsigned 32bit and 64bit integer support
<mrvn>
The thing I really miss in ocaml is that the conversion between unis error number and exceptions isn't public and reversible.
<mrvn>
s/unis/unix/
<mrvn>
For Fuse I need to return errors like ENOENT from the ocaml code back to C.
alexyk has quit []
<kig>
have you written a mapper for that? otherlibs/unix/unixsupport.c looks like the thing to copy
<mrvn>
kig: Only goes one way as far as I saw and I don't want to duplicate that code. I want to use it.
<kig>
there's a hole in that chain of reasoning between "the code doesn't exist" and "i don't want to duplicate it"
alexyk has joined #ocaml
<mrvn>
kig: Half ot it exists: Mapping unix to ocaml.
<mrvn>
kig: Problem is that if I add a ocaml to unix mapping and the next ocaml compiler changes its Unix module then my code breaks.