October 21, 2015 Re: s/TypeTuple/AliasSeq/g? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Shriramana Sharma | On Wednesday, 21 October 2015 at 14:25:18 UTC, Shriramana Sharma wrote: > Marc Schütz wrote: > >>> BTW "isExpressions" – what kind of singular/plural grammar is that? >> >> That's because it refers to the first argument, which is one symbol, not multiple ones. "consistsOfExpression" would probably be nicer, but - meh... > > No it doesn't refer to the first argument. The code in Phobos is: > > static if (T.length >= 2) > enum bool isExpressions = > isExpressions!(T[0 .. $/2]) && > isExpressions!(T[$/2 .. $]); > else static if (T.length == 1) > enum bool isExpressions = > !is(T[0]) && __traits(compiles, { auto ex = T[0]; }); > else > enum bool isExpressions = true; // default > > So it does check all members of the AliasSeq, and only if all of them are expressions (or at least none of them are types) then it returns true. The counterpart is isTypeTuple. I was referring to the "left hand side" of that relationship: "something" is-a "expressions" The "is" makes sense if you see it as an "is-a" relationship. > >> This should not be renamed, because an AliasSeq that consists only of expressions _is_ a tuple. >> >> ... >> We aren't. The only reason we use "AliasSeq" at all instead of >> "AliasTuple" was that some people insisted they were not tuples. >> This does however not apply to all the other things that _are_ >> tuples. Renaming those would only make matters worse. > > Heh, I guess you were one of the dissenters during the rename from TypeTuple to AliasSeq. I personally don't have a problem with calling them tuples, and IIUC the main problem was with the word Type since they can contain even expressions, That is my understanding as well. And the fact that they can contain anything, not just values, was another reason for some not to call them tuples (which I don't consider important, but it was for some). > but nevertheless it *was* renamed to AliasSeq, and if the library is to have any consistency and professional quality then the rest of the references to "Tuple" (and even some internal "List" references) as against tuples created by `std.typecons.Tuple` should be corrected. I'm afraid this won't help. One objection was that we're dealing with several different unrelated concepts that only superficially seem similar, and that all used to be called "tuple". Now, when we just mechanically rename them all to "*Seq", we're back where we started, just with a different name. | |||
October 21, 2015 Re: s/TypeTuple/AliasSeq/g? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Marc Schütz | On Wednesday, 21 October 2015 at 15:21:14 UTC, Marc Schütz wrote:
> I won't repeat the objections against your arguments, as it leads to nothing. But this discussion again shows that the renaming of TypeTuple to AliasSeq was just done for the sake of it (as further witnessed by the way it was done). We shouldn't do more of that nonsense as long as there is no consistent concept and goal behind it.
The renaming was done in an attempt to fix a particularly bad name that has caused a lot of confusion. The result is another bad name that's likely to create confusion for different reasons. As to whether we're better or worse off, I don't know.
Regardless, we're not normally renaming stuff like this anymore. It was just done in this case, because TypeTuple was almost universally reviled, and Walter and Andrei agreed that it was bad enough that it needed changing. So, issues like this aren't likely to be a common occurrence at this point. Still, it would have been nice if we could have come up with a name for TypeTuple/AliasSeq that was actually good...
- Jonathan M Davis
| |||
October 21, 2015 Re: s/TypeTuple/AliasSeq/g? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Marc Schütz | On Wednesday, 21 October 2015 at 13:53:48 UTC, Marc Schütz wrote:
>> When renaming `isExpressionsTuple`, I would think it more appropriate to have "isExpressionSeq" since it's an `AliasSeq` containing only expressions and no types.
>
> This should not be renamed, because an AliasSeq that consists only of expressions _is_ a tuple.
It isn't. Not a single bit more than any other AliasSeq at least.
| |||
October 21, 2015 Re: s/TypeTuple/AliasSeq/g? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On Wednesday, 21 October 2015 at 16:00:57 UTC, Dicebot wrote:
> On Wednesday, 21 October 2015 at 13:53:48 UTC, Marc Schütz wrote:
>>> When renaming `isExpressionsTuple`, I would think it more appropriate to have "isExpressionSeq" since it's an `AliasSeq` containing only expressions and no types.
>>
>> This should not be renamed, because an AliasSeq that consists only of expressions _is_ a tuple.
>
> It isn't. Not a single bit more than any other AliasSeq at least.
For me, a tuple is a finite ordered collection of values of arbitrary type, which can be identified and accessed by their index.
Which definition of tuple are you using that doesn't apply to e.g. `AliasSeq!(42, "foo")`?
| |||
October 27, 2015 Re: s/TypeTuple/AliasSeq/g? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Marc Schütz | On Wednesday, 21 October 2015 at 16:17:46 UTC, Marc Schütz wrote:
> For me, a tuple is a finite ordered collection of values of arbitrary type, which can be identified and accessed by their index.
>
> Which definition of tuple are you using that doesn't apply to e.g. `AliasSeq!(42, "foo")`?
For me important property is that tuple itself must be distinct entity that can be passed around and is generally full part of the type system. Also destructuring is one of established tuple features in other languages. Limiting it to values is irrelevant (but somewhat necessary to define ABI because of mentioned property).
Obviosuly, I am referring to established programming "tuple" concept, not math term it originates from.
| |||
October 27, 2015 Re: s/TypeTuple/AliasSeq/g? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On Wednesday, 21 October 2015 at 15:25:34 UTC, Jonathan M Davis wrote:
> On Wednesday, 21 October 2015 at 15:21:14 UTC, Marc Schütz wrote:
> The renaming was done in an attempt to fix a particularly bad name that has caused a lot of confusion. The result is another bad name that's likely to create confusion for different reasons. As to whether we're better or worse off, I don't know.
+1
| |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply