» Implicit Named Parameters?

Implicit Named Parameters?

March 22, 2014 by Chris Johnson. Filed under code, madeup, public.

In Learnable Programming, Bret Victor argues that to dispel the mysteries of source code we must show data in its context. One of the examples he suggests of offering context is to add a feature to IDEs: when a developer hovers over a parameter in source code, the IDE shows a message indicating the semantic meaning of the parameter. If we’re calling the ellipse function and we hover over the fourth parameter, we see a message like “height of ellipse.”

Instead of asking the IDE to reveal context, we can have the language itself do so. Objective-C, Smalltalk, Python, Ada, Scala, SQL, R, and others do this through named parameters. In Python, we can define the ellipse function like so:

def ellipse(x, y, width, height):
  ...

We may then call the function with an undecorated sequence of positional parameter values, or we may name each one, possibly reordering them:

ellipse(10, 100, 40, 60)
ellipse(x=10, y=100, height=60, width=40)

While I prefer having the language reveal the context instead of the IDE, named parameters do not always contribute value. Sometimes what I want to pass as a parameter is already stored in a meaningfully named variable. In Objective-C, where the names are not optional, passing a message to an object with like-named variables feels silly:

[[Database sharedDatabase]
  addStudentWithFirstName:firstName 
                 lastName:lastName 
                 username:username 
                 inCourse:self.course];

I’m thinking of adding mandatory named parameters to Madeup, but I’d like to avoid the sillyness of labeling z when it’s already named z. One idea that I’ve been considering is to allow developers to omit the explicit mention of z if there’s already a variable in the environment named z. That is, instead of expressing

moveto x:10 y:30 z:0
moveto x:20 y:40 z:0

we allow for

z = 0
moveto x:10 y:30
moveto x:20 y:40

At the time of a function call, if a named parameter is not explicitly passed, we look up the name in the current bindings to determine the value to pass. I’m not sure. One could argue that I’d be hiding the interface of a function. Default named parameters already do this. Plus, the IDE could optionally show the implicit parameter. The benefit is that a developer doesn’t have to express her intent multiple times. “This is what I want z to be.” And that’s that.

Good idea or bad idea?

I see after writing this that Scala already supports this idea.