Named params

[jo...@mentics.com]

I'm curious on what people think of the concept of named parameters.
One of the challenges of languages such as lisp and almost every other
language I know readability of the meanings of parameters:

(write A B C) or write(A, B, C)

What does it write to where how? There's no way reading just the code
to tell which parameter does what.

(write to:A value:B with:C)

Is this perhaps more readable? Are there useful arguments for or
against this type of thing?

I realize this is a general question on not Shen specific, but...
would this be something that might be interesting in supporting
optionally in Shen? Even if the parameter names were completely
ignored, would it perhaps result in more readable code?

Similarly, could we support something like this in defining functions:

(define write { to:stream --> value:number --> with:something } ...)

If we had some standard notation for that, then IDEs could use it to
provide additional support, too.

I'm not suggesting this notation necessarily, I just chose something
to illustrate.

ps. after writing this, I did a search and see that Common Lisp
supports named params, default param values, and out of order. At
first glance, I'm not sure I like the way it's done, but I only
glanced at it.

[Mark Tarver]

Named parameters really came into play in Common Lisp because of the
multiplicity of functions with optional parameters. Sometimes these
had n optional parameters for n = 2, 3 or even more. Without some
sort of naming, using the correct ordering out of n! choices would be
the only way forward. Since the latter was not really acceptable,
naming was used to allow programmers to enter options in an order-free
manner.

Type theoretically this is a PITA, so I avoided it.

Mark

[Mark Tarver]

to expand...

Back in 2002 I wrote a paper on this where I explored the sequent
calculus type theory of CL. It is messy and really its not the way to
go.

If you wanted to implement this in Shen you create a macro to strip
out the keywords and put arguments in a canonical order inserting
default values when needed. This is then sent to the type checker.

But actually I never missed this feature of CL much.

Mark

[jo...@mentics.com]

On Tue, Nov 13, 2012 at 3:03 PM, Mark Tarver <dr.mt...@gmail.com> wrote:
> Named parameters really came into play in Common Lisp because of the
> multiplicity of functions with optional parameters. Sometimes these
> had n optional parameters for n = 2, 3 or even more. Without some
> sort of naming, using the correct ordering out of n! choices would be
> the only way forward. Since the latter was not really acceptable,
> naming was used to allow programmers to enter options in an order-free
> manner.
>
> Type theoretically this is a PITA, so I avoided it.

I don't think it needs to be. The way I see it, the underlying
function is always type specific. The named, optional, etc. are all
just syntax sugar. Maybe could be done with macros? At the very least,
I'm sure klambda would not be affected.

So at "preprocessing" time, this:

(write to:A value:B with:C)

is converted to:
(write A C B) (if we messed with the order)

"optional" parameters would only be optional if they were provided
default values, so as far as the implementation of the function goes,
it would never have any missing params.
(write to:A value:B) would be (write A default-value C)

[jo...@mentics.com]

> Back in 2002 I wrote a paper on this where I explored the sequent
> calculus type theory of CL. It is messy and really its not the way to
> go.

But as you mention below, named params don't need to affect the type
theory at all.

> If you wanted to implement this in Shen you create a macro to strip
> out the keywords and put arguments in a canonical order inserting
> default values when needed. This is then sent to the type checker.

Exactly.

> But actually I never missed this feature of CL much.

Well... so many times I have been reading code and have to go look up
APIs... seems like something like this would make things more
readable. Even looking at function definitions, unless it has some
doc, I often have to read the implementation to find out what the
parameters are supposed to be since the types aren't always
sufficient.

I still can't remember what the order of parameters are for address->.
And vector-> and address-> use different parameter orders.

[Mark Tarver]

If you have functions of a large arity with heterogenous optional
arguments then you need naming. Shen de facto has a max of 3 for
system functions so it was not needed. Generally I'm minimalist in
design. but in other apps you would need naming.

Mark