<Swynndla>
karryall, the function has to take any sized list and reverse it
<det>
Swynndla: is this for a class ?
<Swynndla>
det no
<Swynndla>
det hobby
<Swynndla>
blueshoe, was teaching me by getting me to do challenges ... but I just got stuck on that one ... but he is making me have a good think about it which is good :)
<karryall>
you could try other list functions, like iter, map, length, etc
<blueshoe>
oh, come on
<blueshoe>
those are not beginning topics
<blueshoe>
that's an advanced topic, when you already know how to implement those functions
<Swynndla>
I have read about a simple map function ... it was pretty cool
<blueshoe>
it is cool, but using it in this example is overkill, and you won't learn what you're supposed to
<blueshoe>
imo
<karryall>
what's an advanced topic ? rewriting List.length ?
<Swynndla>
BTW people ... blueshoe is trying to get me to practice recursion ... since I'm not used to it ... so I'm learning to do it with recursion and not fold etc
<blueshoe>
using almost any prewritten function should be left until after you know the basics
<blueshoe>
except for maybe i/o functions
<karryall>
that's why I suggest he should try rewriting simpler list functions if he's stuck on reverse
<blueshoe>
yes, he can implement the length of a list
<blueshoe>
that's a good idea
<Swynndla>
ok ... I'll give it a go now
<Swynndla>
I've done it ....
<Swynndla>
# let rec mylistlen = function
<Swynndla>
[] -> 0
<Swynndla>
| x::xs -> 1 + mylistlen xs;;
<karryall>
great !
<Swynndla>
:)
<blueshoe>
my hero!
<Swynndla>
:))
<Swynndla>
thx teacher :)
<blueshoe>
:)
<blueshoe>
and you've already printed the list forwards
buggs^z has joined #ocaml
<Swynndla>
ok ... now for the reverse .....
<blueshoe>
i think reversing the list using the @ operator should not be hard, now that you know what it does
<det>
Swynndla: now write mylisten tail-recursively! mauahaha!
<karryall>
:)
<blueshoe>
it is tail recursive, isn't it?
<karryall>
no
<blueshoe>
the recursive call is the last thing that happens and there're no other recursive calls inside the function... isn't that definition of tail recursive?
<blueshoe>
recursion
whiskas has joined #ocaml
<det>
blueshoe: the last thing that happens is addition
<det>
blueshoe: infix operators are confusing in that respect
<blueshoe>
ahh yes, now i'm starting to remember
<whiskas>
Hello.
<det>
tail recursively, you would need a accumulator argument
<det>
whiskas: hi
<whiskas>
Roger on that accumulator thing :-)
<blueshoe>
well, i'll take that as _my_ exercise :)
<whiskas>
blueshoe: Mate, I know that stuff, and I don't need it as an exercise thing :)
<det>
tail-recursively is actually simpler to visualize IMO, its just like C with a goto :)
<blueshoe>
no more hints, now!
<whiskas>
But sometimes is not that easy to implement.
<det>
more hints!
<det>
fill in the ...
<det>
let rec length list accum =
<det>
match list with
<det>
[] -> accum
<det>
| x::xs -> ...
<det>
ugh, extra spaces
<blueshoe>
hey!
<blueshoe>
/cls :P
<det>
oh and that wouldnt be the same as length
<Swynndla>
got it ....
<Swynndla>
# let rec mylistrev = function
<Swynndla>
[] -> []
<Swynndla>
| x::xs -> mylistrev xs @ [x];;
<det>
pretend that was called length' then the real length would be defined as "let length l = length' l 0"
<blueshoe>
i am clearing the screen of all your hints
<whiskas>
Neat, I haven't use ' for identifiers so far. =)
<blueshoe>
so your are wasting your breath :P
<Swynndla>
but teacher ... did you see that I got it?
<blueshoe>
yeah
<blueshoe>
good job!
<blueshoe>
:)
<Swynndla>
:))
<blueshoe>
i was wondering if you'd figure out the [x]
<blueshoe>
and you did!
* Swynndla
sticks his chest out
<blueshoe>
yay!
<Swynndla>
hehe ... took me a while
<blueshoe>
your first tough recursion problem
<Swynndla>
but @ is like 'a list @ 'a list ... and not 'a like :: does
<blueshoe>
well, it takes two operands, each of type 'a list
<blueshoe>
and makes a single 'a list out of them
<karryall>
Swynndla: no, evaluate the complexity of your reversion function
<blueshoe>
it joins two lists together
<karryall>
s/no/now/
buggs has quit [Read error: 110 (Connection timed out)]
<blueshoe>
karryall, yes, it's not efficient
<blueshoe>
but that's another advanced topic
<whiskas>
:-))
<whiskas>
blueshoe: So you are the mentor around here? :-P
<ejt>
window 11
<Swynndla>
for me he is :P
<blueshoe>
whiskas, just stating my oppinion
<Swynndla>
blueshoe, is being veeeeeeeeeerry patient with me
<blueshoe>
try your function on a list of tuples
<Swynndla>
ok ...
<blueshoe>
and on a list of lists
<blueshoe>
just for fun
<whiskas>
blueshoe: What is he supposed to do?
<blueshoe>
it's not a problem, but you'll see what values lists can contain
<blueshoe>
and then try to make a list of every other element in the list
<Swynndla>
whiskas, I had to write a recursive function that reverses a list
<whiskas>
Swynndla: Me too...
<blueshoe>
det, how's this look for a tail recursive list length function?
<blueshoe>
let len l =
<blueshoe>
let rec len1 i = function
<blueshoe>
[] -> i
<blueshoe>
| x::xs -> len1 ( i + 1 ) xs
<blueshoe>
in
<blueshoe>
len1 0 l
<whiskas>
I was a self imposed exercise.
<ayrnieu>
bluesheo - rename 'i' to 'acc'
<whiskas>
s/I/it
<blueshoe>
ayrnieu, yes, but functionally it is tail recursive, is it not?
<karryall>
blueshoe: yep
<blueshoe>
cool
<Swynndla>
whiskas, :P .... blueshoe imposed it on me :)
<ayrnieu>
blueshoe - you'd do well with proper terminology, anyway.
<blueshoe>
ayrnieu, you're absolutely right... i is just the first name i thought of... acc is much clearer
* ayrnieu
forgets the common name for the inner recursive accumulating function.
<blueshoe>
helper function?
<karryall>
ayrnieu: is there one really ?
<blueshoe>
i think i would have definitely had trouble writing that function had det not hinted that it had to have an accumulator
<ayrnieu>
karry - I've noted one in Scheme.
<det>
blueshoe: function .. | notation hyrts my eyes :(
<blueshoe>
works for me
<karryall>
in ocaml stdlib it often has a _aux suffix
<blueshoe>
to me "match x with" just seems like extra typing without adding clarity
<det>
blueshoe: it makes it hard to see that len1 really takes 2 arguments
<blueshoe>
what's _aux ?
<ayrnieu>
Yes, aux.
<blueshoe>
det, but it's idiomatic, no?
<det>
blueshoe: the inner len1 function would conventionally be written len_aux
<ayrnieu>
blueshoe - not really.
<blueshoe>
det, i see
<ayrnieu>
det - and thanks for the 'aux' =)
<whiskas>
What does "idiomatic" mean?
<blueshoe>
so "auxilliary function" is the term you were looking for, ayrnieu? or "helper function"?
<det>
blueshoe: write len using match and see how much clearer it is
<det>
blueshoe: as I started to do with the ... filled in
<whiskas>
det: I second that.
<karryall>
det: I don't
<blueshoe>
det, i guess it is clearer to some... to me the "function" syntax is obvious
<karryall>
more things to type, another identifier to introduce
<blueshoe>
exactly
<blueshoe>
and that identifier just gets used in the "match with" expression... seems like such a waste
<det>
it makes the definition of len1 more obvious that it takes 2 arguments, and the matched pattern can appear whereever you want it to. Try writing with the function syntax when the accumulator is second
<whiskas>
Hmm, you might be right...
<blueshoe>
but i can see that for some people it would help to have an explicit argument.... for me, the "function" keyword tells me there's an argument there
<whiskas>
Then, I'm no guru.
<whiskas>
And I'm damn lagged.
<karryall>
he, that's why the accumulator comes first
<det>
karryall: to accomodate syntax, right :)
<blueshoe>
det, i do see that the "match with" expression is useful on occasion... i've used it myself plenty of times... i just avoid it when possible
<det>
ehh, does anyone here use tuareg-mode ?
<blueshoe>
"function" clues me in that there's an argument for that function that will be matched below... it's obvious to me
<blueshoe>
i use vi
<blueshoe>
or vim, rather
<Swynndla>
same
<blueshoe>
emacs is also unnecessary bloat ;)
<karryall>
I use caml-mode (emacs)
<blueshoe>
isn't tuareg supposed to be better?
<det>
I install installed tuareg mode (debian) and it is still reconizing .ml as caml-mode and I have no M-x tuareg-mode ..
<ayrnieu>
tuareg has much niceness to it, sure.
<ayrnieu>
det - yes, you'd do better to install such modes yourself.
<karryall>
there are some xemacs-specific things IIRC
<det>
karryall: I get no syntax highlighting and crappy indentation with caml-mode ..
<blueshoe>
eew
<ita>
use vim :)
<karryall>
det: works fine here
<blueshoe>
what we need is to rewrite vim in ocaml
<blueshoe>
and make it ocaml scriptable
<ita>
blueshoe: do you want to start ? :)
<blueshoe>
yeah!
<blueshoe>
um, no :)
<ayrnieu>
blueshoe - you can't do that in O'Caml, unfortunately.
<blueshoe>
i've never heard those words spoken in this channel
<Swynndla>
can't and ocaml?
<ita>
ayrnieu: why can't we do that ?
<Swynndla>
in the same sentence?
<whiskas>
Sheesh. :-P
<det>
ayrnieu: you can load ocaml bytecode from native binaries I hear
<ayrnieu>
You can write a program designed for extensibility and you can have people write their ~/.ocamlvi's and such and you can compile ocamlvi on the fly whenever such files change -- and that'll work, if you write tight enough code that people can extend it nicely without slowing compilation down too much.
<blueshoe>
det, and it doesn't even have to be bytecode, does it? can't you just embed the ocaml interpreter and feed it source?
<ayrnieu>
But you can't can't can't ever write a program "scriptable in O'Caml" in any way that doesn't abuse the term in O'Caml.
<ayrnieu>
well, you can't write it in any language =)
<whiskas>
ayrnieu: You lost me on that.
<ayrnieu>
You can have a program that you recompile when you make changes in O'Caml, and you can design it well enough that you won't mind this. There's the line.
<blueshoe>
ayrnieu, why do you need it compiled? why not just use the interpreter?
<det>
ayrnieu: not true
<ayrnieu>
blueshoe - can you write me a tiny interpreter in O'Caml? Something that reads O'Caml expressions from stdin and prints their results?
<blueshoe>
swynndla, how's your "create a list of every other element in a list" function coming along?
<blueshoe>
ayrnieu, why tiny?
<Swynndla>
oh ... didn't everything but that one :/
<ayrnieu>
blueshoe - write it.
<whiskas>
blueshoe: What's that? I'd like to take a shot at it...
<blueshoe>
ayrnieu, "ocaml"
<ayrnieu>
blueshoe - in ocaml, you freak >=(
<blueshoe>
ayrnieu, why?
<blueshoe>
ayrnieu, why not just use the one already made?
<whiskas>
So can't you write ocaml in ocaml?
<blueshoe>
it is written in ocaml
<ayrnieu>
blueshoe - and how do you intend to write a program that uses this interpreter to extend itself?
<whiskas>
Good question.
<blueshoe>
ayrnieu, i believe that information is in the ocaml manual or the faq
<ayrnieu>
blueshoe - I believe that you're totally clueless.
<ayrnieu>
det - that would please me =) So many languages similar to O'Caml have that fundamental lisp-distance -- like Haskell and Mercury, I didn't even consider that O'Caml would accomplish that.
<ayrnieu>
blueshoe - now that we've stated our beliefs, we can get on with the real world -- specifically, for me, the sleeping part.
<ayrnieu>
det - where in O'Caml's standard lib does it have 'eval' ? =)
<blueshoe>
such a pleasure to deal with condescending people
<blueshoe>
the internet is such a lovely place sometimes
<det>
ayrnieu: I dont recall it being as simple as that :)
<ayrnieu>
blueshoe - yes, and your current attitude fills me with as much joy.
<blueshoe>
at least i wasn't being deliberately offensive
<housetier>
#lastword
<ayrnieu>
blueshoe - languages divide rather neatly into "with 'eval'" and "without 'eval'". You can so trivially build a self-extensible self-introspective self-scriptable program in one of these that you forget the power, and you can't do anything remotely as easy in the other.
<blueshoe>
anyway, if you give me a few minutes i will find the eval you are looking for
<blueshoe>
now i recall this topic being brought up on the mailing list
<blueshoe>
and there is some solution, i'm sure of it
<ayrnieu>
blueshoe - C and Java and Haskell and Mercury and, though det suggests otherwise, O'Caml all fall exactly as far from the 'self-scriptable vi' that you desire.
<ita>
you should be programming instead of trolling on such stupid topics .. :)
<ayrnieu>
blueshoe - good!
<karryall>
blueshoe: there is really no 'eval' function
<ayrnieu>
ita - hardly stupid topics -- they interest me a great deal.
<ayrnieu>
ita - you've a fairly fundamental divide between language power, here =)
<karryall>
you can sort of reuse the toplevel
<blueshoe>
karryall, there might be no eval function, but that doesn't mean that you can't get eval equivalent functionality
<ita>
i don't care the power of the languages - that sucks - building apps is more interesting
<blueshoe>
just gimme a few minutes
<ayrnieu>
blueshoe - a few minutes from now, after you figure this out, start working on an 'eval' for C.
<blueshoe>
well, lisp can be implemented in c, right?
<ayrnieu>
ita - and you can't build certain kinds of applications with certain kinds of languages, which brings us full-circle.
<ayrnieu>
blueshoe - yes, you can write an 'eval' for lisp in C. Don't confuse the issue.
<blueshoe>
so anything lisp can do c should be able to accomplish, but perhaps in not so straightforward a way
<ayrnieu>
blueshoe - wrong, wrong.
<blueshoe>
anyway, instead of arguing about this, let me concentrate on finding this eval solution for ocaml
<ayrnieu>
blueshoe - where does C have the 'eval' that evaluates C?+
<ayrnieu>
blueshoe - why don't you fucking listen?
<ayrnieu>
blueshoe - I'm not blowing smoke up your ass.
<whiskas>
Still no one answered, can you write O'Caml in O'Caml?
<blueshoe>
it is written in ocaml
<blueshoe>
iirc
<ayrnieu>
whiskas - of course you can. You can write C in C, just as easily.
<housetier>
I am not so sure about that
<whiskas>
So what are you arguing on, then?
<ayrnieu>
whiskas - if O'Caml lacks an 'eval' that evaluates O'Caml, then it has fundamental domain limitations.
<whiskas>
ayrnieu: If you write an O'Caml interpreter in O'Caml to use it from O'Caml, can't you accomplished that 'self-scriptable vi'?
<ayrnieu>
whiskas - an O'Caml-scriptable VI would lie outside these limitations.
<whiskas>
I don't get it.
<ayrnieu>
whiskas - sigh, sure, you can write that O'Caml interpreter in any language.
<ayrnieu>
whiskas - but can that O'Caml interpreter that you've just written contain an 'eval' that evaluates O'Caml? How much would the result resemble the O'Caml that you'd rather use -- the nice one with the extensible toplevels and the fast bytecode compiler and the awesome native-code compiler?
<whiskas>
Ok, I'll shut, I'm not really getting the point.
<ayrnieu>
Actually, I don't care about that interpreter -- if O'Caml here and now doesn't have 'eval', then you can't write an O'Caml-scriptable VI. Can't.
<ayrnieu>
karryall - yes =) That would make for lots of niftiness.
<karryall>
emacs-like text editor
<karryall>
written in ocaml
whiskas has quit [Connection reset by peer]
<ayrnieu>
karryall - how do you do that? Write a program and and then hook it into the toplevel? How easily can you do that?
<ayrnieu>
That serves as a hack to get 'eval', I suppose -- you carry an interpreter around, but you have to. You lose to other languages in that you don't compile to native code anymore, but you don't care because you can just extend and recompile the editor for anything important and non-immediate.
<ayrnieu>
but thanks =) I'll look into that =)
<karryall>
the toplevel related modules has a function like 'run_script'
* ayrnieu
goes to sleep.
<karryall>
loads a file, compile it on-the fly and execute it
<det>
ayrnieu: at the very least you could do an all byte-code system + dynlink
<ayrnieu>
det - you could do that for ~/.ocamlvi and such, sure.
<ayrnieu>
blueshoe - the first one doesn't seem to have anything to do with the discussion, though.
<karryall>
see Xavier's reply for the first link
<det>
ayrnieu: what does efuns do if all of this isnt possible?
<ayrnieu>
ah, but the thread continues.
<ayrnieu>
det - does efuns have an 'eval', then?
<karryall>
the point is that it kind of works, but it's less featureful than the lisp equivalent
<karryall>
the ocaml runtime wasn't desiged for that
<ayrnieu>
Indeed -- and you have to carry around an actual interpreter, instead of a compiler.
<blueshoe>
so what?
<blueshoe>
the point is that it's possible
<ayrnieu>
I'd say that the O'Caml language, also, doesn't really support that -- given all the mumbling about type safety.
<karryall>
you can hijack the toplevel to do that, but it's a bit of a hack
<blueshoe>
emacs is a bloated monstrosity anyway
<karryall>
ayrnieu: the interpretor is the byte-compiler, really
<blueshoe>
so why not carry around an ocaml interpreter?
<ayrnieu>
karry - ah, OK.
<ayrnieu>
blueshoe - note 'interpreter' versus 'compiler'
<ayrnieu>
blueshoe - and don't confuse 'batch compiler' with 'compiler'
<blueshoe>
yes, and?
<ita>
who wants to start an ocamlvim with me ? :)
<blueshoe>
:)
<blueshoe>
anyway, i think i've made my point
<blueshoe>
swynndla, sorry, i had to finish this flamewar
<Swynndla>
:P
<blueshoe>
swynndla, can you show me your function?
<ayrnieu>
blueshoe - sigh, I suspect that your problem lies more in that you've never really used a modern lispy language.
<Swynndla>
# let rec mylistoflist = function
<Swynndla>
[] -> [[]]
<Swynndla>
| x::xs -> [x] :: mylistoflist xs;;
<blueshoe>
actually, didn't you already create a function that turns a list in to the same list? the "forward" function (while you were working on the reverse)
<blueshoe>
no, don't use the [[]]
<blueshoe>
that's a list of a list
<karryall>
ayrnieu: actually I thought that lisp people now agreed that "eval" isn't sucah a good idea
<blueshoe>
your [x] in the reverse function is confusing you, i think
<ayrnieu>
karryall - sure, because they compile everything just as easily as they'd "eval" anything -- and some of them implement 'eval' in terms of their compilers.
<blueshoe>
ayrnieu, you're right i haven't really used lisp... espeically not any advanced features like macros
<Swynndla>
blueshoe, so if I have [1;2;3] then what do I want as the output?
<ayrnieu>
karryall - in general, you don't need -- just you don't generally need it in O'Caml =)
<ayrnieu>
karry - but with an O'Caml-scriptable vi you obvious have to call an 'eval' at some point.
<blueshoe>
swyndla, well, since you were having problems with it, just output [1;2;3] recursively... but, my original request was that you output [2;4] if given [1;2;3;4] (every other element)
<det>
karryall: "It's bad to use eval, it's worse for a language not to have it" is the common belief I think
<Swynndla>
ohhhh
<blueshoe>
swynndla, remember working on your reverse function? at one point you had it outputing your list in order
<ayrnieu>
swyn - two obvious sensible ways exist to reduce a list to a list of 'every other element' -- one to toggle state while recurring, and one to try and match the discarded element with the kept element at the same time.
<karryall>
ayrnieu: would you ? It seems to me being able to dynamically load module already gives you a lot
<blueshoe>
swynndla, that's equivalent to taking [1;2;3] as an argument and returning [1;2;3]
<blueshoe>
ayrnieu, the point is for swynndla to figure this out on his own, if he can
<blueshoe>
ayrnieu, he's trying to learn from this
<ayrnieu>
karry - for an editor? I'd rather just have compilation speeds fast enough to recompile the entire system every time I change something.
<blueshoe>
ayrnieu, not have his learning be subverted by people giving him the answers outright, before he's had a chance to do his best
<ayrnieu>
blueshoe - thanks for the telegram. I don't expect my hint to have answered his question for him.
<det>
ayrnieu: you are crazy
<Swynndla>
blueshoe, yea I did the forward one before ... here is the every other one:
<blueshoe>
cool
<Swynndla>
# let rec mylistoflist = function
<Swynndla>
[] -> []
<Swynndla>
| x::y::xs -> x :: mylistoflist xs;;
<karryall>
ayrnieu: why recompile the entire system ?
<karryall>
the point of dyn.loadable modules is to avoid this of course
<ayrnieu>
karry - if you can do it fast enough, it beats a module system =)
<karryall>
I don't understand, sorry
<ayrnieu>
swyn - do you know where that function fails?
<blueshoe>
swynndla, there's a problem with that
* karryall
is away: (lunkc)
<det>
ayrnieu: no, it is worse
<Swynndla>
if there are an odd number of elements?
<det>
ayrnieu: you can't do things *while it is running*
<det>
ayrnieu: which is the whole point of an extensible editor
<ayrnieu>
det - but you don't care about that, with a vi-like editor. If you can't have the nice :ocaml 1 + 1;;, anyway. I see dynamically loaded modules and trying to extend an editor at runtime with them as just a lot of trouble. With a server, maybe.
<blueshoe>
swynndla, exactly
<blueshoe>
swynndla, now how can you solve that?
<ayrnieu>
swyn - let rec sillyiness x = match x with 0 -> "zero" | 1 -> "one" | 2 -> "two" | _ -> "many";;
<det>
ayrnieu: all of ~/.vimrc can be done while you are using vim
<det>
ayrnieu: in fact your keybindins are bound to that stuff
<det>
ayrnieu: efuns does all this, it seems.
<ayrnieu>
det - I must use my vi-like editors differently than you =) but I don't see how dynamically compiled modules give you that feature.
<ayrnieu>
det - with the toplevel, probably.
<det>
ayrnieu: you never use the colon key in vi ?
<Swynndla>
# let rec mylistoflist = function
<Swynndla>
[] -> []
<Swynndla>
| x::[] -> [x]
<Swynndla>
| x::y::xs -> x :: mylistoflist xs;;
<det>
ayrnieu: I use emacs now anyways
<ayrnieu>
det - eh, of course I do -- but I don't spend lots of time playing with bindings or creating automatic handling of different filetypes and such.
<blueshoe>
swynndla, good job! now do the even memebers
<Swynndla>
# let rec mylistoflist = function
<Swynndla>
[] -> []
<Swynndla>
| x::[] -> []
<Swynndla>
| x::y::xs -> y :: mylistoflist xs;;
<blueshoe>
yay!
<blueshoe>
how about swapping every other element?
<Swynndla>
:)
<blueshoe>
isn't this fun?
<Swynndla>
hehe
<ayrnieu>
blueshoe - I've exhibited unusual rudeness to you, and I'd like to apologize to you for that, but you just annoy the hell out of me for some reason. It seems mutual. I needed to go to sleep five hours ago, so I can't stay up (grr, longer) thinking about a nice way to say what I've said. Good night. I hope we can have better relations in the future, when I don't feel like talking so much about these kinds of (to me, very disturbing) language design issues.
<blueshoe>
ayrnieu, the only reason i was annoyed was because you were rude
<Swynndla>
blueshoe, just the even ones?
<blueshoe>
ayrnieu, i am capable of disagreeing with someone and not be cross with them
<ayrnieu>
blueshoe - and I grew rude when I perceived you as ignorantly, and rudely, dismissing views that I'd given much thought to.
<blueshoe>
swynndla, yes, with just even sized lists
<ayrnieu>
blueshoe - probable enough that my perceptions do not support me very well, at this time.
<blueshoe>
swynndla, so that input of [1;2;3;4] would yield [2;1;4;3]
* ayrnieu
goes to sleep for real.
<Swynndla>
blueshoe, but I swap only the even elements?
<Swynndla>
nite ayrnieu
<blueshoe>
ayrnieu, i obviously did push your button when talking about eval... however, i did not know this was a sore point for you, i just stated what i'd learned of the matter... if you think i'm ignorant, i am open to correction... but i expect the courtesy of being heard politely in return
<blueshoe>
ayrnieu, i also hope we can get along better in the future
<blueshoe>
swynndla, right, swap the elements as if they were pairs
<blueshoe>
in pairs, rather
<blueshoe>
i'm actually going to have to work out the solution to this one myself
<blueshoe>
i just thought it up... i don't know how easily doable it is
<blueshoe>
if you can't figure it out maybe you should try doing the same thing with a list of pairs in tuples
<blueshoe>
like [(a,b);(c,d)] returning [(b,a);(d,c)]
<blueshoe>
that might be easier
<Swynndla>
# let rec mylistswap = function
<Swynndla>
[] -> []
<Swynndla>
| x::[] -> [x]
<Swynndla>
| x::y::xs -> y :: x :: mylistoflist xs;;
<blueshoe>
yay
<Swynndla>
:P
<Swynndla>
but I'm not sure of the tupple one
<blueshoe>
ok, a tuple is a series of values in parenthesis, seperated by commas
<blueshoe>
you actually used them in your absolute differences sum function
<blueshoe>
remember?
<Swynndla>
yup
<Swynndla>
just trying to see how to reverse then
<Swynndla>
in one function I mean
<blueshoe>
you can do it in one function
<blueshoe>
but it's a little tricky
<det>
Swynndla: imagine the even odd thing written like so:
<blueshoe>
i can give you a couple of hints that will probably help
<det>
let rec every_other accum state list =
<det>
match list with
<det>
[] -> accum
<det>
| x::xs -> match state with
<det>
true -> every_other (x::accum) false xs
<det>
| false -> every_other accum true xs
<det>
let odd list = every_other [] true list
<det>
let even list = every_other [] false list
<blueshoe>
det, i've seen a similar strategy in the wc example in pierre weis' ocaml examples collection
<blueshoe>
it's interesting
<blueshoe>
however, don't you think it would be clearer if every_other took an "even" or "odd" argument?
<det>
sure
<det>
type state = Even | Odd
<blueshoe>
cool
<det>
then substiture all occurances of true for Odd and false for even
ott has quit ["BitchX-1.0c16 -- just do it."]
<det>
or just use builtin bool :)
<Maddas>
Good afternoon
<blueshoe>
hi, maddas
<blueshoe>
swynndla, want a hint?
<Swynndla>
yes blueshoe
<blueshoe>
hint #1: use "match foo with" expression
<blueshoe>
hint #2: use parenthesis
<Maddas>
hrm, I wish O'Caml would have typeclasses
<blueshoe>
also, incidentally, there's a "begin" "end" construct in ocaml, that is equivalent to parenthesis.. one might be clearer than the other, at times
<det>
Maddas: I wish sml would have them :)
<Maddas>
det: Is implementation of them planned? It would be awesome
<det>
no!
<Maddas>
Bah
<Maddas>
Why not? Surely they must have heard of them ;-)
<det>
You should propose SML2003
<Maddas>
Heh
<det>
2004!
<Maddas>
det: I doubt they'd be happy about proposals that you can't help with realising
<Maddas>
and since I'm no good coder, I certainly won't be helpful
<blueshoe>
swynndla, here's another hint... "| x::xs -> ( match x with
<blueshoe>
"
<Swynndla>
# let rec mylisttupswap l = match l with
<Swynndla>
[] -> []
<Swynndla>
| x::xs -> match x with
<Swynndla>
(a,b) -> (b,a) :: mylisttupswap xs;;
<blueshoe>
yay
<Swynndla>
:P
<blueshoe>
you didn't need "match l with", you could have used "function", though det would not approve
<blueshoe>
but you did need the "match x with"
<blueshoe>
and i guess you didn't need the parenthesis after all
<Swynndla>
:P
<Swynndla>
well teacher ... I g2g :P
<Maddas>
I would use some, though, in case the second match case grows
<blueshoe>
me too
<Swynndla>
but thx heaps for some much of your patient time!!
<blueshoe>
sure
<Swynndla>
:))
<Maddas>
Actually, I would use begin..end, sinec I prefer that more for long things :)
<blueshoe>
keep on practicing recursion... this is just the tip of the iceberg!
<Swynndla>
LOL
<Swynndla>
ok .. u will still be my teacher from time to time blueshoe?
<blueshoe>
sure
<Swynndla>
sweet :))
<blueshoe>
but, again, i really recommend you get "Elements of ML Programming" by ullman
<blueshoe>
it has lots of good exercises, and super clear explanations
<blueshoe>
leading you from the very basics, step by step
<Swynndla>
I'll have to save up for it
<blueshoe>
see if you can get it on half.com
<Swynndla>
shipping + exchange rate .... to New Zealand
<blueshoe>
they often have a good selection of used computer books
<blueshoe>
wow
<Swynndla>
:P
<blueshoe>
well, you know, that book is compiled from his class notes
<blueshoe>
check out his web page... he has his notes available for free download
<Swynndla>
what is his web page?
<blueshoe>
they are in postscript format, so you should be able to just print them out, and they're probably nearly as good as the book itself
<ita>
whiskas: if you don't know what to do on your spare time ..
<karryall>
ita: jerome marant worked on this too
<ita>
for the moment i'll continue writing my lib in caml and make the gui in kde :-/
<karryall>
why not use lablgtk ?
<ita>
gtk sucks
<karryall>
yeah, right
<ita>
it is ugly at least
<ita>
i used to program in gtk in the past but i really hate it compared to qt
Demitar has joined #ocaml
<karryall>
yeah, sure, C++ is renowed for its beauty
<ita>
the gtk filedialog is scary
<whiskas>
I do like C++.
* Maddas
shudders
<Maddas>
whiskas: You need to code more O'Caml :P
<ita>
and calling a componet (html browser) is too hard
<whiskas>
I didn't say that I don't like O'Caml.
<whiskas>
Though you can do FP in C++, you know...
<whiskas>
That's how I got interested in FP languages...
<Maddas>
whiskas: Yes
<Maddas>
The more I play around with O'Caml/Haskell the less I like the typical procedural programming in general :)
<whiskas>
Well, C++ ain't for sure procedural if ya know how to use it, and Haskell, well I haven't touched it so far. O'Caml looks a lot more better (though I hear monads are a really great invention)
<ita>
Maddas: though some things are easier in procedural programming languages (multiplying matrices?)
<whiskas>
ita: Not if you want to do it efficiently.
<Maddas>
whiskas: What do you mean?
<whiskas>
Umm, well efficient matrix multiplication is another, rather complicated algorithm.
<ita>
whiskas: really ? (seen in the ocaml book that it was easier to do in a procedural way)
<whiskas>
Take a look at blitz++, for example.
<Maddas>
I meant the comment before that
<Maddas>
:-)
<whiskas>
Maddas: ?
<Maddas>
"C++ ain't for sure procedural"
<whiskas>
Maddas: Well, unless you treat at as "C with objects" it ain't surely procedural at all.
<whiskas>
And I don't like treating it as "C with objects".
<Maddas>
oh
<Maddas>
Isn't OO a subset of imperative programming?
<Maddas>
Maybe I shouldn't have said procedural
<whiskas>
Maddas: I've seen some insane C++ code that don't resemble at all procedural.
<whiskas>
Or OO, for that matter.
<Maddas>
whiskas: Sure, you *can* write really functional things, but the language doesn't encourage it
<whiskas>
Seriously.
<whiskas>
Maddas: Heh, I won't bet on it. Have you seen Spirit?
<Maddas>
No
<Maddas>
Is that a library like Boost?
<Maddas>
I see
<whiskas>
Spirit is a lexical analyzer/parser that allows the grammar to be expressed in inline C++.
<whiskas>
It's rather amazing.
<Maddas>
Possible
<Maddas>
I just don't like the taste of C++
<Maddas>
I don't say that you can't do cool things in it :-)
<Maddas>
In fact, maybe I shouldn't have said "procedural programming" in general
<Maddas>
Maybe I should just shut up! Sounds like a godo idea :-)
<whiskas>
NO really.
<whiskas>
s/NO/Not
<Maddas>
heh :)
<whiskas>
I'm not saying that C++ is better. Or that O'Caml is worse for that matter.
<whiskas>
I'm just saying that C++ is a wonderful language if you come to grasp it, and I have no doubts regarding O'Caml either.
<Maddas>
I just miss the things like the rich type system, first class functions (I heard Boost provides that though), those kind of things
<whiskas>
Just that I'm a little better with C++ than with O'Caml at the moment.
<Maddas>
:-)
cjohnson has joined #ocaml
<whiskas>
Hmm, why did everyone shut up?
<ita>
sssshhhh the boss is behind :)
<whiskas>
:-))
<whiskas>
So folks, what kind of apps do you code in O'Caml? Where can I get some code from?
<housetier>
mldonkey is written in ocaml
<whiskas>
Yeah, that I'm aware of.
<Maddas>
I just play around, I don't really have any projects/ideas :)
<Hadaka>
writing an ocaml wiki on top of subversion would really rock :)
<karryall>
ita: is it written in ocaml ?
<ita>
karryall: no, pure C
wazze has joined #ocaml
<ita>
i'm trying to see wether programming in ocaml will increase my productivity
<Demitar>
whiskas: Ah, the joys of C++. Chasing a bug for a week and finally finding out you missed the parent constructor in one of four constructors in a reference. The error? A segfault! ;-) That said I don't mind debugging peoples c++ but I don't enjoy coding in such a language anymore. Then again I also like reimplementing as much as the average Free Software coder. ;-)
<mimosa>
of course it will : no more memory leaks problems (thanks to GC and string typing) is a good argument I think
<whiskas>
Demitar: :-)
<Demitar>
The type system is *the* thing I like about ocaml.
<Maddas>
mimosa: Also, the type system catches bugs early
<ita>
... but if you use QString in c++ there are no more leaks either (char* is evil)
<Maddas>
And no null pointers
<whiskas>
ita: Dude, there's std::string, QT's C++ is NO (and I repeat, NO) C++!!!
<ita>
and for building guis c++ is great
<Maddas>
It has good library support
<mimosa>
the weak point with caml is maybe guis
<ita>
whiskas: std::string looks nice, but using qstring is easier and more secure
<whiskas>
Hmm, maybe we should stop thinking about C++, I'm a little fanatic.
<Maddas>
mimosa: I'd say it's with pretty much any not so popular language
<whiskas>
ita: Well, can you tell me how std::string "leaks"?
<Maddas>
ita: IIRC, a programmer writes approximately the same number of lines per time, not really depending on the language (once he's good at it)
<Maddas>
ita: So if you use a more expressive language, you should be more productive (assuming debugging doesn't consume much more time)
<ita>
whiskas: from times to times char* is necessary
<ita>
whiskas: btw why do you think qstring is no c++ ?
<whiskas>
ita: Pretty long story :-P
<Hadaka>
QString is a joke
<whiskas>
See? :-P
<Hadaka>
arh, no, not getting into this on #ocaml
<ita>
whiskas: explain ? i've read the documentation and i still don't understand ...
<whiskas>
Hadaka: Good point.
<whiskas>
ita: What Hadaka said.
<ita>
let's go on #qt if you like
<ita>
i'm curious
<whiskas>
ita: Well, for one thing, the fact the QT comes with it's own compiler really makes me sick
<ita>
whiskas: it's a meta-compiler (moc), why would you hate it ?
<whiskas>
ita: You answered yourself to your own question :-)
<ita>
well, if c++ had aspect programming built-in it'd be easier. now what ? moc works well and does the job
<whiskas>
ita: Umm, I'd rather change the subject, told ya I'm a fanatic (and a purist).
<whiskas>
Btw, gtk-- is more C++-ish than QT will probably ever be.
<ita>
whiskas: that's not really convincing
<whiskas>
I know.
<ita>
haskell has no imperative side so ocaml suX0r ? is that convincing ?
<whiskas>
Mate, I didn't say I wanted to prove a point. And I warned you about it :-P
<ita>
Hadaka: can you tell me why qstring is a joke ?
<Demitar>
If we want to go back to why O'Caml will rule the world I'd say one of the lovely side-effects of the type system and all is that it allows you to write bad code and get away with it. :) (That is your code actually does what you want to although it's a mess.)
<whiskas>
:-))
<ita>
whiskas: ok, so you're a troll
<Demitar>
ita, drop it.
<whiskas>
ita: Not always.
<whiskas>
Most of the times, I'm pretty O.K.
<Demitar>
This is getting uncannily off-topic really.
<Hadaka>
ita: I'll do it in a private discussion
<whiskas>
Hmm, damn, I ruined a beautiful conversation.
<whiskas>
Well, I guess it's just one of those days... considering that I haven't slept in the last 3 days, it might be excusable...
<Demitar>
whiskas, not having slept enough is merely a sign one should keep away from file maintenance, language wars and coding. One is likely to ruin any of the three.
<whiskas>
Demitar: I wasn't trying to war anybody, and I've clearly stated that I'm not willing to support my oppinions if (more or less) objective arguments.
<whiskas>
s/if/with
<Demitar>
whiskas, I'm using the term language war generally here, meaning any opinion of the type (I find) language X better than language Y since it has feature Z.
<whiskas>
I understand that, but if you recall, <whiskas> I'm not saying that C++ is better. Or that O'Caml is worse for that matter.
<whiskas>
(Hmm, I should have added either, too).
<Demitar>
You say that flavour pure of c++ is better than flavour qt.
ott has quit ["ott has no reason"]
<whiskas>
I merely stated that me, being fanatic, I rather hate the C++ flavour QT brings.
<Demitar>
Anyway, this is just as off-topic as the previous discussion. I should keep silent until someone asks an ocaml question. ;-)
<whiskas>
Heh, ok.
<whiskas>
So how's OOP in O'Caml?
<whiskas>
(How's that for an O'Caml question?)
<Demitar>
Good and bad.
<whiskas>
Like always :-)
<Demitar>
The only real use I have for it personally is to save some typing. :)
<whiskas>
Ooh?
<Demitar>
I can do all else using modules.
<whiskas>
Hmm..
<Demitar>
Well apart from using lablgtk but that's not my code really.
<whiskas>
Well, I've done a couple of tutorials, read a book or two, but I can't say I can code O'Caml. What do you suggest for further learning?
<Demitar>
Write some code. ;-)
<whiskas>
Hehe. Gimme some assignment, so I can be motivated :-P
<Demitar>
Implement froth.
<Demitar>
forth even.
<Demitar>
Not that I've done it but I hear it's very simple. :)
<whiskas>
OOh?
<whiskas>
I've done some forth like 7-8 years ago, on a spectrum, but was too young at that time to really get something out of it.
<Demitar>
But if you want something more interesting you could write a game using camlsdl.
wazze is now known as afkts
<Demitar>
Unless you find implementing languages interesting (well it probably is but I always get confused somewhere among yacc internals :).
<whiskas>
Hmm. What else? :-P
<Demitar>
What did you ask now? Something else to write?
<whiskas>
Well, I'm just looking for suggestions, that's all :-)
<Demitar>
A gtk application perhaps?
<whiskas>
Hmm, that sounds interesting. How's lablgtk?
<Demitar>
I like it, writing a worldforge game client (well I haven't hacked on anything lately but that's my current lablgtk project).
<whiskas>
Cool. Thanks.
blueshoe has quit [Read error: 104 (Connection reset by peer)]
tomasso has quit [Read error: 104 (Connection reset by peer)]
housetier has quit ["#breaks @ irc.highteq.de"]
housetier has joined #ocaml
blueshoe has joined #ocaml
The-Fixer has quit [Read error: 104 (Connection reset by peer)]
The-Fixer has joined #ocaml
The-Fixer has quit [Client Quit]
blueshoe has quit [Read error: 104 (Connection reset by peer)]
tomasso has joined #ocaml
reltuk has joined #ocaml
The-Fixer has joined #ocaml
Nutssh has joined #ocaml
owll has joined #ocaml
owll has left #ocaml []
afkts is now known as wazze
housetier has quit ["#breaks @ irc.highteq.de"]
_JusSx_ has joined #ocaml
Nutssh has quit ["Client exiting"]
blueshoe has joined #ocaml
karryall_ has joined #ocaml
karryall has quit [Remote closed the connection]
karryall_ is now known as karryall
Nutssh has joined #ocaml
buggs^z is now known as buggs
blueshoe has quit [Read error: 104 (Connection reset by peer)]
Nutssh has quit ["Client exiting"]
ita has quit [Remote closed the connection]
maihem has joined #ocaml
blueshoe has joined #ocaml
<blueshoe>
so looks like the martians have successfully attacked the rover
<karryall>
blueshoe: really ?
<blueshoe>
nasa is reporting "a very serious anamoly" (the rover isn't communicating)
<blueshoe>
this happened overnight, so i'm guessing it was a martian ambush
<blueshoe>
surprised this hasn't been slashdotted yet
<blueshoe>
would be cool if they could land the other rover nearby and have it take a look at the carnage