A build of GHC downloaded from the anoncvs repository last
night and running on Sparc-Solaris
produced the following messages. I attach a copy of PrelNumExtra.hi.
This one was fixed a couple of days ago. Maybe something is out of date?
Cheers,
Simon
29 Jul 1999 16:58:53 GMT, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] pisze:
Is it possible to set up classes that express the following (using
ghc extensions)?
[...]
I hoped that the following would work (with -fglasgow-exts
-fallow-overlapping-instances -fallow-undecidable-instances)
but it
Happens also with the solaris binary:
ld: fatal: library -lgmp: not found
ld: fatal: File processing errors. No output written to ...
"S" == S D Mechveliani [EMAIL PROTECTED] writes:
S I have a question for the GHC developers: where it is explained
S the path setting for the gmp
Happens also with the solaris binary:
ld: fatal: library -lgmp: not found
ld: fatal: File processing errors. No output written to ...
Ok, looks like I need to remake these distributions with gmp libraries
included.
Simon
On Thu, 29 Jul 1999, Simon Marlow wrote:
The Glasgow Haskell Compiler -- version 4.04
==
[Snip]
- Rewrite rules can be specified in the source using the RULES
pragma. This is used for automatic fusion of common list
The ghc binary distribution was easy to install, thank you.
I did the full install, with "make install". If you try to
do a "make in-place", you get:
make: Fatal error in reader: = missing from replacement macro reference
I tried to follow the links from
Simon Peyton-Jones [EMAIL PROTECTED] writes:
In other words, it is a bug (and GHC and Hugs don't do it
right - see my previous message; from your comment, I
presume HBC also doesn't follow the definition). I think,
the only Right Thing is to remove this awful rule (unless
In other words, it is a bug (and GHC and Hugs don't do it
right - see my previous message; from your comment, I
presume HBC also doesn't follow the definition). I think,
the only Right Thing is to remove this awful rule (unless
somebody comes up with a rule that can be decided locally).
| How about the Carl Witty's
|
| do a == b == c
|
| does NHC handle this correctly?
It matches ghc and Hugs, reporting
Error when renaming:
Infix operator at 2:21 is non-associative.
Note that this is reported one stage *after* parsing. Because parsing
of infix operators is
Malcolm Wallace wrote:
Because parsing
of infix operators is difficult, all implementations (to my knowledge)
leave resolution of fixity and associativity until later. Indeed, the
Haskell 98 standard recognises this (in an oblique way) by permitting
infix decls to appear *after* the first
Does anybody disagree with my interpretation of the standard? Are
there any implementations that actually follow the standard here?
(Maybe the standard should be changed to follow the implementations in
this area.)
Phew. Well spotted. Of course, none of the existing Haskell
Now that you're an (ahem) Microsoft employee, is there any
intention of
allowing ghc to use Visual C++ instead of gcc,
We plan to allow this, but there'll be a price to pay: the gcc extensions
that we use buy us about a factor of 2 in performance and binary sizes.
or supporting the Win32
Fri, 30 Jul 1999 05:12:51 -0700, Simon Marlow [EMAIL PROTECTED] pisze:
The main reason for its inclusion was to allow things like
let f x = x in ...
and also to automatically insert the final '}' before the end of file.
Perhaps the layout rule should be restricted to these two
Malcolm Wallace [EMAIL PROTECTED] wrote,
[...]
Simon Marlow replies:
GHC and Hugs both make use of yacc-style error recovery, albeit in a very
limited form.
And nhc uses parser combinators, which give you backtracking on error
conditions for free. We actually do almost all layout
14 matches
Mail list logo
