<flux>
the first recursive problem I have ever had might have been filling a continuous region in 2d bitmap with a color. maybe implementing that will be helpful.
<flux>
or possibly constructing code that lists all the files in the filesystem.
<flux>
these cases of recursion are a bit different from what one would usually do in ocaml, I guess
<edlinde>
yeah to me it seems like most functional people know recursion pretty well
<edlinde>
and use it like loops
<edlinde>
:)
<edlinde>
I had to recently do a tree implementation in C++ where I had to recurse and explore a n-ary tree.. was a bit of a challenge
<edlinde>
I realised I needed to get more familiar with it
<edlinde>
:)
<flux>
easy peasy in ocaml. type 'a tree = Node of ('a * 'a tree list) :)
<flux>
you could write iteration/mapping/folding functions for that structure for studying purposes as well :)
<adrien>
tree operations in ml are usually really really nice
<edlinde>
ok
edlinde has quit [Quit: edlinde]
ikaros has joined #ocaml
oriba has joined #ocaml
oriba_ has joined #ocaml
<theDroggl>
Another noob question: I wonder why ">" is polymorphic (4 > 3, 4.0 > 3.0 both work) but "+" isnt (4 + 3 works but 4.0 + 3.0 does not)
<schmrkc>
theDroggl: for the > and + I'd guess it is to bring greater speed without you actually having to give the compiler hints about what it is working with. and also safety :)
<schmrkc>
theDroggl: Not sure what you mean with it doing too much type checking though.
<theDroggl>
just a sec
<theDroggl>
let max a b = if a > b then a else b in print_int (max 2 3);;
<theDroggl>
in this code they say the call to max will be polymorphic and the argument types will be figured out at runtime
<theDroggl>
although it is clear that max will only ever be used with integer arguments
<schmrkc>
ok.. how does this == ocaml doing too much type checking at compile time?
<theDroggl>
I don't know how old the information in that tutorial is though
<schmrkc>
seems to be the opposite of that.
<schmrkc>
me neither :)
<schmrkc>
it would be *better* if it had figured that out at compile time. Which is why the tutorial suggests adding some hints
<theDroggl>
oh sry yeah I meant "too much type checking at runtime"
<schmrkc>
(a : int) (b : int)
<schmrkc>
oh!
<theDroggl>
yeah but it surprises me that the compiler can't find that out without the hints
<theDroggl>
shouldnt be too hard
* schmrkc
isn't a type check specialist...
* theDroggl
neither
<schmrkc>
the other type checking compiler I use now and then also likes them hints
<schmrkc>
(steel banks common lisp)
<schmrkc>
or it uses some generic version of "stuff" :)
<theDroggl>
last change on that webpage was in 2005 btw
<schmrkc>
ya.
<schmrkc>
I really have no idea if this is still so or not.