On Fri, Jan 6, 2012 at 2:03 PM, Mark H Weaver <m...@netris.org> wrote: > Alex Shinn <alexsh...@gmail.com> writes: > >> On Fri, Jan 6, 2012 at 9:49 AM, Mark H Weaver <m...@netris.org> wrote: >>> >>> I'd like to argue in favor of supporting (begin), (cond), (case-lambda) >>> and other such degenerate forms, for the same reason that we support >>> (*), (+), and (let () ...). >>> >>> First of all: Is there any compelling reason not to support them? >>> I can't think of one. Can you? If so, please do tell. >> >> 1. portability - these extensions may not work on other >> implementations. > > Well, how about mandating support for these degenerate forms in R7RS? :) > I'm quite serious. I would argue the point on WG1 if I was allowed to > post there.
You're allowed and encouraged to post to scheme-repo...@scheme-reports.org. We take all comments seriously. >> 2. the fact that these may be indicators >> or broken macros. Suppose in general p% of macro >> expansions into cond are bugs. Since (cond) is a degenerate >> form, it's reasonable to suppose that q > p% of expansions >> into (cond) are bugs. If q is larger enough than p, then it's >> not worth the convenience it saves in some cases. Not >> that I have any idea what p and q are for these forms. > > You could make the same argument against (and), (or), (+), (*), and > perhaps others. If you were designing Scheme from scratch, would you > prohibit these forms? Whether I were designing from scratch or updating an existing standard, I would avoid sweeping generalizations and consider each form or procedure on a case-by-case basis. A foolish consistency is the hobgoblin of little minds :P > It seems highly unlikely to me that flagging errors on (cond) will > significantly reduce the amount of effort needed to debug macros. I've > debugged many macros, and I can't remember a single time when flagging > (cond) as an error would have saved me any effort. Can you? Seeing as how (cond) is currently non-standard, it's the other way around - you have to provide evidence that it's useful in macros. Since by definition you're expanding a macro whose return value is undefined, I think this is likely a corner case (and possible evidence that the macro was poorly thought out to begin with if it may sometimes be defined and sometimes undefined). Again, I haven't really thought about these cases, and they weren't brought up for discussion. Post your argument to the public list and we can consider it for the next draft. -- Alex
