02:34 <taw> hello

02:34 <taw> is there any way of getting extra typing information from the compiler ?

02:39 <ski> zmdkrbou : how about tail-recursion-modulo-cons ?

02:49 <taw> http://pastebin.com/586623

02:49 <taw> am i not allowed to use a smaller variant function where a bigger one is expected ?

02:50 <flux__> taw, ocaml compiler can extract type information with -dtypes

02:51 <flux__> emacs' caml-mode makes use of it

02:54 <flux__> taw, btw, you don't need parenthesis in the let rec-definition

02:54 <taw> http://pastebin.com/586627

02:54 <taw> the shortest example

02:55 <taw> why isn't something of type a automatically of type b if a is a subset of b ?

02:56 <ski> different constructors with same name

02:56 <ski> try polymorphic variants

02:56 <taw> ski: they are polymorphic variants

02:56 <taw> note the `

02:58 <flux__> taw, not automatically, but there's :>

02:58 <ski> em, just saw that

02:58 <flux__> I think the limitation of not automating that is because of type inference..

02:59 <flux__> taw, compare ((`A:a):b) and ((`A:a):>b)

02:59 <flux__> (foo:bar) is a type annotation, :> is type coercion

02:59 <taw> oh

02:59 <taw> :>

02:59 <taw> why isn't it automatic ?

02:59 <taw> oh well, at least it works now

02:59 <flux__> I don't know, but I can imagine someone might be able to whip up an example where the automating would suck :)

03:00 <flux__> I would love that kind of automation with objects too..

03:00 <ski> # let f = function `A a -> a | `B a -> a;;

03:00 <ski> val f : [< `A of 'a | `B of 'a ] -> 'a = <fun>

03:00 <ski> you need '[< ...]' type

03:00 <ski> flux__ : no, that's for objects

03:01 <flux__> ski, but that ((`A:a):>b) works fine?

03:01 <ski> '[< ..blah..]' means "at least ..blah.."

03:01 <flux__> or what did you mean

03:02 <ski> flux__ : hm, it might actually be that ':>' could work here too, not sure

03:02 <ski> '[> ..blah..]' means "at most ..blah.."

03:03 <ski> # let g b a = if b then `A a else `B a;;

03:03 <ski> val g : bool -> 'a -> [> `A of 'a | `B of 'a ] = <fun>

03:03 <ski> (that's an example of the other one)

03:08 <ski> http://caml.inria.fr/pub/docs/manual-ocaml/manual006.html#htoc41

03:09 <ski> flux__ : yes, you're right, one can use ':>' to coerce polymorphic variants, too (had forgotten that)

03:09 <ski> taw : i'm not sure if one can type abbreviate a polymorphic variant type with an implicit constraint type variable without fixing it, though

03:11 <taw> ski: [< stmt] seems to do the right thing

03:27 <ski> m

03:27 <ski> but you can't use '>' or '<' in a type abbreviation to a polymorphic variant type

03:28 <ski> (since it would contain a hidden type variable that can't be abstracted out)

03:34 <ski> ppsmimou : but just applying CPS-transformation just shifts stack use into corresponding heap use, so you essentially just heap-allocate stack frames .. so no direct net win

03:40 <ppsmimou> yes of course, there's nothing magic here

03:40 <ppsmimou> you just avoid stack overflows

03:42 <ski> right

05:25 <dark_light> the ocamlc command produces arch-independant files?

05:26 <dark_light> "compiles Caml source files to bytecode object files".. ok, seems to be

05:26 <dark_light> but it just looks like a regular program o.o

05:41 <vodka-goo> it may include ocamlrun, which is arch independant

05:41 <vodka-goo> s/independant/dependant/

05:42 <vodka-goo> it is possible to have something independant, the generated file being a shebang executable calling ocamlrun

05:44 <vodka-goo> no, other way around

05:44 <vodka-goo> default is to produce a #!/usr/bin/ocamlrun executable, which is arch indep (you just need to have ocamlrun at the same place)

05:45 <vodka-goo> with -custom, ocamlrun (arch-dep) is included in the output executable, and bytecode is put at the end of the file in the data section

15:35 <JosephRivers> Is there any way to have an enum-like type with normal constructors like One, Two, etc. but have the conversion to an integer incur no overhead?

15:41 <stockholm_> Hello, I'm working on a game for one of my classes at school. For this game we need to implement a gui. I've written my game in OCaml and have never done any gui programming before. I was wondering if anyone had a minute or two to chat about design decisions, etc. of gui programming?

15:42 <mikeX_> stockholm_: just ask you questions, maybe someone will answer :)

15:43 <stockholm_> What do you use when you need to program a gui? Glade, GTK+, etc

15:43 <JosephRivers> I would suggest SDL. It's simple and there's ocaml bindings for it.

15:44 <stockholm_> For this project we need to be able to create a tiled map, such as in Warcraft. Users need to be able to drag and drop tiles onto this map. Is this something that is straightforward in SDL?

15:45 <JosephRivers> Well. Loki used to use SDL for all of their Linux game ports, so it should be quite suitable for the task.

15:45 <flux__> going the sdl way will mean you'll need to write your own user interface widgets, though

15:45 <flux__> or are there ready-made widgets for sdl?

15:45 <Demitar> Is this something in-game or an editor for the game?

15:45 <stockholm_> Something in game.

15:46 <flux__> sdl is a thin layer providing basically a frame buffer, while gtk provides actual user interface primitives

15:47 <Demitar> You probably want to go with an SDL or SDL + lablgl based solution, since you're creating a game. But as flux__ says, you'll have to roll your own widgets.

15:47 <Demitar> s/widgets/gui toolkit/

15:47 <stockholm_> Ok, well thank you all for your thoughts. I'm going to check into this SDL business.

15:48 <Demitar> You could of course build an FFI to an opengl gui library and use that. :)

15:49 <Demitar> s/an FFI/bindings/

15:50 <Demitar> stockholm_: Two important questions are of course how much experience you've had with ocaml and how much experience you've had at creating games. :)

15:51 <flux__> it's not impossible to embed real time updated bitmaps into a gtk application either

15:51 <flux__> but sdl will give you that stuff more easily

15:51 <flux__> atleast you'd need to think about different bit depths (and maybe use a library to handle that, like sdl does)

15:52 <flux__> but, sleep (0010 here)

15:52 <stockholm_> I'd like to think I'm a decent OCaml programmer. I've had zero experience creating games (save for the last 10 weeks of my class). One other thing that I should note: I only have one week to learn and write this gui.

15:53 <Demitar> You could of course go with a gtk + opengl application but it won't "feel" like a usual game (unless you like Stars!). :)

15:53 <stockholm_> I've looked over some gtk+ stuff, but it seems like dragging and dropping pixmaps around is a little bit of a trouble.

15:53 <flux__> if all you need is drag'n drop from graphical elements, there is no need for complex gui libraries

15:54 <stockholm_> By complex gui libraries do you mean pre-built widgets and such?

15:54 <pango> is looking at existing libs and projects in ocaml humps considered cheating ?

15:54 <pango> they're already games and game libs there

15:55 <stockholm_> No, it would not be cheating at all.