transitivity does not imply type-checking Matthias Radestock (19 Nov 2005 11:16 UTC)
Re: transitivity does not imply type-checking Jens Axel Søgaard (19 Nov 2005 18:08 UTC)
Re: transitivity does not imply type-checking Matthias Radestock (20 Nov 2005 09:37 UTC)
Re: transitivity does not imply type-checking Jens Axel Søgaard (20 Nov 2005 10:04 UTC)
Re: transitivity does not imply type-checking Matthias Radestock (20 Nov 2005 12:53 UTC)
Re: transitivity does not imply type-checking Jens Axel Søgaard (20 Nov 2005 13:32 UTC)
Re: transitivity does not imply type-checking Matthias Radestock (20 Nov 2005 18:39 UTC)

Re: transitivity does not imply type-checking Jens Axel Søgaard 20 Nov 2005 13:32 UTC

Matthias Radestock wrote:
> Jens Axel Søgaard <xxxxxx@soegaard.net> writes:
>
>>I was just saying *if* you make that interpretation, you need to
>>type check all arguments.

> Apologies for harping on about this, but my initial post contained a
> counter-example: an implementation of = that meets the criteria of your
> interpretation, yet does not type-check all args.

Sorry - I misread your post - I thought the example was meant to
show, that type checking wasn't neccessary in R5RS.

Your example was:

   (define (= x y . rest)
     (and (number? x) (number? y)
          (prim= x y)
          (or (null? rest) (apply my= y rest))))

Hmm - just returning #f, in error situations does indeed make
it transitive.

It does lead to strange behaviour. Even though

      (< 1 'a)     => #f
      (> 1 'a)     => #f

we get that

      (= 1 'a)     => #f .

I'd prefer as many errors to be signaled as possible, but I guess that's
a matter of taste.

What's your view?

 > That is fine by me, but it is not the rationale given by the srfi
 > document, which instead claims that type-checking of all args is
 > implied
 > by the R5RS requirement for transitivity. The point of this thread was
 > to ascertain whether the latter is actually the case. It isn't.

Yes - the wording could have been better.

--
Jens Axel Søgaard