* Alexander S. <alex0player_AT_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)
Received on Fri Nov 08 2013 - 17:00:38 CET