Re: Int overflow

This is my third resend of this message. Previous (partial?) failures appear to be due to that "reply" cannot be used and/or MIME attachments cannot be used. Apologies to anyone seeing this message for the umteenth time. (And this is the *only* mailing list that I have trouble with...)

Re: [kff@it.kth.se: Re: Int overflow]

> > Karl-Filip Faxen <[EMAIL PROTECTED]> writes: > > > There is a hidden cost to trapping Int overflow ... > > operations on Ints become unsafe i.e. may raise exceptions > > This is a problem both for a global > > instruction scheduler (e.g. a trace scheduler) and for other > > optimi

Re: [kff@it.kth.se: Re: Int overflow]

At 10:11 -0500 97/10/29, Benjamin Goldberg wrote: >Just as a note, the computer architecture folks have designed support >for speculative execution in the presence of exception-causing >instructions. The idea, as embodied, for example, in the >Hewlett-Packard Playdoh architecture, is that there i

general parametrized types (was Re: Int overflow)

Hans Aberg wrote: > > Well, my idea is that all those types shouldsomehow be unified by a > single, parametrized type, which allows any bit length (not just 2^n), and > allowing signed/unsigned operations to be mixed without type conversion. > Together with the type-constructors used by monad

Re: Int overflow

There is a hidden cost to trapping Int overflow, beyond the extra instruction per operation mentioned by Paul Hudak. This is that operations on Ints become unsafe i.e. may raise exceptions (well that was the whole idea...). This is a problem both for a global instruction scheduler (e.g. a trace s

[kff@it.kth.se: Re: Int overflow]

Karl-Filip Faxen <[EMAIL PROTECTED]> writes: > There is a hidden cost to trapping Int overflow ... > operations on Ints become unsafe i.e. may raise exceptions > This is a problem both for a global > instruction scheduler (e.g. a trace scheduler) and for other > optimizations based o

Re: Int overflow. Reply to reply to replies.

At 16:13 -0500 97/10/28, Alastair Reid wrote: >Once again, I refer people to the documentation for the shared Hugs-GHC >libraries. > > ftp://haskell.org/pub/reid/libs971028/libs.html > >As well as all the usual mutable stuff, these libraries provide the following > types: > > Int8, Int16, Int32,

Re: Int overflow. Reply to reply to replies.

At 21:25 -0500 97/10/27, Paul Hudak wrote: >S.D.Mechveliani wrote: > >> I wonder, why Haskell does not check/report the overflow for Int? > >After thinking about this for awhile, I agree with Sergey that there >should be an Int datatype that truly implements partial functions, not >total functions

Re: Int overflow. Reply to reply to replies.

Hans Aberg wrote: > From a generalistic point of view (not necessarily in the context of > Haskell), I am inclined to believe that the Int type should be replaced by > a type named Binary(32) or something. This binary type should know how to > do +, -, signed/unsigned

Re: Int overflow. Reply to replies.

S.D.Mechveliani wrote: > I wonder, why Haskell does not check/report the overflow for Int? After thinking about this for awhile, I agree with Sergey that there should be an Int datatype that truly implements partial functions, not total functions modulo some large N. For a compiler emitting nat

Re: Int overflow

>Qxd$QC/sdeK{93/{KA]&T@gir{b8(rd5/zL85UcsTGty!z9Nx%Z+0e193YVEXFcWdM.]+uyVYA6WN Nn]tdh-oQ]/#\R;Vts^}W]a%+%VqSEAu Date: Fri, 24 Oct 1997 11:23:16 -0400 From: Alastair Reid <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] Precedence: bulk Resent-Date: Fri, 24 Oct 1997 16:33:49

Re: Int overflow

On Fri, 24 Oct 1997, S.D.Mechveliani wrote: > For example, x^(2^n) --> x^0, if 2^n > maximal_Int. > > For the algebra, it would be better to >*break in such case with the overflow message*. I'm not sure that people who want to write `production systems' (i.e., ones tha