[Swift-devel] Nasty multiparameter function hack.

[Ben Clifford]

There's a nasty hack in the multiparameter function handling, which 
doesn't affect the extremely simple function invocations that we make at 
the moment but will whenever we try to do anything more advanced.

Basically the problem I had was this:

In the previous single-parameter syntax, a call like this:

   @f(3)    or @f(1+2)

(where the single parameter is a constant or an expression)

turned into a Karajan function call with a single parameter.

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.

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).

--