[EMAIL PROTECTED] writes: > Regarding argument 1: the value of |maxBound :: Int| is also the > function of the environment. Haskell98 Report says [p82, Section > 6.4] > > The finite-precision integer type Int covers at least the range > [ - 2^29 , 2^29 - 1 ]. As Int is an instance of the Bounded class, > maxBound and minBound can be used to determine the exact Int range > defined by an implementation. > > Thus, the value of |maxBound :: Int| may conceivably change from on > program run (under runhugs32 on an AMD64 platform) to another (under > runghc64 on the same platform).
I guess we could declare 32- and 64-bit Ints to be distinct types, and then do a system call to get the native Int type. data SomeIntegral = forall a. Integral a => SomeIntegral a nativeInt :: IO SomeIntegral main = case nativeInt of SomeIntegral (_::int) -> print (maxBound :: int) The disadvantage would be the need for polymorphism over the Integral class whenever we wanted native-sized integers. > Regarding argument 2: the existence of System.Environment.withArgs > seems to doom getArgs to remain with the IO type. It cannot be a pure > function. The simple extension of the argument points however to > inconsistency with the floating-point facility. Haskell98 Report > permits an implementation to use IEEE FP for Haskell Floats and > Doubles. The Report specifically provides the class RealFrac to give a > program access to some aspects of the IEEE FP system. IEEE FP > computations are sensitive to the rounding mode, which is observable > in pure code. The rounding mode can be changed. [...] Should all > floating-point computations be put in the IO monad? In principle, you could use seperate types to distinguish floats with different rounding modes, but I imagine this would be difficult or annoying to implement. -- David Menendez <[EMAIL PROTECTED]> <http://www.eyrie.org/~zednenem/> _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell