complexity of mechanism Taylor R. Campbell (11 Apr 2006 21:38 UTC)
|
Re: complexity of mechanism
Marc Feeley
(11 Apr 2006 21:48 UTC)
|
complexity of mechanism Taylor R. Campbell 11 Apr 2006 21:38 UTC
This is one of the most complex extensions to the fundamental core of Scheme I've ever seen. Although I won't claim that it has no historical precedent, I have to wonder whether the bulk of it couldn't be greatly simplified. I had written up a draft a while ago for a basic optional positional parameter SRFI, but its bulk was in explaining its rationale in comparison to other mechanisms (SRFI 16's CASE-LAMBDA and Olin Shivers' LET-OPTIONALS) and in elaborating on implementation strategies. For those curious, it's at <http://mumble.net/~campbell/proposals/optional.text>. I am personally generally opposed to named parameters intermixed with positional ones. Most of the examples of code in the SRFI 89 document are either very contrived or can be expressed without using named parameters, in some cases much more simply, either by instead using an alist or by changing the idiom of parameter passing; macros for picking apart such alists of options are helpful. For example, R3RS had an elaborate number formatting library based on list-structured formatting specifiers, rather than named parameters to NUMBER->STRING. For XML output, I think simply having a list of attributes makes *much* more sense than manually specifying every possible attribute at the definition site: (define (make-html-styler tag) (lambda (attributes . content) (element tag content (map (lambda (a) (attribute (car a) (cadr a))) attributes)))); although this doesn't provide static guarantees of the allowed attributes, one can always insert checks later on (e.g., with another parameter to MAKE-HTML-STYLER). As for n-ary procedures with named parameters, I always find them very confusing. I don't think the port parameter to I/O procedures should be optional in the first place, and rather than the PRINT procedure described in this SRFI for generating complex output I prefer a higher-level and more structured library of output combinators, <http://mumble.net/~campbell/scheme/output.scm>, in which the various OUTPUT-... procedures return procedures that take a single port parameter and write the output to it. I've built a structured XML output library based on this idiom, in fact, which is very simple but equally general. I'd like to see some compelling examples that demand named parameters and for which alists of options would not suffice, perhaps for performance reasons or otherwise. In my experience I can't recall ever having found any good ones, really; do you have any particularly compelling examples where you found named parameters with this mechanism much more appropriate than any other mechanism, or than separate procedures to do different jobs?