Re: [Chicken-users] Re: A few questions

[Kon Lovett]

On Jan 31, 2008, at 10:28 AM, Elf wrote:

> i had previously read that, kon.  i was thinking of an alternate  
> representation
> for arity when i mentioned that it should be simple.  it should  
> have gone
> into a diff post.
>
> simplest arity is a pair, int . bool, required args and rest?.
> optionals present a problem: do we want to keep defaults, names, or  
> just ordering?
> keywords also present a similar problem.

What about SRFI-89, available for Chicken; Marc Feeley's alternative  
to the DSSSL style? Could use this as a canonical form, mapping the  
DSSSL style.

The default values are probably only relevant to documentation, not  
runtime arity checking.

One idea:

Arity-Info: (<# required> . <rest?>)
            | (<# required> <rest?> (<# optional> . <# keyword>))

(lambda-arity-information PROCEDURE) -> ARITY-INFORMATION
(lambda-pattern-information PROCEDURE) -> SRFI-89-PATTERN

(lambda-keywords PROCEDURE) -> LIST

(lambda-has-required? PROCEDURE) -> BOOLEAN
(lambda-has-rest? PROCEDURE) -> BOOLEAN
(lambda-has-optional? PROCEDURE) -> BOOLEAN
(lambda-has-keyword? PROCEDURE) -> BOOLEAN
(lambda-has-extended? PROCEDURE) -> BOOLEAN (or -optional? -keyword?)

(lambda-arity-required PROCEDURE) -> EXACT
(lambda-arity-optional PROCEDURE) -> EXACT
(lambda-arity-keyword PROCEDURE) -> EXACT
(lambda-arity-extended PROCEDURE) -> EXACT (+ -optional -keyword)

This is very speculative:

Return-Info: (Type-Symbol)
             | (Type-Symbol ...)
             | ()

(lambda-result-information PROCEDURE) -> Return-Info
(lambda-multi-valued? PROCEDURE)
(lambda-single-valued? PROCEDURE)

> theres yet another problem as well with anything more complex than  
> the pair
> mentioned above.  keywords dont have to be specified in the  
> definition, there exists support procedures for parsing out  
> keywords from an arbitrary
> rest arg.

Which "support procedures"? The 'misc-extn' egg has an API but I  
doubt you mean that.

>   additionally, whats the arity of case-lambda?  or of parameters?
> perhaps instead of a direct arity function/macro, a valid-arity? macro
> could exist instead.  that should trade in the can of worms of  
> arity for
> an entirely different, hopefully smaller can.
>
> -elf
<snip>

Best Wishes,
Kon