<flux>
sdschulze, an alternative would be to have the whole module be recursive. that would allow direct access to all the functions in Node_set, which might be what you're after..
<flux>
sdschulze, of course, if you just stick in the 'interface' class, you can cast your actual object into that
<flux>
(infact it might not even need casting)
spearalot has quit [Quit: -arividerchi]
<sdschulze>
Another general question about sets: what data type is used for their internal representation and why are manipulations on them purely functional?
<flux>
for sets?
<flux>
ah, yes :)
<flux>
they are red-black binary trees
<flux>
and they are functional, because that's how we roll in functional languages..
<flux>
if you want 'mutable', you can make-do with a reference type
<flux>
if mutable was the default, there would be no going back to immutable
<sdschulze>
Doesn't adding an element involve reordering of the tree?
<flux>
it might, but you can usually use a great part of the original tree as-is
<flux>
and the new tree is mostly shared with the old one
<flux>
what really is new is the path to the newly inserted nodes, and some other nodes if rebalancing is required
<flux>
in red-black trees the r/l branch can be at most 2x the depth as the opposite branch, so it is not rebalanced continuously
<flux>
s/continuously/repeatedly/
<sdschulze>
ok
<flux>
actually it turns out I misremembered, they are not red-black-trees. looks like avl trees, not sure.
<flux>
btw, map.ml is only 200 lines (and doesn't depend on anything), so it's feasible to read ;)
<sdschulze>
I already found it before, but my knowledge on trees isn't that good, so I didn't recognize it at once.
<sdschulze>
Is immutability better for the compiler?
<sdschulze>
(can it maybe store the payload unboxed?)
<det>
Yeah, ocaml set/map is avl tree
<flux>
well, the compiler might be geared towards immutability, but afaik one big winner is the garbage collector, which like immutability
<flux>
which likes, even
<thelema>
flux: avl trees w/ height distance at most 2
<flux>
thelema, I guess that assertion changed in the RB/AVL mixup :)
<det>
I think immutability is over rated
<thelema>
det: immutability is nice when it's nice and inconvenient when it's inconvenient. Having few immutable values in a program makes it easier to reason about
<det>
I think immutability often makes the program convoluted
<flux>
det, well, as I said: it's much easier to go from immutable to mutable than the reverse
<det>
Sometimes a "for" loop + mutation is much easier to understand than a fold
<sdschulze>
flux: Why exactly? If you consider the easier example of immutable lists, you cannot change the tail of a list, but you can still refer to it, so the respective object must be known to the GC.
<flux>
I must admit I have sometimes written some quite convoluted folds..
<det>
me too
ccasin has joined #ocaml
<thelema>
Many folds are just while loops in disguise, true
<det>
very tempting to convert to iter/mutation
<derdon>
fold, map etc. are simply cool 8)
<derdon>
for and while are not cool at all
<det>
well
<flux>
sdschulze, I don't know the details, that's just the general concensus I've seen from mailing lists. apparently immutability is somehow exploited by the gc.
<det>
foreach is really just iter
<flux>
what det probably means are situations when you usually use fold
<derdon>
det: and the difference is again: coolness
<derdon>
det: foreach is not cool, but iter is
<flux>
for example if you need to fold over a structure that has static three levels and keep summing some values
<flux>
well, obviosuly you can do it as I've done it quite a few times
<sdschulze>
flux: OK, it might give you a factor of two.
<flux>
but I cannot help thinking that simply putting three foreach-inside-foreach updating a mutable variable would be simpler
<det>
yeah, that is a good example
<sdschulze>
As the tutorial says: loops are second-class citizens in OCaml.
<det>
i never have the urge to use while or for in Ocaml
<flux>
sdschulze, btw, I put up a new mutrec.ml, it demonstrates the fully recursive module -based solution
<sdschulze>
flux: OK, thanks
<sdschulze>
det: It's probably about as cool as trying to do a fold in C...
<flux>
there are counter-examples to mutation though. for example I hate the interface of the Arg-module, as it requires using mutability ;)
<det>
I've never used the Arg module
<det>
I agree though, I'd like both options available
<flux>
my fold-based (simple) version allows separating the argument list fully separate from the variables themselves
<flux>
but there is a price to pay..
<flux>
(["--port"; "-p"], CmdArg.int (fun c port -> { c with c_port = port }),
<flux>
("port", "Set the port to listen (default: " ^ string_of_int default.c_port ^ ")"));
<det>
ya, I cant help but think mutating a record would be simpler than function record update
<det>
btw
<det>
why not use Printf
<flux>
I usually do, infact..
<flux>
but it looked more similar to other strings that simply concatenated other strings
<det>
printf is always easier for me to read
<sdschulze>
The general problem I see about using things like lists is that the number of GC objects is linear to the length of the list.
<flux>
obviously it's not if you never modify the end?-)
<sdschulze>
?
Yoric has quit [Ping timeout: 276 seconds]
mal`` has quit [Quit: Coyote finally caught me]
<flux>
I was actually thinking a simplified case. for example for a list of ints the gc could know that if all its elements are already moved into the long-term gc pool, it doesn't need to scan it ever again?
<flux>
not convinced that gc would do that kind of analysis though :)
<sdschulze>
So polymorphism is rather bad for unboxing?
<flux>
yes, unless you throw out the uniform data representation
<sdschulze>
Are there any papers that describe the way OCaml works internally?
<mfp>
sdschulze: if you're interested in the data representation and some GC details, the "Interfacing C with OCaml" part of the manual might help you
sdschulz` has joined #ocaml
sdschulze has quit [Read error: Operation timed out]
<mfp>
sdschulz`: <mfp> sdschulze: if you're interested in the data representation and some GC details, the "Interfacing C with OCaml" part of the manual might help you
sdschulz` has left #ocaml []
sdschulze has joined #ocaml
<sdschulze>
mfp: thanks
<derdon>
which ocaml lib can be recommended for parsing command line options? it should respect the POSIX standard, i.e. accept short and long options for example (the Arg module from the stdlib falls therefore out)
<flux>
derdon, I haven't tried, but atleast ocaml-getopt promises that in its name..
<derdon>
flux: good. thank you!
<derdon>
many ocaml projects lack of good documentation
<derdon>
or of documentation in general
<flux>
mli-files go a long way
<derdon>
flux: mhh
<derdon>
flux: online or pdf files are much better to read
ikaros has joined #ocaml
<sdschulze>
.mli files don't include the variable names for the function arguments, so they suck for documentation.
<flux>
it is rare you see functions like val frabilucate : int -> int -> int -> int -> int
<flux>
so value and type names and library's purpose both need to be taken into account :)
<flux>
of course, if you're lucky, there is a comment with parameter names at the value declaration site
<flux>
and if you're really lucky, there's some actual genuine well-written documentation on how to use the library, with examples!
<derdon>
flux: and this is what I expect!
<derdon>
this is what I am used to from other programming languages (python)
<derdon>
see the pocoo projects on dev.pocoo.org
<derdon>
they have great documentation
<flux>
perhaps there's less social pressure or something to make ocaml writers write documentation
<flux>
or perhaps they are not immersed in examples of other people doing that
<derdon>
so we'll start with good documentation to impress other ocaml programmers and make them imitate us :D
leino has quit [Quit: Lost terminal]
jimi_hendrix has joined #ocaml
<jimi_hendrix>
hello
<jimi_hendrix>
where would the best starting place to learn ocaml be?
<derdon>
jimi_hendrix: the official tutorial, ocaml-tutorial.org, and the o'reilly book
<derdon>
no particular order here; I read from everything every day a bit ;)
<jimi_hendrix>
i see
<jimi_hendrix>
and what would be a good simple project to make to test my knowledge?
<jimi_hendrix>
i have not used a functional language before
<derdon>
jimi_hendrix: hm. the typical excercise is "guess a number"
<derdon>
these excercises don't have to be related to functional programming, btw
<derdon>
you can try to write an addressbook
<derdon>
I love lexing & parsing, so I wanted to start with ocamllex and ocamlyacc very early
<derdon>
a few days ago, I started with an invented esoteric programming language :D
<jimi_hendrix>
ah
<derdon>
jimi_hendrix: and it's very important to learn a lib which extends the standard lib of ocaml, e.g. the batteries
<jimi_hendrix>
why is that?
<derdon>
jimi_hendrix: because the stdlib of ocaml is rather small
<derdon>
and it doesn't offer nice functions for I/O, for example
<derdon>
I don't know how the batteries work with unicode, but I know that the standard lib of ocaml is bad at it
<jimi_hendrix>
i see
<jimi_hendrix>
what lib would you recommend?
<derdon>
jimi_hendrix: surprise, surprise: the batteries :D
joewilliams_away is now known as joewilliams
jakedouglas has joined #ocaml
ulfdoz has joined #ocaml
joewilliams is now known as joewilliams_away
Chicco has quit [Ping timeout: 246 seconds]
<thelema>
11:00 < det> i never have the urge to use while or for in Ocaml
<thelema>
det: the algorithm that most encouraged for loops in my ocaml was:
pimmhogeling has joined #ocaml
<thelema>
All pairs shortest path -- with three nested for loops
<thelema>
which I can't seem to find at the moment...