systems changed the topic of #ocaml to: http://icfpcontest.cse.ogi.edu/ -- OCaml wins | http://www.ocaml.org/ | http://caml.inria.fr/oreilly-book/ | http://icfp2002.cs.brown.edu/ | SWIG now supports OCaml| Early releases of OCamlBDB and OCamlGettext are available | Caml Weekly news http://pauillac.inria.fr/~aschmitt/cwn/
mattam has quit [Read error: 60 (Operation timed out)]
reltuk has joined #ocaml
lus|wazze has quit ["Quidquid latine dictum sit, altum sonatur."]
lus|wazze has joined #ocaml
lament has joined #ocaml
Smerdyakov has joined #ocaml
Kinners has joined #ocaml
rhil_sea is now known as rhil_zzz
lament is now known as lameAFK
foxster has quit [Read error: 110 (Connection timed out)]
Smerdyakov has quit ["sleep"]
foxster has joined #ocaml
lameAFK is now known as lament
Kinners has left #ocaml []
reltuk has quit ["Client exiting"]
travisbemann has joined #ocaml
foxster has quit [Read error: 110 (Connection timed out)]
mattam has joined #ocaml
rox has quit [Read error: 110 (Connection timed out)]
<travisbemann> has anyone done any work with vector graphics in OCaml?
rox has joined #ocaml
mellum has quit ["ircII EPIC4-1.1.11 -- Are we there yet?"]
travisbemann has quit ["leaving"]
lus|wazze has quit ["Quidquid latine dictum sit, altum sonatur."]
lament has quit ["I WILL NOT SHOW OFF"]
wrunt has quit [Read error: 104 (Connection reset by peer)]
wrunt has joined #ocaml
__DL__ has quit [Read error: 54 (Connection reset by peer)]
systems has joined #ocaml
__DL__ has joined #ocaml
gene9 has joined #ocaml
docelic|sleepo is now known as docelic
systems has quit ["Client Exiting"]
karryall has joined #ocaml
wax has quit [Remote closed the connection]
wax has joined #ocaml
det has joined #ocaml
Yurik has quit [Read error: 104 (Connection reset by peer)]
Yurik has joined #ocaml
gene9 has quit []
Demitar has joined #ocaml
mrvn_ is now known as mrvn
olrion has joined #ocaml
<olrion> hi
<Demitar> Hello olrion.
<mrvn> Did anyone write a printf style function?
<Demitar> Like Printf.printf? :-)
<mrvn> yep.
<mrvn> With a variable number of argumnets.
<Demitar> The number of arguments is derived from the format string.
<karryall> mrvn: there's cpsio
<mrvn> Is there some special code in the type checker for format strings or does it get the type from the decoding of the format string done in printf.ml alone?
olrion has quit ["I like core dumps"]
<Demitar> mrvn: The format string has some close interaction with the type-system, if you want to build your own you'll need to use kprintf.
<mrvn> I want to make a different format string.
<mrvn> For binary network in/out-put
<karryall> that's a nice idea
<Demitar> What do you want to do exactly? Bit-fiddling?
<karryall> have a look at cpsio, it might be easier since it is pure caml I believe (no compiler magic)
<mrvn> I need something like %16b for a short and %16n for a short in network byte order.
<mrvn> What does $ do?
olrion has joined #ocaml
<Demitar> Well you can't do that with Printf.* I personally write some wrapping functions (and lately have been generating the protocol encoding/decoding source from xml).
<olrion> re
<Demitar> wb
<mrvn> Hmm, cpsio looks nice. But I need it for input too. But the design looks sound.
<mrvn> thx.
<karryall> ah right, it doesn't do input
wax has quit [Read error: 104 (Connection reset by peer)]
wax has joined #ocaml
<mrvn> Wow, I just found a bound printout of the O'Reilly Ocaml book here at university.
Demitar has quit ["There are bubbles in the air..."]
<olrion> hehe
TimFreeman has joined #ocaml
det has quit ["ircII EPIC4-1.1.2 -- Are we there yet?"]
det has joined #ocaml
TimFreeman has left #ocaml []
mellum has joined #ocaml
<mellum> hi
<olrion> hi mellum
emu has quit [asimov.freenode.net irc.freenode.net]
polin8 has quit [asimov.freenode.net irc.freenode.net]
polin8 has joined #ocaml
emu has joined #ocaml
olrion has quit ["I like core dumps"]
emu has quit [asimov.freenode.net irc.freenode.net]
emu has joined #ocaml
olrion has joined #ocaml
<olrion> re
Zadeh_ has quit []
Zadeh has joined #ocaml
Yurik has quit [Read error: 54 (Connection reset by peer)]
rhil_zzz is now known as rhil
mattam_ has joined #ocaml
mattam has quit [Read error: 60 (Operation timed out)]
owll has joined #ocaml
Smerdyakov has joined #ocaml
owll has left #ocaml []
cDlm has joined #ocaml
<cDlm> a question regarding modules...
<cDlm> type someid = SomeId of int
<cDlm> I want to use maps (Map from the std lib) using keys of type someid and values 'a
<cDlm> eg type 'a somemap = ???? will associate values of type 'a to keys of type someid
<cDlm> i tried several definitions but i cant get one that works
<Smerdyakov> Do you know what type in Map you want to use?
<cDlm> thats 'a
<cDlm> actually i have different types of IDs (so different types of maps)
<cDlm> lets say IdOfThisMap and IdOfThatMap
<Smerdyakov> What?
<Smerdyakov> I mean the type that the Map module uses for maps.
<Smerdyakov> There should be an abstract type in that module.
<cDlm> Map.Make().t ?
<Smerdyakov> That's an expression. I'm asking about a _type_.
<Smerdyakov> Looks like Map.S.t
<cDlm> yes
<cDlm> but that one isnt known either
<Smerdyakov> So you will want to use that type in your type definition.
<cDlm> hmm
<cDlm> as i understand it i have to define one module implementing Map.OrderedType for each ID type i want
<Smerdyakov> Not necessarily.
<Smerdyakov> You can put the Map instantiation inside the module that defines the ids.
<Smerdyakov> And rebind the same structure to a couple of different names.
<cDlm> uh?
<Smerdyakov> Then you use the signature to give each name a different id type.
<Smerdyakov> This only works if you make your id types synonyms for int, instead of using constructors.
<cDlm> the problem is I want type checking over ids
<Smerdyakov> You would have that outside the module. You mean you want this extra checking inside the module where you define the ids?
<cDlm> i dont think so
<cDlm> this is quite unclear for me
<Smerdyakov> In your module, you could have: type id1 = int and id2 = int
<Smerdyakov> Then, in the signature for that module, you just have: type id1 and id2
<Smerdyakov> So, outside the module, you get the same effect as if you had used new types for the ids.
<cDlm> i'm not sure this is what i want
<cDlm> i'm defining state machines
<cDlm> and a state machine has a map from stateids to concrete states, and a map from transitionids to concrete transitions
<cDlm> and a transition is a label and 2 stateids
<cDlm> ah ok
<cDlm> i was trying to do type 'a stateIdMap = 'a (Map.Make(StateId).t)
<Smerdyakov> I know you can't do inline functor applications like that in SML.
<Smerdyakov> Maybe you can in Caml.
<Smerdyakov> I would just bind the result to a name.
<cDlm> I use OCaml
<Smerdyakov> And then use that name in your type definition.
<karryall> same thing in ocaml
<cDlm> i don't like having to think of names i won't use
<karryall> first apply the functor, then use the module
olrion has quit [Read error: 54 (Connection reset by peer)]
* Smerdyakov likes the structure of the SML/NJ Util library map modules better than OCaml's. :-)
<cDlm> i'm not fond of modules and class and functor things in caml
<Smerdyakov> Why not? The mechanisms themselves are nice.
<cDlm> in eiffel its all the same
<cDlm> module = functor = an eiffel class
<Smerdyakov> I just don't like the multi-level substructure stuff in Map.
<cDlm> that part of ocaml is really convoluted syntactically
<karryall> come on ... it's not !
<Smerdyakov> I don't agree.
<Smerdyakov> It's very nice.
<cDlm> maybe not syntactically
<cDlm> but you have to build and name things by hand, i find it tedious
<Smerdyakov> Every functor application creates new code in the final executable.
<Smerdyakov> Allowing it inline is asking for trouble.
<Smerdyakov> karryall, a functor application creates a new record of its input parameters at the least in the executable, right?
<cDlm> why new code ?
<karryall> hmm, it don't really know how functors are implemented but I'd say no
<cDlm> could be the same code, if everything is checked at compile time
<Riastradh> cDlm, you don't seem to understand that functors are like functions that take module arguments and return modules; functors aren't modules themselves.
<karryall> cDlm: there are libraries with set/maps that use the generic comparison function
<Smerdyakov> cDlm, I think generativity of functor application forces the results to be considered separately. It's possible that the actual data associated with an application could be shared between instantations.
<Smerdyakov> cDlm, i.e., apply the same functor to the same arguments twice; if the result has an abstract type, you have made two different modules.
<cDlm> from a typing point of view
<cDlm> ... that doesn't mean new code
<Smerdyakov> And what if the module has references in it?
<Smerdyakov> I think that's the clincher. :-)
<cDlm> you have to instanciate module variables each time
<Smerdyakov> I think I shouldn't have used the word "code" before.
<Smerdyakov> I just mean dumping extra bytes into the final executable.
<cDlm> modules are kind of singleton classes, no ?
<cDlm> Smerdyakov: yes :)
<Smerdyakov> It IS allowed for compilers to generate new code as an "inlining" optimization, though.
<Smerdyakov> I know MLton does it for SML.
<Smerdyakov> You _should_ want functor applications to generate new code whenever possible, if you care about runtime speed.
<cDlm> i don't :)
det has quit [Remote closed the connection]
karryall has quit ["bye"]
det has joined #ocaml
Yurik has joined #ocaml
<cDlm> argh
<cDlm> why can't i define functor () -> blah ?
<Smerdyakov> Why would you want to do that?
<cDlm> to get FirstId.t incompatible with SecondId.t
<cDlm> i can do it by module FirstId : ID = IntID
<cDlm> and SecondId : ID = IntID
<cDlm> but that means i know Ids are implemented using integers
* cDlm likes tetracapillotomy
Smerdyakov has quit ["back out into the breech, for apartment hunting!"]
<cDlm> well lets see later :)
<det> cDlm, will they be incompatible if you just do module FisrtID = IDMoudle
olrion has joined #ocaml
mattam_ is now known as mattam
foxster has joined #ocaml
<olrion> re
mrvn_ has joined #ocaml
Vincenz has joined #ocaml
<Vincenz> Hi!
<Riastradh> Hi!
<mattam> Hi!
<vegai> Ih.
<olrion> hi
olrion has quit [Read error: 104 (Connection reset by peer)]
TachYon has joined #ocaml
det has quit ["ircII EPIC4-1.1.2 -- Are we there yet?"]
mrvn has quit [Read error: 110 (Connection timed out)]
<cDlm> heeeeeee!
<mrvn_> hi
mrvn_ is now known as mrvn
cDlm_ has joined #ocaml
olrion has joined #ocaml
cDlm has quit [Killed (NickServ (Ghost: cDlm_!cdlm@lns-p19-19-82-65-131-64.adsl.proxad.net))]
cDlm_ is now known as cDlm
<olrion> re
foxster has quit [Read error: 104 (Connection reset by peer)]
foxster has joined #ocaml
olrion has quit [Read error: 110 (Connection timed out)]
TachYon has quit [Remote closed the connection]
Vincenz has quit []
det has joined #ocaml
olrion has joined #ocaml
thomas001 has joined #ocaml
<thomas001> hi
<thomas001> anyone here/
<olrion> yes
<olrion> somebody here :)
<thomas001> is it possible to overload functions in Ocaml?
<olrion> don't ask me something like that
<olrion> i'm just a noob
<thomas001> ok ;)
<olrion> who just can ask question not any answer
<olrion> :)
<olrion> i try to learn ocaml
<thomas001> i'm not sure if it's worth
<olrion> i think yes it's worth
<olrion> it is very intresting language
<olrion> i mean not imperative part
<olrion> but the fonctionnal part
<thomas001> i think i'm pretty good at C++,and OCaml confused me a lot
<mellum> thomas001: it's not possible
<mellum> otherwise, type inference wouldn't work
<thomas001> thx mellum
<olrion> thomas001: i used C most of the time
<olrion> and ocaml confused me a lot too
<olrion> but it is like a challenge
<thomas001> i wonder if the ocaml compiler is as good as g++
<mrvn> nope
<mrvn> ocaml is pretty bad unboxing floats
<olrion> and about secure ?
<olrion> security
<mrvn> ocaml won#t segfault unless you use Obj magic
<olrion> and buffer overflow
<mrvn> no buffer overflows and the like possible
<olrion> or anything like this
<olrion> so that's why i like ocaml :)
<thomas001> what does unboxing floats mean?
<olrion> good question
<mrvn> floats are stored as a box saying "I contain a float" and the actual float.
<thomas001> olrion: with clean C++ segfaults and buffer undersruns are also seldom
<mrvn> Thats so the GC can see its a float.
<mrvn> thomas001: but possible.
<thomas001> sure
<thomas001> mrvn: and what is so complex in unboxing a float?
<mrvn> When you do "let rec loop x = if x < 1.0 then () else loop (x -. 1.)" ocam will extrac the float from the box, subtract 1. and put back into a nother box and call loop. It should just keep the floa in a register.
<mrvn> Lots and lots of memory accesses and stall cause it stores a float and reads it back next cycle. Thats rather expensive.
<mrvn> Its not so bad on i386 though.
<mrvn> But try writing a fractal programm that basically just loops around some float calculations.
<thomas001> floating point speed is rather important to me,as i want to do some 3d stuff
<mrvn> i386?
<thomas001> ?
<mrvn> ibm pc or compatible?
<thomas001> yes,but i won't complain if it runs on other platforms
<mrvn> PCs don#t have such a problem with this. Their fpu is stack based and the compiler is somewhat better there.
<mrvn> I saw someone did some 3D stuff with ocaml.
<mrvn> Nowadays all the hard work is done with the graphics card anyway, with gl.
<thomas001> many,yes,but not all
<mrvn> But all the small tight loops.
<mrvn> If you only read in a float, manipulate it once and store it its not so much a problem if it doesn't unbox it. Its those several cycles penalties for reading a just written float that kill a fractal program on alpha I think.
<thomas001> ok,thx a lot
<mrvn> Before you do it without ocaml try it with. You can allways rewrite the few intensive routine in C later if they become a problem.
<olrion> what is a fractal program ?
<mrvn> Never drawn a Mandelbrot fractal?
<olrion> nope
<olrion> i know what is fractal
<thomas001> l-systems are also nice
<olrion> chaos theory ?
<mrvn> yep
<olrion> thx mrvn
<mrvn> olrion: try "ocaml graphics.cma fract.ml"
<olrion> ok
<mrvn> or better compile it.
<olrion> ocamlc :)
<mrvn> ocamlopt -o fract graphics.cmxa fract.ml
<olrion> if i can dl it
<olrion> can you send it via mail (if it is possible) ?
<det> mrvn, the GC needs to know the types of variables to collect properly ?
<mrvn> Why? dcc worked
<mrvn> det: yes
<olrion> both failed
<mrvn> 00:46 DCC sent file fract.ml [3kB] for olrion in 1 secs [2.93kB/s]
<olrion> a
<olrion> i will find it
<det> mrvn: send it to me!
<mrvn> firt one failed on my side.
<mrvn> your away
<mrvn> You have to press return after each image.
<mrvn> (on the console, not the image)
<olrion> Cannot open /home/olrion//dcc/fract.ml for writing - aborting.
<olrion> this is why it didnot work
<mrvn> Then create that dir
<det> ./exec mkdir ~/dcc
<olrion> yeah
<olrion> thank you
<det> does the fract take a long time to generate
<det> oh, there it goes
<det> n/m
<mrvn> compared to a c prog doing it it takes ages.
<olrion> no
<olrion> it is very fast
<mrvn> A lot of the time is wasted on redrawing the image for every pixel though.
<det> is it because the delta between C and ocaml performance ?
<emu> there shouldn't be any
<thomas001> does ocaml support runtime polymorphism (don't know if this is the right word) like c++'s virtual ?
<det> or just a lousy fractal implementation ?
<emu> likely a lousy program ;)
<det> thomas001: with objects, all methods are virtual
<det> thomas001: or you can create closures :)
<mrvn> thomas001: not realy not cleanly. But virtual functions don#t need it.
<det> thomas001: what are you doing that you expect the need for virtual functions
<olrion> i like but i had to learn mathematics before do stuff like that
<det> mrvn, I was reading a fairly old post on the OcamlML about first class modules, it seems it would do everything I dream of if they ever implemented it
<mellum> ppo/wi gr 30
<mellum> oops
<thomas001> det: i think very c++,so for interfaces mainly
<mrvn> thomas001: thats what ocaml has modules for normaly.
<det> thomas001: give an example ?
<mrvn> thomas001: Like List, Hashtbl, Array.
<emu> functors not good enough?
<mrvn> There are also functors like a Set.
<mrvn> emu: functors are somewhat a lot of syntax for something one can do with a simple object or just closures.
<thomas001> det: e.g. in a GUI toolkit the root window stores a list of widgets like buttons and lists and so on. so the list is a list of objects of type Widget. and for every widget the rootwindow would call a method paint() to draw the window. and every widget implements paint() differently
<thomas001> i hope my explanation is not too bad
<mrvn> thomas001: type paintable = { paint : root_window -> (); }
<mrvn> Then let every widget have a paintable record with properly set closure.
<det> thomas001: ahh, yes I was asking about the exact same thing last week, we came to the conclusion that you need to use objects, OR keep a record of closures with the widget partially applied
<thomas001> which way is more ocaml?
<mrvn> det: or functors.
<det> well, the object way is very close to c++ :)
<det> mrvn, /me cries hetergenous lists, functors can't do that, remember :)
<mrvn> With objects you have one drawback. Objects can't have a reference to an object of their own class.
<thomas001> huh?
<mrvn> You could only make one with Obj magic.
<thomas001> why not? it is possible in C++
<det> mrvn, are you sure ?
<mrvn> thomas001: You would ahve to pass the object to reference along in the Constructor. But which object do you pass to the first object?
<det> that seems very strange
<det> we'll, you'd use a variant obviously
<mrvn> type foo = { other : foo } let rec foo = { other = foo; }
<thomas001> mrvn: NULL ;-)
<mrvn> You can#t make thiose with objects.
<det> SomeObj | NullObj :)
<mrvn> Sure you can use an object option. No problem there.
<Riastradh> You can do that, mrvn? I thought that not only could functions be the only RHS values in let rec but also that that would infinitely loop.
<thomas001> the more i get to know about ocaml the more i fear it
<Riastradh> What have you to fear about it?
<mrvn> Riastradh: Thats perfectly valid. It allocates space for foo and inserts its own adress into it.
<det> thomas001: I imagine you can do whatever you need with ocaml objects
<mrvn> Riastradh: no looping there. Just the output is rather long.
<Riastradh> Er, no, it wouldn't infinitely loop, duh.
<det> thomas001: mrvn is likely just scaring you :)
<thomas001> Riastradh: the way programming is different from "normal" languages like C/C++/Pascal/...
<det> thomas001: most would reguard that as a good thing :)
<Riastradh> By 'normal' you must mean 'imperative,' or else I shall have to stab you to death with a spork.
<mrvn> thomas001: Do you realy need a class that references itself?
<mrvn> thomas001: If so one can use Obj Magic to fool it.
<thomas001> mrvn: you mean a object which stores references to objects of the same type ?
<det> mrvn, you can have a class reference *itself*, or an object of the same class ? :)
<mrvn> thomas001: yes or itself.
<det> s/can?can't/
<thomas001> mrvn: yes for widget trees e.g.
<mrvn> det: class foo = object(self) val me = self end
<thomas001> hmm for nearly all kind of trees...
<thomas001> +s
<mrvn> thomas001: Your root widget class wouldn't have a reerence to other root widgets.
<mrvn> det: something like that is impossible in ocaml.
<thomas001> mrvn: yes right
<mellum> mrvn: you should not mention Obj.magic on a public channel, it's evil ;)
<mrvn> thomas001: You can have a list of objects or an object option. Just not a circula link.
<mrvn> mellum: evil, Evil, EVIL. :)
<mellum> mrvn: even though it does absolutely nothing. How very deep.
<det> mrvn, why can't you use a variant
<mrvn> I still don't understand why "val me = self" won't wok though.
<mrvn> det: wastes space and needs extra code on every use.
<det> well, for a tree, you would need a variant reguardless, or you would have an infinite type
<det> I really don't think any of this would be an issue for him anyways
<mrvn> A lot of algorithm books use a link to itself to symbolise the end of a tree or list.
<det> that's wrong
<thomas001> the C way is a NULL pointer
<det> and the ocaml way is to use Nil :)
<emu> the C way is crash
<emu> there is no other way
<mrvn> An option wastes space and if a node points to itself you can test for the end with a simple ==
<mrvn> or !=
<emu> the Lisp way is NIL
<thomas001> emu> the C way is crash ?
<Riastradh> The decrepit Lisp way, foo.
<emu> The Scheme way is ()
<det> you should check for the end with matching a variant, or an empty method
<emu> though some Schemes have NIL -> (). is that stadnard?
<mrvn> det: as I said, wastes space.
<Riastradh> Definitely not.
<Riastradh> mrvn, er, how much space?
<det> mrvn, oh, I understand
<mrvn> det: Another method is to have a special marker element in for example a double linked list. That acts as first and last element.
<mrvn> Nothing will point to itself but you still have a circular link. Needs an option type in objects.
<mrvn> Riastradh: 3 times as much maximum
<Riastradh> 3 times as much as what?
<det> mrvn, well, Ocaml could optimize variants in certain cases to save memory
<mrvn> Riastradh: as without option
<emu> Riastradh: it's okay though, Scheme is purposefully decrepit
<mrvn> det: it does.
<Riastradh> emu, uh, how so? Its standard wasn't last updated twenty years ago.
<det> mrvn, in the case of type 'a list = Nil | Cons of 'a * ('a list) ?
<emu> obviously, cause it's flawed
<mrvn> det: Nit is an int and Cons a struct with 2 fields.
<det> mrvn, in that case it could represent lists like C does, with a special NULL address
<mrvn> det: That would require even more magic than pointing to itself.
* emu notes that 9 years /= 20 years
<thomas001> is there a ML standard or is every implemention free to do what it wants?
<det> mrvn, well, seems like if ocaml makes those optimizations, it wastes no space at all
<emu> thomas001: there is no OCAML standard, but there is an SML standard
<thomas001> SML=?
<olrion> i gonna bed
<emu> Standard ML, naturally
<olrion> so have a good night
<emu> =)
olrion has quit ["I like core dumps"]
<thomas001> emu: what are the differences?
<emu> syntactic, the type system is a bit more limited i think
<det> ocaml generates (much) better native code?
<emu> no
<emu> smerdy says that MLton is very good now
<det> ocaml has an object system
<emu> for some value of "object system"
<emu> that goes under the heading of "more limited type system"
<Riastradh> emu, it's hard to find something that can't be considered an 'object' with the terrible definition thereof.
* emu grins
<Riastradh> Based on the great language shootout, it seems to me that the OCaml compiler is slightly better than MLton.
<mrvn> # let int cont (x:int) = cont x;;
<mrvn> val int : (int -> 'a) -> int -> 'a = <fun>
<mrvn> # let ($) = fun f g -> fun cont -> g (f cont);;
<mrvn> val ( $ ) : ('a -> 'b) -> ('b -> 'c) -> 'a -> 'c = <fun>
<mrvn> # int $ int;;
<mrvn> - : (int -> '_a) -> int -> '_a = <fun>
<mrvn> Shouldn't that be (int -> int -> 'a) -> int -> int -> 'a?
* emu explodes
<det> what else does the ocaml type system have that SML doesn't besides polymorphic variants, objects ?
<emu> humps
<Riastradh> An easily extended definition.
<emu> what's that mean
<det> policy, I assume
<Riastradh> It's easier to include more into the language; there's no very official standard to which it must conform which is difficult to update.
<emu> standards are good, mmm
<emu> languages without standards are immature
* emu hums innocenly
<Riastradh> Yes, standards do have their advantages; but there are also a few advantages to languages without standards.
<det> emu, there's this language called haskell, you might be very interested in
* emu notes he is on #haskell and #sml too
* Riastradh smacks emu -- Scheme -does- have a standard, though it may not be an ISO or ANSI standard or anything.
<det> emu, uses a standard from '98 :)
<emu> there's a difference between a standard and a useless standard, Riastradh
<emu> SML '98 too
<Riastradh> emu, uh, useless standards are all standards.
<emu> oops, '97
<emu> nah, Scheme is useless for anything but writing another Scheme interpreter
<Riastradh> How is that relevant to what I just said?
<det> emu, and gimp lugins!
<emu> nah, that's guile
<Riastradh> det, no, that's SIOD.
<Riastradh> emu, uh, no, it's SIOD, foo.
<det> guile is scheme
<emu> or is it SIOD?
<emu> guile is shit
<Riastradh> Indeed, indeed.
<det> guile _isnt_ scheme ?
<emu> guile is shit
<Riastradh> guile implements Scheme.
<thomas001> guile=scheme+extensions
<det> SIOD ?
<emu> guile=scheme+more shit
<Riastradh> Scheme In One Defun.
<emu> hehe: defun!
* emu hops on Riastradh
<Riastradh> It is the worse thing on Earth that anyone even considers a Scheme implementation.
<emu> is GIMP written in CL then?
<Riastradh> s/worse/worst/1
<Riastradh> emu, no, but the person who wrote SIOD didn't know Scheme, obviously.
<thomas001> what's so bad about scheme?
<det> SIOD is a book ?
<emu> it's an implementation, believe it or not
<Riastradh> No, SIOD is a piece of crap interpreter.
<emu> thomas001: the standard defines just about nothing
<emu> and attempts to make itself less useful to practical programming
<det> thomas001: some people seem to think cal/cc makes efficient compilation impossible
<mrvn> det: ocaml has call/cc
<emu> no, it makes UNWIND-PROTECT a lot hairier
* Riastradh hugs CPS.
<emu> it does impact on compilation too, though
<mrvn> its a dirty fork hack but it works.
<emu> since you can't just have a single call stack
<det> erm, then what is http://lists.tunes.org/archives/tunes/1999-August/002235.html bitching about ?
<mrvn> emu: Why would you need a call stack?
<det> just losers ?
* emu grins
<Riastradh> emu, look at SLIB and the SRFIs, foo.
<mrvn> det: the call/cc is a dirty hack.
<Riastradh> det, pretty much.
<mrvn> emu: I don't see why it would be less efficient to allocate stack frames from the head instead on the stack.
<mrvn> s/head/heap/
<det> ocaml cal/cc is a patch ?
<mrvn> det: I saw a small module for it.
<emu> allocating on the heap is much less efficient
<emu> c'mon
<mrvn> det: misuses marshaling and fork
<det> does it suck performance-wise ?
<mrvn> emu: it increases the heap pointer and that it. allocation on the stack increases the stack pointer. So what?
<mrvn> det: most likely.
<emu> you have to GC them then
<mrvn> emu: Whats a few more objects between friends?
<emu> if your heap allocation routine is any bit smarter, it's more than just icnreasing the heap pointer
<emu> mrvn: every single function call in a functional language? great
<mrvn> emu: ocaml just increases the heap pointer.
<emu> so it never reuses memory?
<mrvn> the GC moves longer living things around and frees the space again
lus|wazze has joined #ocaml
<emu> dealing with lots of little objects is never going to be faster than not having to do so
<emu> practically
<emu> in current computer systems
<Riastradh> Oh, another difference between the type systems of OCaml and SML -- records.
<mrvn> emu: One could optimize it so that the GC immediatly frees the space unless you had a call/cc.
<Riastradh> SML records must be explicitly annotated, but field names can be reused; the opposite is true in OCaml.
<det> emu, maybe compiler support for linear types ?
<emu> (define (f g) (g ...)) what does g do?
<mrvn> emu: g is a function
<lus|wazze> scheme :|<
<emu> can you discard the activation record?
<emu> hmm
<emu> i think we might actually be leaving soon
<emu> woo
<Riastradh> G is whatever the argument to F was.
<mrvn> And if it was the wrong one scheme barfs at runtime
<Riastradh> No need for any FUNCALL junk!
<mrvn> n8
<det> curiously, how old are you guys ?
<docelic> 11
<det> docelic: heh
* det runs off to the store
<det> I assume you all to be 11 then!
* Riastradh 's age can be represented in a fixnum.
<det> fixnum is a C int ?
<Riastradh> I'm not sure exactly.
<Riastradh> But it's smaller than a bignum.
<det> Riastradh: Now now, don't be too revealing your wisdom registered at 2**31 + 1 on my age-o-meter!
<det> lies
* det is away: food
<Riastradh> 2**31 _+ 1_?
<docelic> damn lies
<det> Riastradh: a very big number
<Riastradh> statistics
<det> Riastradh: too big for a signed integer (fixnum) in fact!
mattam_ has joined #ocaml
<Riastradh> I see.
<thomas001> is type foo=A|B|C;; the same as C++'s enum foo{A,B,C}; ?
docelic is now known as docelic|sleepo
<det> thomas001: except type-safe :)
<thomas001> enum aren't type safe?
<thomas001> +s
<det> thomas001: and can't be coerced to an integer
<det> (I think)
<lus|wazze> enums aren't type safe because you can cast an integer to an enum type
<lus|wazze> the other direction doesnt (shouldnt) cause any problems
<thomas001> ok,thx
<det> you don't even ned to cast
<det> enum foo{A,B,C};
<det> enum foo bar(void) { return 0; }
<det> doesn''t give any warning with gcc -Wall
<Riastradh> type foo = A | B | C
<Riastradh> let bar () : foo = 0
<Riastradh> ...won't work.