smkl changed the topic of #ocaml to: OCaml 3.07 ! -- Archive of Caml Weekly News: http://pauillac.inria.fr/~aschmitt/cwn, A tutorial: http://merjis.com/richj/computers/ocaml/tutorial/, A free book: http://cristal.inria.fr/~remy/cours/appsem, Mailing List (best ml ever for any computer language): http://caml.inria.fr/bin/wilma/caml-list
<pattern> i am trying to write a function that takes a list like [1;2;3] and converts it to a list of lists like [[1;2;3];[2;3];[3];[]] but it's not working -> http://www.rafb.net/paste/results/z2007330.html
<pattern> on line 18, for function f i've tried "[x]@y" as it's in there, and "x@y" and "x::y" and "[x]@[y]" and "[x@y]@y" and "[x@y]@[y]" and probably a bunch of other combinations but none of them work
<Smerdyakov> And the idea is that you must do this using reduceb as your only means of recursion?
<pattern> i think so
<pattern> the problem does not specifically say this, but reduceb was just introduced, so i assume they wanted me to use it
<Smerdyakov> Well, try unfolding the recursion of the call to reduceb.
<Smerdyakov> Step through the execution in your head or on paper.
<pattern> i was just changed line 18 to read: let f = fun x y -> [x::y]@[y] in
<pattern> and line 21 to "let x = reduceb ( f ) g l i"
<Smerdyakov> I think the parentheses around f are not needed.
<pattern> and ocaml complains that reduceb wants an: 'a -> 'a list -> 'a list
<pattern> while i'm giving it an: 'a -> 'a list -> 'a list list
<Smerdyakov> Well, then give it something with the type it wants. :D
<pattern> smerdyakov i didn't use the parenthesis around f the first time around, but then i thought that function application would bind g and l to f before passing it to reduceb, and added the parenthesis
<pattern> smerdyakov, but i need a list of lists
<pattern> so maybe i should modify reduceb
<Smerdyakov> Maybe you confused the error message?
<pattern> This expression has type 'a -> 'a list -> 'a list list
<pattern> but is here used with type 'a -> 'a list -> 'a list
<Smerdyakov> The first one is the type the expression has.
<Smerdyakov> The second one is the type reduceb expects.
<pattern> the cursor is on f in line 21
<pattern> yes
<pattern> that's what i said
<Smerdyakov> OK
<Smerdyakov> So that means you should be modifying f, not reduceb.
<pattern> but i want a list of lists
<pattern> and, anyway, i can't figure out what the right modification for f should be
<pattern> i'm kind of blindly trying different combinations of [] and :: and @ operators on x and y
<Smerdyakov> I don't think any combination of those will work.
<pattern> well, not blindly
<Smerdyakov> It's better to understand what's actually going on. ;)
<pattern> but i've tried everything that kidn of made sense and none of it worked
<pattern> yeah
<Smerdyakov> I get this type for reduceb:
<Smerdyakov> val reduceb : ('a -> 'b -> 'b) -> 'b -> 'a list -> 'b
<pattern> yeah, that's what i get too
<Smerdyakov> So the 2nd arg and return of f must be the same.
<pattern> i know
<Smerdyakov> reduceb looks an awful lot like fold.
<pattern> yeah
<pattern> it's a gentle introduction to fold
<pattern> they get in to fold later
<Smerdyakov> OK
<Smerdyakov> Can you explain in words "what reduceb does"?
<pattern> yeah, it takes a function and applies it to the last part of the list along with the g
<pattern> then it takes the result of that and recursively applies f to the next (actually previous) element of the list and that result
<pattern> coming up with a final value
<pattern> which should be this damned list of lists
<Smerdyakov> OK. So what operation makes sense to use here to build up the result through considering the input list elements from right to left?
<pattern> @
<Smerdyakov> OK, and you are using [] for g.
<Smerdyakov> So what is reduceb (@) [] [1] ?
<pattern> an error, i think
<pattern> because 1@[] doesn't make sense
<Smerdyakov> OK... so I guess (@) isn't it, eh? :)
<pattern> well, it could be part of it, like i have it: [x::y]@[y]
<pattern> but that clearly doesn't work either
<Smerdyakov> Can you think of an f that works when the input list has only one element?
<pattern> damn, i have to go
<pattern> work calls
<pattern> thanks for your help, smerdyakov
<pattern> i'll bbl
<Smerdyakov> OK
gim has quit []
<pattern> ok, i'm back
<pattern> sorry abou that
<pattern> for one element, say [3] i thought f being [x::y]@[y] and g being [] would create [[3];[]], which is what i want, right?
<Smerdyakov> So f would be called like this:
<Smerdyakov> f 3 []
<Smerdyakov> Does that give the result you want?
<pattern> 3 would become x in f, and [] would become y, so [x::y]@[y] would be [3::[]]@[[]]
<pattern> [3::[]] would become [3] and [3]@[[]] would become [[3];[]], no?
<Riastradh> That very last step is wrong.
<Smerdyakov> Think of the types of the arguments you pass to (@).
<pattern> [3]@[[]] does not become [[3];[]]?
<Smerdyakov> They aren't the same, but (@) requires that they be the same.
<Smerdyakov> It isn't even well-typed, pattern.
<Smerdyakov> It has no result./
<pattern> oh yeah
<pattern> [3] is not a list of lists
<pattern> well, that's why i tried all those other combinations too... [x@y]@[y] and a bunch of others :(
<Riastradh> pattern, what standard list operation can have the type [['a list -> 'a list list -> 'a list list]]?
<cleverdra> pattern - do you actually want to turn such as [1;2;3;4] into such as [[1];[2];[3];[4];[]] ?
<pattern> cleverdra, no
<Smerdyakov> cleverdra, no. We are taking this a step at a time, to see if he can get it to work one one-element lists first. :)
<cleverdra> pattern - then what do you want to do?
<pattern> cleverdra, i want to turn [1;2;3] in to [ [ 1;2;3 ] ; [ 2;3 ] ; [ 3 ] ; [] ]
<cleverdra> pattern - oh, OK.
<pattern> using reduceb as in here http://www.rafb.net/paste/results/z2007330.html
<pattern> riastradh, :: can take a head element and combine it with a tail which is a list, which can be the @ of two lists of lists... is that what you're getting at?
<cleverdra> pattern - so have you solved your problem already?
<pattern> riastradh, @ and :: are the only standard list operations i know (apart from the folds and maps)
<pattern> cleverdra, no
<pattern> it's broken
<Riastradh> pattern, what is the type of an operation that turns the inputs [3::[]] and [[]] into [[3];[]]?
<Riastradh> Er, sorry, 3::[] and [[]].
<pattern> @
<pattern> i think
<Riastradh> No, wait a moment, you've gone and confused me.
<pattern> hehe
<pattern> at least i'm not the only one :)
<cleverdra> pattern - Riastradh asked you about the type of the operation that would turn the arguments 3::[] and [[]] into [[3];[]]
<Riastradh> How do you get that [3::[]] would evaluate to [3]?
<cleverdra> allowing for the confused question =) '@' doesn't define a type.
<pattern> ok, one thing at a time
<Smerdyakov> Riastradh, I think he answered your first question, not the second.
<pattern> 3::[] and [[]] can be turned in to [[3];[]] by using ::
<Riastradh> pattern, no, how does [3::[]] manage to evaluate to [3]?
<pattern> because 3::[] turn in to [3], which can be the head element of the :: operator, which will then take [3]::[[]] and make [[3];[]]
<Riastradh> No, you frobbled something up somewhere in there. What does [3::[]] evaluate to?
<cjohnson> [[3]] ?
<pattern> [3::[]] turns in to [[3]]
<pattern> but that's not what the original question was
<Riastradh> I know.
<pattern> the original quesiton was 3::[]
<cleverdra> Sure. A function that performed :: would have type ('a -> 'a list -> 'a list) -- in [3]::[[]] you have (int list) for 'a
<Riastradh> But you said that f 3 [] is [x::y]@[y], which is [3::[]]@[[]]...
<cleverdra> pattern - so have you finished your function yet?
<Riastradh> And then you jumped to [3::[]] evaluating to [3].
<pattern> cleverdra, no.. that's what we're working on now
blueshoe has joined #ocaml
<cleverdra> pattern - what part of it remains a problem for you?
<Smerdyakov> cleverdra, I think Riastradh is already working with him on that.
<pattern> riastradh, i was confused
<Riastradh> It's contagious, isn't it?
<pattern> it's hard
<Smerdyakov> No, it really isn't.
<pattern> :P
<Smerdyakov> Can you describe in English a function that would do what you want?
<pattern> i want a function that takes an element as argument x and a list of lists as argument y and makes a new list of lists containing both x and y as a list and y
<pattern> i think
<pattern> no, wait
<pattern> x and y can't be made in to a list if x is an element an y a list of lists
<pattern> i'm confused
<cleverdra> pattern - remember what I said about :: and ('a -> 'a list -> 'a list)
<pattern> yeah
<Smerdyakov> pattern, this really shouldn't be complicated. Think of representative example inputs.
<pattern> x is 3 and y is [[]]
<pattern> and i want [[3];[]]
<pattern> so i want [x]::y
<pattern> or do i?
<cleverdra> pattern - use the O'Caml toplevel.
<cleverdra> pattern - it also displays types. Very handy.
<pattern> wait, [x]::y compiled
<cleverdra> let lookatme x y = [x]::y;;
<Smerdyakov> pattern, that's not a very representative sample input. Try one where y has more elements.
<pattern> ok
<pattern> x is 2 and y is [[3];[]]
<pattern> and i want [[2;3];[3];[]]
<cleverdra> No you don't.
<pattern> i don't?
<Riastradh> Yes he does.
<cleverdra> No, he doesn't.
<pattern> [1;2;3] should become [ [ 1;2;3 ] ; [ 2;3 ] ; [ 3 ] ; [] ]
<cleverdra> pattern - when do you ever start with with 2 and [[3];[]]
<cleverdra> ?
<pattern> cleverdra, when i've already processed 3 and [[]]
<cleverdra> pattern - when do you process just 3 and [[]] when you've this 2 elsewhere?
<Riastradh> cleverdra, at the second iteration...
<Smerdyakov> cleverdra, he really is correct here.
<pattern> 3 and [[]] are the first two values of x and y
* cleverdra sighs.
<pattern> 2 and [[3];[]] are the second two values of x and y, on the 2nd recursive call, as riastradh says
<pattern> i think
<Smerdyakov> pattern, so what function would work correctly on the 2nd recursive call?
<pattern> i don't know how to make [[2;3];[3];[]] out of 2 and [[3];[]]
<pattern> at least not simply
<Riastradh> pattern, use <your nick> matching!
<pattern> i'd have to pattern match on y
<Riastradh> Yes, exactly.
<Smerdyakov> That's OK, unless your assignment says you should only write "simple" functions. :)
<pattern> no, i could write more complex ones
<pattern> i thought it would be a simple one, though
<pattern> but i guess there's no reason not to use pattern matching
<pattern> well, that gives me more hope
<pattern> this'll take a little while, though
<Smerdyakov> Hm. It shouldn't take very long....
<Riastradh> pattern, 2 & [[3]; []] -> [[2; 3]; [3]; []] How hard can that be?
<pattern> ok, stop asking me and let me think
<pattern> :P
<Riastradh> Faster!!
<pattern> yessh, master!
<pattern> let ll x l = match l with
<pattern> [] -> [[]]
<pattern> | y::ys -> [x::y]@ys
<pattern> how does that look?
<Smerdyakov> Well, does it work?
<pattern> haven't tried yet
<Smerdyakov> Well, you should try it before asking. :)
<pattern> well, it compiled
<pattern> i did try compiling
<Smerdyakov> And running?
<cleverdra> pattern - paste it into the bloody toplevel.
<pattern> val ll : 'a -> 'a list list -> 'a list list = <fun>
<pattern> but that doesn't tell me if it'll work with my problem
<pattern> in fact, it doesn't appear to
<Riastradh> pattern, _try_it_.
<pattern> but that could be a problem elsewhere
<pattern> i did just try it
<pattern> and it didn't work, somewhere...
<Smerdyakov> Can you put the new code on that paste site?
<pattern> way ahead of you
<cleverdra> pattern - you know that you can pass arguments to individual functions in the toplevel, right?
<pattern> i could have probably eliminated the supurflous f and just used ll
<pattern> cleverdra, yeah
<Smerdyakov> Your printing functions are highly suspicious.
<pattern> that's where i thought the problem would lie
<Smerdyakov> Why not just use the toplevel's pretty-printing?
<pattern> haven't investigated it yet
<Riastradh> You, uh, know what the toplevel is, right?
<pattern> i would but all my stuff is wrapped up in main
<cleverdra> pattern - you may want to actually play around with that ll function in the toplevel before you start relying on it elsewhere in your program.
<Smerdyakov> pattern, how do you test main?
<pattern> cleverdra, advice well taken
<pattern> smerdyakov, i can't, except by printing
<cleverdra> pattern - sigh. Hint: your function does not work.
<Smerdyakov> pattern, how do you test it by printing?
<Smerdyakov> pattern, what do you run/type/etc. to test it?
<pattern> cleverdra, i could have figured that out if only i'd try what you'd said instaed of talking here :)
<pattern> smerdyakov, i could just type main
<pattern> in fact there's more to the program that actually runs main, but that's irrelevant
<Smerdyakov> pattern, so just type main.
<pattern> # let ll x l = match l with
<pattern> [] -> [[]]
<pattern> | y::ys -> [x::y]@ys
<pattern> ;;
<pattern> val ll : 'a -> 'a list list -> 'a list list = <fun>
<pattern> # ll 2 [[3];[]];;
<pattern> - : int list list = [[2; 3]; []]
<pattern> #
<pattern> so cleverdra's perfectly right, my ll function is broken
<pattern> and ll is such a stupid name... i have yet to figure out how to name these little ocaml functions more descriptively without using a whole paragraph
<Smerdyakov> You don't need to name them.
<Smerdyakov> You can just use them directly as parameters.
<pattern> smerdyakov, i do if i want a seperate function
<Smerdyakov> No, you don't.
<pattern> smerdyakov, that way lies madness
<Smerdyakov> Anonymous functions are still functions.
<pattern> anonymous functions should be very simple, imo
<pattern> something this big as an anonymous function is write-only code
<Riastradh> This 'big?'
<pattern> because it's not clear what it's for except by decyphring the function itself
<pattern> that's what names are for
<cleverdra> pattern - please hold back on such assertions for a while.
<pattern> so you know what's going on without parsing the code
<pattern> anyway, that's a stylistic issue
<pattern> not really relevant to the problem
<Smerdyakov> It's not a stylistic issue that experienced OCaml programmers agree with.
<Smerdyakov> I think any such person would introduce no new names but the name for the function you are writing.
<Smerdyakov> All done in a single line.
<pattern> well, i have found lots of programs that experienced ocaml wrote to be indecyphrable... perhaps the convention of using one and two letter names for functions has somethign to do with that.. or maybe i'll see the light once i become more experienced with ocaml
<cleverdra> pattern - yes, please wait until you grow in experience.
<pattern> s/experienced ocaml/experienced ocaml programmers
<Smerdyakov> Hopefully the latter, because your example is really trivial and not deserving of lots of definitions.
<pattern> ok, i'll take that on faith
<Smerdyakov> So I hope you've figured out how to write ll by now, in any case. ;)
<pattern> i probably would have if i didn't get caught up in this flamewar ;)
<Smerdyakov> Hardly a "flamewar".
<pattern> -> ;) <-
<cleverdra> I hate the way newbies like to make everything an argument, though.
<cleverdra> (Where by 'make an argument' I don't mean 'start an argument', I mean 'call something an argument'.)
<Smerdyakov> And "argument" the kind of conversation, not the function parameter?
<pattern> # let ll x l = match l with
<pattern> [] -> [[]]
<pattern> | y::ys -> ([x::y]@[y])@ys
<pattern> ;;
<pattern> val ll : 'a -> 'a list list -> 'a list list = <fun>
<pattern> # ll 2 [[3];[]];;
<pattern> - : int list list = [[2; 3]; [3]; []]
<Smerdyakov> Because both interpretations make a lot of sense in the context of functional languages.
buggs|afk is now known as buggs
<pattern> # ll 1 [[2; 3]; [3]; []];;
<pattern> - : int list list = [[1; 2; 3]; [2; 3]; [3]; []]
<Smerdyakov> pattern, OK. Does it all work now?
<pattern> i think my printing function is still broken
<pattern> 'cause it prints 1
<Smerdyakov> Obviously. It's not recursive. How could it print a whole list
<pattern> yeah,i just made it recursive
<pattern> but it's sitll broken
<pattern> so i'm working on it
<Smerdyakov> Do you need to write printing functions for this assignment?
<cleverdra> pattern - (_@[y])@ys, _@([y]@ys), _@(y::ys), _@l
<pattern> ok, now it works
<Smerdyakov> IO is usually ignored in functional programming courses, since interactive environments can do it for you easily.
<pattern> no, i don't need to write a printing funciton
<pattern> that's just for myself
<pattern> and these assignments are just for myself anyway
<Riastradh> pattern, why don't you just use the toplevel?
<Smerdyakov> OK. Now it would be good if you tried to shrink the size of ll.
<cleverdra> pattern - do you understand what I just said?
<pattern> cleverdra, what is that?
<cleverdra> pattern - (_@[y])@ys, _@([y]@ys), _@(y::ys), _@l
<pattern> what does it mean?
<pattern> what are _@
<pattern> ?
<pattern> smerdyakov, i like IO
<pattern> it's practical
<cleverdra> pattern - all of those expressions mean the same thing. _ means what it means in pattern matching (not real O'Caml, here).
<cleverdra> evaluate to the same list, anyway.
<pattern> i don't understand
<cleverdra> pattern - please consider them in the light of your ([x::y]@[y])@ys
<pattern> _@ seems to mean whatever comes in the expression before it
<cleverdra> OK.
<pattern> some kind of wildcard
<Smerdyakov> _ stands for any list in what cleverdra wrote.
<Smerdyakov> It would be better to use L instead of _, or some other dummy variable.
<cleverdra> pattern - ([x::y]@[y])@ys, [x::y]@([y]@ys), [x::y]@(y::ys), [x::y]@l
<pattern> ah
<cleverdra> pattern - do you have much of a mathematical background?
<Smerdyakov> I guess it has to be l in OCaml, where uppercase means module or constructor. :)
<pattern> cleverdra, no
<Riastradh> It might also be worth noting that [a]@b is the same as a::b.
<pattern> yes
<pattern> that makes sense, riastradh
<cleverdra> pattern - do you understand what I said, now?
<pattern> cleverdra, you're saying all those expressions are equivalent
<Riastradh> pattern, with those equivalences in mind, you can simplify ll greatly.
<pattern> i like parenthesis
<pattern> they let me not worry about remembering ocaml's binding rules :)
<cleverdra> pattern - eh, indeed. Hint: you initially erred in that your function threw 'y' away when it pattern-matched l on (y::ys), resulting in a list that contained a mutation of y and ys. You fixed this by re-inserting y in the appropriate place. I just point out that you already have y in the 'appropriate place': in l.
<cleverdra> pattern - this has nothing to do with parentheses.
<pattern> yeah, i see the other reductions too
<pattern> i'm just trying to figure them all out and how they apply
<cleverdra> Sounds like a plan.
<pattern> thanks, btw
<pattern> even though i know that you all, as advanced ocaml programmers, must write stylistically indecyphrable code ;)
<cleverdra> your ([x::y]@[y])@ys takes much more effort to decypher than my [x::y]@l -- particularly as people will try to understand why you did it that way.
<pattern> what i really need to do is get more familiar with :: and @ and when i'd use them
<pattern> :: and @ are so simple, yet, obviously, combining them intelligently is hard
<pattern> cleverdra, yes, that's true
<pattern> i see that now
<Riastradh> @ appends two lists. :: creates a pair.
<pattern> yeah, i know!
<pattern> wait, :: creates a list
<pattern> not a pair
<pattern> a pair is tuple
<pattern> or a type of tuple
<pattern> well, i guess a list could also contain just a pair of elements
<pattern> but it could be longer than a pair
<Riastradh> A list is either nil or a pair whose second component is a list.
<pattern> ah
<pattern> ok, that's true
<Riastradh> [] is pronounced 'nil' and :: is pronounced 'cons.'
<pattern> yeah, i've heard those terms
<cleverdra> pattern - Riastradh's assertion makes more sense in the context of Lisp, where CONS can produce improper lists. It also makes more sense when you think more about pattern matching and about the structure of a linked lists.
<cleverdra> also, 'linked list'.
<pattern> right
<pattern> :: just links the rest of the list to the first element
<pattern> whereas @ has to traverse the first list to the end and then link the 2nd list
<pattern> thus @ is much less efficient than ::
<cleverdra> more appropriately, :: produces a pair which includes the first element and a pointer to the second.
<pattern> or a linked list
<pattern> or just list, in ocaml
yangsx has joined #ocaml
stepcut has quit ["whee!"]
yangsx has quit ["离开"]
Nutssh has joined #ocaml
buggs is now known as buggs^z
<blueshoe> programming languages sorted by number of links on google's directory pages: http://nopaste.snit.ch:8001/521
<blueshoe> with ocaml evidentally being less popular than either brainfuck or intercal
<blueshoe> don't know how frequently google updates its directory pages, or how representative the sampling is
<blueshoe> interesting that erlang comes right after c, though... and that ruby is less popular than rexx
wazze has joined #ocaml
blueshoe has quit [Read error: 104 (Connection reset by peer)]
tomasso has quit ["Leaving"]
Nutssh has left #ocaml []
blueshoe has joined #ocaml
blueshoe has quit [Read error: 104 (Connection reset by peer)]
blueshoe has joined #ocaml
blueshoe has quit [Read error: 104 (Connection reset by peer)]
Maddas has joined #ocaml
<Maddas> Morning
<Maddas> Can any of you recommend any GUI toolkit with O'Caml?
<teratorn> gtk probably.
<Maddas> Hm, I'll give it a look.
reltuk has joined #ocaml
Kinners has joined #ocaml
Swynndla has joined #ocaml
<pattern> from one of the mars rover team:
<pattern> <JPL-Justin> I've used OCaml
<pattern> <pattern> what did you think, jpl-justin?
<pattern> <JPL-Justin> pattern: Uh... I can't endorse it but
<pattern> <pattern> why not?
<pattern> <JPL-Justin> I can state that it's a very safe language that's very fast, very efficient, with sytnax that is readable
<pattern> <JPL-Justin> and plenty of features
<pattern> <pattern> :)
<pattern> <JPL-Justin> I cna't endorse anything in this darn channel
<pattern> <pattern> ahh
<pattern> <JPL-Justin> read between the lines dude
<pattern> <pattern> !!!
<Swynndla> he likes it but he can't officially say it because he's not allowed?
<pattern> yeah
<Swynndla> why isn't he allowed?
<pattern> none of the jpl team can endorse stuff on the channel
<pattern> they're often not even allowed to comment
<pattern> nasa rules, i think
<Swynndla> oic yea
<pattern> unfortunately, though, i think most of the critical software on the rover is written in c
<Swynndla> that may change in the future
<Kinners> the rover runs vxworks right?
<pattern> yeah
<Maddas> Heh
<pattern> i guess languages with automatic garbage collection aren't real popular with the real-time systems crowd
reltuk has quit ["leaving"]
<Kinners> maybe they'll end up using java :)
<pattern> they do
<pattern> that's what maestro is written in
<Kinners> for realtime stuff
<pattern> but not for the fault-tolerant stuff
<pattern> heh, yeah
Kinners has quit [Remote closed the connection]
Kinners has joined #ocaml
Kinners has left #ocaml []
<Swynndla> what is garbage collection? ... is that when the program recovers memory after it finishes with some variables?
Kinners has joined #ocaml
<pattern> yes
<Kinners> pattern: about the applylist problem yesterday, module type signatures would have complained
<pattern> hmm... applylist... i remember working on it, but i don't remember what the exact problem was :)
<pattern> oh, right
<pattern> i haven't learned much about modules and their type signatures yet
<pattern> i know what they are and what they generally look like and what they're used for
<pattern> but i don't understand how they'd have helped
gim has joined #ocaml
Kinners has left #ocaml []
systems has joined #ocaml
systems has quit ["Client Exiting"]
Kinners has joined #ocaml
cleverdra has quit ["qnx"]
<pattern> kinners how would the module type signatures have helped?
<pattern> why would they have complained while my type annotations within the program didn't?
<Kinners> the type annotations are weaker for some reason which escapes me
<pattern> by "weaker" you mean that they can let some sorts of type errors through without complaining?
<Kinners> seems to be
<pattern> maybe it's a bug
<Banana> hello.
<Banana> sorry to intrude, are u talking about constraining type with type anotation versus module signature ?
<Kinners> hello Banana
<Kinners> yes
<Banana> the advantage of type signature is that it allows you to hide the structure of the type.
<Banana> (imho).
<Kinners> pattern: I think there is an explanation of it buried in the mailing list...
<pattern> bannana, we actually weren't debating their relative merits, but trying to understand why a type annotation would let through certain types of type errors
<Banana> hum ok.
<pattern> kinners, i'm searching it now...
<pattern> well, there's this... but i'm not sure if it applies - http://pauillac.inria.fr/caml/caml-list/0705.html
<pattern> that's about all i can find
<Banana> hum, maybe with this exemple (and let say a more complex function) the programmer expect to have type 'a -> int and thus type error is reported when he uses the function, ont when he declares it. With signatures the compiler would complain about incompatible definitions.
<Banana> that's all i can see.
<pattern> i don't think that in our case we had something more general, though
<pattern> i think we had something completely wrong
<pattern> let me see if i can regenerate the error (unless Kinners has it handy)
<Banana> yes if you anotate with an incompatible type, the type checker would complain immediately.
<pattern> but it doesn't
<pattern> or didn't
<Banana> would be akward if not :
<Banana> ?
<Banana> realy
<pattern> yeah
* Banana wakes up
<pattern> that's why i think it's a bug
<Banana> O_O
<Banana> that would be huge.
<pattern> too bad i didn't save it in the weird state
<pattern> i have a later, corrected version of the program
<pattern> now trying to get back to the weird state...
<Banana> backtack ala prolog hu hu.
<Banana> track*
<pattern> hmm.. no, i really don't remember how it was
<pattern> too many things changed
<pattern> i remember the gist of it, but not the specifics
<pattern> kinners is my witness :)
<Kinners> let foo (l:'a list) = match l with [[]] -> [] | x->x;;
<Kinners> val foo : 'a list list -> 'a list list = <fun>
<Banana> yeah.
<pattern> looks like a bug to me
<pattern> although maybe they consider 'a list a more general version of 'a list list
<Banana> of course they do.
<pattern> they do?
<Banana> you should rename type variable.
<pattern> what do you mean?
<Banana> 'a list ~~ 'b list list
<Banana> where~~ means you can unify to
<pattern> unify?
<Banana> this what they do to infere type automaticaly.
<pattern> oh
<Banana> you ha ve basic types : int, bool ....
<Banana> and types with variables : 'a list, 'a ref , 'a t...
<pattern> right
<Banana> when they infere type, they make equations : like int list = 'a t and t = 'b list
<Banana> and they try to solve them
<Banana> 'b t = 'b list **
<Banana> and they give the most generic solution.
<pattern> why not just say int list = 'a list?
<Banana> it was an exemple.
<pattern> ok
<Banana> but it is what they will solve.
<pattern> so they infer that 'a list is a more general version of 'a list list
<Banana> be cautious.
<pattern> is that because 'a list can contain other lists?
<Banana> you can't write 'a list = 'a list list.
<Banana> because in a way it would be circular.
<Banana> caus it reduse to 'a = 'a list.
<pattern> 'a list list is a type of 'a list
<Banana> let say 'b list list is a type of 'a list.
<pattern> ok
<Banana> the two 'a have nothing in common.
<pattern> true
<Banana> so a list can contain other lists there is nothing wrong with that.
<Banana> and the second list can contain another list
<Banana> but you have to stop that somewhere.
<pattern> ok, well, i'm still not sure that was the type annotation behavior we were experiencing the other day
<pattern> let me look in my logs...
<pattern> ok, this was it:
<pattern> # let rec applylist (l:('a -> 'a) list * 'a list ) = match l with
<pattern> [], [] -> []
<pattern> | _::xs,[] -> []::applylist (xs,[])
<pattern> | [], y::ys -> y::applylist ([],ys)
<pattern> | x::xs,y::ys -> (x y)::applylist (xs,ys)
<pattern> ;;
<pattern> val applylist : ('a list -> 'a list) list * 'a list list -> 'a list list =
<pattern> <fun>
<pattern> so looks like it was very similar to what kinners said
<pattern> i guess 'a is just a more general version of 'a list
<pattern> makes sense now
<pattern> thanks, banana and kinners
<Banana> you can to infer type 'by hand' and it won't be surprising.
<pattern> so why did ocaml generalize here but not with module type signatures?
<pattern> kinners said it would complain there
<Banana> of course.
<Banana> 'a list list is not a generalisation
<Banana> it is a specialisation
<pattern> yes, that's what i meant
<Banana> ha ok.
<Banana> sorry.
<Banana> with a signatures, you force the compiler to take your declaration.
<Banana> this way you can make a function less specialized.
<pattern> so if your function is more specialized than it's type signature it will complain
<pattern> but not with type annotations
<Banana> yes.
<Banana> type annotation are ways to give hint to the typecheker, bbut it will unify the type variables
<Banana> when you anotate with 'a list the type checker will infer for what 'a your type is valid.
<pattern> but why not the same with type signatures?
<Banana> and it turns that to be well typed 'a has to be of the form 'b list.
* Banana thinks.
* Banana knows it deep inside is head.
<Banana> >_<
<Banana> ok I have it.
<Banana> take your signature.
<smkl> hey, does somebody have time to test if my program compiles?
<Banana> you would write something like : val applylist : ('a -> 'a) list * 'a list
<Banana> smkl: i have lunch in 30 minutes so I guess I have time ;)
<Banana> pattern: that is what you would have in your .mli file ok ?
<pattern> yeah, i'm with you
<Banana> imagine someone only has your .mli and a .cmo
<Banana> he would use your module without knowing your implementation.
<Banana> only the signature.
<pattern> i see
<smkl> Banana: perhaps that's enough .. but you'd first have to install ocamlsdl
<Banana> arf
<Banana> apt-get install libsdl-ocaml-dev
<Banana> oups
<Banana> sorry.
<Banana> smkl: done. ready when you are.
<Banana> pattern: to allow that, the compiler should modify* your .mli and write the appropriate type there... that ist of course not acceptable.
<pattern> yeah, it all makes sense now
<pattern> thank you, banana
<Banana> nothing.
<Banana> hu hu. many should have type unit warnings.
<Banana> arf
<Banana> needs sdlimage to.
<Banana> so close T_T
<Banana> pattern: did you find your solution about th list prefix problem ?
<pattern> yes
<pattern> now i'm on another problem
<pattern> how to find whether a string is a substring of another
<pattern> "bc" would be a substring of "abcd"
<Banana> do you use a List.map in f or not ?
<pattern> shhh!
<pattern> no hints, yet
<pattern> or were you asking about my earlier problem?
<Banana> yes.
<pattern> no, i didn't use a map function
<pattern> i used reduceb, which is a fold-like function
<Banana> oki.
<Banana> that was the more ellegant solution.
<pattern> i'll put my solution up on a code pasting site, if you'd like to see it
<pattern> and it's not really my solution... had lots of help from people on this channel
<pattern> couldn't have done it without them
<Banana> it reminds me of lambda calculus and recursors... reduceb seems to be a recursor.
<Banana> smkl: pb at linking phase.
<pattern> it's like foldr
<pattern> but with an initial element
<Banana> yep.
<pattern> it's really going to take me a while to get comfortable with all of these list manipulating functions
<smkl> Banana: what kind of?
<Banana> /usr/lib/ocaml/3.07/sdl/libsdlttfstub.a(sdlttf_stub.o)(.text+0x171): dans la fonction « sdlttf_open_font »:
<Banana> : undefined reference to `TTF_OpenFontIndex'
<Banana> (erf error messag in french, sorry).
<Banana> there are other
<smkl> Banana: are all of them for ttf?
<Banana> yes
<Banana> i have libsdl-ttf though
<smkl> the ocamlsdlttf is broken then
<Banana> i don't have the cvs version of ocamlsdl. but the last stable release.
<Banana> ok time to eat.
Banana is now known as Banana[AFK]
<smkl> try adding -cclib -lSDL_ttf
ita has joined #ocaml
<ita> hi all
Swynndla has quit ["Leaving"]
Hipo has quit ["leaving"]
<pattern> why does this give me a syntax error?
<pattern> # let makefnlist (f:'D->( ('T1->'T2) as 'R) ) l =
<pattern> let rec (fl:'D list -> 'R list) m = match m with
<pattern> [] -> []
<pattern> | x::xs -> (f x)::(fl xs)
<pattern> in
<pattern> fl l;;
<pattern> Failure: this is not a constructor, it cannot be applied in a pattern
<pattern> with the m underlined
<pattern> while this works:
<pattern> let makefnlist (f:'D->( ('T1->'T2) as 'R) ) l =
<pattern> let rec (fl:'D list -> 'R list) = function
<pattern> [] -> []
<pattern> | x::xs -> (f x)::(fl xs)
<pattern> in
<pattern> fl l
<pattern> i'm sorry, it wasn't the m underlined
<pattern> the cursor was before (fl:'D list...etc
<pattern> two different errors from camlp4o vs ocaml
<pattern> but the m is definitely involved
<pattern> the two versions are identical, except in one i use "m = match m with" and in the second i use "= function"
<smkl> you cannot add type annotation to a function name definition
<Banana[AFK]> smkl: it's the same.
<pattern> it works when i have the function name definition annotated
<Banana[AFK]> (i meant with -cclib -lSDL_ttf)
<pattern> it just doesn't work when i specify an argument after the annotation
<pattern> but when that argument is implicit with "= function" it does work
<Banana[AFK]> pattern: when you give explicit arguments, you have to anotate the type separately :
<Banana[AFK]> let (f :int ->int) = function x -> x+1
<pattern> ah
<Banana[AFK]> let f (x:int) : int = x +1 ;;
<Banana[AFK]> see you.
* Banana[AFK] &
<pattern> thanks banana
<pattern> but how can i then annotate the return value of that function?
<Kinners> pattern: try let rec fl
<Kinners> pattern: try let rec fl (m: 'D list) : ('R list) = match ...
<pattern> the part after the : specifies the return type?
<Kinners> apparently :)
<pattern> i just like having things be explicit :)
<pattern> thanks, btw
Kinners has left #ocaml []
Tachyon76 has joined #ocaml
ita has quit [Remote closed the connection]
buggs^z is now known as buggs
Tachyon76 has quit ["Leaving"]
_ott has joined #ocaml
_ott has quit [Client Quit]
ott has joined #ocaml
ott has quit []
ott has joined #ocaml
ott has quit [Client Quit]
cjohnson has quit ["Drawn beyond the lines of reason"]
Nutssh has joined #ocaml
Nutssh has quit ["Client exiting"]
mattam_ is now known as mattam
rox has quit ["Client exiting"]
rox has joined #ocaml
Nutssh has joined #ocaml
Nutssh has quit ["Client exiting"]
cjohnson has joined #ocaml
Banana[AFK] is now known as Banana
cmeme has quit [Read error: 104 (Connection reset by peer)]
cmeme has joined #ocaml
Swynndla has joined #ocaml
Nutssh has joined #ocaml
cleverdra has joined #ocaml
housetier has joined #ocaml
mattam_ has joined #ocaml
teratorn has quit ["Terminated with extreme prejudice - dircproxy 1.0.5"]
teratorn has joined #ocaml
mattam has quit [Read error: 110 (Connection timed out)]
derfy has joined #ocaml
rox has quit [saberhagen.freenode.net irc.freenode.net]
gim has quit [saberhagen.freenode.net irc.freenode.net]
smkl has quit [saberhagen.freenode.net irc.freenode.net]
gim has joined #ocaml
smkl has joined #ocaml
rox has joined #ocaml
Nutssh has left #ocaml []
cmeme has quit [saberhagen.freenode.net irc.freenode.net]
buggs has quit [saberhagen.freenode.net irc.freenode.net]
Demitar has quit [saberhagen.freenode.net irc.freenode.net]
det has quit [saberhagen.freenode.net irc.freenode.net]
pattern has quit [saberhagen.freenode.net irc.freenode.net]
rox has quit [saberhagen.freenode.net irc.freenode.net]
smkl has quit [saberhagen.freenode.net irc.freenode.net]
gim has quit [saberhagen.freenode.net irc.freenode.net]
teratorn has quit [saberhagen.freenode.net irc.freenode.net]
housetier has quit [saberhagen.freenode.net irc.freenode.net]
cleverdra has quit [saberhagen.freenode.net irc.freenode.net]
Smerdyakov has quit [saberhagen.freenode.net irc.freenode.net]
Etaoin has quit [saberhagen.freenode.net irc.freenode.net]
srv has quit [saberhagen.freenode.net irc.freenode.net]
mw has quit [saberhagen.freenode.net irc.freenode.net]
derfy has quit [saberhagen.freenode.net irc.freenode.net]
mattam_ has quit [saberhagen.freenode.net irc.freenode.net]
yella has quit [saberhagen.freenode.net irc.freenode.net]
Nomme has quit [saberhagen.freenode.net irc.freenode.net]
The-Fixer has quit [saberhagen.freenode.net irc.freenode.net]
mellum has quit [saberhagen.freenode.net irc.freenode.net]
async has quit [saberhagen.freenode.net irc.freenode.net]
ejt has quit [saberhagen.freenode.net irc.freenode.net]
themus has quit [saberhagen.freenode.net irc.freenode.net]
gim|570 has quit [saberhagen.freenode.net irc.freenode.net]