[Copying the WG1 list on this point.] Christian Stigen Larsen scripsit:
> Draft 8 does not say whether the return value for an unmatched cond-expand > is unspecified. You're right, and it's All My Fault, but it's probably too late now. The winning proposal was CondExpandCowan, which was cloned from SRFI 0. In SRFI 0, falling off the end of a cond-expand is an error, and I meant to clone that feature into my proposal, but didn't. That's not a big problem for the cond-expand macro, because you can add your own else clause. In the cond-expand library declaration, however, it's another story, as there is no explicit way to signal an error from library expansion. Chibi simply ignores the whole cond-expand in that case, which is not perhaps the best thing. > "[...] Otherwise, the cond-expand has no effect. Unlike cond, > cond-expand does not depend on the value of any variables." Without a vote, we can't override the previous vote. I do not feel inclined to call for such a vote myself at this point, though other WG members may feel differently. -- Yes, chili in the eye is bad, but so is your John Cowan ear. However, I would suggest you wash your [email protected] hands thoroughly before going to the toilet. http://www.ccil.org/~cowan --gadicath _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
