Okay, I think this is a good point. As systems languages like BitC are not interpreted (byte code) either there needs to a hole in the type system like addrToHValue# in Haskell (which I have used to implement dynamic module loading) or you need two things:
- run time type information - a way to associate the RTTI with a shared object that is loaded. All you would need to do is write a data table with the required type information as part of the output to the shared object, and then check on loading that the expected static types match the types in the method table added to the shared object in a runtime loader. However this would require runtime support, and I think systems languages should have no runtime (or as minimal as possible). I think the Haskell solution is better. Include an unsafe address to value function, and allow external 'C' functions to be called. Then you can write the type-safe dynamic loader as a library. K. On 14 July 2015 at 09:31, Matt Rice <ratm...@gmail.com> wrote: > On Mon, Jul 13, 2015 at 7:50 PM, David Jeske <dav...@gmail.com> wrote: > > > > On Jul 13, 2015 8:26 AM, "Keean Schupke" <ke...@fry-it.com> wrote: > >> I agree until the "unlike C++". Clearly you can implement all this in > C++, > > > > This argument is not helpful to understanding c++ capabilities. > > > > Turing completeness already says we can implement anything in any of > these > > systems, even if it means implementing the other system. We are talking > > about how different languages solve problems in their native constructs, > not > > what one can theoretically implement (which is the same for all turing > > complete languages). > > > > What we are talking about is how the native language structures are > handled > > by the runtime. > > > > In known C++ compilers, base class size, vtable layout, parametric > > instantiation and instance variable layout are hard coded at compile > time. > > In objc/swift/clr/java, these are all resolved dynamically at load time. > > This enables many binary compatible dll updates which are not possible in > > c++ (* when actually using c++ language features) > > Just to add to what David is saying, If the native language does not > support it, > the simplest way to implement it is going to be through unsafe pointer > arithmetic > and implementing it in a safe language which doesn't support it is > likely to end up with something completely alien to the host > language... > _______________________________________________ > bitc-dev mailing list > bitc-dev@coyotos.org > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
