CG-03-03.md

CW: In the proposal, my understanding is that the structural subtyping relationship would be pre-computed ahead of time, so you don't get quadratic behavior.

RT: There’s a few things that come up, if you have large classes that table gets really bit, the precompiler phase gets really big - you could try to move stuff from the compiler phase.. Could try amortizing these costs. When you have polymorphism, you will have types/casts whose types are determined at runtime, that approach is made effective by canonicalization. At runtime you have to got through the canonicalization process, there’s a lot of heavy machinery to make that work.. We need implementation, a whole thorough test like a big Java implementation to make sure it works, hard to predict

<back to slides - nominally tagged casts>

JP: Are these slides available? [RT: I'll put them up],

JP: The proposal I know of is the GC proposal, the alternative is?

RT: The secondary one is an alternative... here's the link:

https://github.com/soil-initiative/gc/pull/1/

RT: We tried having a discussion about what can we do to improve this? There was a discussion about existential types, we haven’t had a chance to discuss it yet

AK: Andreas was on vacation this time -- there's a plan to put a GC subgroup together. That's a good place to have a focused discussion on structural subtyping working. In a smaller setting, with focus in that area.

RT: Mostly wanted to present, agree that we should not be hashing out what to do right now - having someone new come in and give a big proposal is not ideal, but realized that the reasons why we did this was not documented out. Looking for feedback on the structural approach and how it would work out with all the situations that were outlines

BS: Read through PR, it’s very comprehensive - a lot of it is potentially not something ina first version - wasn’t clear to me which parts are useful to be in a first version and which ones not

RT: We roadmapped much further down the road than what we have planned for now, we tried to find a middle ground of showing a roadmap without going all the way, part of the roadmap is staging the releases - if this is the direction to go then we should have a discussion about figuring out what to target, as well as plan for the next releases. We talked about how dynamic languages have the switch thing, but that’s something we can add later on - it’s useful to know that’s there for..

AZ: In the talk here we mentioned 2 GC proposals. But there's another proposal (Wouter's) that exists too.

RT: I was also talking with Arjin (sp?) that may help have GC better support interop between modules, which Wouter's path is specifically not wanting to do. Arjin's idea is -- if we just wanted to support GC languages better, then what could we do to compile GC objects to linear memory, then have language stack walk and create their own GC themselves. So that's potentially another path.

TL: Thinking about the module interop story, that’s a big discussion we should have - should the GC proposal define interlanguage GC issues? My question is how that would work at the course level? I don’t know of any languages that have the ability to import any arbitrary arrays at the source level

PP: I also have the same question

PP: I agree, outside of C you can't really do that at the source level.

RT: Even for the GC languages w/ a runtime. They may want them to be implemented in c/c++ languages, and still want to be able to reason about GC objects. If we come up with something like that -- like the crypto example. Suppose it was written in C++. But we come up with some way to use C++ code through imports/tooling/etc. So it could take an array -- not a C++ array, but some GC array -- all I care is that it has an indexing operator. Then I can write my code, and it could compile down to that example.

TL: Sounds like the tooling story would be pretty similar to interface types, the source language unmodified isn’t able to do anything, but the tooling will have to figure out how to make these things work together.

RT: There might be other strategies for figuring this out -- this is probably the most obvious way. May be orthogonal to the GC discussion. No matter what proposal you pick, this problem is going to come up.

PP: We don’t even have.. We don’t even know if they’ll support it yet - we can’t really support or talk about interop between C ?& Java because that’s not supported yet.. So unsure how to discuss it. ..

RT: The clarification is -- we were not discussing language interop, we were discussing GC/non-GC interop. C++ code that needs to be able to reason about GC references. It's possible that you could do that in ways that C++ code interop with other languages -- but GC/non-GC interop is the bigger question.

PP: It's the same thing as if you want to call a C function from Java...

Closure