3 ms·

I've not used the CLR, but the one thing I noted in Gilad Bracha's recent post on generics ( https://gbracha.blogspot.com/2018/10/reified-generics-search-for-cu

I've not used the CLR, but the one thing I noted in Gilad Bracha's recent post on generics ( https://gbracha.blogspot.com/2018/10/reified-generics-search-for-cure.html https://gbracha.blogspot.com/2018/10/reified-generics-search... ) was his claim that the CLR makes implementing and using dynamic languages difficult: > In systems designed to support multiple programming languages, reification brings a different problem. All languages must deal with the complexity of reification; worse they must conform to the expectations of the reified generic type system of the "master language" (C# or Java, for example). > Consider .Net, the poster child of generic reification. Originally, .Net was intended to be a multi-language system, but dynamic language support there has suffered, in no small part due to reification. Visual Basic was a huge success until .Net came along and made it conform to C#. And what Iron Ruby/Python programmer ever enjoyed being forced to feed type arguments (whatever those might be) into a collection they are creating? Not saying CLR's approach is bad; just that it doesn't seem like an example of one-size-fits-all as is sometimes claimed (and the same goes for the JVM, etc. too)

int_19h 8y ago
This particular snippet that you quote talks about dynamic languages that want to interop with the rest of the CLR language ecosystem. Because CLR provides a strong static type system that has reified generics, it means that dynamic languages have to devise ways to interop with that system. For example, if you're in IronPython, and you want to create a list that is strongly typed from C# perspective, you have to do something like this: from System.Collections.Generic import List lst = List[str]() lst.Add(123) obj.DoSomething(lst) However, this is only an interop problem. A dynamic language targeting the CLR that does not care to interop with C# does not have to do anything special. And none of this has anything to do with the GC - that operates on a level far lower than anything to do with generics. (I would also claim that the quoted snippet vastly overstates the problem, while also misrepresenting it - it has all to do with static/dynamic type system mismatch, and practically nothing with reification. In practice, if you want to interop between C# and Python, you'd just use "dynamic" in C#, and access native Python collections directly - that's exactly the scenario it's intended for. The only time you'd need to muck around with generics from the Python end is when you're calling into a library written with C# - but that's just FFI, no different in principle than having to specify types when you're using ctypes to invoke into C.)
yoklov 8y ago
Reification seems pretty unrelated, as Wasm doesn't have an equivalent concept.

int_19h 8y ago

This particular snippet that you quote talks about dynamic languages that want to interop with the rest of the CLR language ecosystem. Because CLR provides a strong static type system that has reified generics, it means that dynamic languages have to devise ways to interop with that system. For example, if you're in IronPython, and you want to create a list that is strongly typed from C# perspective, you have to do something like this: from System.Collections.Generic import List lst = List[str]() lst.Add(123) obj.DoSomething(lst) However, this is only an interop problem. A dynamic language targeting the CLR that does not care to interop with C# does not have to do anything special. And none of this has anything to do with the GC - that operates on a level far lower than anything to do with generics. (I would also claim that the quoted snippet vastly overstates the problem, while also misrepresenting it - it has all to do with static/dynamic type system mismatch, and practically nothing with reification. In practice, if you want to interop between C# and Python, you'd just use "dynamic" in C#, and access native Python collections directly - that's exactly the scenario it's intended for. The only time you'd need to muck around with generics from the Python end is when you're calling into a library written with C# - but that's just FFI, no different in principle than having to specify types when you're using ctypes to invoke into C.)

yoklov 8y ago

Reification seems pretty unrelated, as Wasm doesn't have an equivalent concept.