Since you did not mention the name of your professor, I have forwarded your
query to both the undergraduate and graduate secretaries at the University
of Manchester. I am sure they will be able to deal more effectively with
your homework and your complaints than I can. I am sorry to hear that you
dear sir/madam
iam contacting you regarding a java problem which i have come
across. My teacher at manchester met has set a problem for
us to solve but thinking his teaching is excellent and everyone understands
him wen no one does I would appreciate you helping me in this problem as it
would sa
On Tuesday, February 26, 2002, 15:36:18 EST, David Feuer wrote:
> [...]
> Question: Is there any standard way in Haskell of determining the maximal
> and minimal Int values?
There is one. Use maxBound :: Int and minBound :: Int.
> [...]
By the way, the report says: "Class Enum defines operati
Dean Herington:
> I strongly prefer that that behavior _not_ be provision of any
> normal Int value.
I agree.
I think a operation to let you examine the (possibly) underlying 2s
complement representation without raising an exception should be quite
separate from the operation to convert between
David Feuer writes:
:
| Question: Is there any standard way in Haskell of determining the
| maximal and minimal Int values?
Yes, instance Bounded Int, which means you can use
maxBound :: Int
and
minBound :: Int
___
Haskell mailing list
[E
What about having Int be considered a restricted integer that notices
overflow, and create another type (bit bunch?) that does not notice
overflow, and require explicit conversion to go from one to the other?
This would seem to be the best of both worlds. The "bit bunch" type
could also provide u
It seems to me that the behavior for `(fromInteger x)::Int`, where x is
an Integer outside Int range, should be the same (in terms of the
Haskell report) as that for `y + y`, where y is an Int such that
`toInteger y + toInteger y` is outside Int range. I strongly prefer
that that behavior _not_ b
| It'd be lovely if the Haskell report took a stand on the
| issue, but I suspect that may be too much to hope for.
Actually, it'd be an easy, non-destablising change to make
to the Report to specify the behaviour of the Int instance of
fromInteger on numbers larger than will fit in an Int.
I didn't phrase it right. I meant that a let/lambda/if always
extends to the next relevant (not part of a smaller expression)
punctuation symbol; and if that phrase parses as an exp
that's fine, otherwise it's a parse error. So I should not really
speak in terms of 'ambiguity'.
Perhaps we can
On Tue, Feb 26, 2002 at 07:30:44AM -0800, Simon Peyton-Jones wrote:
> Replace "The ambiguity is resolved by the meta rule that each of these
> constructs extends as far to the right as possible" by
>
> "The ambiguity is resolved by the meta rule that each
> of these constructs extend
| Consider the following Haskell 98 expressions:
|
| (let x = 10 in x `div`)
| (let x = 10 in x `div` 3)
|
| To parse the first, a bottom-up parser should reduce the
| let-expression before the operator, while to parse the second
| it should shift. But it needs 4 tokens of lookahea
I've recently run up against the following rather annoying
inconsistency between haskell implementations:
HUGS:
Nat> fromInteger 4294967264 :: Int
Program error: {primIntegerToInt 4294967264}
GHCI:
Nat> fromInteger 4294967264 :: Int
-32
I don't have nhc installed at the moment, so I can't tell
> On Mon, Feb 25, 2002 at 05:07:35PM -, Simon Marlow wrote:
> > On the other hand, one way to fix this problem *is* to specify the
> > relative precedence of 'let' & co. as compared to infix operators
> > (namely that 'let' should have a lower precedence). That would be a
> > reasonable fix
13 matches
Mail list logo
