chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Elf
Subject: Re: [Chicken-users] Re: A few questions
Date: Thu, 31 Jan 2008 11:50:31 -0800 (PST)

On Thu, 31 Jan 2008, Kon Lovett wrote:

<snip>

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.

sorry, i meant to say type predicates, not default values. it would be a further extension that generally goes along with arity checking. apologies.


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.

i was referring to the get-keyword and let-optionals procedures/macros.

the big problem i see with arity is separating it from program logic. options can require other options, etc. a case where there are a number of required args, a number of independent (non-interconnecting) optional args, and a number of interlinked (ie, if one optional arg is passed, it requires other optional arg(s) to be passed as well) args is fairly common.
what would arity be of such cases?  is this actually an arity problem or
a program logic problem?  if we're going to include keywords explicitly
(opposed to counting them as rest arg or as optionals), the line gets even fuzzier.

a modification of your proposal would be what guile used to do.  trivalue
arity of the form (required-count optional-count rest?), before keywords
were a thing.  also, does a keyword arg count as one or two args for arity?
since invalid keywords are silently ignored (which is incorrect behaviour, imho), i would say that keywords == rest.

i do think that the handling of keywords should automatically catch invalid
arguments, though, in which case keywords should either be a count or included in optional-count. storing an extra symlist per procedure doesnt
seem like a good idea.

-elf


  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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]