11:27 <two-face> hi there

11:32 <zack> hi

11:47 <two-face> zack: i'm preparing a new cameleon, it take some time because i have to patch

11:48 <zack> two-face: ack, any problem with libdir transition there?

11:49 <two-face> zack: i don't think so

11:49 <two-face> zack: i can no longer grab the daily snapshot, since it depends on ocaml cvs

11:50 <zack> two-face: .... :-(

11:50 <zack> two-face: I suppose you have already asked maxence about this ...

11:50 <two-face> zack: yes :)

11:50 <two-face> zack: and he told me he has no choice

11:51 <zack> ok, BTW, I'm curious: where does this dependency come from?

11:51 <two-face> zack: the debugger mainly

11:52 <zack> ocamldebug?

11:52 <zack> or epeire?

11:52 <two-face> zack: epeire is based on ocamldebug

11:54 <zack> ok, do you know which changes are going on with ocamldebug in ocaml 3.07?

11:55 <two-face> zack: not at all, and we don't even know when 3.07 is going to be released

11:56 <zack> two-face: ok, thanks, regarding release date ... I don't know buf from Xavier's mails it seems to me not to near in the future

11:56 <two-face> zack: yes, 6 months i think :)

11:57 <zack> with a 3.08 a few days later? :-DDD

11:58 <two-face> zack: i think you have some precognition powers:)

11:58 <zack> two-face: not at all, I only remember from somewhere that history is usually looping ;)

12:00 <two-face> zack: :-)

12:00 <two-face> zack: we've already told them about .1 .2 and so one

12:01 <zack> well, ocaml team position regarding releases is anyway reasonable: each release requires a full library rebuilding ...

12:02 <two-face> yes, but bugfixes for the same release do not require such stuff

13:06 <two-face> BBL

13:37 <Kinners> what's the best way to turn [a;b;c] into b, c ?

13:49 <sam_> match lst with [a; b; c] -> (b, c) perhaps

13:51 <Kinners> ah yes that's good

14:53 <sofayam> any book translators out there ?

15:24 <sam_> no, just us ocaml hackers

17:02 <aleksi> I'm with imperative background, and I've read the english translation for 4 chapters now

17:03 <aleksi> it's a bit hard to understand how purely functional datastructures, with nonmutable memory regions could be efficient for anything but the small pieces

17:04 <aleksi> so I feel, that I'd balance my code regarding datastructures into functional side for very small or mainly list-like things, and everything else I'd do in imperative style

17:04 <aleksi> am I way off the mark, would twist me more to the functional side? (I'd like to go there :)

17:54 <sam_> aleksi, well, personally i don't buy into this "my paradigm is better than yours" stuff.. in my opinion the strength of 'functional programming' comes more from higher order functions, closures, pattern matching, etc than from purely functional data

17:58 <sam_> not to say i don't like purely functional data.. i do, but i agree, that sometimes you need mutable data for performance reasons (or that mutable data just deals with the problem easier).. though, i do use mutable data a _lot_ less than when i first got introduced to functional programming (comefrom imperative/oop programming world too)

17:59 <sam_> i think finding a good balance between them just needs some time

19:15 <aleksi> sam, ok

19:15 <aleksi> so what's your suggestion for the balance I should try to find to the beginning

19:16 <aleksi> maybe policy, like try to do everything in functional datastructures, unless there's no way to do it, or that there's no way to get it fast enough

19:16 <aleksi> keep interfaces so clean, so that the datastructure could be changed whenever you feel

19:50 <sam_> i go for functional data for almost all data.. and for the cases where i use imperative data, it's usually that i find it more convenient than the performance increase.. i find the performance with functional data just fine for most cases.. and for the cases i don't, such as heavy graphics of sound processing.. i'm not sure you should be using ocaml in the first place. even with mutable data, you'd have tough time getting it to C speeds

20:08 <aleksi> sam, I see

20:08 <aleksi> actually one of the reasons I turned for Ocaml was speed

20:09 <sam_> oh, and while i keep mostly all globally moving data (as in, data that functions return, take as parameters etc) functional, i use 'ref's inside functions often, so the 'imperativeness' does not show outside the function

20:09 <aleksi> so now I might consider again whether to combine C with Haskell instead of Ocaml

20:10 <aleksi> sam, that's a nice trick to use

20:10 <aleksi> kind of using closures to close imperativeness inside a function

20:11 <sam_> well, depends on what your needs from a language are.. i use ocaml, cause it's 'high level', but still 'fast'.. now as fast as c, but far beyong scripting language speeds like python

20:12 <sam_> s/now/not

20:16 <aleksi> sam, I guess I'm heading on that level too

20:16 <aleksi> nowadays I use Ruby as a "scripting" language (actually my main *programming* language)

20:17 <aleksi> and it's very nice because it already has many functional features, like higher order functions, and closures, even very limited form of pattern matching

20:18 <aleksi> but it's a bit too slow for some things

20:18 <aleksi> and I hope to replace it with another at least equally high level language

20:18 <sam_> haven't looked much into ruby, but i don't think i'd switch to a language without a static (ml-type) type system anymore.. and also, i kind of dislike using interpreted languages (i'm a speed freak :-)

20:19 <aleksi> I find stuffing all kind of data into a array (or list). Like right now I have a list of Date, couple of ints and float. The size of the record may vary quite a lot.

20:20 <aleksi> How do you cope with this kind of "freeform" datastructures with strict typing of ML.

20:20 <aleksi> (Which I like on paper very much! Haven't written any programs yet, so I don't know how much of a pain it will be, especially with uninformative warnings and errors.)

20:22 <sam_> in ocaml, you can do a sum type that handles all the cases.. but the 'ml-type' type system does not prevent you from having a 'dynamic' type, e.g. GCaml has one.. it's just one of the many features i'd wish ocaml did have too, but doesn't currently

20:23 <sam_> that is, sum type as in "type foo = Date of date | Intpair of (int * int) | Float of float'

20:25 <sam_> anyway, leaving to see Two Towers now.. later

20:25 <aleksi> yes, thanks, see ya

20:28 <matkor> Good evening. ;)

21:12 <Qui_Gon> hello

21:12 <Qui_Gon> is anyone using camllight on linux ?