[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 | |
---|
| 20 | Overview of New Features |
---|
| 21 | ------------------------ |
---|
| 22 | In terms of code written, this feature interacts with the following: |
---|
| 23 | |
---|
| 24 | Function Applications and Arguments: |
---|
| 25 | When a function is applied and passed arguments those arguments must be |
---|
| 26 | provided either as `Positional Arguments` or `Named Arguments`. |
---|
| 27 | |
---|
| 28 | Positional arguments use the existing C syntax and named arguments could |
---|
| 29 | reuse member designator syntax (`.NAME = EXPR` in an argument list). |
---|
| 30 | |
---|
| 31 | Function Declarations and Parameters: |
---|
| 32 | When a function is declared its parameters may be defined as `Positional |
---|
| 33 | Parameters` or `Named Parameters`. Unlike with arguments, this is not an |
---|
| 34 | either or thing, parameters are actually in three groups `Positional Only`, |
---|
| 35 | `Named Only` and `Positional or Named`. In addition, all parameters can |
---|
| 36 | be `Required Parameters` or `Optional Parameters`. |
---|
| 37 | |
---|
| 38 | Current C syntax should be used for positional parameters. New syntax will |
---|
| 39 | be needed for named-only or named-or-positional parameters. Something like, |
---|
| 40 | `TYPE .NAME` (a dot at the front of the parameter name, to reflect the |
---|
| 41 | argument form). |
---|
| 42 | |
---|
| 43 | Current Cforall does have some support for optional parameters and default |
---|
| 44 | arguments. An optional parameter is declared by proving it with a default |
---|
| 45 | argument (putting `= EXPR` after the parameter declaration). There is also |
---|
| 46 | syntax for explicitly requesting the default argument is used (`@`). |
---|
| 47 | |
---|
| 48 | As an extension, we could allow array designators (`[ POSITION ] =`) as a way |
---|
| 49 | to explicitly give the position of an argument. This is not an existing |
---|
| 50 | Cforall feature, nor directly related to named parameters, but it is an |
---|
| 51 | extension of C semantics that fits in this area. |
---|
| 52 | (I would actually recommend against it at this time, parameter lists should |
---|
| 53 | not be so long that this is useful.) |
---|
| 54 | |
---|
| 55 | Function Pointers |
---|
| 56 | ----------------- |
---|
| 57 | Function pointers do not need to support named parameters, in the same way |
---|
| 58 | they do not support optional parameters. (You can write an optional parameter |
---|
| 59 | in a function pointer, but it is ignored.) There could be some way to convert |
---|
| 60 | or cast between the two forms, but in practice, the types of functions where |
---|
| 61 | named parameters are useful have very little overlap with those that you |
---|
| 62 | would pass to a higher order function or use as an assertion. |
---|
| 63 | |
---|
| 64 | Argument Matching |
---|
| 65 | ----------------- |
---|
| 66 | How are arguments connected to parameters. This will become part of the |
---|
| 67 | overload resolution process, luckily it is a pretty simple straight forward |
---|
| 68 | pass fail check so does not effect cost. This covers all the features being |
---|
| 69 | considered, but most can cleanly be removed. |
---|
| 70 | |
---|
| 71 | First, the positional parameters have to be sorted out. |
---|
| 72 | |
---|
| 73 | Undesignated arguments are positional arguments, if one appears at the front |
---|
| 74 | of the argument list it is the 0 positional argument, otherwise it must |
---|
| 75 | follow another positional argument and it goes into the next position. It is |
---|
| 76 | an error for an undesignated argument to appear after a named argument. |
---|
| 77 | |
---|
| 78 | Array designated arguments are positional arguments. The constant expression |
---|
| 79 | is evaluated and the result is the position of the parameter it is matched |
---|
| 80 | with. |
---|
| 81 | |
---|
| 82 | The same process is way simpler with named arguments, as all are labeled. |
---|
| 83 | Member designated arguments are named arguments. They are matched with the |
---|
| 84 | parameter with the same name. |
---|
| 85 | |
---|
| 86 | The `@` argument can be used anywhere other arguments can be. The parameter |
---|
| 87 | it is matched with must be an optional parameters and this explicitly requests |
---|
| 88 | that the default argument be used. |
---|
| 89 | |
---|
| 90 | Then we can just check to make sure no parameter is provided/matched with an |
---|
| 91 | argument more than once, and that every required parameter is provided |
---|
| 92 | exactly once. If any arguments could not be matched to a parameter, it is an |
---|
| 93 | error. |
---|
| 94 | |
---|
| 95 | Note that there are no special rules for positional-or-named parameters, they |
---|
| 96 | can just be used in either case. |
---|
| 97 | |
---|
| 98 | Backwards Compatibility |
---|
| 99 | ----------------------- |
---|
| 100 | All parameters and arguments in C code can treated as (required and) |
---|
| 101 | positional, except for initializers which are optional and use designators. |
---|
| 102 | |
---|
| 103 | Initializers and C designators always consider the underlying parameter's |
---|
| 104 | position the important part. The designator moves the position in the |
---|
| 105 | parameter list forward or backward. If an argument is not designated, it is |
---|
| 106 | put the next position after the previous argument (or the first position if |
---|
| 107 | it is the first argument). |
---|
| 108 | |
---|
| 109 | It should be noted that this is actually more permissive than most languages. |
---|
| 110 | Other named parameter system enforce that all positional arguments come |
---|
| 111 | before all named arguments. |
---|
| 112 | |
---|
| 113 | However, we could translate this using optional and named-or-positional |
---|
| 114 | parameters. Removing the ability to have undesignated arguments follow |
---|
| 115 | a member designated arguments is required for named only parameters, doing |
---|
| 116 | the same for named-or-positional for a consistent interface. |
---|
| 117 | |
---|
| 118 | C also allows chained designators, nested initializers and descending into and |
---|
| 119 | out of recursive initializers automatically as the beginning or end of those |
---|
| 120 | sections. In the context of a member/element initializer, the system does |
---|
| 121 | have enough information to do this, because the target types are fixed by the |
---|
| 122 | type being initialized. |
---|
| 123 | |
---|
| 124 | These should be supported in the C escape initializer (`@=`), but cannot be |
---|
| 125 | generalized to function calls (not even initializers we resolve as functions) |
---|
| 126 | because of overloading. |
---|
| 127 | |
---|
| 128 | Run-time Implementation |
---|
| 129 | ----------------------- |
---|
| 130 | The underlying code must be translated into simple C code that does not use |
---|
| 131 | these parameters or arguments. |
---|
| 132 | |
---|
| 133 | For this purpose, we do use the ordering of all parameters, writing them |
---|
| 134 | out in the order they appear in the declaration. |
---|
| 135 | Note that the programmer still does not have to (and sometimes cannot) |
---|
| 136 | interact with the order of parameters, but the compiler will still use them. |
---|
| 137 | Here it boils down all the named forms down to positional code. This is the |
---|
| 138 | run-time efficient way to implement it. Other forms of argument packing, such |
---|
| 139 | as putting the named arguments into a map, tend to be slower and their |
---|
| 140 | advantages allow for more dynamic behaviour has a harder time using |
---|
| 141 | effectively. |
---|