07:58 <dark_light> i have two records that has equals fields instead of one.. the records are named substantivo_t and artigo_t.. i am returning a valid substantivo_t, but the compiler is saying that The record field label proprio belongs to the type substantivo_t but is here mixed with labels of type artigo_t (proprio is the field that is on substantivo_t but not in artigo_t).. someone knows how fix it?

07:59 <dark_light> i tried to manually define the type of exit, trying to do ({field_a=value; fieldb_value} : substantivo_t), but i got a syntax error..

07:59 <dark_light> (and i don't want to manually define the type of returning value!)

07:59 <pango> fields name are associated with the module namespace

08:00 <pango> so if you want to use the same field name, you have to define the record types in different modules

08:01 <dark_light> well.. so i think it is a poor choice..

08:01 <dark_light> maybe i will use a object instead..

08:04 <pango> or just don't use the same field name in different record types within the same module

08:05 <flux__> using such fields from other modules can be slightly painful though, with value.OtherModule.fieldname :/

08:06 <flux__> maybe using objects would be a nice alternative. one will lose pattern matching then, though.

08:09 <dark_light> pattern matching? how can i do pattern matching with records?

08:09 <pango> { field_a = x } -> f x

08:10 <dark_light> nice

08:10 <flux__> there's a lighter requirement for module names in pattern matchin, the module name needs to be stated only in the first fields

08:10 <flux__> so { Module.field_a = x; field_b = Foo } -> ..

08:12 <dark_light> i though in use a array, of a variant type like.. Type1 of .. | Type2 of .., but it was too complicated

08:13 <dark_light> i think in objects as it being a unecessary overhead (for this program at least), but i don't know how much

08:14 <pango> what's the relation between the two record types ? maybe one should be included in the other, for example

08:15 <pango> or you should use only one type, with extra fields being option types

08:17 <dark_light> option types?

08:17 <pango> type 'a option = None | Some of 'a

08:18 <dark_light> Hmm

08:19 <dark_light> pango, both represent a word, one representing a article ("the", "a", "an".. but in portuguese) and the other a noun, but in portuguese. it stores the word and additional info (the gender, the plural/singular..)

08:19 <dark_light> first i tryied to make a 'word' type, like type 'a word = ..., but it was too complex

08:20 <pango> do you expect to extend your design to other kinds of words ?

08:20 <dark_light> yes

08:21 <dark_light> pango, the types must not be exactly the same so logical type errors can be detected at compile time

08:22 <pango> if there's a clear hierarchy between all words, then maybe object classes is the right approach

08:24 <dark_light> pango, and all objects inherits the proprierties of a generic "word" class?

08:24 <pango> OCaml's OO is structural, so you don't need something like that, afaik

08:24 <pango> that said, I never used OCaml's OO ;)

08:25 <pango> (so I wonder if the hierarchical constraint is even necessary)

08:26 <pango> (that said, it makes the inheritance, hence the OO approach, more attractive)

08:26 <dark_light> pango, i didn't understand, why i don't need something like that?

08:27 <pango> # let print_word word = word#print () ;;

08:27 <pango> val print_word : < print : unit -> 'a; .. > -> 'a = <fun>

08:27 <pango> means that print_word can be called on any object, as long as it has a print method, of type unit -> 'a

08:27 <pango> no need for a base class or anything

08:30 <dark_light> but, hm.. a word basic class would be useful for keep the basic things that all words have

08:31 <pango> yes, it's just that from the point of view of types, it's not a requirement

08:35 <dark_light> pango, but it isn't the default in OO? two classes that are the same but one inherits some things of a parent, are equivalents

08:35 <dark_light> i think C++ behaves this way too

08:36 <flux__> dark_light, but in ocaml you don't need to inherit from anything

08:36 <flux__> dark_light, it is simply enough that you provide the method of the required signature

08:37 <dark_light> hmmm.. there are languages that requires the class to inherit?

08:38 <flux__> c++, java

08:38 <flux__> many others

08:39 <dark_light> didn't know:)

08:42 <pango> I think you'll have to read, then experiment a bit with OCaml's OO...

08:44 <pango> it has its own load of concepts and restrictions attached, I can't tell if it's the best approach for your problem

12:56 <flux__> hm, where can I find documentation for ocamlmklib?

12:57 <flux__> ah, there is something in the chapter describing how to interface with C

13:12 <flux__> ah, I had foo.c and foo.ml, and things worked just great until I enabled native code generation which clobbered file foo.o

13:26 <flux__> apparently luck was slightly involved, because sometimes I managed to generate a working library

18:56 <fremo> hello

18:56 <zmdkrbou> lo

21:50 <DRMacIver> Sigh

21:50 <DRMacIver> It makes me sad when there's something a language does so very much better than anything else out there, and it's still not good enough.

21:50 <DRMacIver> (ML and OCaml's pattern matching)

21:52 <DRMacIver> Well, pattern matching in function definition.