"S.D.Mechveliani" wrote:
Dear GHC,
I fear, there is some hard bug in ghc-4.06.
On the program
main = let p= 5 :: Integer
iI = eucIdeal "be" p [] [] [(p,1)]
r1 = Rse 1 iI dZ
dK = upGCDRing r1 eFM
--upRing
Nick Eby wrote:
In trying to compile the Random library from the hugs98 distribution
i got the following error:
Random.hs:205: parse error on input `::'
Line 205 reads:
primitive getRandomSeed :: IO Integer
I don't see a syntactic error in this line.
I do. :-)
Does ghc have a problem
Some letter! Some investigation. Thank you, Jeffrey.
GHC, please, could you fix things?
If only it is true ...
Indeed, the DoCon program uses overlapping and "undecidable"
instances quite freely. The constructor Rse below is supplied with
the two overlapping instances in this bug project. The
Michael Weber wrote:
On Wed, Feb 02, 2000 at 09:16:01 -0800, Simon Peyton-Jones wrote:
| From: George Russell [mailto:[EMAIL PROTECTED]]
| panic! (the `impossible' happened):
| cgEvalAlts: dodgy case of unboxed tuple type
[...]
I'm unable to reproduce this. It's a message
| If y'all agree that GHC should match hugs on this, it's only
| about a 4 line
| fix - I've tried it out already. On the other hand, I don't
| think that this
| will make Sergey a happy camper. Many instance declarations
| need to be
| tweaked. It's a tedious job, but straightforward.
On Fri, Feb 04, 2000 at 11:27:19 +0100, George Russell wrote:
[...]
However I didn't use -Onot. build.mk (minus comments and blank lines was):
^
HAPPY = /usr/local/pub-bkb/ghc/ghc-latest/bin/happy -a -g -c
GhcLibHcOpts += -H20m
HC_OPTS += -H30m -Onot
I've just tried to upgrade to the latest GHC binaries for NT (Cygwin) -
which appears to be ghc-4.05( no 4.06 yet?) The binaries install fine
and appear to compile simple Haskell programs (such as HelloWorld), but
when I try to run the resulting executable I get the message:
The procedure
Simon Peyton-Jones wrote:
| If y'all agree that GHC should match hugs on this, it's only
| about a 4 line
| fix - I've tried it out already. On the other hand, I don't
| think that this
| will make Sergey a happy camper. Many instance declarations
| need to be
| tweaked. It's a tedious
Sven writes:
Does ghc have a problem with the 'primitive' declaration? [...]
Exactly. In GHC (and probably already in NHC, too. Malcolm?) you
have to write
foreign import unsafe getRandomSeed :: IO Int
Yes, since 1999-11-19, nhc98 also supports the new FFI.
Regards,
Malcolm
No, there isn't any ./CVS/ directory entry in the current directory
I am using. Maybe the problem is the absence of a fptools/CVS/ and/or
fptools/CONTRIB/CVS directory in the FP Tools cvs server.
When I checkout the complete fptools there is no problem.
I've seen this one before, but can't
Folks,
The adventurous among you may like to try an innovation
which in some cases nearly doubles the speed at which
ghc compiles programs. This innovation is our native code
generator, which has long been in the GHC source tree,
but has only just been made to work for x86. It reduces
Two things.
We have seen many times (last was Matt Harden) such definitions :
class RandomGen g where
next :: g - (Int, g)
split :: g - (g, g)
genRange :: g - (Int, Int)
genRange _ = (minBound, maxBound)
Do you always use integer random numbers?
I don't know about you,
Jerzy Karczmarczuk ([EMAIL PROTECTED]) wrote:
[...]
: the Haskell standard libraries offer only the basic integer RNG,
: which will force all the users to reconstruct the needed reals,
: this is not extremely painful, but anyway.
: I would love having 'next' returning reals as well...
: And
Jerzy Karczmarczuk writes:
[...]
I would love having 'next' returning reals as well...
And vectors (with decently uncorrelated elements). Etc.
Do you think that all that must be manufactured by the user, or
can one parameterize the R. Gen. class a bit differently?
Try making each of
Jerzy Karczmarczuk wrote:
class RandomGen g where
next :: g - (Int, g)
split :: g - (g, g)
genRange :: g - (Int, Int)
genRange _ = (minBound, maxBound)
Do you always use integer random numbers?
No. But this is the primitive class we're discussing here. The library
More on randoms.
Haskell uses the names `next', `split' for Random.
Maybe, it is better to add some prefix or suffix?
For there are so many basic operations in the universe that can be
naturally called `next' and `split'. And Random does not look so
priveleged to enjoy privately such a simple
S.D.Mechveliani wrote:
| Haskell uses the names `next', `split' for Random.
| Maybe, it is better to add some prefix or suffix?
No!
Haskell has a perfectly fine module system which can take
care of these kind of issues. If you have other definitions
of "split" or "next", use "Random.split"
I wrote recently on the need of prefix or suffix for `next',`split'
of Random.
Somebody corrected me, saying that Random.next
is, at least, possible.
It is all right. But I would like to add something.
If goodOp is an operation of *class* C, then C.goodOp
- when needed, - looks like
On 04-Feb-2000, S.D.Mechveliani [EMAIL PROTECTED] wrote:
If goodOp is an operation of *class* C, then C.goodOp
- when needed, - looks like a good disambiguation forgoodOp
(is it of Haskell ?).
No, Haskell doesn't allow that.
Nor does Mercury allow the equivalent, though this
Matt Harden wrote:
... Darn. Now I want the genRange operation again. The
"clarification" can really be a significant performance cost. Not to
mention, you're also shortening the period of the RNG (perhaps by a
factor of 4!).
Can we have both (see below)?
class RandomGen g where
20 matches
Mail list logo
