[f3811df] | 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 |
|
---|
[1f11818] | 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 |
|
---|
[f3811df] | 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 |
|
---|
[1f11818] | 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 |
|
---|
[f3811df] | 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 |
|
---|
[1f11818] | 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 |
|
---|
[f3811df] | 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.
|
---|