On Wed, Apr 16, 2008 at 09:39:52AM -0400, Brandon S. Allbery KF8NH wrote:
> On Apr 16, 2008, at 3:49 , John M. Dlugosz wrote:
>> Or, are the operators written in a tricky way, to return an object that 
>> encapsulates the original right argument and the proper boolean result, 
>> and has forms to take this object as well?  IOW, no built-in support.
> Yes, they use multiple-typed values such that (3 < 5) returns (5 but True), 
> which used in a numeric context is a 5 that can be chained with further 
> infix:{'<'}s but in a boolean context is True.

Well, that's more or less how Icon does it, but we're not going to expose
anything like that to the user.  If we assume that comparisons take two
immutable objects, we can leave it to the compiler to compute the actual
value once, and then feed it to both sides of the implicit AND.  The
user just writes an ordinary binary comparison that returns a boolean.

For several years now I've been treating any use of "but" as a code
smell, and changing the design so it isn't necessary.  It's been a
rather useful construct that way, like "eval" and "BEGIN". :)


Reply via email to