I came up with a neat idea for changing the syntax for call by name parameters recently (it turned out that it’s actually a reversion to an older syntax for it! The new one was there to resolve some problems, but I like the old syntax better so would rather resolve those problems directly). In the discussion of this some problems were pointed out and the feature list sortof spiralled out of control and collided head on with a previous proposal by Andrew Foggin. Here’s a summary of the current state of the proposal.
- Any of the modifiers currently allowed for local variables is allowed as either a function argument or a constructor parameter. i.e val, lazy val, var or def.
- A parameter marked as def has the same semantics as call by name parameters currently do. It replaces the old syntax (or, rather, the new syntax).
- A function taking N arguments is equivalent to a function taking a ProductN (modulo compiler optimisations). So given def stuff(val foo, var bar, def ba z) the invocation stuff(x, y, z) is equivalent to the invocation stuff(new Product3{ val _1 = x; var _2 = y; def _3 = z; })
In order to take into account the need to make call by name parameters constructor local, and generally improve the behaviour of constructors, we introduce an additional privacy modifier, “local”. Conceptually, things marked local are only visible within the constructor. It’s basically a stronger form of private, and is the scoping modifier that constructor arguments with no qualifiers currently have. local variables and defs are not visible outside the body of the class. Unlike private members, you may not access the local variables of another member of the same class.Edit: Seth Tisue has pointed out in the comments that you can already do this. The notation for it is private[this]
Since you beat me to the write-up of the combined proposals, I’ll add some comments here:
* ‘val’ can probably be optional
* Likewise ‘lazy val’ could just be ‘lazy’ (and also in the non-parameter case IMHO)
* At the moment Scala functions compile to a class having an apply method with possibly multiple arguments. While this remains a good solution where the parameter list has a direct Java equivalent, the boxing of multiple arguments into a ProductN may turn out to be a useful and efficient implementation technique when defs, vars and lazy vals are involved.
* This may also be useful for resolving problems where a Scala method cannot be overloaded because the Java signatures are indistinguishable – a specific wrapper class could be generated.
Nesting of arguments might be an issue. What happens if you have a function which takes one argument of Product3? I think having both forms might be difficult, at least at the Scala layer.
Why not take it all the way through and make all arguments ProductN for functions? The compiler can treat existing (Java) functions as having wrappers with ProductN, but then you solve the problem in terms of applying functions – they’re *all* ProductN calls. (Under the covers, the compiler may choose to do optimisations to inline currying; but there’s no reason to need it at the language level.)
Hm. That’s basically what I meant. I must not have explained myself well. Methods and functions with multiple arguments should really be methods/functions which take a ProductN + some stuff to select which implementation of ProductN is passed by default.
Is “local” the same as “private[this]”?
Good point! I’d forgotten you could do that.
Ok. Ditch that part of the suggestion. :-)