<SmerdyOffice>
arcticd, I would bind the 'readfile_lines' result to a variable, perform the 'close_in', and return that variable.
<SmerdyOffice>
arcticd, also, I wouldn't use parentheses in the List.rev call.
<arcticd>
Ok...But putting the List.rev call in that function is fine or?
mpc has quit []
<pango>
it's ok
mpc has joined #ocaml
<arcticd>
Thanks everybody...That was a long way to read a file :) Bye
arcticd has quit [Client Quit]
fab_ has joined #ocaml
_fab has quit [Read error: 110 (Connection timed out)]
mpc has quit []
SmerdyOffice has quit ["home"]
mrsolo has quit [Read error: 104 (Connection reset by peer)]
booyaa has joined #ocaml
tom_p has quit [Read error: 110 (Connection timed out)]
mpc has joined #ocaml
mpc has quit [Client Quit]
faigo has quit ["Leaving"]
tom_p has joined #ocaml
pango_ has joined #ocaml
pango has quit [Read error: 104 (Connection reset by peer)]
* Smerdyakov
LOL's at the title of a chapter of _Coq'Art_: "Dependent Products <i>or</i> Pandora's Box"
Mathman has quit [zelazny.freenode.net irc.freenode.net]
Codename_V has quit [zelazny.freenode.net irc.freenode.net]
Nutssh has joined #ocaml
threeve has quit []
tom_p has quit [Read error: 110 (Connection timed out)]
Schmurtz has quit ["Plouf !"]
__DL__ has joined #ocaml
tom_p has joined #ocaml
booyaa has quit ["leaving"]
Codename_V has joined #ocaml
pango_ has quit [Remote closed the connection]
mlh_ has quit [Remote closed the connection]
Submarine has joined #ocaml
pango has joined #ocaml
Skal has joined #ocaml
batdog is now known as batdog|gone
batdog|gone is now known as batdog
batdog is now known as batdog|gone
batdog|gone is now known as batdog
vdrab has joined #ocaml
<vdrab>
Hello 'camlers. i've searched around for this one, but couldn't find any answer on the net. Is there a way for a polymorphic function to check the type of an argument ? I'm trying to define a polymorphic printf function.... no go?
<vdrab>
this is obviousy newbie stuff...
<haakonn>
the question is why would you need the type
<haakonn>
using sum types instead is probably what you want
gim has quit ["piouf"]
ejt has joined #ocaml
<vdrab>
because , say, printf "%f" arg wouldn't work on an int argument
<haakonn>
so the function is polymorphic in the sense that arguments can have one of a couple of predetermined types, right?
<vdrab>
and using constructors for every occurence of an int or float doesn't feel like a realistic option
<vdrab>
right.
<haakonn>
i'd just use a sum type, like 'type foo = Int of int | String of string | ...', and then use matching in the function to determine the printf call
<vdrab>
that would obviously work, but it also means rewriting all my code to add constructors for every little int used.... that doesn't sound like an option, really
<haakonn>
that would admittedly be boring
<haakonn>
i understand you can use the Obj module to determine type to some extent, though i haven't tried it
<__DL__>
vdrab: what you want is a generic function. Gcaml exist but it's still in early develoment.
<vdrab>
so, there is no way to access type info? like, " match (type arg) with ... "
<vdrab>
I see
<__DL__>
no, type information are lost at run time
<vdrab>
doh
<__DL__>
an int and char have same internal representation, one cannot at run time now is sommething is a int or a char
<ejt>
vdrab: why don't you know what the type is at compile time ?
<vdrab>
ehm.... I guess I do. ... just trying to get some form of pretty printing without having to define a separate function for every data type.... something like haskell's Show class comes to mind, but I haven't found the equivalent in ocaml...
<bacam>
vdrab: Instead of having stuff like printf "%f" somefloat, you can write a function along the lines of printf (Float f)
<ejt>
or, print_float, print_int
<vdrab>
bacam: right, that is what haakonn suggested
<mflux_>
I suppose it would finally look like printf "hello %2, you are %1 years old." [I age; S name]
<vdrab>
ejt: that is sort of what I want to avoid...
<mflux_>
without using the format string hacks (that the Printf-module uses)
<ejt>
vdrab: ML avoids function overloading (thankfully). Consider how + and +. are seperate
<haakonn>
thankfully? hm
<vdrab>
ejt: yes,
smimou has joined #ocaml
<haakonn>
i think it leads to stupid things like modules with one function "create" and another function "make", etc :)
<vdrab>
How do you people usually deal with situations like that? I'm still very much learning the ropes here, so I 'll take any advice... you just define a printer for every data type? isn't that rather medieval?
<ejt>
that's just bad naming, they could just as easily be called 'make_from_list', 'make_from_vector'
<haakonn>
ejt: perhaps
Submarine has quit [Remote closed the connection]
<ejt>
vdrab: I don't print that much out, but when I do I tend to convert to a string by hand and then pass to print_endline
<mflux_>
vdrab, use Printf-module
<vdrab>
I was using printf, but it doesn't seem to solve my problem... can you elaborate?
<mflux_>
with proper functions you can write like Printf.printf "vector: %t.\n%!" (vector_display v)
<mflux_>
which I think is slightly better than print_ for each datatype
<mflux_>
let vector_display v st = Printf.fprintf st "x=%d, y=%d" v.x v.y
<mflux_>
(so you really actually have print_ for each datatype, but with an argument order suitable for currying ;))
<vdrab>
hmm... so it's partially applied...?
<vdrab>
i see
<vdrab>
I should have never gotten used to python before switching to ocaml.... ; )
<haakonn>
btw, is partial application "cheap", or would you want to avoid it in performace-critical code?
<mflux_>
well it does atleast involve additional jumps..
<mflux_>
so propably not
<mflux_>
I don't think ocaml is particularly good at inlining those
<haakonn>
so probably avoid?
<mflux_>
yes
<mflux_>
but, benchmark first, optimize later ;)
<haakonn>
very true :)
smimou has quit ["?"]
<vdrab>
here's another one: how do Map and Hashtbl compare in terms of performance? I don't need an updateable hash, but the documentation for Map looks scary...
<haakonn>
i use PMap from extlib, it's like Map but without the scary functor stuff
<vdrab>
cool. is extlib included in the standard distribution, or do I have to go find it?
<haakonn>
you have to go find it :)
<vdrab>
sigh
<vdrab>
ok, thanks.
<haakonn>
i use godi for easy lib installations
<haakonn>
it's like apt-get but for ocaml :)
<vdrab>
oh, wow
<vdrab>
best news in days
<haakonn>
or you could use Map and have a go at functors, could be a useful exercise
Submarine has joined #ocaml
<bacam>
I wouldn't go to the bother of installing another library just to avoid a single functor application...
<vdrab>
true, that. but it means I have to learn about functors first...
<ejt>
Map is straight forward to use
<ejt>
vdrab: what do you wnat to put in the map ?
<haakonn>
(i actually ripped PMap out of extlib and use it separately, works ok :)
<bacam>
Yup, you don't really need to know functors to use it.
<vdrab>
ejt: just a list of attributes for every occurrence of some data type I defined. does that mean I have to cook up a hash function as well?
<ejt>
so you want strings as the keys ?
<vdrab>
not if I can get away without it.... the standard compare function seems to work on my data type, so...
<haakonn>
it magically works on any type
<vdrab>
aha
<haakonn>
(unless you have some specialized notion of comparison of course9
<vdrab>
so, then that means my data type can be used as a key, correct?
<haakonn>
yep
<vdrab>
sweet
<haakonn>
which is why writing functors are just boring boiler-plate to me everytime i've done it :)
revision17 has quit [Read error: 110 (Connection timed out)]
<vdrab>
so, to get back to the original question, are Map and Hashtbl comparable in term of performance?
<ejt>
heh, I didn't know that, I've been writing ordered modules for my own types
<ejt>
Map will be slower, but it's still fast, and I find I have fewer bugs if I use functional data structures
<haakonn>
ejt: amen to that
<vdrab>
in that case, I think I 'll go with Hashtbl... :-) I don't need to update the hash, just use it for reference.
<haakonn>
immutable types are very useful :)
<vdrab>
so, i can use it in a purely functional way
<ejt>
hmm
<haakonn>
how is Map slower btw?
<ejt>
I've not benchmarked it
<haakonn>
they both have the same time complexities afaik
<haakonn>
for me Hashtbl was a lot slower because i needed to copy it a lot :)
<vdrab>
O(log2) ?
<ejt>
insertion should be O(1) for hash, I don't think this is true for Map
<haakonn>
hm, probably logarithmic for Map, yes
<vdrab>
under the hood, they are both binary trees though, right?
<ejt>
no
<haakonn>
Map is, Hashtbl is not
<vdrab>
oh really?
<ejt>
hash table is an array of lists
<vdrab>
what are the array's indices then?
<ejt>
which is why you need to make a good estimate for the number of items in your hash when you create it
<haakonn>
vdrab: hash(value) mod x :)
<ejt>
array is indexed by hash value
<vdrab>
so the hash function gives you an int value, and that is the index? interesting
<haakonn>
the int is taken modulo the number of buckets
<ejt>
y, standard stuff
<vdrab>
the buckets being the lists? sorry, i'm not a CS major...
<ejt>
vdrab: read the source, it's very simple
<ejt>
buckets = entries in the array (yes, the lists)
<vdrab>
i see.
<haakonn>
i've read a lot by reading the library source, it's a very useful part of ocaml imo
<haakonn>
s/read/learnt/
<vdrab>
i imagine
<ejt>
it all seems very simple and obvious - a sure sign of good code
<haakonn>
yeah, little magic, except the calls to external c code ;)
<vdrab>
i will need to get around to doing that then... if i find some time. (as if...)
<vdrab>
hehe
<vdrab>
ok, thanks for the input people.
jave has quit [Remote closed the connection]
Submarine has quit [Connection timed out]
Gueben has joined #ocaml
vdrab has quit ["Leaving"]
Snark has joined #ocaml
<mellum>
I asked this yesterday, but I got disconnected, so I'll try again...
<mellum>
can somebody explain this to me? module IntMap = Map.Make(struct type t = int let compare = compare end);; let s = List.fold_left (fun s x -> IntMap.add x 0 s) IntMap.empty [3; 17; 666] in IntMap.fold (fun x _ () -> print_int x) s ()
<mellum>
why does this print 666173 and not 317666? The manual says I get the keys in increasing order...
<haakonn>
< mfurr> mellum: it appears the manual does not match the implementation... perhaps you should
<haakonn>
submit a bugreport to inria
<ejt>
y, fold is this:
<ejt>
let rec fold f m accu =
<ejt>
match m with
<ejt>
Empty -> accu
<ejt>
| Node(l, v, d, r, _) ->
<ejt>
fold f l (f v d (fold f r accu))
<ejt>
so it'll visit right first, then current node, then left
<ejt>
iter works in order however
Snark has left #ocaml []
<mellum>
Oh great... well, I'll go submit a bug report then
<ejt>
I bet they change the documentation rather than the code
<haakonn>
kind of like how they don't go out and terraform if they discover errors on maps? ;)
<ejt>
well we were talking about maps
<avlondono>
mellum: the documentation says exactly what it's doing