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: > On Thu, 6 Jan 2005, Taylor Campbell wrote: > > > 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. > > Yes; but it's just as surprising to encounter a guard? and then => too. One could find anything that one is unfamiliar with surprising. I'm not sure what you find surprising in specific about that, however, and the deception that it could look like a procedure call is very specific & concrete. Furthermore, the order I chose is more consistent with the order in which things are evaluated: first the generator, then the guard, and finally -- conditionally -- the receiver. > > Also, the guard is usually in that position in similar constructions > > that linearize nested conditionals: SYNTAX-CASE, Andrew Wright's MATCH, > > &c. > > I don't know MATCH, but SYNTAX-CASE must place fender-expr second because > it doesn't have the special "=>" marker. No, there is no such constraint. It could just as easily put the guard first. > Do you think of the guard as > optional? If so, then you're logically talking about sub-casing the > existing => clause, not adding another cond clause syntax. Recast your > proposal in those terms. If it helps you to think of it that way (with the default guard being the identity function), go ahead; the way I wrote the specification was intended to be as simple & straightforward as possible. I'm not going to change the wording just because you demand that it better match your thoughts. > > 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. > > On what basis do you believe that the value is temporary? See my comments > below. I was using the word loosely, for the purposes of describing what the new COND clause does. 'Local' or 'generated' value might have been better choices of words, but it is not as significant as you make it out to be. > > Not only do your suggested workarounds require either writing several > > new routines for every possible application or inserting clumsy IFs in > > COND clauses, > > I would construct something like > (define (anaphoric x) (if x x #f)) ;;make macro and with-values easily > and get > (cond > (((anaphoric char?) (read-char port)) => (lambda (c) ...)) > ...) That is still a workaround that requires inserting a few extra tokens into the conditional and still exhibits all of the temporary boxing problems. > > but they may also require complicating the matter by constructing > > temporary boxes to hide #F if it is a possible useful temporary value. > > I don't see how your proposal avoids this ... #F means "go to next clause" > for cond. Maybe I don't understand this point; can you explain? If #F is considered a useful value -- e.g., as a table entry --, then it would not work for the conditional part of a (<conditional> => <receiver>) clause to return #F, because that would make the clause fail. Instead, it must box #F somehow to pass to the receiver, so that COND doesn't take its result to mean failure, and the receiver must remove the contents of the box. > > 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. > > Convince me that the guard will *always* treat the value(s) as temporary: > ie. the guard doesn't memoize or perform some other operation that forces > it to be a listified anyway. Otherwise, you can't safely do what you're > proposing, unless the guard is so simple that a decent peephole or > inter-procedural optimizer can see its way clear to doing this. I'm not trying to convince you of that. It isn't true. What I _did_ argue is that the way it is currently designed is easier to optimize for most cases than your kludgey workarounds. Even ignoring boxing of #F, what you suggest for multiple return values requires boxed lists. For example, consider your MY-PROJ0 procedure (which probably ought to have a different name, since it is very different from PROJ0): it takes any number of arguments; if the first argument is true, it returns a list containing all of the arguments. This is harder to analyze & optimize: even if it is a known procedure, only if either all call sites are also known or the call is integrated can the list be easily unboxed by the compiler. With my design, the list is never returned: it is only propagated to different procedures in quick succession. What those procedures do is immaterial: if the guard stores its argument list somewhere, sure, a list will have to be allocated. However, the design I constructed does not _intrinsically_ necessitate allocating a list, unless the compiler does not even optimize rest argument propagation. It is specific to the guard anyway. In brief, your workarounds are harder to optimize in the general case, whereas mine are trivial, unless the specific application intrinsically uses a heap-allocated list anyway, in which case the point is moot.