01:46 <mwc> I have a question about the run time's storage for ints. I know it uses one bit to mask pointers. So how does it do this efficiently without creating a lot of overhead. I don't really care about the bit, more what seems to me to be extra bit shifting functions that would add up on sufficiently cache-local integer work

01:56 <Smerdyakov> I think it does just the operations you would expect it to.

01:58 <mwc> Hmm, I should probably find a good test case to be sure anyways

01:59 <mwc> but boxing scares me

08:33 <pango> ocaml does many operations directly on "boxed" ints (increment => add 2, etc.)

08:34 <pango> btw they're tagged rather than boxed

08:39 <pango> http://www.ocaml-tutorial.org/performance_and_profiling, "The representation of integers, tag bits, heap-allocated values"

12:16 <ulfdoz> Is there a nice project, using ocamlyacc/-lex? I need some advanced examples to have a look at.

12:25 <haakonn> aren't the canonical calculator examples advanced enough? :)

12:26 <haakonn> i found their treatment in the o'reilly book instructive

12:35 <ulfdoz> haakonn: thx, I haven't recognized the chapters on first sight.

12:35 <haakonn> it's a thick book :)

12:37 <haakonn> also i used the ocaml manual to learn about them. i thought the example there wasn't very good, but the tools are described well

12:44 <ulfdoz> My biggest problems are in design and interoperability of lexer and parser. Sometimes I'm not sure, where to construct a value.

15:25 <Smerdyakov> ulfdoz, can you be more specific?

17:47 <ulfdoz> Smerdyakov: I try to. As I understand it, the lexer simply returns a token with each call. As there are several types of tokens, a natural way would be, to return the input simply word by word without any transformation in some dummy type Token of string, the parser gets this abstract token and has now to decide, whether it is a Bracket, a control struct or something similar or a string. The other way would be, to determine the special type of token

17:48 <Smerdyakov> Always determine the special type of the token. It makes your life much easier.

17:48 <Smerdyakov> Have a token constructor for each keyword, etc..

17:48 <ulfdoz> Am I right? This only works for context free grammars?

17:49 <Smerdyakov> In general, yacc only works for CFGs, yes.

17:49 <Smerdyakov> Well, that's not entirely true.

17:49 <Smerdyakov> You can do some processing in your rule bodies which allows more complicated language recognition.

17:50 <Smerdyakov> But this really isn't relevant to standard uses.

17:50 <ulfdoz> The application is sieve for the moment. Shouldn't be to hard, I hope.

19:42 <sethk> in the manual, core language, this syntax for type appears without being explained: type idref={mutable id: 'a. 'a -> 'a } Is that like a lambda syntax, \x.x? I understand 'a -> 'a; the function takes a value of some type and returns a value of the same type.

19:42 <sethk> but 'a. appears here with no explanation. I see that ocaml knows that a function is involved

19:43 <__DL__> it is a polymorphic field

19:43 <sethk> yes, I understand that

19:43 <sethk> but I don't see a reason for the first 'a in 'a. 'a -> 'a

19:43 <sethk> there is the type of the argument, 'a, and the type of the value returned, 'a

19:43 <__DL__> the first 'a mean : forall 'a the type is 'a -> 'a

19:43 <sethk> but what is the third 'a for?

19:44 <sethk> I can't see any situation where 'a -> 'a would appear where it would not be for all 'a

19:44 <__DL__> it is too make the diference with type 'a idref = {mutable id: 'a -> 'a }

19:44 <sethk> ok, which means what?

19:44 <sethk> what is different?

19:44 <sethk> I see no restriction on 'a in your example

19:44 <__DL__> in your example, something of type idref must contain a function that must accept an argument of anytype

19:45 <Smerdyakov> Consider these two functions:

19:45 <Smerdyakov> let idPoly x = x

19:45 <__DL__> in my example, soemthing of type (for example) int idref must containt an int-> int function

19:45 <Smerdyakov> let idInt (x : int) = x

19:45 <Smerdyakov> This has type idref: {id = idPoly}

19:45 <__DL__> when something of type float idref must contain a float -> float function

19:45 <Smerdyakov> This has type int parametric_idref, but not idref: {id = idInt}

19:49 <sethk> ok, taking __DL__'s example, I still don't see where the 'a. 'a -> 'a would occur where a function that returned, say, int would not also take an argument of type int

19:49 <sethk> I'm not sure if that makes sense since I'm missing the point

19:50 <sethk> is there a second function involved, so that some function is assigned to id, and that function returns another function of, say, the type int -> int?

19:50 <__DL__> well, I need example.

19:51 <sethk> __DL__, not sure what you mean. The manual pops in with type idref = { mutable id: 'a. 'a -> 'a };; There is nothing else

19:51 <sethk> then they have a let like this: let r = { id = fun x -> x};;

19:51 <sethk> which ocaml then infers as the type: val r : idref = { id = <fun> }

19:52 <sethk> and I don't understand how to interpret that

19:53 <__DL__> just one example :

19:53 <__DL__> type poly_idref = {mutable id1: 'a. 'a -> 'a };;

19:53 <__DL__> let f x = x;;

19:53 <__DL__> { id1 = f };;

19:53 <__DL__> let g x = x + 10;;

19:54 <__DL__> { id1 = g };;

19:54 <__DL__> try this, and see what appen

19:54 <__DL__> then compare with

19:54 <sethk> O

19:54 <__DL__> type 'a param_idref = {mutable id2: 'a -> 'a };;

19:54 <sethk> I'm completely lost, because id1 is part of a _type_. How can I assign something to it?

19:55 <sethk> the type itself changes, and has a current value like a global variable?

19:55 <__DL__> id1 is the name of a field. { id1 = f } is an objacte of type poly_idref, where the field id1 contain f

19:55 <sethk> I don't see how you create an object by declaring a type

19:55 <__DL__> s/objacte/value/

19:55 <__DL__> you don't

19:55 <sethk> ok, then I don't see how you create a value by declaring a type. :)

19:56 <__DL__> you create a new kind of value, and { id1 = f } is just one of those value

19:56 <sethk> I haven't used let. The only appearance of id1 anywhere is within your type statement.

19:56 <sethk> so what is f being assigned to?

19:57 <__DL__> type t = { a : int } create a new record type

19:57 <__DL__> having one field, a of type int

19:57 <sethk> it seems like by declaring the type, you've created a persistent thing, with a global name, that can be assigned to creating a current value of a type

19:57 <__DL__> No no, no

19:57 <__DL__> you create a new kind of value

19:58 <sethk> where? what value?

19:58 <__DL__> when you wrote { id1 = f };; then { id1 = g };; you try to create two different value of type poly_idref

19:58 <__DL__> but both id1 are different, each in a different poly_idref record

19:59 <sethk> when I enter your {id1 = f };;, ocaml says: - : poly_idref = {id1 = <fun>}

20:00 <__DL__> that mean that the expresion "{id1 = f }" have type poly_idref and value {id1 = <fun>} (where <fun> mean that this is a function that can't be printed)

20:00 <sethk> but that value isn't preserved anywhere

20:00 <__DL__> yes

20:00 <sethk> the only way to reference it is poly_idref

20:01 <__DL__> it is just an example to show you that when you wrote { id1 = g } caml will complain

20:01 <sethk> so I've changed the meaning of poly_idref until I decide to do another { id1 = something } ?

20:01 <__DL__> no, it is lost. It is just an example. The value have been created, and is imediatly lost scince I dont put it into a variable

20:01 <sethk> well, ok, but that doesn't tell me how I would actually use something like this.

20:02 <sethk> I could create a value? I could say let z = {id1 = f};; ?

20:02 <__DL__> yes

20:02 <__DL__> then you could wrote z.id1 to have the function in the id1 field of z

20:02 <sethk> so that means that I've created the equivalent of a global variable, id1, and when I reference id1 I change poly_idref

20:02 <__DL__> NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

20:03 <sethk> well, I never typed poly_idref, did I? I only typed id1

20:03 <sethk> let z = { id1 = f } ;;

20:03 <sethk> val z : poly_idref = {id1 = <fun>}

20:03 <__DL__> ok, I see

20:03 <__DL__> ocaml is intelligent, it know that id1 is a field of the poly_idref type

20:04 <__DL__> and find (alone) that you want to refer to this type

20:04 <__DL__> in C you would have, to do the same, to wrote the type

20:04 <sethk> what if I create another type and use the name id1 again?

20:04 <__DL__> Then, you will have a problem

20:04 <__DL__> one should not have two record with the same field name in the same module

20:05 <__DL__> (but you could do it if you put them in different module (say file for a starter))

20:05 <sethk> obviously. So I've got a global variable, and if I use it again, I create ambiguity which ocaml doesn't flag.

20:06 <__DL__> it is not a global variable, and there isn't realy an ambiguity : ocaml use the last declared one

20:06 <sethk> the line: z = { id1 = f };; does not stand alone, it depends on the most recent reference to id1

20:06 <__DL__> the most recent type declaration with such field

20:07 <sethk> ok, I guess I can't use that feature and preserve the usual protections you would expect in a functional language. Since mutable is imperative, I guess that's to be expected

20:07 <__DL__> note that let z = { id1 =f };; let y = { id1 = g };; will create two value with no conection betwen them

20:08 <sethk> yes, I see that, but you still are unprotected from using the same name twice, which would absolutely happen in code of real life complexity. Even a C compiler can generate a warning about that.

20:08 <__DL__> well, an module should ba of a reasonable size, and there is no problem.

20:09 <__DL__> I still have the impression that you missunderstood me.

20:09 <__DL__> if you do :

20:09 <__DL__> let z = { id1 =f };;

20:09 <__DL__> then

20:09 <sethk> no, I understand, I'm just surprised that such a name clash wouldn't be flagged. Maybe a non-interactive compile would flag it.

20:09 <__DL__> let y = { id1 = g };;

20:09 <__DL__> maybe, i don't remeber

20:10 <__DL__> note that the toplevel is to be seen as a developer tool to make some test

20:10 <__DL__> not as an end user thing

20:10 <__DL__> (well, it is also usefull to learn and teach ocaml)

20:11 <sethk> yes, I understand that. The book talks about doing ocaml -c, but I just tried that and it doesn't work. Maybe the compiler has a different name.

20:12 <__DL__> it is ocamlc -c, not ocaml -c

20:12 <sethk> yes, I see that. The book doesn't.

20:12 <__DL__> which book ?

20:13 <sethk> an on line thing. It's a misprint; ocamlc appears later in the same page

20:14 <sethk> no warning, though.

20:14 <__DL__> well, you will have error when you use them

20:15 <sethk> ok, I'll have to try that

20:15 <sethk> the docs I've read so far are quite good, except in a few places they do something out of left field and don't explain it.

20:23 <sethk> I see what they are doing. They are giving you a way to hack around the fact that the compiler can't infer a particular type of polymorphism. Possibly the fourth page of the introduction is not the best place to do that. :)

20:32 <__DL__> yes, it is not the simpleur things in ocaml...

20:35 <sethk> it's kind of subtle if you are just starting to figure out how types work in the first place