Feature name poll #20
Comments
|
I am in favour of trait and these are the reasons:
- The term "concept" is too general and too often used in everyday language
to be able to distinguish and "enclose" what we mean
- The term "constraint" is too much focused on excluding things
- The term "trait" is much more neutral in that respect than "constraint"
and much more specific than "concept". I know it from a
biological/ecological context and to me (*) it seems the near-perfect term
to indicate a characteristic that is shared by several
individuals/species/...
(*) Caveat: English is not my native tongue, so the word may "taste"
differently for me than for someone born and raised in an Anglophone
environment.
Op vr 23 okt. 2020 om 15:23 schreef Tom Clune <notifications@github.com>:
… Yesterday there was a virtual meeting in which different languages with
template capabilities use different terminologies. C++ has the term
'concept', which is a 'trait' in rust, and 'constraint' in yet other
languages.
Ultimately J3/WG5 will have to agree on a term, but the generics subgroup
needs a term that we can agree upon for preliminary discussions and
prototyping. I really dislike the word 'concept' in this context. I'm
strongly in favor of 'constraint' but am also happy with 'trait' and could
possibly come around to others. (In the discussion yesterday, I think that
'trait' was the most popular, but we did not take a poll.)
This issue is to solicit opinions from the community. Ultimately the
generics subgroup of J3 will decide, but we'd likely go with majority
opinion. Please only vote if you have a strong opinion. (Bonus points if
you articulate your reasoning.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#20>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN6YR3YB2XYLRE4G5FNIN3SMF7U7ANCNFSM4S4RX7XA>
.
|
|
Hmm. I see traits (by whatever means) as a mechanism to essentially express the sentiment: "Allow any type here, so long as the specified interfaces exist for that type." That is exactly what a constraint is. Anything that satisfies a constraint is allowed, and anything that does not satisfy a constraint is disallowed. I agree that the term "trait" suggests that it is shared by multiple entities. But is that an important property here? Traits that can be reused are of course useful, but so are constraints that are reusable I suppose I might feel differently if we were to actually specify traits when the types themselves are defined. But the existing examples from other languages, and my poor understanding of same, suggest that traits are typically (always?) expressed in templates and the compiler is the one that checks to see if the trait applies to any given type. I.e., the compiler checks to see if the type has the trait. Sounds like a constraint to me. If traits instead were a property declared in the definition of a type, then word would be closer to the conventional meaning. For fun I googled 'trait' in the context of biology. The first example that came up was eye color. Here, trait is not a specific color (which would be the phenotype: blue, brown, hazel, ...), but the generic class of eye colors. From that perspective, "trait" seems just a bit off to me. Phenotype would be more precise for our use, but I'm not going to propose that alternative. To be fair, we may be only interested in "traits" that have a single phenotype and the distinction is unwarranted. Again - not strongly opposed to using 'trait'. It at least has the right connotations in my mind. While English is my native language, I feel that I've still expressed myself poorly here. I may come back with more refined arguments. But only if we have a healthy debate going. Cheers. |
|
@tclune, since you asked "But is that an important property here?" I will suggest the term "Property" as a possible keyword too. :) |
|
The general idea is that of a requirement or prerequisite or expectation or "job qualification" or skill that must be satisfied by an actual type parameter. I don't think any of the terms that are currently in use by other languages are terribly intuitive for this purpose. I am a native English speaker, if that matters. I find the terms "concept" and "trait" to be so vague as to be meaningless until you learn their special definitions in the languages that use them -- one might as well use "idea" or "aspect" instead, and I hope that they seem as bad to you as they do to me. Please avoid all of these. I don't mind Haskell's "constraint" as much as I do "concept" & "trait", but I don't think that it conveys its meaning of "must be a member of a particular typeclass" very well either. Similarly, ML's use of the word "signature" isn't terribly intuitive, and it seems to mean "function prototype" to many (younger) programmers. So I encourage you to find a new term in the absence of a compelling precedent. There's lots of great alternatives. |
|
Myself I am partial to "requirement", but don't mind "trait". I think "concept" is terrible. |
|
Not terribly opposed to "property". It points in the right direction but is a bit of an all purpose word. Similar to "attribute" in that sense. Seems safe in the Fortran context though. @wclodius2 Thanks for the suggestion. I like "requirement" as well. I consider it roughly equivalent to "constraint" in my mental map, and has the extra advantage that it is not a meta-term in the standard. And if we end up needing a verb, saying that X requires Y reads very clearly. |
|
I like “constraint” or “requirement.” Both are used in programming by contract and I suspect/hope that what we do will have similarities to that approach. I think these terms are also used in formal methods, which I hope will inspire some of what we do.
I find “concept” vague and worry that the C++ community is so much bigger than the Fortran community that people will expect our approach to mirror theirs if we borrow their terms.
I’m ok with “trait” or “property.” I think of them as synonyms for “attribute.” Whether that is a feature or a bug depends on how similar what we are describing is to what we currently call an “attribute.” I suspect that what we are looking to do is quite dissimilar from current attributes.
Damian
…Sent from my iPhone
On Oct 24, 2020, at 06:00, Tom Clune ***@***.***> wrote:
Not terribly opposed to "property". It points in the right direction but is a bit of an all purpose word. Similar to "attribute" in that sense. Seems safe in the Fortran context though.
@wclodius2 Thanks for the suggestion. I like "requirement" as well. I consider it roughly equivalent to "constraint" in my mental map, and has the extra advantage that it is not a meta-term in the standard. And if we end up needing a verb, saying that X requires Y reads very clearly.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Taking a look at this again, I wonder if we aren't trying to give one name to what are effectively 3 separate aspects of the generics facility we are trying to implement. Those 3 things being:
@FortranFan 's work towards the KART approach has given us a good idea for the requirements of part 1. So far we have assumed that part 2 is sufficiently by specifying the name of a specific 1 for a template parameter, but we could of course expand that and give part 2 it's own name in the syntax. We have discussed allowing part 3, and I believe have mostly agreed it should be optional, but if allowed would also need it's own syntax and/or keyword. Based on the above partitioning, I would propose we vote on each aspect, with my suggested options for each listed below. I think I would lean towards 1. typeclass, 2. restriction, 3. membership, but I think there are other combinations that would be acceptable too.
|
|
Please don't use the word "typeclass". That term refers today only to a specific and distinct feature in another language. And it limits your abstractions to types. Consider following the classic model of Standard ML's signatures and structures and functors instead; modules correspond nicely to ML's structures, and I think you need to be working at the level of modules anyway if you want type-bound procedures to work. |
Yesterday there was a virtual meeting in which different languages with template capabilities use different terminologies. C++ has the term 'concept', which is a 'trait' in rust, and 'constraint' in yet other languages.
Ultimately J3/WG5 will have to agree on a term, but the generics subgroup needs a term that we can agree upon for preliminary discussions and prototyping. I really dislike the word 'concept' in this context. I'm strongly in favor of 'constraint' but am also happy with 'trait' and could possibly come around to others. (In the discussion yesterday, I think that 'trait' was the most popular, but we did not take a poll.)
This issue is to solicit opinions from the community. Ultimately the generics subgroup of J3 will decide, but we'd likely go with majority opinion. Please only vote if you have a strong opinion. (Bonus points if you articulate your reasoning.)
The text was updated successfully, but these errors were encountered: