* Alexander S. <alex0pla...@gmail.com> [2013-11-08 08:22:37 +0400]: > There seems to be some misunderstanding about what is type-safety and > when checks are made.
as i said this static type-checking fantasy does not work without runtime type information, not because you need any further checks at runtime, but because each type has different representation (abi call type class, inmemory alignment, size, etc) (x86_64 type classes with different argument and return value passing methods: memory, integer, sse, sseup, x87, x87up, complex_x87, no_class) > They are actually made when you are calling a function with signature > described above. I used higher-order lambda to express the notion > that, for example, an extra argument in pthread_create is the same > type as the only argument to its entry point. To the *implementation*, > these are just opaque pointers. We don't get our typechecking by > substituting templates and checking that calls don't violate the > rules; something more beautiful is going on here. (C++ templates don't > support type lambdas, sadly). the opaque pointers work if you convert them to void* and back (the c way), you could make that safer probably in this particular case, but only for single object pointers, not what you described earlier (passing arbitrary number of arbitrary objects) the callback still has to accept a void* argument, but a parametrized void*: the representation and call abi would be as if void* is passed, but the type-checker can take the parameter as a hint about the type that is implicitly converted to this void* as you can see it's more complicated and less useful than what you described, different pointers are not the same (eventhough on most architecture they are, the compilers treat them differently for various reasons) you can fix a few type-unsafe cases with this, but not all, and the consequence is that the type of the caller and the callback functions become much more complicated (it's already hard to write down function pointer types in c, there is a reason why ml had to invent type inference, you don't want to go there with c) > Structures are usually passed by pointer anyway if they don't fit in > 64-bit register, I believe? no you underestimate the complexity of what you want to do and overestimate its benefits any solution should take into account the current c call abi on widely used architectures, otherwise it's useless, unfortunately modern languages approach the problem from high-level abstract type-theory (which is the easy part of the challenge) instead of the hard facts about the arch abis (making it a pain to interact with existing systems if that's possible at all)