05:46 <d_bot> <beheddard> ok, so after much head banging, I have suspicions about what is going on...

05:47 <d_bot> <beheddard> Is it a known or expected thing that allocations with Ctypes need to be happening at the top level?

05:49 <d_bot> <beheddard> all of the testing functions are happening within closures, and they pretty well hang forever when ran. But if the same code is placed at the top level of a file and compiled to executable, or run in utop, they work just fine.

05:52 <d_bot> <beheddard> Do references to pointers need to exist on the toplevel in order to ensure that allocation actually happens, or to prevent the GC from destroying them? I would have though that any existing ocaml reference would be fine, even if it is within a scope below the top level. Anyway, am a bit confused and nothing I have turned up so far would have had me predict this

06:11 <Fardale1> @mbacarella I don't know

08:38 <d_bot> <khady> talking about better error messages, what happened to the work of Arthur Charguéraud? It has been totally abandonned?

08:54 <d_bot> <octachron> The small improvements have been integrated, the part that rely on a duplicated and partial typechecker are not really usable. Some of the idea might be revisited after the typechecker 2.0 but don't hold your breath on that.

15:42 <cemerick> I was surprised that I needed to eta-expand `is_b` here: https://gist.github.com/cemerick/f674e46b149ea7f90a23154d2b200f52

15:43 <cemerick> (`%>` is the usual compose operator BTW)

15:44 <cemerick> the domain of `is_a` is known and closed, so I expected the same to be inferred for `is_b`

15:44 <d_bot> <Drup> `#a` is equal to ``[< `A]``

15:44 <d_bot> <Drup> so there is some polymorphism hidden there

15:46 <companion_cube> hmm, is `#a` like `<A` in contravariant position, and `>A` in covariant positions?

15:46 <d_bot> <Drup> you could say it like that

15:46 <d_bot> <Drup> Actually, `#a` in pattern is always going to be in negative position, so the question is moot

15:47 <companion_cube> but in type definitions it can be in positive position

15:48 <cemerick> Drup: it's a _silly_ sort of polymorphism though, at least as far as what `is_a` accepts

15:48 <cemerick> i.e. if I declare it like `is_a : [`A | `B] -> bool`, then the nominal polymorphism is waved away, and `is_b` is accepted as-is

15:49 <d_bot> <Drup> *shrug*

15:49 <cemerick> likewise, I guess

15:49 <d_bot> <Drup> It's the one that accepts most valid programs

15:50 <d_bot> <Drup> the value restriction issue is only going to trigger at module boundary

18:42 <hockpa2e> Just curious, why does the coerce-to-supertype operator :> point in the opposite direction to what the subtype relation <: would be? I guess you could say it's like an arrow pointing in the direction of the coercion, but is there a theoretical meaning to it?

18:44 <companion_cube> maybe it's a parsing matter

18:45 <hockpa2e> good point, companion_cube, I never thought of that