08:51 <ninjaaron> I'm trying to grok locally abstracted types, and I'm having a hard time. c.f. https://caml.inria.fr/pub/docs/manual-ocaml/locallyabstract.html

08:52 <ninjaaron> what is a "type constructor" in this context?

08:52 <ninjaaron> This isn't like a constructor in a variant, right?

09:04 <zozozo> ninjaaron: list is a type constructor because it takes a type (for instance int), to create a type (e.eg; int list)

09:05 <zozozo> though in the case of the manual page you listed, a typeconstr-name is typically just a type variable

09:06 <zozozo> or rather a locally abstract type (which can be used in more places than a simple type variable)

09:10 <ninjaaron> Thanks zozozo. The sentence I'm looking at is the first one: The expression [...] introduces a type constructor named `typeconstr-name` which is considered abstract in the scope of the sub-expression, but then replaced by a fresh type variable.

09:11 <ninjaaron> However, in the example code, it doesn't look like it's dealing with a type constructor in the sense of `list`.

09:11 <zozozo> indeed I slightly mispoke at first

09:12 <zozozo> what's introduced is what the section title says: a locally abstract type

09:13 <ninjaaron> I guess I don't know what that means. I just use it in ignorance to make my GADTs work.

09:13 <zozozo> (which actually coincides with the notion of a type constructor such as list but with 0 arguments (whereas list takes 1 argument))

09:14 <zozozo> well, in practice it's mainly used when using GADTs (or recursive functions), to specify a polymorphic type that would not be inferred

09:16 <ninjaaron> What I don't get is how adding the locally abstracted type makes it inferable. I'm quite new to the algebra of types.

09:17 <ninjaaron> and I don't understand when I should use `type a.` as opposed to `(type a)`

09:17 <zozozo> well, it doesn't magically makes things inferrable but usually, you use the locally abstract type introduced to specify the type of arguments (or the function's return value), which contrains the inference, and then once the body of the function has been typed, and the function need to be assigned a type, the locally abstract types are turned into type variables, which makes the function polymorphic

09:17 <zozozo> in thos type variables

09:19 <ninjaaron> Ah!

09:20 <ninjaaron> So, it forces a type to be "generic" instead of allowing the function to infer a concrete type?

09:20 <zozozo> indeed

09:20 <zozozo> that's one of the use of it

09:20 <ninjaaron> Thanks so much!

09:20 <ninjaaron> That makes sense.

13:07 <Leonidas> companion_cube: haha, the test from your PR actually showed a change in behaviour in my PR.

13:20 <companion_cube> :o

13:20 <companion_cube> what's the change like?

13:23 <Leonidas> companion_cube: a bug, I was outputting \0000 instead of \u0000. So that's very neat!

13:23 <Leonidas> Hatemail from Travis stopped

13:24 <companion_cube> wooooo!

17:29 <jco> Hi! using cohttp i retrieved the body of a post request: id=good&filename=gg&...

17:29 <jco> are there methods to parse the request and extract the fields?

17:30 <jco> i was thinking of matching the string with regexps

17:38 <jco> ah there's a to_string_list function for that

21:06 <ollehar> how about making mutability a subclass of immutability, so you can cast the first to the other (but not the other way around)?

21:08 <ollehar> subtype*

21:49 <ziman> hell, my program calls a C readLine function for each line in a file, puts the lines in a list, and when it tries to concate all those lines, it hits binary garbage. GDB says that the corrupted address was written to by GC so I suspect that the strings I read are not registered with GC properly somehow. However, my C function uses CAMLlocals1(ret_str) and CAMLreturn and everything. Are there other

21:50 <ziman> common gotchas that could cause similar behaviour?

21:50 <ziman> Apologies for the vagueness of the question; the code is generated via Malfunction so it's not easy to paste a MFE.

21:51 <ziman> so i thought i'd ask anyway in case there's something that people hit frequently

21:51 <ziman> s/hell/hello/ :D

21:53 <ziman> the readLine function uses caml_copy_string()

21:58 <ziman> oh, hang on, i found something

22:17 <ziman> i'm probably mixing up (char *) and value somewhere

22:17 <ollehar> heh, Hoar saying that references are as bad as goto

22:17 <ollehar> 1973

22:47 <ollehar> "eferences are likejumps, leading wildly from one part of a data structure to another. Their introductioninto high level languages has been a step backward from whichwe may never recover"

22:48 <ollehar> 50 years later...