6 ms·
> To keep the guarantees you expect inside your typed code, you have to figure out how to handle untyped data that flows into it. This would be solved in a co
by willtim 9y ago
> To keep the guarantees you expect inside your typed code, you have to figure out how to handle untyped data that flows into it.
This would be solved in a conventional static type system by forcing the user to eliminate the variant, and forcing the user to deal with the case that it has an unexpected value.
So I cannot see why even C# dynamic is necessary, except to perhaps save some thinking, but this isn't a good thing IMHO.
- avip 9y agoThe dynamic type was added to C# to facilitate interoperability (ex. DLR), not so much to encourage lazy devs to get their bugs at runtime rather than compile time.
- pjmlp 9y agoAdditionally to simplify dynamic dispatch calls on COM.
- willtim 9y agoI still do not understand why this cannot be done via a Variant type. Also it doesn't explain why Dart 2 has a similar feature.
- barrkel 9y agoThink of dynamic as a different word for Variant. The semantic differences for OLE2 Variants vs C# dynamic mostly only exist in implementation protocols.
- masklinn 9y ago> I still do not understand why this cannot be done via a Variant type. Makes little difference, either way you need a magical type since it has to allow any method call at compile time, and then requires enough RTTI that it can check for and dispatch method calls at runtime. Whether you call it Variant or dynamic has no relevance.
- ufo 9y agoThe problem munificent was talking about is that for more complex types you cannot write that type checking predicate you want, which would check if a value belongs to the given type and return a variant-free version of the object. For example, if you have a reference to an array of integers in the typed part of the code you need to protect against untyped parts of the code inserting non-integers inside the array. The only solution is to insert typechecks in the reads and/or writes to the array (there is more than one way to do it, with different tradeoffs in expressivity and performance). A similar problem happens with functions: if you try to give a static type to a function with a dynamic implementation you can't just make the check at that point. You also need to insert type checks after every call, to see if the return value has the expected type (and again there is more than one way to do it...)
- munificent 9y agoThis is exactly right. It's a subtle, complex problem that isn't apparent until you start really digging into these kinds of type systems. It's really hard to define the right membrane around the untyped code and values as they flow through your program into typed regions while giving you the safety and performance you expect inside the typed code.
- willtim 9y agoI respectfully disagree. The "right membrane" around any untyped value is a Variant type. A static type system would then stop you making any assumptions without unpacking and asserting its type. If we don't want variants and just want to defer type errors until runtime, then this is possible too (GHC Haskell can do this).
- ufo 9y agoGHC's Dynamic type can only contain monomorphic values, it can't handle polymorphic stuff. GHC also considers Dynamic->Dynamic and Int->Int to be incompatible types, which is not quite what one would want in a gradualy typed setting. Haskell also sidesteps the difficulties that come with mutability in a gradualyly typed setting.