Eq TypeBound should be removed; Affine could be added. #1298
Replies: 6 comments 4 replies
-
|
What about ports that must be used at least once (i.e. values can be implicitly copied but not implicitly discarded)? I think you would call these relevant types from relevant logic. I don't see an immediate application of this though and it would break the nice subset relation we have atm |
Beta Was this translation helpful? Give feedback.
-
|
Broadly agree (no Eq). Not entirely opposed to your extreme alternative either. Couple of points:
|
Beta Was this translation helpful? Give feedback.
-
|
Dupable implies both a Also not opposed to no-typebounds-and-explicit-copies-everywhere, that'd be a big change tho....I think that might be a different discussion.... Mark makes a good point about "Relevant". I don't think sub/superset-ness is vital either, so we could have the full diamond (Any - (Relevant | Affine) - Copyable). OTOH that might also be a good argument for dropping Affine...however I think it's more likely that we'll have affine than relevant. (WTF can be copied but not removed? If you copy it then you now have two instances to work out what to do with....) |
Beta Was this translation helpful? Give feedback.
-
Right, so there isn't actually a distinction between these except that Dupable has specially declared operations for 0-ary and 2-ary copy. Is this really enough reason for Dupable to be its own thing?
Hmm. I dunno ... non-erasable memory? |
Beta Was this translation helpful? Give feedback.
-
I now can't get out of my head...the magic brooms in the (original) Sorceror's Apprentice... |
Beta Was this translation helpful? Give feedback.
-
|
Including Dupable was a mistake - it doesn't fit the description of "only pertains to connectivity" because it comes under "Interfaces/TypeClass". Removing for clarity. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, fair. Dupable is related (but not the same issue) in two ways:
|
Beta Was this translation helpful? Give feedback.
-
|
How about using the term "Linear" instead of "Any"? It seems clearer to me; "Any" suggests no constraints, which is really what "Copyable" is. I don't know how standard the terminology is in this article, but it uses "Linear" rather than "Any", and "Normal" rather than "Copyable". |
Beta Was this translation helpful? Give feedback.
-
|
Linear instead of Any might be OK? It's fine to treat Copyable types linearly, just you don't have to. (IIRC we've mentioned Dislike Copyable -> Any, though. It's a description of what types there are in the set, not what operations/edge-arities it supports. Perhaps the ambiguity between those two senses of "Any" is enough reason not to use Any ? |
Beta Was this translation helpful? Give feedback.
-
|
There are a number of outcomes here that I will order in what I believe to be highest to least consensus. Mercifully each is independent and can be tackled independently.
|
Beta Was this translation helpful? Give feedback.
-
Currently there is no conceptual coherence in what a TypeBound is. Eq is the smallest bound, but it is defined as "can have equality operation applied to it". This appears to be a special case "interface", much like "hashable", "collection" or "qubit-like" might be. See #842.
Proposal is instead to restrict TypeBound to be something that describes port connectivity specifically:
Any: cannot be implicitly discarded or copied (linear), i.e. exactly one connection from outgoing value port to incoming
[OPTIONAL] Affine: can be implicitly discarded, 0 or 1 connections.
Copyable: Any number of connections valid.
These three still form valid subsets of each other, but this is not a strict requirement.
I mostly just want to remove Eq, the additions may not be worthwhile.
Eq etc. should be considered as part of the interface system, whatever that turns out to be.
Extreme alternative (too extreme imho):
No type bounds, explicit copy operations, linear/affine are also now part of the interface/constraint system.
Beta Was this translation helpful? Give feedback.
All reactions