Codd 1970 'domain' does not mean Date 2016 'type' [was: burble about Date's IM]
Quote from johnwcowan on November 4, 2019, 7:34 pmQuote from dandl on November 4, 2019, 12:15 amTo me, a dynamic type is a type that can be created at runtime.
Okay, then we really are on different tracks. By "dynamic type" I mean "type of a value or, in languages with mutable objects (a superset of values) of an object".
You're still not being at all clear. A type is a set of values and a value belongs to a type (more than one in the IM). Types are static, values are static, the relationship of values to types is static. In some languages type checking is static, in some it is dynamic, in others a bit of both. Values returned by a computation or stored in a variable at runtime are dynamic in the sense that they vary over time. In a few languages types are also values, so can be dynamic in that same sense.
What exactly do you say is 'dynamic'? and what on earth is a 'superset of values'?
A few languages have that, but very few,
Languages with reflection certainly do: you can create new classes out of nothing on the JVM using ASM at the level of bytecode (equivalent to
System.Reflection.Emiton the CLR) or Janino at the level of Java 1.4. Of course you have to declare them as implementing a statically known interface.libtccmakes the same things possible in the C world.
Those are not language features. Every compiler is necessarily written in some programming language and when you create new classes that way you are replicating some of the features of a compiler. There are no dynamic types in C#, or Java, or C.
So do languages with
eval, which is also reflective: you can for example eval a class definition in Python that you have constructed.
Ditto. You are invoking the compiler from the execution of a program.
Finally, there are actual meta-object protocols, where the class/method/etc. system is exposed directly to the user through ordinary method calls. This is semi-standard in Common Lisp (it was removed from the actual standard at the last minute), available in all Smalltalks (though the ANSI standard, which is based mostly on standard interfaces rather than standard classes, doesn't have it).
Those are the only ones I would admit to this very select group. The key feature is they have a runtime 'class of class' and/or something with a name like 'metaclass', and classes exist as values at runtime. There is nothing remotely close to that in Java, C#, C, Python, etc. Only compilers.
I wrote:
In the case of the IM, the sole difference is that the value is a member of one or more types that are themselves part of a type hierarchy. There is nothing dynamic about it, and as far as I know, no type failure can occur at runtime (except through the explicit use of a cast).
Now that you know what I mean by dynamic type, perhaps you can see its relevance: the dynamic type of a value is its MST (I think).
No it really isn't. A value in the IM is always and forever a member of one or more types. For some purposes it is necessary to pick one of those types (the MST) according to a set of rules. The MST of a value is static, the MST of the results of an expression are the MST of that value. I still have no idea where the concept of dynamic type is supposed to fit in.
Quote from johnwcowan on November 4, 2019, 7:34 pmQuote from dandl on November 4, 2019, 12:15 amTo me, a dynamic type is a type that can be created at runtime.
Okay, then we really are on different tracks. By "dynamic type" I mean "type of a value or, in languages with mutable objects (a superset of values) of an object".
Those are curious definitions. Dynamic type generally refers to a characteristic of a value reference (i.e., variable, parameter, constant) that it can be assigned values of any type at runtime.
This is distinct from static type, which generally refers to a characteristic of value references that can only be assigned values of specified (or inferred) compatible types at runtime, and thus can be statically type checked at compile-time.
The latter does not necessarily preclude dynamic type checking, which may still occur to verify that an assigned value belongs to a subset of types in the set of compatible types.
Quote from dandl on November 5, 2019, 12:51 amYou're still not being at all clear.
Evidently. I really do think that we are like the landlords of the two pubs on opposite sides of the street who are yelling at each other out of their upper-story windows: we will never agree, for we are arguing from different premises.
What on earth is a 'superset of values'?
The set of all objects (in the usual OO sense) is a superset of the set of all values, for objects may be mutable or immutable, whereas values are by definition immutable.
Those are not language features. Every compiler is necessarily written in some programming language and when you create new classes that way you are replicating some of the features of a compiler. There are no dynamic types in C#, or Java, or C.
You said that only a few languages could create new classes at runtime. I show you how classes can be created at runtime, and you say "no true Scotsman". Certainly saying that System.Reflection.Emit is a compiler is stretching the definition of the term.
[Languages with meta-object protocols] are the only ones I would admit to this very select group. The key feature is they have a runtime 'class of class' and/or something with a name like 'metaclass', and classes exist as values at runtime. There is nothing remotely close to that in Java, C#, C, Python, etc. Only compilers.
Java has java.lang.Class, whose values are run-time classes, and Class.class is the metaclass (unlike Smalltalk, there isn't a metaclass for every class). Googling for ["meta-object protocol" "java"] found this rather old implementation. Python's MOP is explicitly so called and was inspired by the Common Lisp MOP, though it is considerably weaker. Perl's MOP is in the CPAN library and is quite strong. Ruby's MOP is basically Smalltalk's. These are all, of course, reflective: there's no getting away from that.
Quote from Dave Voorhis on November 5, 2019, 8:26 amThose are curious definitions. Dynamic type generally refers to a characteristic of a value reference (i.e., variable, parameter, constant) that it can be assigned values of any type at runtime.
I would say that's a definition of dynamically typed expression or by extension dynamically typed language. For me, as I have said, a dynamic type is a set of run-time objects with a name; shared behavior is generally implied.
This is distinct from static type, which generally refers to a characteristic of value references that can only be assigned values of specified (or inferred) compatible types at runtime, and thus can be statically type checked at compile-time.
I'd add "expression" to your list "variable, parameter, constant". In C, 1 + 2 has a static type of int just as much as 3 does.
Quote from johnwcowan on November 5, 2019, 5:18 pmQuote from Dave Voorhis on November 5, 2019, 8:26 amThose are curious definitions. Dynamic type generally refers to a characteristic of a value reference (i.e., variable, parameter, constant) that it can be assigned values of any type at runtime.
I would say that's a definition of dynamically typed expression or by extension dynamically typed language. For me, as I have said, a dynamic type is a set of run-time objects with a name; shared behavior is generally implied.
But expressions are almost invariably statically typed in languages with dynamically typed variables & parameters.
I suspect we'd all agree here if we were identifying parts of a specific language, rather than talking in these rather abstract terms.
Quote from johnwcowan on November 5, 2019, 5:10 pmWhat on earth is a 'superset of values'?
The set of all objects (in the usual OO sense) is a superset of the set of all values, for objects may be mutable or immutable, whereas values are by definition immutable.
So are you trying to say: all values are objects, but not all objects are values, because some of them are mutable? Apart from being obviously wrong (integers are not objects in Java), what point are you trying to make?
Those are not language features. Every compiler is necessarily written in some programming language and when you create new classes that way you are replicating some of the features of a compiler. There are no dynamic types in C#, or Java, or C.
You said that only a few languages could create new classes at runtime. I show you how classes can be created at runtime, and you say "no true Scotsman". Certainly saying that System.Reflection.Emit is a compiler is stretching the definition of the term.
And I stand by that. These are features that stand outside the language definition, are not found in the language standard, and depend on implementation-dependent libraries that are identical in effect to emitting source code and issuing a system call to run the compiler. I have written a compiler using Reflection.Emit, I have created classes using AssemblyBuilder and ModuleBuilder, I know them well. They do not make C#, Java etc "dynamically typed", ie with dynamically created types a feature of the language, which was the point at issue.
The point at issue was actually: what do you mean by "dynamically typed"? We were debating the IM type system, in which the types are patently static (known to the compiler, not created at runtime), but you seemed to take a different view. Do you care to restate it now?
Quote from dandl on November 6, 2019, 12:53 amSo are you trying to say: all values are objects, but not all objects are values, because some of them are mutable?
Yes.
Apart from being obviously wrong (integers are not objects in Java),
A trivial distinction. The designers of Java chose to say that eight of its types are "not objects". They look like objects to me: their analogues in Smalltalk and Ruby (and Scala and C#) certainly are.
(Note BTW that I am not confining values to instances of what C# calls value types. If there aren't any mutators, it's a value.)
what point are you trying to make?
I'm trying to talk about the classification of values.
And I stand by that. These are features that stand outside the language definition, are not found in the language standard, and depend on implementation-dependent libraries that are identical in effect to emitting source code and issuing a system call to run the compiler.
You really think it makes all the difference that CLOS is part of the CL standard (though the full MOP is not) and System.Reflection.Emit is not? I truly cannot understand the basis for that. In any case, CLOS is part of the "library" not the "language", though admittedly the distinction is a fine one.
The point at issue was actually: what do you mean by "dynamically typed"?
I simply cannot muster the emotional energy to explain a third time.
Quote from johnwcowan on November 6, 2019, 3:46 amThe point at issue was actually: what do you mean by "dynamically typed"?
I simply cannot muster the emotional energy to explain a third time.
With all due respect, that's a major cop-out. You're willing to fight endlessly over a wide range of lost causes that are incidental or irrelevant, but the one question I asked right back at the beginning and is actually what this thread was supposed to be about you still won't answer?
Anyway, no matter whatever you had in mind the TTM (with our without the IM) is a system of static types and values that belong to those types, so I guess it really doesn't matter.
Quote from dandl on November 6, 2019, 5:51 amQuote from johnwcowan on November 6, 2019, 3:46 amThe point at issue was actually: what do you mean by "dynamically typed"?
I simply cannot muster the emotional energy to explain a third time.
With all due respect, that's a major cop-out. You're willing to fight endlessly over a wide range of lost causes that are incidental or irrelevant, but
the one question I asked right back at the beginning and is actually what this thread was supposed to be about you still won't answer?
David, pull your head in. "Fighting endlessly" is something you do to an unacceptable extent.
Since I started this thread, and set the title, and made the first post, I'm the one to decide what this thread is "supposed to be about" from "right back at the beginning". And it certainly wasn't about "dynamically typed" -- on which you and John have contributed opinions "endlessly", but I'm none the wiser. (And thank you but I don't want any more.) Go start another thread, and stop hijacking the ones I start.
Anyway, no matter whatever you had in mind the TTM (with our without the IM) is a system of static types and values that belong to those types, so I guess it really doesn't matter.
Quite. Off topic.
Quote from dandl on November 6, 2019, 5:51 am
With all due respect, that's a major cop-out.
Think what you will; I'm done with this discussion.
You're willing to fight endlessly
I neither fight nor argue. I say what I think or what I know, and I listen and try to learn.
I asked right back at the beginning and is actually what this thread was supposed to be about you still won't answer?
"The question so phrased is both accusatory and inaccurate. I can swallow some accusation, or some inaccuracy, but the combination is poison." —UKL
In any case, I have answered, twice. I can't get past your front-end processor because you insist on interpreting my use of dynamic type in the sense you mean it rather than in the sense I mean it and defined it: expressions have static types, values have dynamic types. (Even Dave called your interpretation "unusual".)
So have your final say (if you want one) and let's let it drop.