<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 ] ; [] ]
<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?
<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.
<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.
<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, 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