<palomer>
but a lot of this can be done with List.iter, List.map and List.fold_left
<thelema>
but if you wanted to write it out, palomer's version reads much more naturally
<hjpark>
x::xs
<hjpark>
yeah, i got it.
<palomer>
x::xs is (cons x xs)
<thelema>
but it also works in patterns.
<palomer>
thelema, they're ignoring my bug:(
<hjpark>
so, match expression have to have same type, but i want to make other type.
<palomer>
"1" -> game (make_rnd_deck card_deck); print_endline "Bye" is probably what you want
threeve has quit []
<hjpark>
but, it still said about type error
<hjpark>
"This expression has type unit but is here used with type int"
<thelema>
palomer: your bug is likely just a result of overflowing the event queue. My bug with the program crashing might be fixable, but probably has to do with stressing the GTK memory management.
<palomer>
thelema, I'm running a program which creates tons of widgets every 10 seconds or so
<thelema>
1: new game, 1: about blackjack, 2: exit?
<palomer>
thelema, and I think that an event has to finish before the timer starts again
<hjpark>
like that.
<thelema>
palomer: that event has to finish before the next event will start, but the timer will queue more events if the time for them to happen has passed.
<hjpark>
idiot code like this | "2" -> print_endline "Exit!\n";10 works;
<thelema>
palomer: it takes my computer about 13-15 seconds to complete one widget-add/remove loop in the C code.
<thelema>
hjpark: why is game returning an int?
<palomer>
thelema, I can write other code that creates a ton of widget every 10 minutes
<palomer>
and it'll still take up more and more memory
<thelema>
palomer: show me the graph of memory usage vs. time for a 1 minute timeout.
<hjpark>
hmm..
<palomer>
lemme write my test case
<thelema>
hjpark: game returns whatever game_hit / game_stand return.
<mfp>
downvoted rather aggressively (2 downvotes a minute after posting) for some reason :-?
<tsuyoshi>
well I don't know about you.. but I downvote everything that's about python or java
<tsuyoshi>
maybe lots of python and java people are downvoting everything about ocaml
<mfp>
and we don't have the #haskell vote power to keep links afloat, let alone push them to the top
<tsuyoshi>
why not put it in ocaml rather than programming?
pango has quit [Remote closed the connection]
<velco>
upvoting it now :P
pango has joined #ocaml
<mfp>
"nobody" is subscribed to the OCaml reddit; I'd bet more Caml riders will see it in programming, even if downvoted
<velco>
I downvote everything retarded
<velco>
i.e. everyone who does not agree with me :P
<mfp>
also, it's not like there are too many OCaml links in programming
<tsuyoshi>
well yeah.. all the ocaml stuff gets downvoted out of existence
<mfp>
I don't mean only the top page, but in absolute terms too
<mfp>
so it's not like we're pushing OCaml aggressively on reddit the way it is being done with Haskell
Amorphous has quit [Connection timed out]
Amorphous has joined #ocaml
bluestorm has joined #ocaml
poulet has joined #ocaml
willb has joined #ocaml
Camarade_Tux has joined #ocaml
willb has quit [kornbluth.freenode.net irc.freenode.net]
Amorphous has quit [kornbluth.freenode.net irc.freenode.net]
GustNG has quit [kornbluth.freenode.net irc.freenode.net]
sporkmonger has quit [kornbluth.freenode.net irc.freenode.net]
Associat0r has quit [kornbluth.freenode.net irc.freenode.net]
_zack has quit [kornbluth.freenode.net irc.freenode.net]
xevz has quit [kornbluth.freenode.net irc.freenode.net]
ppsmimou has quit [kornbluth.freenode.net irc.freenode.net]
gim has quit [kornbluth.freenode.net irc.freenode.net]
mfp has quit [kornbluth.freenode.net irc.freenode.net]
willb has joined #ocaml
Amorphous has joined #ocaml
GustNG has joined #ocaml
sporkmonger has joined #ocaml
Associat0r has joined #ocaml
_zack has joined #ocaml
xevz has joined #ocaml
gim has joined #ocaml
mfp has joined #ocaml
ppsmimou has joined #ocaml
GustNG1 has joined #ocaml
<flux>
if I wanted to determine whether a piece of code has "leaked" memory (some global state obviously) when going from point a to point b, would it be sufficient to run Gc.full_major () and compare the values of Gc.stat.live_words before and after running the code under testing?
Sylvestr1 has joined #ocaml
GustNG has quit [Connection timed out]
Palace_Chan has joined #ocaml
GustNG1 has quit [kornbluth.freenode.net irc.freenode.net]
_zack has quit [kornbluth.freenode.net irc.freenode.net]
ppsmimou has quit [kornbluth.freenode.net irc.freenode.net]
Associat0r has quit [kornbluth.freenode.net irc.freenode.net]
gim has quit [kornbluth.freenode.net irc.freenode.net]
mfp has quit [kornbluth.freenode.net irc.freenode.net]
willb has quit [kornbluth.freenode.net irc.freenode.net]
sporkmonger has quit [kornbluth.freenode.net irc.freenode.net]
xevz has quit [kornbluth.freenode.net irc.freenode.net]
Amorphous has quit [kornbluth.freenode.net irc.freenode.net]
GustNG1 has joined #ocaml
willb has joined #ocaml
Amorphous has joined #ocaml
sporkmonger has joined #ocaml
Associat0r has joined #ocaml
_zack has joined #ocaml
xevz has joined #ocaml
gim has joined #ocaml
mfp has joined #ocaml
ppsmimou has joined #ocaml
Palace_Chan has quit [Client Quit]
Fullma has joined #ocaml
hjpark` has joined #ocaml
<Yoric[DT]>
_zack: ping
<_zack>
Yoric[DT]: pong
<Yoric[DT]>
I'm currently browsing through your code.
<Yoric[DT]>
Mind if I ask questions as I browse?
<_zack>
sure, go ahead
<Yoric[DT]>
First what is this directory common/?
<_zack>
I believe it is explained in the README
<Yoric[DT]>
mmmhhhh
* Yoric[DT]
doesn't see a README.
<_zack>
but the idea is that it contains code shared by other libs
<_zack>
uh?
<Yoric[DT]>
Oh, here it is.
<_zack>
src/libs/README
<Yoric[DT]>
ok
<_zack>
I believe that each time we will integrate different libs that need to be abstracted over
<_zack>
then we will have some glue which does not belong to any specific lib
<_zack>
my idea is to put that stuff in common/
<_zack>
of course that choice (as every other choice I've mode) is just a *proposition*
<Yoric[DT]>
Sure.
<Yoric[DT]>
Sounds like a good idea.
<_zack>
cool
<_zack>
another choice I didn't mention via email is to have GZip/BZ2/.. _outside_ Compress
<_zack>
I kinda fear that the module hierarchi of batteries is becoming too deep ...
Linktim has joined #ocaml
<Yoric[DT]>
Well, that's a fear of mine, too.
<Yoric[DT]>
I think that's everybody's fear, actually.
<_zack>
for example, do we need System ?
<_zack>
can't we just splice its content one level up?
<Yoric[DT]>
Where would you put Unix, Sys, upcoming shell stuff, etc.
<Yoric[DT]>
?
<Yoric[DT]>
I concur that IO might be better off a little higher.
<Yoric[DT]>
But I'm not sure about the rest.
<_zack>
well, have a look at the python stdlib (which is a good lib IMO, in spite of the language :) ), the big classes are all top-level, and they don't have clashes
<_zack>
I don't know about haskell lib, but it's worth having a look too (you probably already did that)
<Yoric[DT]>
Well, the current hierarchy is somewhat inspired from Haskell.
<_zack>
ok, I'll stick my foot in my mouth next time :)
<Yoric[DT]>
:)
<Yoric[DT]>
I'm looking at extGZip.mli and I have a few remarks.
<_zack>
yup
<Yoric[DT]>
1. The module name is not completely consistent (I know I'm guilty of the same kind of things, but well, that doesn't count:))
hjpark has quit [Read error: 110 (Connection timed out)]
<_zack>
np about that, tell me the needed rename, and I'll implement it
<Yoric[DT]>
That is, we use modules [ExtStuff]
<Yoric[DT]>
when there's a module [Stuff] we're masking
<Yoric[DT]>
in which case the replacement for [ExtStuff] is actually [ExtStuff.Stuff] .
<_zack>
fair enough, what do you propose then?
<Yoric[DT]>
That's not quite necessary but it's inherited from Extlib.
pango has quit [Remote closed the connection]
<Yoric[DT]>
Well, would it hurt compilation if you just called it [GZip]?
<_zack>
it will clash with the higher-level module, doesn't it?
<_zack>
extGzip is the low-level module
<_zack>
while gZip is the high-level one
<Yoric[DT]>
Ok.
<Yoric[DT]>
In that case, just make it a module [ExtGzip] containing a module [Gzip].
<Yoric[DT]>
You'll need to add the necessary comments, as usual.
<_zack>
note that it does not extend Camlzip's Gzip, in fact it masks some of its method if open together with it
<_zack>
wait
<_zack>
that module is not meant to be used by the final user
<Yoric[DT]>
Which one?
<_zack>
the current extGzip
<Yoric[DT]>
What is supposed to be used?
<_zack>
gZip
<_zack>
in the same dir
Sylvestr1 has quit ["leaving"]
itewsh has joined #ocaml
<Yoric[DT]>
Ah, ok.
<Yoric[DT]>
What's the point of [ExtGzip], then?
<_zack>
well, code layering?
<Yoric[DT]>
ok
* Yoric[DT]
has only looked at the .mli so far.
<_zack>
it is just the equivalent of Camlzip's Gzip module, but we can't reuse it
<_zack>
hence we develop our own
<_zack>
but extra stuff is added elsewhere
<_zack>
YMMV
<_zack>
but that probably confirms that the name is not well-chosen, feel free to propose something different
<Yoric[DT]>
Maybe [InnerGZip] ?
<_zack>
yep, makes sense
* _zack
creates a TODO list
<Yoric[DT]>
We'll still need to find a way to normalize types.
<Yoric[DT]>
But that's another issue.
<Yoric[DT]>
2. Quite minor quibble: in .mli, we tend to start our comments at {6 ... } rather than at {1 ... } .
<_zack>
I'm all hears :)
<_zack>
ok
<Yoric[DT]>
Iirc, we're following the base library on this.
<Yoric[DT]>
If not, then there's no good reason :)
<_zack>
do you have a reference file to point me to?
<_zack>
or maybe you want to change directly the .mli, and I'll learn for the next time? :-P
<Yoric[DT]>
Say IO.mli .
<_zack>
ok, noted
<Yoric[DT]>
For that, I'll need to understand my way around Git branches.
<Yoric[DT]>
Which isn't done yet :)
<_zack>
ok, a suggestion on that
<_zack>
git push at the beginning can be annoying
<_zack>
always try first with --dry-run + git diff on the returned range
<_zack>
helps avoiding the mistakes I made months ago elsewhere ;)
LeCamarade has joined #ocaml
pango has joined #ocaml
* Yoric[DT]
will try and remember that.
<_zack>
regarding the commens
<_zack>
is it ok to put then in gZip.mli
<_zack>
or they should be put elsewhere?
* _zack
is still astonished by the ocamldoc magics implemented in batteries
<Yoric[DT]>
gZip.mli is the right place.
<_zack>
k
* Yoric[DT]
did spend some time working on that custom generator :)
<Yoric[DT]>
Oh, and don't forget @author .
<_zack>
I presume I'll find it in IO.mli as well, right?
<Yoric[DT]>
Yep.
<Yoric[DT]>
Barring any error of mine, that is :)
<_zack>
eh
<Yoric[DT]>
Now on to
<_zack>
while we are at it, you don't use @param / @raise or am I mistaken?
<Yoric[DT]>
No good reason for that.
<Yoric[DT]>
Don't hesitate to use them.
<Yoric[DT]>
I should use them.
<_zack>
ok
<Yoric[DT]>
3. Don't [include] interfaces in a .mli .
<Yoric[DT]>
That will screw up the documentation generator.
<_zack>
oh, that's too bad
<Yoric[DT]>
In a future version, I'll try and copy that.
<_zack>
but then what do you propose?
<_zack>
leave the commented interface in common.mli?
<_zack>
and put an uncommented version in gZip.mli?
* Yoric[DT]
has no better suggestion than copying and pasting.
<_zack>
argh
<Yoric[DT]>
Sorry, being called afk.
* Yoric[DT]
will try and return in about 1/2h.
<_zack>
comments will go out of sync in half a second
<_zack>
see ya
* _zack
goes back to releasing camlbz2
poulet has quit []
* Yoric[DT]
is actually back.
<_zack>
ok
<Yoric[DT]>
No release?
<_zack>
yes, pre-release done, but the boring part is writing the homepage, discussing batteries is more fun :-P
<Yoric[DT]>
:)
<bluestorm>
regarding the "include" problem, maybe Camlp4Macros's INCLUDE could help ?
<Yoric[DT]>
bluestorm: good idea.
<_zack>
sounds cool
<bluestorm>
i actually think it's ugly but, well, ocamldoc was there first
<_zack>
bluestorm: if it does what I mean it is not that ugly, it is just a level of metraprogramming
<Yoric[DT]>
4. From this point in the code, use [IO.input]/[IO.output] rather than [InnerIO.input]/[InnerIO.output].
<_zack>
s/metra/meta/
<_zack>
Yoric[DT]: I had problem with that, but maybe they god solved thanks to thelema suggestion of yesterday evening
<Yoric[DT]>
Until we have found a way to completely hide [InnerIO], that's as good as we can get to a readable function type.
<_zack>
noted as well
poulet has joined #ocaml
* Yoric[DT]
will now take a look at the .ml .
* _zack
fills like back to school :)
<Yoric[DT]>
:)
<Yoric[DT]>
gZip.ml: don't forget the header comments.
<_zack>
uh?
<Yoric[DT]>
Well, blame yourself, you wanted a review:)
<_zack>
lol
<Yoric[DT]>
_zack: well, you know, "this code is released under LGPL + Linking Exception", all that.
<_zack>
they are there
<Yoric[DT]>
They are?
<_zack>
but probably you are looking at the tagged version
<Yoric[DT]>
Well, don't forget to add @author in the .ml, as mentioned before.
<_zack>
sure, noted
<bluestorm>
general, non-batteries question : without help from caml, what would you guess the type of "let a, b = [], [] in (a=b,a,b)" is ?
<_zack>
Yoric[DT]: now that (if) we are convinced that it is not worth generalizing Camlzip's interface, the comment at the beginning of gZip.ml can be toned down
<_zack>
IOW it is no longer a "ugly hack" :-D
<Yoric[DT]>
:)
<Yoric[DT]>
I concur with the toning down :)
<Yoric[DT]>
In extGzip.ml, I'd add a comment to detail what kind of buffer is given size with [buffer_size].
<Yoric[DT]>
I wonder if [Compress.Error] is a good exception.
<Yoric[DT]>
I wonder if [Compress.Error] is a good exception name, that is.
<_zack>
I'm open to suggestions :)
<Yoric[DT]>
Well, in [ExtString], we have [Invalid_string], in [IO] it's [Input_closed]/[Output_closed], etc.
<Yoric[DT]>
In other words the name of the exception (and not its module) gives its meaning.
<Yoric[DT]>
So perhaps [Compress_error]?
<_zack>
ok
<mfp>
bluestorm: fighting the relaxed value restriction? one of bool * '_a list * '_a list or bool * 'a list * 'a list ? (I pick the former)
<flux>
btw, weak hash tables is something that'd be nice to see in batteries ;-). (but perhaps the bts is better for wish list entries)
<_zack>
by the way is "Decompress" convincing English?
<_zack>
maybe Uncompress is better?
<mfp>
ooh bool * 'a list * 'b list = (true, [], [])
<_zack>
or even Inflate/Deflate, but I've never liked the two
<mfp>
how come a = b didn't at least unify the 'a?
<flux>
_zack, IMO it's not a good idea to change terminology when binding to an existing library (with established terminology)
<Yoric[DT]>
Fair enough.
gdmfsob has quit [Read error: 110 (Connection timed out)]
<_zack>
flux: that's easy if you are binding *one* library
<bluestorm>
mfp: i can hardly sleep since i discovered that
<_zack>
but here we are talking about abstacting over several compression libraries
<_zack>
it is not granted that they share terminology
<flux>
gzip manual page talks about compressing and expanding. but, I'm not sure I like it :)
hjpark` has quit [Connection timed out]
<_zack>
bzip2 is {de,}compress
Linktim has quit [Read error: 110 (Connection timed out)]
<bluestorm>
(the worst part is that i discovered it while implementing my own type inference code; I spent quite some hours tracking the bug)
<mfp>
even ref (a=b, a, b) turns into : (bool * '_a list * '_b list) ref, with '_a and '_b :-/
<bluestorm>
Haskell behaves differently
<mfp>
this must be explained in some paper by uh Garrigue?
<rwmjones>
File "liv.ml", line 55, characters 21-38:
<rwmjones>
Unbound value Display.root_mode
Palace_Chan has joined #ocaml
<rwmjones>
but display.cmi exists in the same directory and contains that value ...
filp has quit ["Bye"]
<flux>
you don't have other display.cmi-files around, and there is no module you have opened with submodule Display?
<flux>
strace the compilation process and check that it really reads the relevant .cmi-file..
<rwmjones>
flux, yeah I did that already, and it isn't opening the .cmi file
<rwmjones>
maybe there's a submodule somewhere ...
Linktim_ has quit [Read error: 110 (Connection timed out)]
Linktim_ has joined #ocaml
<rwmjones>
Hmmmm Gdk.Display
<_zack>
Yoric[DT]: anything else?
<_zack>
in ocamlbuild's .mlpack files I can avoid specifying the transitive closure of module dependencies, right?
<Yoric[DT]>
_zack: I can't think of anything else for the moment.
<_zack>
sorry, I mean .mllibs
<Yoric[DT]>
Good work :)
<Yoric[DT]>
No, you can't.
<_zack>
:(
<_zack>
Yoric[DT]: thanks :)
<Yoric[DT]>
I have an additional target to write a .mllib automatically.
<Yoric[DT]>
Not robust enough for use in the actual build system but it can help you.
<_zack>
.oO( why the heck ocamlbuild has the deps knowledge if it doesn't use it? )
<_zack>
ah, that's the famous "autolib" I guess
<Yoric[DT]>
Oh no, I removed it for some reason.
<Yoric[DT]>
I probably never finished it.
<Yoric[DT]>
Sorry.
Kerris0 has joined #ocaml
<_zack>
Yoric[DT]: but remember that I've a request :), I could use some hints about where to put the for-pack() tags
<Yoric[DT]>
Any .cmx/.cmxa that should go into a (packed) .cmxa .
<_zack>
yes, the point is the tag argument
<_zack>
I managed to end-up in a kind of a looping request Common.Common.Common....Compress :)
<_zack>
but I'll try again
Linktim has quit [Read error: 113 (No route to host)]
poulet has joined #ocaml
<Yoric[DT]>
for-pack(stuff) is equivalent to -for-pack stuff on the command-line
* Yoric[DT]
hopes that's a sufficient hint.
<_zack>
yup, should be
velco has quit ["Went wasting time elsewhere ..."]
Koordin has joined #ocaml
poulet_ has joined #ocaml
<Koordin>
hi, why can't find documentation about Obj.magic on the official man pages ?
<flux>
because it's dark magic
<flux>
and if the goal is to create working, non-segfaulting, software, its use is to be avoided :)
<Yoric[DT]>
Dirty syringe and all that.
<hcarty>
Yoric[DT] and _zack: How are you/are you handling the different findlib names for ocamlzip between GODI and Debian+Fedora?
<Yoric[DT]>
We're unfortunately not handling that yet.
<Yoric[DT]>
I sit back and hope that _zack will come up with a patch for Debian :)
tomh has joined #ocaml
<_zack>
hcarty: I wasn't aware of that, but it can be handle at source configuration time
<Yoric[DT]>
That is, a patch applied to our META file.
<hcarty>
_zack: Sounds good. I'm just curious, as I've run up against the problem locally
<flux>
funny how replacing Hashtbl with Weaktbl can make runtime and memory consumption shoot up
<_zack>
hcarty: how is it called in GODI?
<hcarty>
_zack: camlzip
<hcarty>
_zack: Locally, I install a "compatibility" package zip which is just a META file requiring camlzip
<_zack>
that's a bit annoying, given that we created camlzip's META well in advance that GODI existed
<_zack>
but we have to cope with that, I guess
<hcarty>
GODI may be willing to change, I don't know
<hcarty>
I haven't taken the time to submit a request or patch
<_zack>
hcarty: that would be interesting indeed
<Koordin>
flux: i just want to document myself
poulet_ has quit []
poulet has quit [Connection timed out]
Octavian has joined #ocaml
<Octavian>
gug
<bluestorm>
Koordin: what i learned by fooling around is that Obj.magic does nothing except letting you change the value type
<bluestorm>
ie. it does not change the memory representation of the value (doesn't even copy it), so if you do evil thing (making an array think he's an integer, for example) you segfault
<Koordin>
so what can we do with it ?
<bluestorm>
the good answer probably is "nothing"
<bluestorm>
it's sometimes used in some not-so-evil cases
<bluestorm>
see for example Extlib list hack
<bluestorm>
(they create mutable lists for efficiency, and then make them believe they're regular lists)
bluestorm has quit ["leaving"]
Octavian has left #ocaml []
okagawa has joined #ocaml
<flux>
there may also be cases where you have a better proof than the compiler has for the equality of value types
<flux>
I believe the code extracted from Coq (a proof assistant) may contain valid uses of Obj.magic
<flux>
obviously, Coq has a more advanced type system than O'Caml..
vixey has joined #ocaml
<Koordin>
yes i hear good things about Coq here where i'm studying
Axioplase has joined #ocaml
okagawa has left #ocaml []
okagawa has joined #ocaml
filp has joined #ocaml
okagawa has left #ocaml []
GustNG has joined #ocaml
velco has joined #ocaml
<vixey>
I was looking at The Definition of Standard ML.. scary book
<flux>
although at the moment I'm actually pondering of using Obj.magic too :P
<vixey>
why flux?
<flux>
I want to implement a certain kind of interface and I'm having trouble with Weaktbl
<flux>
the idea would be that you have for instance let event = create_hook () let t = create () hook t event print_endline issue t event "hello world"
itewsh has quit ["KTHXBYE"]
marmotine has joined #ocaml
_zack has quit ["Leaving."]
GustNG1 has quit [Read error: 110 (Connection timed out)]
Snark has quit [Read error: 60 (Operation timed out)]
Snark has joined #ocaml
<flux>
any suggestions for implementing that?
Kerris0 has quit [Read error: 104 (Connection reset by peer)]
jeremiah has quit [Read error: 104 (Connection reset by peer)]
det has quit [Read error: 110 (Connection timed out)]
<litb>
oh so there is a caml, and a ocaml implementation
Linktim_ has quit [Read error: 110 (Connection timed out)]
tomh has joined #ocaml
<^C>
# let k x y = x ;; # let s x y z = (x z)(y z) ;; # let id = s k k ;; val id : '_a -> '_a = <fun>
ofaurax has joined #ocaml
<^C>
Could anyone explain me why id has got type '_a -> '_a instead of 'a -> 'a?
<Camarade_Tux>
if you want a caml implementation from inria you can get caml-light, it's not developped anymore afaik but it's still supported (except there's not my to fix ;) )
Linktim has joined #ocaml
rhar has joined #ocaml
olegfink has joined #ocaml
<vixey>
I couldn't compile caml-light
<vixey>
I don't know f it is just broken or what
sporkmonger has quit [Read error: 110 (Connection timed out)]
<litb>
hmm
<litb>
Ocaml sounds easier than haskell tho
<Camarade_Tux>
vixey, it worked for me
<Camarade_Tux>
and I can't believe it : it takes 10 seconds to compile, even less to bootstrap...
<Camarade_Tux>
in fact the 'make configure' part is by far the longest one !
<litb>
alright bye all :p
litb has left #ocaml []
<Camarade_Tux>
well, actually it's shorter but anyway, caml-light doesn't take 30 seconds to compile and check
Associat0r has quit [Client Quit]
<vixey>
oh I better try it again sometime
<vixey>
I was really disappointed when it didn't compile
Camarade_Tux has quit ["Leaving"]
sporkmonger has joined #ocaml
apples` has joined #ocaml
Submarine has quit [Remote closed the connection]
Camarade_Tux has joined #ocaml
Axle has left #ocaml []
Linktim has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
'night everyone.
Yoric[DT] has quit ["Ex-Chat"]
Camarade_Tux has quit ["Leaving"]
<Axioplase>
^C: because chere are references in Caml
Kerris3 has joined #ocaml
<Kerris3>
is there a good OCaml book on compilers?
<Axioplase>
Your type is "give me any type, Éll stick to it"
<Axioplase>
Kerris3: the Tiger is in SML/NJ but great
<Axioplase>
So is Compilinh with Continuations (both by A. Appel)
<Kerris3>
Axioplase: thanks, I've heard of the latter but not the former
<Kerris3>
oh, that's because it's not a book name, haha
<Axioplase>
Kerris3: Like the Dragon (Aho & Ullman), it's a nickname
<Kerris3>
yeah I just found out from Amazon :)
<Kerris3>
thanks very much
<Axioplase>
I suggest Lisp in Small Pieces by Ch. Qeuinnec. It's not about ML, but it's great
<vixey>
Compiling With Continuations is brilliant actually
<vixey>
that is a must read
longh has joined #ocaml
<Axioplase>
I prefer it to the tiger actually
<Kerris3>
Axioplase: is Lisp in Small Pieces about compilers?
<Axioplase>
Kerris3: about interpreters and compilers
<Kerris3>
I like Lisp as a family of languages, but unfortunately I don't have much time this semester to write Lisp :(
<Kerris3>
oh wonderful, thank you very much
velco has quit ["Ex-Chat"]
Kerris3 has quit [Remote closed the connection]
Kerris0 has joined #ocaml
Kerris0 has left #ocaml []
willb has quit ["Leaving"]
vixey has quit [Client Quit]
Axioplase has quit ["leaving"]
apples` has quit [Read error: 110 (Connection timed out)]
apples` has joined #ocaml
hkBst has quit [Read error: 54 (Connection reset by peer)]
longh has quit [Client Quit]
itewsh has quit ["KTHXBYE"]
MrEvil has joined #ocaml
MrEvil has quit ["Leaving"]
rhar has quit [Read error: 110 (Connection timed out)]