Index: doc/proposals/tuples.md =================================================================== --- doc/proposals/tuples.md (revision 7a0e8c847d322ed60a768012cb7e370a79730488) +++ doc/proposals/tuples.md (revision b0fcd0e9c5cb8cfb0efe57e6fb351703839a2a65) @@ -3,6 +3,6 @@ This proposal is to update tuples, as they were created by Rob in his thesis, -to address problems have appeared in their use since then. This proposal is -an attempt to address some of those problems. Adding new functionality, +to address problems that have appeared in their use since then. This proposal +is an attempt to address some of those problems. Adding new functionality, updating existing features and removing some problematic features. @@ -56,5 +56,5 @@ Multi-Assignment assigns every element to the matching element of a source -tuple (both tuples must be the same side). +tuple (both tuples must be the same size). [int, long, float] dst; @@ -88,10 +88,10 @@ } -This is the unique feature of Cforall tuples. There are a few languages have +This is the unique feature of Cforall tuples. There are a few languages with multiple return values, but they are usually are a stand alone feature. ### Tuple Casts -C-style casts can be used on tuples. These usually conversion casts (casts +C-style casts can be used on tuples. These are usually conversion casts (casts that preform operations on the cast type, as opposed to reinterpreting the existing value). @@ -104,6 +104,6 @@ This casts the first element type from a char to an int and drops the last -element. The second line can be replaced the following code, that creates -a new tuple of by casting the kept elements of the old tuple: +element. The second line can be replaced with the following code, which creates +a new tuple by casting the kept elements of the old tuple: [(int)x.0, (char)x.1]; @@ -129,11 +129,11 @@ tuple is flattened, the second assertion "T max(Ts);" matches types with multiple parameters, although it is used as a tuple function inside the -function body. For example, in three argument case (all three of the +function body. For example, in the three-argument case (all three of the same type), both assertions can match the same function. Then "Ts args" -introduces args as a tuple, where it is past to max. +introduces args as a tuple, where it is passed to max. Issues with the Current State ----------------------------- -There are a veriaty of problems with the current implementation which we +There are a variety of problems with the current implementation which we would like to fix. @@ -141,5 +141,5 @@ Spoilers, this proposal actually takes them further away from being objects. -But this illistrates why the current version is not as useful is it could be. +But this illustrates why the current version is not as useful is it could be. Tuples do not have the lifetime operators (copy construction, copy assignment @@ -150,12 +150,12 @@ This prevents tuples from being interwoven with regular polymorphic code. -### Providing TType Arguments is Inconistent +### Providing TType Arguments is Inconsistent The syntax for ttype arguments is slightly inconsistent. It hasn't come up much yet because you do not directly provide ttype polymorphic arguments to -functions and the are very few existing use-cases for ttype structures. - -Passing arguments to a function inlines the arguments into inlines the -arguments while passing them to a polymorphic type requires them to be +functions and there are very few existing use-cases for ttype structures. + +Passing arguments to a function inlines the arguments, +while passing them to a polymorphic type requires them to be enclosed in a tuple. Compare `function(x, y, z)` with `Type(A, [B, C])`. @@ -167,10 +167,10 @@ The tuple syntax conflicts with designators and the new attribute syntax. -These conflicts break C compatability goals of Cforall. Designators have had +These conflicts break C compatibility goals of Cforall. Designators have had to their syntax change and Cforall cannot parse the new attributes. Although most of this redesign is about the semantics of tuples, but an update to tuple syntax that removes these conflicts that would improve the -compatability of Cforall going forward (and also open up the new attribute +compatibility of Cforall going forward (and also open up the new attribute syntax for cforall features). @@ -183,11 +183,11 @@ The existing tuples will be even more "unstructured" than they are now. Tuples are considered a sequence of types or typed entities. These packs are -then unpacked into the surounding context. Put differently, tuples are now +then unpacked into the surrounding context. Put differently, tuples are now flattened as much as possible, with some places (like parameter lists) being treated as an implicit tuple and the tuple being flattened into that. -Structred tuples are now a separate feature, a structure called "tuple". -These are polymorphic structures, an instance should act as a structure -except that use indices instead of field names. These structures shouldn't +Structured tuples are now a separate feature, a structure called "tuple". +These are polymorphic structures; an instance should act as a structure, +except that it uses indices instead of field names. These structures shouldn't have to be used often, but fill in the use cases that unstructured tuples no longer support. @@ -197,5 +197,5 @@ Changed Features ---------------- -Some of the concrete changes to the features of the languages. +Some of the concrete changes to the features of the language. ### Structured Tuple Type @@ -261,7 +261,7 @@ These may not work exactly as given (for one, the copy assignment assertion -in the first function would likely be redundent/conflicting with the implicit +in the first function would likely be redundant/conflicting with the implicit assertions on the parameters), but they show the pattern. Multi-assignment -is also would be very hard to write with simple tuple types, because the +also would be very hard to write with simple tuple types, because the relationship between the two halves of the parameter list does have to line up, that cannot be enforced with two different tuples. @@ -272,14 +272,14 @@ polymorphic parameters as polymorphic type packs. The `Vars...` syntax introduces a pack of types into scope. It can be used in many of the same -ways as a tuple tuple, but in some new ways to. - -The primary existing use remains, you can use a polymorphic pack in a +ways as a tuple, but in some new ways to. + +The primary existing use remains; you can use a polymorphic pack in a parameter list, both as part of an assertion and in the signature of the -main function. The difference, is that this is not an enclosed tuple, but +main function. The difference is that this is not an enclosed tuple, but a series of types. The only effective difference this makes is it doesn't prefer to match another tuple/pack. This pattern continues to a parameter defined with a pack of types, which -is considered a pack of parameters, and the name of it introduces is a pack +is considered a pack of parameters, and the name it introduces is a pack of variables, or a flattened tuple. @@ -287,5 +287,5 @@ void function(Params values); -New uses cases include declarations of members and variables. For example, +New use cases include declarations of members and variables. For example, the creation the structured tuple structure: @@ -296,5 +296,5 @@ This is again, treated as a pack of members. They have the same layout as -if they were written out by hand. Now, the name get is still accessed is if +if they were written out by hand. Now, the name get is still accessed as if it was a regular, singular, member. The result of that expression is a pack expression, a tuple of all the field accesses, which can be used with a @@ -344,5 +344,5 @@ The unstructured tuple cannot represent all the types that the previous semi-structured tuple could. These cases still exist in various ways, -special in the internals of a polymorphic type, but general should be +special in the internals of a polymorphic type, but in general should be considered in their reduced form. @@ -364,5 +364,5 @@ is to say a single type in an unstructured tuple is a no-op. -Lastly, nested tuples are always flattened into to form a one deep tuple. +Lastly, nested tuples are always flattened into to form a one-deep tuple. This means that `[bool, [char, int], float]` is resolved as `[bool, char, int, float]`, with the internal structure of the tuple ignored. @@ -396,5 +396,5 @@ each element in the result tuple decided by the matching element of the range, which gives the index of the original tuple to place there. -The type of the indices may be and intergal type, but all indices must be in +The type of the indices may be and integral type, but all indices must be in range, otherwise it is a compile time error. @@ -438,5 +438,5 @@ This would act much like a `FunctionDecl` except for tuples, narrowing the possible types, to `TupleType` instances instead of `FunctionType` instances, -and storing some additonal information, in this case the names of the +and storing some additional information, in this case the names of the elements of the tuples. @@ -447,5 +447,5 @@ ### Field Packs Field packs in structures will probably have to be written out in full by -the specialization pass. If they are not it could have some negative effects +the specialization pass. If they are not, it could have some negative effects on layout, causing a structure to take up extra space. It may be able to reuse some of the specialization code for the existing tuples. @@ -469,7 +469,7 @@ tuple is a different polymorphic type. -Tuple types and expressions are written with a parenthesized, comma seperated +Tuple types and expressions are written with a parenthesized, comma separated list of types or expressions. To avoid confusion with the grouping "(...)", -one element tuples must have a trailing comma (and larger tuples may have a +one-element tuples must have a trailing comma (and larger tuples may have a trailing comma). @@ -479,5 +479,5 @@ Element access uses similar syntax to field access (that is "."), but uses an -interger literal instead of a field name (for example: "pair.1"). Tuples +integer literal instead of a field name (for example: "pair.1"). Tuples support pattern matching with similar syntax to their expression form. @@ -495,5 +495,5 @@ meta-programming. -C++ is also one of the few languages with support for varadic polymorphic +C++ is also one of the few languages with support for variadic polymorphic types, so there is one template that defines all the types. It is written as `std::tuple`, where "TYPE..." is any number of comma separated @@ -501,5 +501,5 @@ There is no special syntax for member access of a tuple. You have to use a -template function for example `std::get<0>( tuple )`. +template function, for example `std::get<0>( tuple )`. C++ also has structured binding, a kind of limited pattern matching. In a @@ -517,5 +517,5 @@ has functions for tuples of up to 7 elements. -The syntax for tuples is a comma seperated list of elements. Either element +The syntax for tuples is a comma separated list of elements. Either element types to create a tuple type, or element values to create a tuple value. The context decides which one we are looking for. Such as `(6, "six")` or @@ -543,10 +543,10 @@ OCaml does not support 0 or 1 element tuples. It does however have the `unit` -type which has one value written `()`. +type which has one value, written `()`. - https://ocaml.org/docs/basic-data-types#tuples #### Swift -Swift has tuple types that use the basic parenthesized list of comma +Swift has tuple types that use the basic parenthesized, comma separated list of types or values. It only supports 0 and 2 or more element tuples (the `Void` type is an alias for the empty tuple type). @@ -580,5 +580,5 @@ ### Packs -Packs (or unstructures tuples) are a much less common feature. In fact, there +Packs (or unstructured tuples) are a much less common feature. In fact, there might just be one language, C++, that supports packs. The most common use case for unstructured tuples is returning multiple values, so there is a @@ -604,5 +604,5 @@ #### Lua -Lua is a scripting languague, is dynamically typed and stack based. Although +Lua is a scripting language, is dynamically typed and stack based. Although the stack usually only directly visible in the C-API, it does allow any function to return any number of values. Even in a single return, if the @@ -635,5 +635,5 @@ public: template - Outer(Args&&... args) : inner(std::foward(args)...) {} + Outer(Args&&... args) : inner(std::forward(args)...) {} }; ``` @@ -641,9 +641,9 @@ In the first application, `Args&&... args` both uses a pack and introduces another one. `Arg0&& arg0, Arg1&& arg1, Arg2&& arg2, ...` is the pattern -it explands too. The `&&` is used to copy the argument type's reference +it expands too. The `&&` is used to copy the argument type's reference qualifier (the default can strip references away). The second application, `std::forward(args)...` uses two packs. These -are expanded in parellel, and must be the same length (in this case they +are expanded in parallel, and must be the same length (in this case they always will be). It also helps show that the `...` is actually the bit doing the expansion, it is a suffix "operator" to the expansion pattern. @@ -653,5 +653,5 @@ element of the `args` pack together. -C++ about the best you could ask for in this area, but it does a lot of work +C++ is about the best you could ask for in this area, but it does a lot of work at compile time to make this happen.