[Swift-devel] Nasty multiparameter function hack.

[Mihael Hategan]

On Wed, 2007-04-25 at 08:32 +0000, Ben Clifford wrote:
> However, where the parameter is a variable:
> 
>   @f(x)
> 
> this turned into a Karajan function call with two parameters, a 'variable' 
> and a 'path'. In the above case, the variable is x and the path is empty.
> 
> In the case of @f(x.y) then the variable would be x and the path would be 
> y.

That's kinda wrong:
@f(x) should be f(getfield(x, path="")) which can be reduced to f(x) and
@f(x.y) should be f(getfield(x, path="y")).

Consequently:
@strcat("x", x) -> strcat("x", x)
@strcat("x", x.y) -> strcat("x", getfield(x, path="y"))

> 
> This leads to inconsistencies, such as :
> 
>  x = 3
>  y = @f(x)
> 
> resulting in a very different karajan function invocation to 
> 
>  y = @f(3)
> 
> This rather awkward arrangement is used by @filename because it 
> essentially wants pass-by-reference rather than pass-by-value semantics in 
> order to extract the filename of its passed parameter.
> 
> I wanted to avoid indulging in massive expression evaluator hackery, so I 
> put in the following behaviour for multi-parameter functions:
> 
> For a function f with parameters x1, x2, x3, etc which may be constants or 
> expressions or other function calls or variables (note that all three are 
> treated differently), then:
> 
>   if x_n is a constant, expression or function call, we translate that 
> into a single karajan-layer parameter.
> 
>   if x_n is a variable reference, then we translate that into two karajan 
> parameters, first the path, and second the variable.
> 
> This magically works for @strcat when used with top level variables, 
> because path is empty, so  @strcat("hi",x) translates into a concatenation 
> of *three* things: "hi", the path "", and the contents of variable x, and 
> as "" is a zero wrt @strcat then its the same as "hi" and the value of x.
> 
> However, this approach will fail in at least the following circumstances 
> (I think)
> 
>  i) @strcat("hi",x.y)   (because now path will be non-null)
> 
>  ii) if we ever have a function that cares about the ordering of its 
> parameters.
> 
> I don't particularly propose resolving this for the 0.2 timeframe. 
> However, this is a mess which *will* cause trouble later on, so a work 
> item (perhaps for 0.3 milestone) should be to sort out this (and a number 
> of other messy bits in the expression system).
>