On 13/09/2014, at 12:50 PM, srean wrote:

> A slightly peripheral operator related gripe (about C and C++) :
> 
> unsigned_int - unsigned_in -> unsigned_int
> 
> is just wrong. 

Yes it is, but if you want a proper solution to this you need a very powerful
dependent type system. I'm not sure even ATS can handle it.

> There should not be a polymorphic subtract that takes two unsigned ints and 
> returns and unsigned int. The value returned should be an int.

Those statements are contradictory :-)

It depends what you think an unsigned int is.  The C model is

        Z (i) + Z (j) => Z_{n^2) (i + j)

which is perfectly consistent, practical. I.e. do the calculation
then modulo back to the starting base.

If you want a signed difference, well, int isn't big enough anyhow.

> If one really wants wrap around semantics they should cast the result back to 
> unsigned explicitly, or the language should offer some other operator, just 
> not "-" for modulo subtraction.

Why not? It uses + for modular addition.

Really, however, the operation is as above. Division, for example, isn't
defined on base 2^n for any value of n other than 1. So there is no
modular division (except on bool :)


> 
> Same holds for unsigned and signed. Mixed sign arithmetic is just fraught 
> with peril in particular subtraction. Of course this is just band aid because 
> even signed subtraction is not closed either  but I have seen enough bugs 
> resulting from  unsigned_int - unsigned_in -> unsigned_int,  not enough from 
> their signed cousin.

Felix does not do any implicit conversions (well not that kind anyhow).

It also doesn't define bitwise operators &, ^, | or ~ on signed integers.

Haskell's solution is correct: infinite precision integers. But then, it is
also very slow .. :)

Ultimately computer programs are local approximations: they work
within certain limits. For (most) integer operations you can say
the result is correct if the arguments are small enough.

Unfortunately keeping track of what is small enough is very hard
and not practical by any means other than a run time check.

--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org




------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to