Andreas Rossberg

The current docs do not incorporate generative types yet, neither statically nor dynamically. If we add nominal types then of course we'd also want to add generative RTTs. However, that...

I would argue that that the necessity to add a rich collection of binding operators would be a failure mode.

Agreed. In a first approximation that implies that there are going to be only two binding expressions per IDL type: one mapping to memory and one to GC types. And...

That's an excellent point. I think with the new bulk operators it makes total sense to treat active segments as a legacy feature that cannot be combined with any new...

The other way in which the segment bounds check can fail is if the offset given in the segment is determined by an imported global, and that is somehow off....

@sabine: > Then, static code specialization kills one nice feature of OCaml: separate compilation of modules. That would be the smallest problem. More importantly, as you note in your edit,...

Consider a function like this one from the Map interface: ``` val mapi : (key -> 'a -> 'b) -> 'a t -> 'b t ``` This is polymorphic in...

> the concerns are fairly specific to OCaml due its use of specifically 31-bit arithmetic. No, they're not, and it's getting a bit boring at this point that I have...

> To clarify, I was not suggesting specializing polymorphic functions based on their type arguments. I was suggesting coercing monomorphic functions that work specifically on integers to polymorphic functions Oh,...

@aardappel, repeating what I pointed out above, and I believe many times before: static type specialisation _does not work_ in a language with first-class polymorphism or polymorphic recursion. Simplest possible...