These two types aren't typing the same data, though: in the latter case (in Rust) you've actually thrown away some of the data, and the type reflects that.
In Clojure the data is thrown away too, just at a slightly later point. The data is parsed then destructured then processed, and it is at the destructuring stage that irrelevant data is discarded and marked for GC.
Just as the Rust function avoids coupling by using a more narrow type, the Clojure function avoids coupling by using a more narrow binding.
I think this isn't a great comparison: the usual vehicle for this thing in Rust is the trait, which manages to abstract over the representation statically without introducing a bunch of runtime machinery for it
But you have to create and implement those traits. I'm not saying this is impossible in Rust; just a lot more onerous because you don't get all the machinery Clojure has that makes it trivial.
These are just predicates; I don't think they have much to do with this discussion?
This might be why we're talking past each other. When I say "type", I mean a set of possible values. I don't think this is an uncommon definition; the first sentence of the "data type" Wikipedia page pretty much defines it the same way.
Given this definition, you perhaps see why we can narrow a runtime type by composing it with a predicate.
My understanding is that you view types differently, as more of an interpretation of some sequence of bits, rather than a set of data values. Is that correct?
As we get better at writing compilers we're increasingly seeing a move towards mechanisms like Rust's traits or C++'s concepts that allow the programmer to actually abstract over the representation of a type (as opposed to forcing a uniform representation as is common in dynamically typed languages).
I agree that's there's no reason in principle that you couldn't statically type it with a sufficiently advanced compiler.
In Clojure the data is thrown away too, just at a slightly later point. The data is parsed then destructured then processed, and it is at the destructuring stage that irrelevant data is discarded and marked for GC.
Right; the difference is that by the destructing time you have lost the type information about that ‘discarded’ data, meaning you no longer know how to discard it. In Clojure this is not a problem, because the only values you're allowed to have are those that can be garbage collected, and (furthermore) garbage collected by calling a known function with nothing more than a universal set of GC metadata that is attached at a standard location on every value. But this is only possible because of a large restriction Clojure places on allowable values: the base ‘unitype’ of all Clojure values already contains all of this extra data, and any values for which it can't be attached or it doesn't make sense are simply forbidden.
But you have to create and implement those traits. I'm not saying this is impossible in Rust; just a lot more onerous because you don't get all the machinery Clojure has that makes it trivial.
On this I absolutely agree. The only thing I'd be careful to distinguish is not simply that Rust doesn't have the machinery but that the machinery makes sense only given a fairly onerous set of additional assumptions about your values that Rust doesn't make (and that are usually held to be incompatible with a systems programming language, but IMO are also helpful for many — though not all — ‘userland’ programs).
When I say "type", I mean a set of possible values. I don't think this is an uncommon definition; the first sentence of the "data type" Wikipedia page pretty much defines it the same way.
It's not an uncommon one, indeed, and while there are more sophisticated definitions (e.g. including equality) I don't think they need to be invoked for this discussion.
Given this definition, you perhaps see why we can narrow a runtime type by composing it with a predicate.
No, you're right: I think I was thrown off by your assertion that these are uncoupled from the type system when we were talking originally of ‘conceptual’ types.
My understanding is that you view types differently, as more of an interpretation of some sequence of bits, rather than a set of data values. Is that correct?
Quite the opposite. These words aren't entirely standardized so I set out my definitions above:
- I am using ‘value’ to refer to any object of discussion in a programming language that nominally exists at runtime; effectively, a value can be defined by the set of operations available on it
- I am using ‘data’ to refer to values that have ‘data-like’ semantics, i.e. has ‘default’ move and discard mechanism like bitwise copy/overwrite or GC
Comments
In Clojure the data is thrown away too, just at a slightly later point. The data is parsed then destructured then processed, and it is at the destructuring stage that irrelevant data is discarded and marked for GC.
Just as the Rust function avoids coupling by using a more narrow type, the Clojure function avoids coupling by using a more narrow binding.
But you have to create and implement those traits. I'm not saying this is impossible in Rust; just a lot more onerous because you don't get all the machinery Clojure has that makes it trivial.
This might be why we're talking past each other. When I say "type", I mean a set of possible values. I don't think this is an uncommon definition; the first sentence of the "data type" Wikipedia page pretty much defines it the same way.
Given this definition, you perhaps see why we can narrow a runtime type by composing it with a predicate.
My understanding is that you view types differently, as more of an interpretation of some sequence of bits, rather than a set of data values. Is that correct?
I agree that's there's no reason in principle that you couldn't statically type it with a sufficiently advanced compiler.
Right; the difference is that by the destructing time you have lost the type information about that ‘discarded’ data, meaning you no longer know how to discard it. In Clojure this is not a problem, because the only values you're allowed to have are those that can be garbage collected, and (furthermore) garbage collected by calling a known function with nothing more than a universal set of GC metadata that is attached at a standard location on every value. But this is only possible because of a large restriction Clojure places on allowable values: the base ‘unitype’ of all Clojure values already contains all of this extra data, and any values for which it can't be attached or it doesn't make sense are simply forbidden.
On this I absolutely agree. The only thing I'd be careful to distinguish is not simply that Rust doesn't have the machinery but that the machinery makes sense only given a fairly onerous set of additional assumptions about your values that Rust doesn't make (and that are usually held to be incompatible with a systems programming language, but IMO are also helpful for many — though not all — ‘userland’ programs).
It's not an uncommon one, indeed, and while there are more sophisticated definitions (e.g. including equality) I don't think they need to be invoked for this discussion.
No, you're right: I think I was thrown off by your assertion that these are uncoupled from the type system when we were talking originally of ‘conceptual’ types.
Quite the opposite. These words aren't entirely standardized so I set out my definitions above:
- I am using ‘value’ to refer to any object of discussion in a programming language that nominally exists at runtime; effectively, a value can be defined by the set of operations available on it - I am using ‘data’ to refer to values that have ‘data-like’ semantics, i.e. has ‘default’ move and discard mechanism like bitwise copy/overwrite or GC