[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH][5] types.db entries for the overflow-aware
From: |
LemonBoy |
Subject: |
Re: [Chicken-hackers] [PATCH][5] types.db entries for the overflow-aware ops |
Date: |
Sun, 21 May 2017 20:12:42 +0200 |
User-agent: |
Mutt/1.8.2 (2017-04-18) |
On Sun, May 21, 2017 at 06:25:09PM +0200, Peter Bex wrote:
> I don't really care that much about this, so unless others have similar
> concerns I think we can apply this change.
>
> However, they shouldn't be #:enforce; they don't raise an error when
> their types are fixnum or false, which is what enforce means: if the
> code goes beyond this expression, you may assume the input types are
> correct.
>
I know, I've added the #:enforce annotation because the result is either
C_SCHEME_FALSE or something that went trough C_fix so no matter what the input
is we _always_ get a result with the correct type...whether or not the result
has any meaning is a different topic :)
The same goes for the other procedures, there's a comment in types.db that reads
`;;XXX should these be enforcing?` so this has been already discussed before.
> I believe these procedures can be marked #:pure, though, since they
> don't have *any* side effects (except for fx/?, since it will raise an
> exception when dividing by zero).
>
> Speaking of which: can't all the other fixnum-specific procedures be
> pure as well? Except for fx/, of course.
>
Of course, good catch.
> > - There's no way to distinguish the result of `(fx+? 'foo 3)` from the
> > result of an
> > overflowing calculation, couple it with the lack of any warning and
> > you're in for a nice bug
> > hunt.
>
> Speaking of strange bugs, I'm wondering whether these fixnum procedures
> should be foldable at all (that also goes for the procedures that are
> already in types.db). Consider the case where you're compiling on a
> 64-bit machine. The compiler folds the fixnum operations at
> compile-time, resulting in a fixnum. However, if the fixnum is not
> representable as a fixnum on the target computer, it will be represented
> as a bignum (or on CHICKEN 4, as a flonum).
>
> This not only produces a different answer than when the same code would
> be compiled on the 32-bit machine and in the interpreter, but it also
> may trigger other unexpected behaviour resulting from a mismatch of the
> expectation that you're dealing with fixnums only. For example, a
> specialised unsafe version of a generic procedure might end up being
> specialised for fixnums, but on a 32-bit platform it might still receive
> a bignum (or a flonum on master).
>
I think that's the right thing to do, too bad we can't check if the result of
the constant evaluation matches the expected type at compile time.
> Hm, I wonder if this stuff causes other problems as well...
>
> Anyway, attached is a signed-off version of your patch without
> the #:enforce and with the #:pure annotations, and a second patch
> which removes #:foldable from the other fixnum operations too.
>
> Cheers,
> Peter
- [Chicken-hackers] [PATCH][5] types.db entries for the overflow-aware ops, lemonboy, 2017/05/19
- Re: [Chicken-hackers] [PATCH][5] types.db entries for the overflow-aware ops, Peter Bex, 2017/05/19
- Re: [Chicken-hackers] [PATCH][5] types.db entries for the overflow-aware ops, lemonboy, 2017/05/21
- [Chicken-hackers] [PATCH] Do not assume all fixnum literals will be fixnums at runtime [was: Re: [PATCH][5] types.db entries for the overflow-aware ops], Peter Bex, 2017/05/21
- Re: [Chicken-hackers] [PATCH] Do not assume all fixnum literals will be fixnums at runtime [was: Re: [PATCH][5] types.db entries for the overflow-aware ops], Evan Hanson, 2017/05/24
- Re: [Chicken-hackers] [PATCH] Do not assume all fixnum literals will be fixnums at runtime [was: Re: [PATCH][5] types.db entries for the overflow-aware ops], Peter Bex, 2017/05/24
- Re: [Chicken-hackers] [PATCH] Do not assume all fixnum literals will be fixnums at runtime [was: Re: [PATCH][5] types.db entries for the overflow-aware ops], Evan Hanson, 2017/05/24
- Re: [Chicken-hackers] [PATCH][5] types.db entries for the overflow-aware ops, Evan Hanson, 2017/05/24