Short circuiting behaviour in type specific equality predicates

Short circuiting behaviour in type specific equality predicates

[Ian Price]

Hello, Guilers

When using type specific equality predicates in guile, I've noticed
that they only test the type of an argument, if it has not already
decided that the answer is false. Working my way through all the
predicates given by the meta command ",a =\??$" we find

GNU Guile 2.0.0.147-e309f
Copyright (C) 1995-2011 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (= 9 10 "foo")
$1 = #f
scheme@(guile-user)> (char-set<= char-set:letter char-set:digit "foo")
$2 = #f
scheme@(guile-user)> (char-set= char-set:letter char-set:digit "foo")
$3 = #f
scheme@(guile-user)> (string-ci>=? "bar" "foo"  '(#\f #\o #\o))
$4 = #f
scheme@(guile-user)> (string-ci<=? "foo" "bar" '(#\f #\o #\o))
$5 = #f
scheme@(guile-user)> (string>=? "bar" "foo" '(f o o))
$6 = #f
scheme@(guile-user)> (string<=? "foo" "bar" '(f o o))
$7 = #f
scheme@(guile-user)> (string-ci=? "foo" "bar" '(f o o))
$8 = #f
scheme@(guile-user)> (string=? "foo" "bar" '(f o o))
$9 = #f
scheme@(guile-user)> (char-ci>=? #\b #\f "foo")
$10 = #f
scheme@(guile-user)> (char-ci<=? #\f #\b  "foo")
$11 = #f
scheme@(guile-user)> (char-ci=? #\f #\b  "foo")
$12 = #f
scheme@(guile-user)> (char>=?  #\b #\f "foo")
$13 = #f
scheme@(guile-user)> (char<=? #\f #\b  "foo")
$14 = #f
scheme@(guile-user)> (char=? #\f #\b  "foo")
$15 = #f
scheme@(guile-user)> (>= 9 10 "foo")
$16 = #f
scheme@(guile-user)> (<= 10 9 "foo")
$17 = #f

... and so on.

I have not checked all of Guile's included modules, but I suspect this
is the case for most of them (certainly it is true for boolean=? and
symbol=? from (rnrs base) ).

Certain predicates do not have this problem because their third
argument is expected to be an integer (string-ci<=, string-ci>=,
string=, string>=, string<=, string-ci=) and others are restricted to
an arity of two (free-identifier=?, bound-identifier=?).

I was not sure whether or not to report this, as the behaviour is VERY
consistent and therefore, I thought, likely to have been a conscious
design choice. If this is the case, you can ignore this, but it seems
to me that the reason for having type specific equality predicates is
because 1. I want the guarantee or 2. It could theoretically help the
bytecode compiler give better code. This is similar to the situation
with fixnum and flonum arithmetic functions. If it is not, then we
have some low hanging fruit for wannabe guile contributors ;)

Regards,
Ian

Re: Short circuiting behaviour in type specific equality predicates

[Andy Wingo]

On Sun 03 Apr 2011 22:43, Ian Price <ianprice90@googlemail.com> writes:

> scheme@(guile-user)> (= 9 10 "foo")
> $1 = #f
[...]

> I was not sure whether or not to report this, as the behaviour is VERY
> consistent and therefore, I thought, likely to have been a conscious
> design choice.

Amusingly, I don't think it was a conscious decision, despite the
consistency.

> If this is the case, you can ignore this, but it seems to me that the
> reason for having type specific equality predicates is because 1. I
> want the guarantee or 2. It could theoretically help the bytecode
> compiler give better code.

I would not be against some compile-time warning passes to check that
the arguments are of the right type, but at least for things like <
there's the possibility of goops extending the primitives to be generic,
so that e.g "bar" could be less than "foo".  So producing a warning, or
indeed, even doing a typecheck, is tricky.

Thank you for investigating this issue, but unless someone feels very
strongly about it, I am inclined to punt :)

Regards,

Andy
-- 
http://wingolog.org/