oleg@pobox.com 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 <zednenem@psualum.com> <http://www.eyrie.org/~zednenem/>