optional arguments

[stibear]

I often want to define the function receiving optional arguments.
IMO, it is not necessary, but should be discussed.
How do you feel about it?

[nyuichi]

Basically, about the way of processing optional arguments, we have two options:

1. provide utility macro(s)
2. extend lambda (and maybe define, too) syntax

In the first approach, picrin would provide macros, known as let-optional let-optionals, for binding destructured optional arguments. They are not breaking any compliance with RnRS, and highly portable. But I'm sure it's not the best answer for your question.

The second approach is that we extend lambda's formals to take special keyword and succeeding expression(s) as a command for the lambda that it should process the arguments in certain range as optional arguments. This approach makes it very convenient to use optional arguments and rest argumets (and perhaps keyword argumets), but the compiliance gets appearantly decreased.

[nyuichi]

@stibear

let-optional example:

(define (foo a b . opts)
  (let-optionals opts ((c #f) (d 0) (e ""))
    ...))

If you submit a piece of code of let-optional implementation to me, I can start discusstion to decide to merge it or not soon!

[stibear]

Rather than using let-optional, I want to use pattern matching (#65).

[stibear]

Or, use case-lambda.

[nyuichi]

I'm not so against to add case-lamba, but at the same time I'm not for the addition very much.

[stibear]

R7RS requires case-lambda, doesn't it?

[nyuichi]

No, it specifies but optional.

[stibear]

Why are you not for the addition of case-lambda?

[stibear]

You're discussing the addition of keyword objects.
So I want to listen your opinion about SRFI-89 (http://srfi.schemers.org/srfi-89/srfi-89.html).

[nyuichi]

@stibear

Hi,

Why are you not for the addition of case-lambda?

I think case-lambda is too big to be a part of the core. The syntax is not so sophisticated yet, too. The only reason I need to add case-lambda is, if exists, because R7RS specifies it.

the addition of keyword objects.

Yeah, I often feel like using keyword arguments or optional arguments when coding on picrin. But thinking about what keyword object enables us to do, I cannot figure out the real merits of using keyword objects in addition to symbol objects. I want rational explanation for that. You can use quoted symbols wherever you're using keywords.

I want to ask your opinion about SRFI-89

As described above, I agreed keyword objects are very useful in most practial cases. But I won't supply that by the primitive operators. The implementation would be by scheme, not in C.

[nyuichi]

@stibear

You can find some documentation about Haskell's way of handling default parameters just by googling a little. Takes XMonad for example, they did default arguments using $ operator and record type updater:

main = do
    xmonad $ defaultConfig
        { manageHook = manageDocks <+> manageHook defaultConfig
        , layoutHook = avoidStruts  $  layoutHook defaultConfig
        }

In Haskell, as you may know, a record is an applicable object, and when he or she is applied with some of their field names and values, he or she returns a newly allocated record with the values of given field names updated with given values. That is, in the code above, defaultConfig { ... } returns a new record.

-- this evaluates to a record, whose manageHook and layoutHook are 
-- set to given values, and other attributes are of the values defaultConfig record holds.
defaultConfig {
    manageHook = manageDocks <+> manageHook defaultConfig
  , layoutHook = avoidStruts  $  layoutHook defaultConfig
  }

This doesn't makes any extension against parameter passing style, even though it scales very well and looks so beautiful.