This page is part of the web mail archives of SRFI 61 from before July 7th, 2015. The new archives for SRFI 61 contain all messages, not just those from before July 7th, 2015.
On Thu, 6 Jan 2005, Christopher Dutchyn wrote: > I'm unconvinced of the utility of your proposal. First, I would recommend > placing the guard before the generator, it reads so much better. Your examples > become: > (char? (read-port port) => (lambda (c) ...)) > and > (proj0 (table-entry <table> <key>) => (lambda (present? value) ...)) > > It becomes clear that you're just distingishing the number of terms before the > =>; R5RS section 4.2.1 gave a single alternate for (<test> => <exp>). That sounds reasonable. I'll consider it. However, it might be a bit deceptive or confusing in the syntax, in that it looks like a regular procedure call at first, though it's not. Also, the guard is usually in that position in similar constructions that linearize nested conditionals: SYNTAX-CASE, Andrew Wright's MATCH, &c. > But, once I write your examples in the more legible way, I realize that I > already have what I want using the accepted definition that only #f is false > (R5RS section 6.3.1): > > (define anaphoric-char? (lambda (c) (if (char? c) c #f))) > (define myproj0 (lambda p?v (if (car p?v) p?v #f))) > > and your examples in R5RS syntax become > > ((anaphoric-char? (read-port port)) => (lambda (c) ...)) > and > ((myproj0 (table-entry <table> <key>)) => (lambda p?v ...)) > > Is there something about your proposal that I'm missing? Yes. What you suggest here are some workarounds for the real problem, which is having more general way to conditionalize. Essentially, this proposal more cleanly separates the condition from a temporary value that is useful if the condition holds true, while the existing COND => syntax multiplexes the temporary value and the condition. Not only do your suggested workarounds require either writing several new routines for every possible application or inserting clumsy IFs in COND clauses, but they may also require complicating the matter by constructing temporary boxes to hide #F if it is a possible useful temporary value. This overhead is also necessary in order to support multiple possibly useful temporary values, which you must store in a temporary list; such a list is harder for a compiler to optimize than the way I have designed it. (The way I have designed it, the temporary rest argument list used by the second argument to the CALL-WITH-VALUES is both ephemeral and used only as the second argument to APPLY, in immediate succession. This is trivial for a compiler to optimize into code that just reuses the same registers or the same stack frame for the arguments to the guard and the receiver. With your workarounds, however, the list has arbitrary extent, and it is operated on with heap-accessing list processing routines.) (By the way, your MY-PROJ0 example wouldn't work. It would need to instead be (CALL-WITH-VALUES (LAMBDA () (TABLE-ENTRY TABLE KEY)) MY-PROJ0), given the way I described TABLE-ENTRY.)