mbishop changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | Grab Ocaml 3.10.0 from http://caml.inria.fr/ocaml/release.html (featuring new camlp4 and more!)
jlouis_ has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
yminsky has quit []
jlouis has joined #ocaml
jlouis_ has quit [Read error: 110 (Connection timed out)]
buluca has quit [Read error: 113 (No route to host)]
CRathman_ has joined #ocaml
crathman has quit [Read error: 110 (Connection timed out)]
CRathman_ is now known as CRathman
gaja_ has joined #ocaml
gaja_ has quit [Client Quit]
yminsky has joined #ocaml
ulfdoz has quit [zelazny.freenode.net irc.freenode.net]
Hadaka has quit [zelazny.freenode.net irc.freenode.net]
seafood has quit [zelazny.freenode.net irc.freenode.net]
eroyf has quit [zelazny.freenode.net irc.freenode.net]
acatout has quit [zelazny.freenode.net irc.freenode.net]
Demitar has quit [zelazny.freenode.net irc.freenode.net]
Jedai has quit [zelazny.freenode.net irc.freenode.net]
piggybox has quit [zelazny.freenode.net irc.freenode.net]
c has quit [zelazny.freenode.net irc.freenode.net]
jonathanv has quit [zelazny.freenode.net irc.freenode.net]
gaja has quit [zelazny.freenode.net irc.freenode.net]
flux has quit [zelazny.freenode.net irc.freenode.net]
zbrown has quit [zelazny.freenode.net irc.freenode.net]
svenl has quit [zelazny.freenode.net irc.freenode.net]
ramkrsna has quit [zelazny.freenode.net irc.freenode.net]
mvitale_ has quit [zelazny.freenode.net irc.freenode.net]
authentic has quit [zelazny.freenode.net irc.freenode.net]
vorago has quit [zelazny.freenode.net irc.freenode.net]
henry_r has quit [zelazny.freenode.net irc.freenode.net]
unfo-ninja has quit [zelazny.freenode.net irc.freenode.net]
Amorphous has quit [zelazny.freenode.net irc.freenode.net]
zmdkrbou has quit [zelazny.freenode.net irc.freenode.net]
mvitale_ has joined #ocaml
authentic has joined #ocaml
vorago has joined #ocaml
henry_r has joined #ocaml
mattam has quit [Remote closed the connection]
SmerdyLaptop has quit ["g'bye"]
mattam has joined #ocaml
hcarty has quit [Remote closed the connection]
hcarty has joined #ocaml
robozni has quit [Remote closed the connection]
jlouis has quit [Remote closed the connection]
tsuyoshi_ has joined #ocaml
robozni has joined #ocaml
tsuyoshi has quit [Remote closed the connection]
jlouis has joined #ocaml
rx_t has joined #ocaml
yminsky has quit [zelazny.freenode.net irc.freenode.net]
zvrba has quit [zelazny.freenode.net irc.freenode.net]
cmeme has quit [zelazny.freenode.net irc.freenode.net]
Oatschool has quit [zelazny.freenode.net irc.freenode.net]
Sparkles has quit [zelazny.freenode.net irc.freenode.net]
dropdrive has quit [zelazny.freenode.net irc.freenode.net]
TaXules has quit [zelazny.freenode.net irc.freenode.net]
rx has quit [Read error: 104 (Connection reset by peer)]
rx_t is now known as rx
hcarty has quit [Remote closed the connection]
ita has quit [Remote closed the connection]
__mattam__ has joined #ocaml
robozni_ has joined #ocaml
robozni_ has quit [Client Quit]
mattam has quit [Read error: 104 (Connection reset by peer)]
CRathman has quit [Connection timed out]
univac has quit [zelazny.freenode.net irc.freenode.net]
tsuyoshi_ has quit [zelazny.freenode.net irc.freenode.net]
aij has quit [zelazny.freenode.net irc.freenode.net]
rx has quit [zelazny.freenode.net irc.freenode.net]
jlouis has quit [zelazny.freenode.net irc.freenode.net]
jdavis_ has quit [zelazny.freenode.net irc.freenode.net]
schme has quit [zelazny.freenode.net irc.freenode.net]
szsz has quit [zelazny.freenode.net irc.freenode.net]
rwmjones has quit [zelazny.freenode.net irc.freenode.net]
bebui has quit [zelazny.freenode.net irc.freenode.net]
gunark has quit [zelazny.freenode.net irc.freenode.net]
tristram has quit [zelazny.freenode.net irc.freenode.net]
lde` has quit [zelazny.freenode.net irc.freenode.net]
Smerdyakov has quit [zelazny.freenode.net irc.freenode.net]
mbishop has quit [zelazny.freenode.net irc.freenode.net]
Nutssh has quit [zelazny.freenode.net irc.freenode.net]
authentic has quit [zelazny.freenode.net irc.freenode.net]
vorago has quit [zelazny.freenode.net irc.freenode.net]
henry_r has quit [zelazny.freenode.net irc.freenode.net]
mvitale_ has quit [zelazny.freenode.net irc.freenode.net]
Ober_ has joined #ocaml
rx has joined #ocaml
jlouis has joined #ocaml
jdavis_ has joined #ocaml
schme has joined #ocaml
szsz has joined #ocaml
rwmjones has joined #ocaml
bebui has joined #ocaml
gunark has joined #ocaml
tristram has joined #ocaml
lde` has joined #ocaml
Smerdyakov has joined #ocaml
mbishop has joined #ocaml
Nutssh has joined #ocaml
tsuyoshi_ has joined #ocaml
aij has joined #ocaml
Ober has quit [Remote closed the connection]
mvitale_ has joined #ocaml
authentic has joined #ocaml
vorago has joined #ocaml
henry_r has joined #ocaml
unfo-ninja has joined #ocaml
zmdkrbou has joined #ocaml
Amorphous has joined #ocaml
diakopte1 has joined #ocaml
univac has joined #ocaml
zvrba has joined #ocaml
cmeme has joined #ocaml
Oatschool has joined #ocaml
Sparkles has joined #ocaml
TaXules has joined #ocaml
dropdrive has joined #ocaml
Demitar has joined #ocaml
Jedai has joined #ocaml
piggybox has joined #ocaml
c has joined #ocaml
jonathanv has joined #ocaml
seafood has joined #ocaml
eroyf has joined #ocaml
gaja has joined #ocaml
zbrown has joined #ocaml
ulfdoz has joined #ocaml
flux has joined #ocaml
Hadaka has joined #ocaml
ramkrsna has joined #ocaml
svenl has joined #ocaml
acatout has joined #ocaml
diakopter has quit [Read error: 104 (Connection reset by peer)]
__mattam__ has quit [Success]
kelaouch1 has joined #ocaml
mattam has joined #ocaml
hcarty has joined #ocaml
robozni has quit [Connection timed out]
Ober_ is now known as Ober
kelaouchi has quit [No route to host]
salierix has joined #ocaml
<salierix> I can't seem to install lablgl, the build complains that "ocamlc: Command not found"
robozni has joined #ocaml
salierix has quit ["Leaving"]
yminsky has joined #ocaml
yminsky has quit []
salierix has joined #ocaml
jlouis_ has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
robozni_ has joined #ocaml
robozni has quit [Read error: 110 (Connection timed out)]
RL has joined #ocaml
CRathman_ has joined #ocaml
CRathman_ is now known as CRathman
CRathman has quit [Read error: 110 (Connection timed out)]
RL has quit ["Leaving"]
asmanur has joined #ocaml
darinm has joined #ocaml
robozni_ has quit ["leaving"]
CRathman_ has joined #ocaml
CRathman_ is now known as CRathman
CRathman has quit [Remote closed the connection]
Tetsuo has joined #ocaml
filp has joined #ocaml
bluestorm_ has joined #ocaml
darinm has quit []
Yoric[DT] has joined #ocaml
<Yoric[DT]> hi
<salierix> Morning.
<Yoric[DT]> How do you do ?
<bluestorm_> fine
kelaouch1 has quit [Client Quit]
buluca has joined #ocaml
sgnb has joined #ocaml
pango_ has quit [Remote closed the connection]
pango_ has joined #ocaml
screwt898 has quit [Read error: 104 (Connection reset by peer)]
Abo-Marwan91 has quit [Read error: 104 (Connection reset by peer)]
bluestorm_ has quit [Remote closed the connection]
bluestorm_ has joined #ocaml
<salierix> What are .mli files used for?
<bluestorm_> interface files
<bluestorm_> .ml file are an implicit module
<bluestorm_> the .mli file (if it exists) is the interface of that module
screwt898 has joined #ocaml
<bluestorm_> in the .mli you describe the values of your modules you want to expose to the outside world
seafood_ has joined #ocaml
<bluestorm_> and give their types
<salierix> Ok, thanks.
<bluestorm_> that way, you can restrict values (values that are not in the .mli are kinda "private" to the module)
<bluestorm_> moreover, .mli are commonly used to put function documentation
l_a_m has joined #ocaml
<bluestorm_> there is a standard way to do it, and the Ocamldoc tool can extract it and give you a .html, .tex or whatever
seafood_ is now known as seafoodX
screwt898 has quit [Read error: 104 (Connection reset by peer)]
Abo-Marwan91 has joined #ocaml
Abo-Marwan91 has quit [Remote closed the connection]
Abo-Marwan91 has joined #ocaml
screwt898 has joined #ocaml
filp has quit ["Bye"]
yminsky has joined #ocaml
Demitar has quit [Read error: 110 (Connection timed out)]
yminsky has quit []
<salierix> int is only 31 bits? How bizarre...
yminsky has joined #ocaml
<asmanur> salierix: if you want 32bits-int, you can use Int32, if you want "nativeint" (as int in C), you can use Nativeint
<asmanur> (the last bit is used by the GC)
<salierix> How large is an int32? The docs say it i s larger than int (including the GC bit).
<asmanur> 32 bits
<salierix> The docs say it's larger than 32 bit.
<asmanur> "This module provides operations on the type int32 of signed 32-bit integers."
<salierix> "Performance notice: values of type int32 occupy more memory space than values of type int, and arithmetic operations on int32 are generally slower than those on int. Use int32 only when the application requires exact 32-bit arithmetic."
<sgnb> an int32 is a 32-bit integer
<sgnb> (as in int in C on a 32 bit machine)
<asmanur> salierix: because Int32 are stored like blocs
<asmanur> but you have only 32 bits for the integer itself
<sgnb> in memory, it is larger, but you don't have to care
<salierix> Oh.
<sgnb> (as asmanur said)
yminsky has quit []
<salierix> Why is "begin" sometimes used in if statements?
<sgnb> begin/end are like parentheses
<sgnb> "begin t end" is equivalent to "(t)"
<sgnb> you have to use it sometime because of priorities
<Yoric[DT]> Actually, "int" is platform-dependent.
<sgnb> for example : if a then b; c else d is parsed as "(if a then b); c else d" which is nonsense
<Yoric[DT]> It's 31 bits on 32 bit platforms, 63 bits on 64 bit platforms.
<sgnb> so you have to use if a then (b; c) else d
<Yoric[DT]> This "begin...end" stuff actually disappears in the revised syntax.
<salierix> sgnb, I don't see what the first part is trying to do even if it was legal.
<salierix> Oh, I understand.
<salierix> ; sequences things. I forgot.
<salierix> Does ocaml have support for efficient bit arrays?
yminsky has joined #ocaml
<sgnb> no
<sgnb> you mean, as in C ?
<salierix> What's revised syntax?
<salierix> Will ocaml ever support smp?
ulfdoz has quit [Read error: 60 (Operation timed out)]
yminsky has quit []
<flux> I suppose that depends on the definition of "support"; you can do it now with multiple processes, by using message passing (or in the extreme, shared memory)
<flux> judging from the comments of xavier leroy an actual two threads of ocaml code running concurrently in the same address space looks unlikely
ulfdoz has joined #ocaml
<salierix> What about that software transactional memory stuff? Think we'll ever get hardware support for that?
<flux> we well; look up 'htm' and 'hytm'
<flux> there is this an ocaml "threading" library that attempts to seamlessly traditional ocaml green threads and ocaml processes; infact I think it even supports such things across the network. for shared data stm is provided.
<flux> uh, "we will" even
<flux> yes
<salierix> How do I fork the running process in ocaml?
<flux> Unix.fork ()
<flux> you will need to provide your own communication though; the Marshal-module might be helpful
<flux> (one cool feature: you can pass closures too; limited so that the receiving and sending ends must be the same binary)
<salierix> What I want to do is embarrassingly parallel so I only need to return a result.
<flux> you could implement a function pmap
<flux> it has been implemented in this channel a few times..
<flux> one approach: for map inputs into file descriptors to processes that are performing the mapping, and the map those descriptors to what they feed you
<flux> s/for //
<flux> let fds = List.map (fun i -> let (i, o) = Unix.pipe () in if Unix.fork() = 0 then let v = i () in .. marshall to o.. else i) inputs in List.map (fun fd -> ..unmarshall fd, close it, join process..) fds
<flux> that will not work well when you have much more inputs than processors, though ;)
<salierix> I still have to learn more ocaml first though I think.
<flux> someone on the channel had a pmap that took that into account, perhaps he can join in..
<salierix> Is "Developing Applications With OCaml" still good?
<flux> I haven't read it, but it is constantly being praised
<salierix> It's a little old now though right?
<flux> right
<flux> but for the most part I doubt that matters; after having read that, one should be able to march through the manual too (which is always a good idea)
<salierix> OCaml for Scientists sure is expensive.
ita has joined #ocaml
ygrek has joined #ocaml
love-pingoo has joined #ocaml
<Yoric[DT]> salierix: there's support for SMP.
<Yoric[DT]> It's called CoThreads.
<Yoric[DT]> It's a library.
<flux> has anyone actually given a spin to the library? I haven't yet..
<Yoric[DT]> Not yet.
<Yoric[DT]> I'm planning to.
<flux> it isn't quite the same as using threads in, say, C, where you can split a large bitmap into two regions and have two threads manipulate their own regions?
<flux> atleast without separately making said bitmap into shared memory..
vpalle has joined #ocaml
<flux> but I guess having stm work with that library will be helpful
<salierix> Why is "1.0 == 1.0" false but "1 == 1" is true?
<flux> 1.0 are boxed: they are stored in memory as a pointer and the value at the end of the pointer
<flux> == compares those pointers
<salierix> Ah.
<flux> 1.0 allocates a new memory location for the value; such addresses will differ
<flux> you usually want to use =
<flux> using == is in my experience very rare, and needs some thought before using it..
<flux> it is perhaps a bit unfortunate that they picked two so similar operators..
<flux> also, = is to <> what == is to !=
<flux> that actually has bitten me atleast once :-o
<flux> (used != when I intended to use <>)
<salierix> Good to know.
buluca is now known as mac
pango_ has quit [Remote closed the connection]
seafoodX has quit []
mac is now known as buluca
pango_ has joined #ocaml
crathman has joined #ocaml
crathman has quit [Remote closed the connection]
<vorago> flux, i still ocaml is better hire than PHP
<vorago> flux, AFAIR they use == and === and I never know which is which.
<ita> === is comparison without implicit casting ? :-)
<vorago> i -> i think; hire -> here. Think, then type...
<bluestorm_> ocaml use =
jlouis has joined #ocaml
<bluestorm_> and keeps == for nasty things
<bluestorm_> it's useful to have a keyword that let you say "ok, you're going to blow yourself up because of that very line"
<vorago> Yes; but this is error prone for many developers which come from C/C++. So we are discussing approach.
<bluestorm_> Haskell have UnsafePerformIO for exactly the same purpose, i guess
<vorago> Hm.
<vorago> It could be something like /ignore/.
<ita> i have always found funny that array bound checking does not exist in c, as if the optimization was worth the resulting bugs
<vorago> I guess it's doable with camlp4.
robozni has joined #ocaml
tetsuo_ has joined #ocaml
<vorago> ita, gcc supports -fbounds-check
<vorago> Hm... wait a minute.
<ita> vorago: yeah, wait a minute :-)
<vorago> Only for fortran and java. ;s
Tetsuo has quit [Read error: 104 (Connection reset by peer)]
<vorago> So it really stinks. ;p
<bluestorm_> i'm not sure C really make sense to the "bound checking" idea anyway
<vorago> It does during debugging stages. But they can be more/less done with GDB.
<vorago> debugging and testing.
<ita> vorago: just like python, work with the debugger and do the compiler's work
<Yoric[DT]> IMO, array bounds checking is a typical case of "worse is better".
<Yoric[DT]> that is, the absence of array bounds checking is "worse is better".
<ita> Yoric[DT]: i suspect the compiler guys were too lazy to implement it
<Yoric[DT]> A very good reason to use OCaml (or Java, or C#...), but there is a whole category of people who consider that they're better without it.
<ita> compiling c is really hard
<Yoric[DT]> ita: well, that's part of "worse is better" :)
<Yoric[DT]> Are you kidding ?
<ita> no
<ita> compiling c is difficult
<Yoric[DT]> Unoptimized compilation of C looks trivial.
<ita> Yoric[DT]: haha, make a preprocessor for c first
<Yoric[DT]> I might be wrong, but it maps nearly directly to assembly language.
<ita> nope
<Yoric[DT]> What's difficult about the preprocessor ?
<Yoric[DT]> It's barely more than a lexer.
<vorago> Well it has some quirks.
<ita> the ## the # the macro rules and the other niceties
<ita> some quirks
<ita> yeah, that's everybody says
<Yoric[DT]> Well, maybe, but does it make C harder to compile than, say, OCaml ?
<ita> do it, and you will change your mind
<vorago> ##, #, ..., __FILE__, __LINE__, __FUNCTION__, other. But doable.
* Yoric[DT] admits he's no expert about compiling C.
<ita> yes, c is much harder to compile than ocaml
* Yoric[DT] usually compiles *to* C.
<bluestorm_> you could compile to OCaml too
<ita> first, lexing c is difficult (requires semantik info for the comments)
<bluestorm_> the prolog guy achieved convincing results
<Yoric[DT]> ita: what do you mean semantic info for the comments ?
<Yoric[DT]> bluestorm_: well, yes, I could, but then I would have to teach OCaml to my students first :)
<Yoric[DT]> Which is kind of difficult in 10 hours.
<bluestorm_> what are you teaching ?
<ita> Yoric[DT]: "/* \" */" /* hehe */
<Yoric[DT]> ita: it's just a widely complex regexp, isn't it ?
<ita> Yoric[DT]: no
<flux> ita, compiling c must be easy if that's the difficult part :)
<Yoric[DT]> ita: oh, because of the quotes.
<Yoric[DT]> Is that it ?
<Yoric[DT]> bluestorm_: depending on the days, Java, OCaml, mathematics for computer science, DBMSes and compilers.
<flux> now, compiling c++, on the other hand..
<Yoric[DT]> bluestorm_: compilers in one university, everything else in the other.
jlouis_ has quit [Read error: 110 (Connection timed out)]
<flux> or rather, the parsing part
<bluestorm_> hm
<bluestorm_> now i have a really funny question
<bluestorm_> do you get paid correctly ? :-'
<Yoric[DT]> bluestorm_: no :)
* Yoric[DT] reading ita's reference.
<Yoric[DT]> ita: erf.
<ita> Yoric[DT]: then, remember that c requires several passes over the code (trigraphs, comments, macros, then the lexing and parsing)
<ita> Yoric[DT]: erf ?
<flux> ita, btw, "(* \" *)" (* hehe *) is the ocaml case; I would expect that from all the languages with block comments..
robozni has quit ["leaving"]
<flux> if you wanted to target a new platform, you could just use an already-existing preprocessor
<Yoric[DT]> ita: I must admit I forgot what trigraphs are all about.
<flux> and I doubt implementing c preprocessor can be _that_ hard.. I don't know in which stage trigraphs should be handled, but I would expect they would be first
<Yoric[DT]> Well, ok, so C is a crap spec.
* Yoric[DT] returns to OCaml anyway :)
<ita> Yoric[DT]: ??= represents a #
<ita> Yoric[DT]: and for digraphs, %: represents a # too
<Yoric[DT]> I surrender, I surrender !
<salierix> Why do so few ocaml programmers seem to use objects?
<flux> I wouldn't strictly call those multiple passes anyway, because they can be performed at the same time
<Yoric[DT]> salierix: because 99% of the time, there's a better mechanism for doing the same thing with less code and faster results.
<ita> Yoric[DT]: look at a funny example: http://freehackers.org/~tnagy/main.c
<ita> Yoric[DT]: (reduces to #include "foo.h")
<ita> flux: i doubt that
<flux> ita, how much forward lookup does trigraphs or comments require?
<flux> or even macros
* Yoric[DT] returns to parse JavaScript, which *is* easier.
<ita> salierix: because functions can be embedded into other functions (closures and scopes), so where a hierarchy of classes is needed, a few nested functions do it much more elegantly
<ita> flux: the comments cannot be parsed until the trigraphs are transformed
<flux> ita, but really, can't that be built into the lexer itself?
<flux> although I suppose the definition of pass I used isn't quite universal.. I wonder what is, though
<flux> ita, and phase == stage?-)
<flux> ..or "pass"
<ita> flux: the lexer is not a lexer already, as it needs semantik info for lexing .. :-)
<ita> it is like xml, it looks all nice and simple until you have to actually parse it
<vorago> Hah, good comparison.
<flux> about xml: atleast how openoffice uses it.. it's fscking impenetrable!
<Yoric[DT]> XML never looked nice :)
<vorago> No wonder. if C is actually that complicated think how complicated is C++ compiler with their templates etc.
<vorago> No wonder that there actually exist _no_ full c++ standard implementation.
<vorago> Of comeau after implementing export keyword has full standard support... it would be one compiler only.
<ita> vorago: let's say that there are c++ programs that we cannot know if they compile or not
<flux> well, atleast there are multiple implementations. things are simple when there's only one implementation, and the specification is basically "what the implementation does" ;)
<flux> judging from the traffic in c++ newsgroups, those undefined corner cases, bring a lot of questions
<ita> (since c++ templates are turing-complete)
<vorago> Yeah. This is what I hate about them most.
<vorago> I've seen Functional-language done using C++ templates.
<vorago> List parsing etc.
<vorago> It looked horrible. I'd kill for using sth like this in projects.
<flux> :-)
<flux> templates in c++ are like another language in c++
<flux> I hear in D things might be better. and they're becoming slightly better in c++, too
<Yoric[DT]> Well, just like Camlp4.
<Yoric[DT]> Except, of course, that Camlp4 is OCaml :)
<ita> flux: they *are* another language (turing complete)
* Yoric[DT] has played (too much) with templates.
<flux> ita, well, technically they aren't, because it's part of C++ standard, no?-)
* Yoric[DT] has played with Java generics.
<vorago> But they generally should be functor - like. Not camlp4 like.
* Yoric[DT] has played with Camlp4.
<flux> yoric[dt], yes, but the mechanism how it works is quite different
* Yoric[DT] know which one he chooses.
<flux> yoric[dt], it would be fun if the type information was available in camlp4
<Yoric[DT]> flux: sure, Camlp4 works, templates don't.
<Yoric[DT]> flux: I'm sure there's a way to get that somehow.
<ita> flux: it is a sub-language within the language .. ? :-)
<Yoric[DT]> But you'd need several passes.
<Yoric[DT]> camlp4 -> ocaml -i -> camlp4
<flux> templates - and overloading - in right hands can result in some beautiful and concise code
<flux> in wrong hands.. well ;)
<vorago> Preprocessor shouldn't have unlimited power. ;p
<flux> vorago, like camlp4?-)
<ita> vorago: double negation ?
<flux> or lisp..
pango_ has quit [Remote closed the connection]
<vorago> Hm, right. I meant C++ templates have too much power. Recursive calling and creating templates for compile-time calculation I guess should not take place.
<flux> the capability to generate code based on types of expressions is quite a powerful feature
<vorago> Is it possible (as I don't know camlp4) to do recursive camlp4 calls?
<bluestorm_> "camlp4 calls" ?
<Yoric[DT]> vorago: probably. Depends on what you mean by "camlp4 calls".
<Yoric[DT]> Camlp4 *is* OCaml.
<Yoric[DT]> So, yeah, you have recursivity.
<Yoric[DT]> You use OCaml to pre-process OCaml.
<Yoric[DT]> (just like Lisp)
<Yoric[DT]> Somewhat as what Ruby or Python allow, except for Ruby or Python, it's during execution, while for OCaml it's during compilation.
<bluestorm_> hm
<bluestorm_> but camlp4 is purely syntaxic
<vorago> Hm. C++ templates are used for things which they won't intended for.
<bluestorm_> while reflexion and meta-programming are based on semantic properties
<vorago> camlp4 I guess is more generic.
pango_ has joined #ocaml
<Yoric[DT]> bluestorm_: fair enough.
<Yoric[DT]> Still an apt comparison, I believe.
<flux> I don't buy the reason "x wasn't intended for y" for explaining why doing y is bad. it is not that uncommon that things will find a wider range of use than what the author originally visioned.
<bluestorm_> flux:
<bluestorm_> in the templates case
<flux> of course, sometimes I buy that: I wouldn't want to see a real application written in brainfuck :-)
<bluestorm_> i think that means the original complexity was not in control
<bluestorm_> "wider range" is a benefit from solid foundations
<bluestorm_> "WTF ranges" mean the original design maybe wasn't that careful
<flux> I've heard that the explanation why LaTeX is turing-complete is because many things needed to be described, and it would have been more (much more?) difficult to devise a language that would provide all that - instead of going in and just make sure everything you want is possible, by going to turing completeness
<flux> actually, read that just a few days back, perhaps a link from reddit..
<flux> for programming languages.. well I suppose there were even at the time c++ was designed examples or working solutions for that particular domain
<flux> but atleast the implementations so far haven't (before mlton?) haven't been quite 'c-like'; that is, if you want to really construct special-case code for all types etc
* Yoric[DT] assumes the design of C++ started with the words "Cthulhu f'taghn".
<vorago> flux, sure but it's even more implementation defined then. Like,
<ita> Yoric[DT]: jejeje
<flux> sml apparently came around at 1990
<vorago> flux, some calculations need recursive use of templates. Depth of recursion depends only on compiler,
<vorago> flux, and still is awful.
<flux> vorago, yeah, it's nice to have compilations always terminate
<flux> vorago, but those cases rarely come up. they might, if you use some template combinator library for doing something fun, though..
<vorago> flux, well; there are plenty of sites on how to do 'template metaprogramming'. People learn to use it.
<flux> I'm quite sure compilers need to support a certain level of template instantiations also.. although I recall some boost code suggests the user to up the number a bit ;)
<flux> could sml type system have been retrofitted into c (in the form of c++ml or something), while keeping backwards compatibility and maintaining the things a c-programmer expects? perhaps.. perhaps I would need to buy some book from stroustrup to see what he was thinking ;)
<vorago> ;d
<Yoric[DT]> You know what they say about mad arab poets :)
<flux> although then again, haskell type classes are in practice more powerful than modules, although modules would be nice there too - and c++ templates already cover that (well, mostly)
tetsuo_ has quit ["Leaving"]
<flux> c++ still has quite a lot of verbosity. I wonder what closures and type-inference would do to that..
* Yoric[DT] is still trying to understand the difference between type classes and modules + functors.
<flux> yoric[dt], have you read the paper on that? [I haven't]
<bluestorm_> flux: wich one ?
<ita> flux: c++09 haha!
<ita> bluestorm_: no permissions to access that file
<flux> ita, only partial type inference, no closures.. but gc ;)
<flux> bluestorm_, I think I mean this: http://www.cis.upenn.edu/~bcpierce/FOOL/papers9/shields.pdf
<flux> google:haskell type classes ocaml modules
<Yoric[DT]> flux: there's a paper on that subject ?
<Yoric[DT]> Ok.
<Yoric[DT]> I'll read it.
<Yoric[DT]> Thanks.
* Yoric[DT] notes that Pierce is *everywhere*.
<flux> :)
<bluestorm_> i'd be interested in a paper comparing modules/functors and type classes on practical grounds
<bluestorm_> it seems admitted that they are of equivalent expressivity
<bluestorm_> but i still haven't founded a concise way to express monads in OCaml, for example
<Yoric[DT]> type classes seem easier to use, plus they allow a form of operator / function overloading, which does make them much nicer IMO.
<bluestorm_> (the Deriving project is doing interesting things)
<flux> has gocaml advanced? I wonder what is its relation to type classes..
Abo-Marwan91 has quit [Remote closed the connection]
<flux> on the surface it doesn't seem to be the same thing, though
* Yoric[DT] thinks he heard that gocaml was dropped.
screwt898 has quit [Remote closed the connection]
<ita> bluestorm_: monads in caml ? try zith ?
<bluestorm_> tssk
<Yoric[DT]> bluestorm_: what's Deriving ?
<flux> ah, the name was gcaml
<Yoric[DT]> The proble, iirc, is that G'Caml maintains a run-time type.
<Yoric[DT]> IIRC, type classes don't.
<flux> don't they?
<Yoric[DT]> You have to manually specify the type, though.
<flux> there is atleast dictionary passing going on
<Yoric[DT]> But that doesn't look like a major problem for me.
<Yoric[DT]> I might be wrong, though, I'm no Haskell pro.
<flux> let's say you have a function do_show : Show a => a -> String do_show a = show a (this might not be valid, I haven't looked at haskell for quite a while)
<flux> if that function is to be compiled only once, some runtime information must be passed to that function for that to work..
<bluestorm_> iirc Haskell sometimes use runtime dictionnary, and sometimes doesn't
<flux> and it is my understanding that it doesn't generate one do_show for each type
<flux> like c++ would..
<flux> deriving looks cool - it just feels a bit redundant to have to point out the types explicitly.. what whatcha gonna do.
<Yoric[DT]> Operator overloading would be nice.
<vorago> In OCaml/
<flux> some of the examples on that deriving intro look like magic :)
<bluestorm_> because there is some camlp4 magic under the hood i guess
<bluestorm_> (although i haven't looked into the code yet)
<bluestorm_> yallop is doing interesting things
<bluestorm_> his other project on Google Code (click on his name to see the url) is a little camlp4 extension wich looks really nice
<flux> now only if someone wrote a campl4 type inference module.. ;-)
<Yoric[DT]> :)
<bluestorm_> flux: camlp4 type inference ?
<Yoric[DT]> The problem is that you'd need a way to extend that type inference.
<flux> and ocaml would go to the undecidable land too! (I guess)
<bluestorm_> hm
<flux> bluestorm_, you know, like determining types of expressions at camlp4 stage
<bluestorm_> err
<bluestorm_> looks like a strange idea
<flux> which can be tricky as the code could change the types
<bluestorm_> and very complex too
<bluestorm_> are you not looking for a generic generic programming solution like MetaOCaml ?
<flux> but that would make those pesky explicit type annotations go away.. Show.show<int list> [1; 2; 3]
<flux> I must admit I haven't taken a look at MetaOCaml
<bluestorm_> i've seen promising things concerning MetaOCaml integration with Coq somehow
<bluestorm_> (at the type level)
<flux> coq.. now that's something I would be interested in learning, but haven't found the time
jenny2 has joined #ocaml
<flux> ah yes, concoqtion, I saw it earlier
<flux> or is that just one example of that integaration
Abo-Marwan has joined #ocaml
jenny2 has quit [Client Quit]
<vorago> How is camlp4 related to ocamlyacc and ocamllex?
<flux> it isn't
<vorago> Ok.
<vorago> Just like I thought.
screwt8 has joined #ocaml
<vorago> It would be queer; I've written two, three parsers and still have no idea about camlp4.
<bluestorm_> flux: concoqtion is the thing i was thinking at
<bluestorm_> i read an interesting paper about it
<bluestorm_> but it's quite theoretic for me
<flux> hah, this is something fun I found just now: http://prover.cs.ru.nl/
<flux> now all I need to do is learn it ;)
<vorago> online prover.
<vorago> Hmh.
<hcarty> Is there a way to #use multiple files in the toplevel after loading a camlp4 extension?
<hcarty> A first #use works ok, but a second gives "I/O error: Bad file descriptor"
<hcarty> Which makes testing things in the toplevel a pain
<salierix> Should I use the revised syntax or not?
<bluestorm_> salierix: what for ?
<bluestorm_> ita: i'm interested in monads for the idea of behavioral genericity
<bluestorm_> not precisely error reporting or I/O
<ita> bluestorm_: yes, i understand
<flux> does metaocaml bring anything else except performance?
<flux> hm, indexed types were mentioned.. so I suppose yes
<flux> perhaps I need to read the whitepaper through first, not ask questions during reading it ;)
<salierix> bluestorm_, in general.
asmanur has quit [Connection timed out]
<hcarty> salierix: It's somewhat of a personal choice. The original syntax is used more often, but there are tools to automatically convert the syntaxes back and forth
<bluestorm_> i considered the choice this summer
asmanur has joined #ocaml
<bluestorm_> and i concluded that the best thing to do syntax-wise would be to use my own personal syntax
<bluestorm_> (a mix from the standard and revised one)
<bluestorm_> then i got lazy and stuck with the standard one
<bluestorm_> moreover, this raises question about inter-developpers communication and so on
<bluestorm_> salierix: you should try to use it for a while, and see
<bluestorm_> i used it for camlp4 extension, and while i think a part of it is really nice, some bits are heavy to use
<bluestorm_> (i'd say the [ ] on pattern matching and the different things to do with ; )
<salierix> What's the dirrence between camlp4 and camlp5?
<bluestorm_> for the 3.10, camlp4 got a partial rewrite
<bluestorm_> it's incompatible with former versions
<bluestorm_> the original author of camlp4 is not happy with these changes
<bluestorm_> so he "forked" : took the old camlp4 and created camlp5
<bluestorm_> the confusing thing is, camlp5 is closer to 3.09 camlp4 than 3.10 camlp4 is
<flux> hm, the metaocaml white paper doesn't touch the capability to extend ocaml type system.. I wonder what concoqtion does, then. extends metaocaml also?
<flux> ..like it says in the front page :-)
Smerdyakov has quit ["Leaving"]
<bluestorm_> :p
<bluestorm_> (before actually trying to learn coq iirc)
<bluestorm_> didn't understand everything, but was interested and excited about it :-'
<flux> that's apparently the actual paper
<flux> these are the slides
<bluestorm_> i don't like reading slides online
<flux> perhaps easier to read; perhaps void of content ;)
<flux> it's only 19 pages, serves as a prelude to the paper I suppose
love-pingoo has quit ["Connection reset by pear"]
<bluestorm_> hum
<flux> right.. the actual paper is only ten pages - but the font size is very different ;)
<flux> the first page having 848 words
<Yoric[DT]> salierix: I've just switched to revised syntax, and I'm currently quite happy about it.
<bluestorm_> Yoric[DT]: don't you think [ ] on matching are a little bit painful ?
Smerdyakov has joined #ocaml
<bluestorm_> i use function | foo -> bar | baz -> foobar
<bluestorm_> (with newline before each | of course)
<bluestorm_> [ ] make the whole thing asymmetrical
<Yoric[DT]> bluestorm_: as I have many cases of nested matching, it saves me from irregular begin...end.
<bluestorm_> hm
<bluestorm_> i use ( ) for nested matching
<bluestorm_> and i rarely need to nest pattern
<bluestorm_> most of the time i get the inner pattern out in an auxiliary function
<Yoric[DT]> In my current project, this would make things even more irregular.
<bluestorm_> (i dislike having tons of code between two patterns anyway)
<bluestorm_> what i really like about revised syntax is the curryfied syntax for constructors and functors
<Yoric[DT]> And I personally prefer match expr with [ ] to (match expr with ) for pattern-matching.
<bluestorm_> (concerning types i still find that a bit odd but...)
<Yoric[DT]> Yeah, the currifyed syntax is nice.
<bluestorm_> and the "where" is nice too, although it is much less useful than it was in caml light
<Yoric[DT]> Changing the associativity of types should make things easier to explain to students.
<bluestorm_> because of that ambiguity restriction
<bluestorm_> Yoric[DT]: i feel "int list" much more natural to read than "list int"
* Yoric[DT] only used "where" once or twice so never realized it had been removed from OCaml.
<bluestorm_> Haskell people use "where" everytime
<bluestorm_> and it's rather elegant
<Yoric[DT]> bluestorm_: well, yes, but then, it's closer to what happens in Java/C#.
<bluestorm_> maybe
<bluestorm_> and it match de construction order
<bluestorm_> s/de/the/
<Yoric[DT]> Plus I think it's less confusing to have a list list list option 'a than an 'a option list list list...
<Yoric[DT]> and to explain how the compiler understands that.
<bluestorm_> hm
psnively has joined #ocaml
<bluestorm_> i find it more confusing, but maybe it's a matter of taste
<Yoric[DT]> Until now, it was along the lines of "everything is left-associative except types and sometimes ::".
<bluestorm_> "'a option list" makes sense as an english expression, doesn't it ?
<Yoric[DT]> Not as a French expression, though :)
<bluestorm_> i try think english while programming
<bluestorm_> +to
<Yoric[DT]> Well, me too, but my students don't.
<bluestorm_> hm
<bluestorm_> i'm not sure teaching revised syntax to your students would be a good idea
<Yoric[DT]> I'm still pondering.
<Yoric[DT]> I *think* I'm going to teach it.
<Yoric[DT]> Things are slightly more regular.
<Yoric[DT]> The syntax relies slightly less on subtleties.
<bluestorm_> wouldn't they have problem with exterior OCaml sources then ?
<bluestorm_> i still remember the first time i discovered the without-;; way to write
<Yoric[DT]> Unless I'm mistaken, they can also rely on list expressions with the revised syntax.
<bluestorm_> was slightly shocked :D
<Yoric[DT]> s/list expressions/list comprehension/
<Yoric[DT]> (I haven't checked that particular point yet)
<Yoric[DT]> :)
<bluestorm_> hm, i have not seen any list comprehension
<bluestorm_> but they exists as a camlp4 extension
Torment has joined #ocaml
* Yoric[DT] needs to find a documentation about that.
<bluestorm_> hm
<bluestorm_> thanks to you, i just remembered than the use of :: in the revised syntax is awful
<bluestorm_> [a::[b::[c::d]]]
<bluestorm_> urg
<Yoric[DT]> Well, or [a::b::c::d]
<bluestorm_> and it still can't read [x; y; z :: t]
<bluestorm_> [a::b::c::d] won't work
<Yoric[DT]> Oh, maybe [a;b;c::d]
<bluestorm_> who can read that ?
<bluestorm_> plus i put :: everywhere
<bluestorm_> with revised syntax, the very simple recursive list function gets tons of [ and ] everywhere :p
<Yoric[DT]> Fair enough.
buluca has quit [No route to host]
Smerdyakov has quit ["Leaving"]
bluestorm_ has quit [Remote closed the connection]
bluestorm_ has joined #ocaml
Tetsuo has joined #ocaml
tetsuo_ has joined #ocaml
tetsuo_ has quit [Client Quit]
Jedai has quit [Read error: 110 (Connection timed out)]
Smerdyakov has joined #ocaml
Tetsuo has quit ["Leaving"]
ita has quit [Remote closed the connection]
asmanur has quit [Remote closed the connection]
ita has joined #ocaml
<flux> hmm, building ocamlrt (from code.google.com), omake says "ocamldep-omake: unknown option `-syntax'", omake being version 0.9.8.5
<flux> any suggestions?
<Yoric[DT]> Are there any specialists of ocamlbuild around ?
<Yoric[DT]> flux: I can just say that I compiled it a while ago without problems.
<flux> the one from darcs repository apparently has compiled for me too, but that doesn't
<flux> apparently the switch -syntax camlp4o is an old one - gotta compare to the darcs version..
<flux> sigh, the structure is entirely different
<flux> ah, I'm looking at some obsolete stuff apparently, last changes year 2006 :)
<flux> the darcs repository is apparently up-to-date; changes this month
seafood_ has joined #ocaml
vpalle_ has joined #ocaml
seafood_ has quit []
vpalle has quit [Read error: 110 (Connection timed out)]
jlouis_ has joined #ocaml
Demitar has joined #ocaml
Thunderfoot has joined #ocaml
jlouis has quit [Connection timed out]
Demitar has quit [Read error: 110 (Connection timed out)]
Demitar has joined #ocaml
ygrek has quit [Remote closed the connection]
p_a_u_l_ has joined #ocaml
<vorago> Simple simulation. Base force control with 'a' and 'd'.
<vorago> I've last 6 seconds of simulation time so far. ;p
<vorago> Nice game.
<vorago> There's a model description in physics_complete.pdf for interested. ;p
<pango_> (a shortcut for refresh := !refresh + 1 is incr refresh)
<pango_> and I found equilibrium (or very near shot), so I'm over 2 minutes now ;)
salierix has quit ["Leaving"]
<tristram> how do I get it running ? it complains Reference to undefined global `Graphics'; do I need a specific package ?
<pango_> ocamlopt -o Simul graphics.cmxa unix.cmxa Simul.ml
ita has quit ["Hasta luego!"]
<tristram> thanks !
Yoric[DT] has quit ["Ex-Chat"]
<pango_> http://img455.imageshack.us/my.php?image=simuloq0.png (running for over 5 minutes... slowly falling)
seafood_ has joined #ocaml
<vorago> pango_, thanks.
<vorago> ;D
<vorago> I'd like to create a robot with AVR Atmel which would be able to balance itself.
<vorago> So that's why I've written this simulation.
<pango_> 379.75s. Beat that ;)
<vorago> With timeres 0.0005?
<vorago> I doubt I could. ;p
Thunderfoot has quit []
<pango_> didn't change anything to the source
<vorago> So 0.0005.
<vorago> It's not well timed.
<vorago> But it should be more/less the same on all fast computers.
<vorago> In line 187 you've got simulation parameters.
<pango_> Unix.select only guarantee is that it will take _at least_ the requested time
<vorago> Sure. And I had quite big problem.
<vorago> select was broken each time an event occured.
<pango_> but it's free to use more, depending on OS scheduler,...
<vorago> So this is why there's a recursive function for sleeping.
<vorago> I guess it would be better to use lablgl + gtk. But it was supposed to be simple.
buluca has joined #ocaml
<vorago> I guess it's harder with switched h_mass and l_mass
bluestorm_ has quit [Remote closed the connection]
<pango_> it should be more accurate to measure the deltat between display refreshes and use that to update parameters
<pango_> rather than trying to enforce a static timeres (you won't get accurate 0.0005 pauses unless the kernel is compiled with HZ >= 2000, which is still an unusual setup those days)
<vorago> Sure I wasn't thinking about real-time display.
<vorago> Rather about more/less accurate simulation.
<pango_> (just checked that stock Debian kernel uses CONFIG_HZ_250)
seafood_ has quit []
<vorago> I wonder. It would be rather hard to calculate in real-time model situation at time t
<vorago> For any t given
buluca has quit [Read error: 113 (No route to host)]
p_a_u_l_ has quit ["leaving"]
p_a_u_l has joined #ocaml
p_a_u_l is now known as stbrn
stbrn has quit [Client Quit]
smimou has joined #ocaml
jeremiah has joined #ocaml
jeremiah has quit [Remote closed the connection]