1 | Named Parameters |
---|
2 | ================ |
---|
3 | An examination of the possibility of adding named parameters to Cforall. |
---|
4 | Named parameters allow arguments to be passed and matched to a parameter by |
---|
5 | their name instead of their position in the argument list. |
---|
6 | |
---|
7 | A comparison of positional and named argument passing: |
---|
8 | make_position(getWidth(), getHeight()); |
---|
9 | make_position(.x = getWidth(), .y = getHeight()); |
---|
10 | |
---|
11 | The example of a Python style printer using optional named parameters: |
---|
12 | printp("Error:", errorCode, .file=serr, .endl=""); |
---|
13 | |
---|
14 | Variations of this feature can be found in various languages: |
---|
15 | + Python - Keyword Arguments |
---|
16 | + Swift - Argument Labels |
---|
17 | + Ada - Named Association |
---|
18 | + C - Designators (limited) |
---|
19 | |
---|
20 | Status of Proposal |
---|
21 | ------------------ |
---|
22 | This proposal is "an examination", there are still issues to solve. Including |
---|
23 | syntax, the exact rules of how forward declarations and definitions must |
---|
24 | relate. It does break through a major problem C had, in that names of |
---|
25 | parameters are not consistent. By using C parameters as positional-only |
---|
26 | parameters so that does not cause issues. |
---|
27 | |
---|
28 | Overview of New Features |
---|
29 | ------------------------ |
---|
30 | In terms of code written, this feature interacts with the following: |
---|
31 | |
---|
32 | Function Applications and Arguments: |
---|
33 | When a function is applied and passed arguments those arguments must be |
---|
34 | provided either as `Positional Arguments` or `Named Arguments`. |
---|
35 | |
---|
36 | Positional arguments use the existing C syntax and named arguments could |
---|
37 | reuse member designator syntax (`.NAME = EXPR` in an argument list). |
---|
38 | |
---|
39 | Function Declarations and Parameters: |
---|
40 | When a function is declared its parameters may be defined as `Positional |
---|
41 | Parameters` or `Named Parameters`. Unlike with arguments, this is not an |
---|
42 | either or thing, parameters are actually in three groups `Positional Only`, |
---|
43 | `Named Only` and `Positional or Named`. In addition, all parameters can |
---|
44 | be `Required Parameters` or `Optional Parameters`. |
---|
45 | |
---|
46 | Current C syntax should be used for positional parameters. New syntax will |
---|
47 | be needed for named-only or named-or-positional parameters. Something like, |
---|
48 | `TYPE .NAME` (a dot at the front of the parameter name, to reflect the |
---|
49 | argument form). |
---|
50 | |
---|
51 | Current Cforall does have some support for optional parameters and default |
---|
52 | arguments. An optional parameter is declared by proving it with a default |
---|
53 | argument (putting `= EXPR` after the parameter declaration). There is also |
---|
54 | syntax for explicitly requesting the default argument is used (`@`). |
---|
55 | |
---|
56 | As an extension, we could allow array designators (`[ POSITION ] =`) as a way |
---|
57 | to explicitly give the position of an argument. This is not an existing |
---|
58 | Cforall feature, nor directly related to named parameters, but it is an |
---|
59 | extension of C semantics that fits in this area. |
---|
60 | (I would actually recommend against it at this time, parameter lists should |
---|
61 | not be so long that this is useful.) |
---|
62 | |
---|
63 | Function Pointers |
---|
64 | ----------------- |
---|
65 | Function pointers do not need to support named parameters, in the same way |
---|
66 | they do not support optional parameters. (You can write an optional parameter |
---|
67 | in a function pointer, but it is ignored.) There could be some way to convert |
---|
68 | or cast between the two forms, but in practice, the types of functions where |
---|
69 | named parameters are useful have very little overlap with those that you |
---|
70 | would pass to a higher order function or use as an assertion. |
---|
71 | |
---|
72 | Argument Matching |
---|
73 | ----------------- |
---|
74 | How are arguments connected to parameters. This will become part of the |
---|
75 | overload resolution process, luckily it is a pretty simple straight forward |
---|
76 | pass fail check so does not effect cost. This covers all the features being |
---|
77 | considered, but most can cleanly be removed. |
---|
78 | |
---|
79 | Note that matching arguments to parameters is tied up into matching calls |
---|
80 | with definitions, and requires arguments to be resolved, and so has to happen |
---|
81 | within the resolver. |
---|
82 | |
---|
83 | First, the positional parameters have to be sorted out. |
---|
84 | |
---|
85 | Undesignated arguments are positional arguments, if one appears at the front |
---|
86 | of the argument list it is the 0 positional argument, otherwise it must |
---|
87 | follow another positional argument and it goes into the next position. It is |
---|
88 | an error for an undesignated argument to appear after a named argument. |
---|
89 | |
---|
90 | Array designated arguments are positional arguments. The constant expression |
---|
91 | is evaluated and the result is the position of the parameter it is matched |
---|
92 | with. |
---|
93 | |
---|
94 | The same process is way simpler with named arguments, as all are labeled. |
---|
95 | Member designated arguments are named arguments. They are matched with the |
---|
96 | parameter with the same name. |
---|
97 | |
---|
98 | The `@` argument can be used anywhere other arguments can be. The parameter |
---|
99 | it is matched with must be an optional parameters and this explicitly requests |
---|
100 | that the default argument be used. |
---|
101 | |
---|
102 | Then we can just check to make sure no parameter is provided/matched with an |
---|
103 | argument more than once, and that every required parameter is provided |
---|
104 | exactly once. If any arguments could not be matched to a parameter, it is an |
---|
105 | error. |
---|
106 | |
---|
107 | Note that there are no special rules for positional-or-named parameters, they |
---|
108 | can just be used in either case. |
---|
109 | |
---|
110 | Backwards Compatibility |
---|
111 | ----------------------- |
---|
112 | All parameters and arguments in C code can treated as (required and) |
---|
113 | positional, except for initializers which are optional and use designators. |
---|
114 | |
---|
115 | Initializers and C designators always consider the underlying parameter's |
---|
116 | position the important part. The designator moves the position in the |
---|
117 | parameter list forward or backward. If an argument is not designated, it is |
---|
118 | put the next position after the previous argument (or the first position if |
---|
119 | it is the first argument). |
---|
120 | |
---|
121 | It should be noted that this is actually more permissive than most languages. |
---|
122 | Other named parameter system enforce that all positional arguments come |
---|
123 | before all named arguments. |
---|
124 | |
---|
125 | However, we could translate this using optional and named-or-positional |
---|
126 | parameters. Removing the ability to have undesignated arguments follow |
---|
127 | a member designated arguments is required for named only parameters, doing |
---|
128 | the same for named-or-positional for a consistent interface. |
---|
129 | |
---|
130 | C also allows chained designators, nested initializers and descending into and |
---|
131 | out of recursive initializers automatically as the beginning or end of those |
---|
132 | sections. In the context of a member/element initializer, the system does |
---|
133 | have enough information to do this, because the target types are fixed by the |
---|
134 | type being initialized. |
---|
135 | |
---|
136 | These should be supported in the C escape initializer (`@=`), but cannot be |
---|
137 | generalized to function calls (not even initializers we resolve as functions) |
---|
138 | because of overloading. |
---|
139 | |
---|
140 | Syntax Options |
---|
141 | -------------- |
---|
142 | The syntax suggested above both does not work and may be incomplete. It was |
---|
143 | good enough for the initial descussion but will need some further work. |
---|
144 | |
---|
145 | The issue with the above syntax is that `TYPE .NAME` can look like a |
---|
146 | qualified type to the parser. Considering how wide spreak the qualified type |
---|
147 | syntax is, it could be changed. Here are some syntax suggestions: |
---|
148 | |
---|
149 | Named Argument: `.NAME = EXPR` |
---|
150 | Named (Required) Parameter: `TYPE .NAME` |
---|
151 | Named (Optional) Parameter: `TYPE .NAME = EXPR` |
---|
152 | |
---|
153 | The first suggestion is an attempt to use C designator syntax as the name |
---|
154 | syntax. A named parameter is now a generialization of designators. The |
---|
155 | parameters are added into a function's parameter list. |
---|
156 | |
---|
157 | `@NAME = EXPR` | `TYPE @NAME` | `TYPE @NAME = EXPR` |
---|
158 | `?NAME = EXPR` | `TYPE ?NAME` | `TYPE ?NAME = EXPR` |
---|
159 | |
---|
160 | Some other characters that could be used in the same syntax. The `@` symbol |
---|
161 | hints at some location/address. Peter was just excited about `?` but it is an |
---|
162 | little used symbol and parses at this time. This does weaken the connection |
---|
163 | with designators, which was the main advantage of the designator like syntax. |
---|
164 | |
---|
165 | Named Argument: `NAME: EXPR` |
---|
166 | Named Parameter: `NAME: TYPE NAME0` | `TYPE NAME:` |
---|
167 | |
---|
168 | Another bit of C syntax we could try to adapt to named parameters are labels. |
---|
169 | We reuse the label syntax used at the statement level at the expression level |
---|
170 | to note where (with which parameter) this expression goes. |
---|
171 | |
---|
172 | This syntax (the first option for the named parameter) is also has an example |
---|
173 | of a possible (but not popular) feature where the parameter name (the |
---|
174 | identifier used inside the function) and the parameter label (the identifier |
---|
175 | used at the call site) are independent. |
---|
176 | |
---|
177 | `PARAMS;PARAMS` | `;PARAMS` |
---|
178 | |
---|
179 | Another way to describe the type of parameters is by dividing the parameter |
---|
180 | list into sections. Here we replace a `,` separator between two parameters, |
---|
181 | with a single (per parameter list) `;` that marks the end of the positional |
---|
182 | parameters. The argument syntax would have to be borrowed from some other |
---|
183 | example (such as the designator one, where the parameter is the problematic |
---|
184 | one for the parser), possibly with another `;` separator to add context. |
---|
185 | Also, the `;` separator can appear at the beginning of the parameter list as |
---|
186 | well if all parameters are positional. |
---|
187 | |
---|
188 | Named Argument: `NAME @= EXPR` |
---|
189 | Named Parameter: `TYPE NAME @= EXPR` |
---|
190 | |
---|
191 | Another syntax to modify is assignment, with a special "assign to parameter" |
---|
192 | operator (although structurally it |
---|
193 | |
---|
194 | `NAME := EXPR` | `TYPE NAME := EXPR` |
---|
195 | |
---|
196 | Like with the variations of the designator-like syntax, the separator could |
---|
197 | be changed out, so that symbol can be used as the identifying feature of the |
---|
198 | named argument. |
---|
199 | |
---|
200 | The incompleteness is that most of these just have one more parameter |
---|
201 | declaration. That is, there is only syntax for positional-or-named parameters |
---|
202 | or named-only parameters, so far it has been named-only. Positional-only |
---|
203 | parameters are "locked" to the C syntax for compatability reasons. Supporting |
---|
204 | both cases gives additional flexibility and could be done by combining two |
---|
205 | of the above syntax (or by altering one). |
---|
206 | |
---|
207 | void call(int position, char .position_or_name = a; double .name = b); |
---|
208 | |
---|
209 | Note, that C-style autogenerated constructors would still be positional or |
---|
210 | named parameters for compatability. |
---|
211 | |
---|
212 | Run-time Implementation |
---|
213 | ----------------------- |
---|
214 | The underlying code must be translated into simple C code that does not use |
---|
215 | these parameters or arguments. |
---|
216 | |
---|
217 | For this purpose, we do use the ordering of all parameters, writing them |
---|
218 | out in the order they appear in the declaration. |
---|
219 | Note that the programmer still does not have to (and sometimes cannot) |
---|
220 | interact with the order of parameters, but the compiler will still use them. |
---|
221 | Here it boils down all the named forms down to positional code. This is the |
---|
222 | run-time efficient way to implement it. Other forms of argument packing, such |
---|
223 | as putting the named arguments into a map, tend to be slower and their |
---|
224 | advantages allow for more dynamic behaviour has a harder time using |
---|
225 | effectively. |
---|