On Sun, Feb 06, 2005 at 02:30:21AM +0800, Autrijus Tang wrote: > On Sat, Feb 05, 2005 at 02:39:26PM +0000, Nicholas Clark wrote: > > On Sat, Feb 05, 2005 at 10:04:02PM +0800, Autrijus Tang wrote: > > > On Sat, Feb 05, 2005 at 01:52:05PM +0000, Nicholas Clark wrote: > > > > > #t and (0 | 6) < 2 # reduction in boolean > > > > > context(!) > > > > > > > > Why is it allowed to do this? > > > > > > Because "and" forces boolean context to determine whether it > > > short-circuits or not. However, I should've make it clear that > > > if the left hand side evaluates to #f, it will return the junction > > > itself, not #f. This is true in both spec and pugs implementation. > > > > (Without understanding the background to the implementation of junctions) > > why are you using a short-circuiting "and"? > > Well, because perl5's "and" is short-circuiting, and I assume perl6's > "and" is no exception... > > > Surely if you take an expression that contains the junction (a|b) and > > convert that to ... a ... and ... b ... then you are implying an order to > > the elements of a junction? I didn't think that junctions had order - I > > thought that they were sets. > > Sure. The question is whether the junctions should autothread over the > whole comparison chain (globally), or only to a specific binary > comparison (locally).
OK. So the question I'm asking, which I think is orthogonal to yours, is If junctions are sets, and so a|b is identical to b|a, then isn't it wrong for any implementation of junctions to use any short-circuiting logic in its implementation, because if it did, then any active data (such as tied things will side effects) may or may not get called depending on whether a junction happened to be stored internally with a first, or with b first? (unless the implementation can prove to itself that nothing it's dealing with has side effects, so short circuiting will have no effect. Of course, this is an implementation detail, and aside from speed, must not be determinable from outside) Nicholas Clark
