<taw_>
i want an object to have in its fields objects that link back to it
Tachyon76 has joined #ocaml
PierreTramo_ has quit [Read error: 113 (No route to host)]
shawn has quit [Connection timed out]
shawn has joined #ocaml
_shawn has quit [Read error: 110 (Connection timed out)]
<love-pingoo>
taw_: looks like the problem is not related to the back-linking but it's just that instance variables "cannot be accessed from the definition of another instance variable"
<love-pingoo>
but OK, refactoring is difficult because of the loop dependency
<love-pingoo>
taw_: what's the supposed interface of node, why does it depend on graph ?
<love-pingoo>
btw, other question: is there a std function for escaping shell's special chars ?
<flux__>
love-pingoo, I don't remember (infact there might be a function for doing atleast ocaml-quoting), but when I run external programs through the shell, I pass tricky data via environment variables
<flux__>
and sidestep the issue of quoting altogether
<love-pingoo>
yeah, but here I let the user script my app, and call a string->string function for shell calls, I should also to give him an escape function
<love-pingoo>
-to
<taw_>
love-pingoo: well, this is a minimal example, but something like node#add_neighbour : node
<love-pingoo>
taw_: then try to write node before graph, by specifying the relevant subtype of graph needed for the methods of graph
taw__ has joined #ocaml
<taw__>
taw_: die
<taw__>
any solution for my problem when my session was dying ? ^_^
<love-pingoo>
<love-pingoo> taw_: then try to write node before graph, by specifying the relevant subtype of graph needed for the methods of graph
<love-pingoo>
that's all :)
<love-pingoo>
then ocaml will accept a graph at these placeholders
<taw__>
uhm, they're specified together
<taw__>
class a = ... and b = ... and c = ...
<love-pingoo>
taw_: the types may be cyclic but not the definition of the classes
taw_ has quit ["Lost terminal"]
<taw__>
uhm, how can i initialize root field then ?
<love-pingoo>
class a = object method f (b:<f:int>) = b#f end
<love-pingoo>
class b = object val a = new a method f = a#f end
<love-pingoo>
does it help ?
<love-pingoo>
instead of the int you can even put a "a"
<taw__>
b's initializer needs (a:a) argument
<taw__>
my best result so far is : val mutable root : node = Obj.magic () method init = node <- self#add_node
<taw__>
uhm, root <- self#add_node, anyway :-)
<love-pingoo>
bad idea
<love-pingoo>
Obj.magic can break the garbage collection
<love-pingoo>
class b (a:a) = object method f = a#f end
<love-pingoo>
that works after my definition of class a too
<mattam>
so you want to live in a point free world, just saying which morpisms you want to use ?
<mattam>
maybe we're not talking on the same level
<Smerdyakov>
Just look at the first example program in the demo. :)
<mattam>
yeah, i know
<Smerdyakov>
Most software has nothing new in its and should be assembled in almost entirely a point free manner, yes.
<mattam>
i see, you're not talking about algorithms but components
<Smerdyakov>
Algorithms are usually irrelevant.
<mattam>
however vague it may be
<Smerdyakov>
Programmers don't write algorithms much in practice.
<mattam>
well, that's the hardest code to prove in my view
<Smerdyakov>
And the least numerous. It's a violation of the old rule of optimizing the common cases.
<mattam>
so the most interesting one
<Smerdyakov>
It's so uncommon that proofs can be constructed manually very cheaply.
<mattam>
well, i'm not talking about optimizing i'm talking on proving difficulty.
<mattam>
i actually agree that 'components' ougth to be freely and easily composable
<Smerdyakov>
I know. It's easy to prove the correctness of almost all algorithmic components, compared to the total effort needed to build software products.
<mattam>
i'd say it depends on the product and the technology you use.
<Smerdyakov>
I'm quantifying over all software development, contingent on the right choices of technology.
<mattam>
well, that may be true. We'll see when provers are able to tackle such problems if it's actually the hardest part.
<mattam>
or just that technology was not adequate
<Smerdyakov>
Provers already _are_ able. Just see the CompCert project!
<mattam>
well, you're talking about general, potentially complex software.
<Smerdyakov>
What's more complex than a compiler? :)
<Smerdyakov>
Answer: Almost nothing, quantified over software today!
<mattam>
i should have said complicated
<Smerdyakov>
The "complexity" or "complication" you see comes from bad language tools.
<mattam>
well yes
<mattam>
in a way
<Smerdyakov>
You see these hot shots bragging about how their software has millions of lines of code, but almost all of it should have been generated by a compiler, and could have been with technology from the 80's.
<mattam>
but CompCert is certainly not the end. The project was taylored to the possibilities of the prover.
<descender>
hahaha
<Smerdyakov>
mattam, OK, but based on my own experience, today I refuse to accept insinuations that complete program verification is a lofty goal of the future.
<Smerdyakov>
mattam, I do it every day.
<Smerdyakov>
mattam, and for programs much more complicated than 99% of programmers ever dream of writing.
<mattam>
yeah i know
* Smerdyakov
disappears for a bit.
<mattam>
actually CompCert is a good example of my point. The hardest part of all was to prove the optimizations done by the compiler correct, not the 'dumbed down' compiler certification.
jcreigh has quit [Read error: 110 (Connection timed out)]
* mattam
just commited ocaml-3.09.2.ebuild
jcreigh has joined #ocaml
<mikeX>
kala den tou leo
<mikeX>
oops sorry
khaladan has joined #ocaml
khaladan_ has joined #ocaml
khaladan_ has left #ocaml []
<mikeX>
The length and position of last character of an Objective CAML string are determined not by looking for a terminating null character, as in C, but by combining the size of the memory block that contains the string with the last byte of the last word of this block, which indicates the number of unused bytes in the last word.
<mikeX>
does this sound about right?
<Smerdyakov>
I have no idea. I would have assumed that a string simply start with a word giving the length.
<mikeX>
there's a figure there describing the machine representation of structured types
<mikeX>
so that makes String.length O(1), right?
<mellum>
mikeX: sure. It's O(1) in any decent language
<mikeX>
i see mellum, thanks
Snark has quit ["Leaving"]
Schmurtz has quit ["Plouf !"]
jcreigh has quit ["Do androids dream of electric sheep?"]
teop has quit ["Chatzilla 0.9.72 [Firefox 1.0.7/20051010]"]
_JusSx_ has quit ["leaving"]
<ulfdoz>
What's this good for?
<ulfdoz>
val choose : t -> elt
<ulfdoz>
Return one element of the given set, or raise Not_found if the set is empty. Which element is chosen is unspecified, but equal elements will be chosen for equal sets.
<ulfdoz>
It's from docs of Set.Make
<flux__>
well, for taking an element?-)
<flux__>
you never need to take an element, any element?
<ulfdoz>
It's strange, that you can't know what element is taken.
<flux__>
it doesn't always matter
<zmdkrbou>
if your algorithm relies on the choice axiom, then you got your choice function :)
<flux__>
and if you have that luxury, you might just use it to gain some (marginal) performance gain ;)
<ulfdoz>
choice axiom. A bell rings deep inside my head.
<flux__>
likely you would use that function iteratively: choose, remove, choose, remove..
<zmdkrbou>
many algorithms (on graphs as exemple) use sets, and you have this "take any x in S, then do ..." repeated until S is empty
<flux__>
choose + remove is likely faster than (min|max)_elt + remove
<ulfdoz>
but choose/remove is a good example. I think I can even use it for my problem. :)
<flux__>
infact, choose is probably O(1), while (min|max)_elt are O(log n)
<flux__>
although the documentation doesn't provide such guarantees
<flux__>
remove is probably O(log n) too, though, so it in the O-sense it wouldn't matter ;)