ghc-4.08 (the current version in
http://www.haskell.org/ghc/dist/4.08/ghc-4.08-i386-unknown-linux.tar.gz)
compiles the following program without error:
module Main(main) where
main = main
data Foo = baz
According to the Haskell 98 report, this is not legal Haskell. Are
there are any Glasgow
Reuben Thomas writes:
What version of ghc are you using to build GreenCard?
trb@elysium:/usr/local/src/fptools-build-4.08/green-card ghc --version
The Glorious Glasgow Haskell Compilation System, version 4.08
(from the fptools-4.08 I mentioned building from the CVS sources)
It works fine
OK, this is now fixed on the 4.08 branch. In a while we'll ship binaries
for 4.08pl1.
Simon
| -Original Message-
| From: Martin Pokorny [mailto:[EMAIL PROTECTED]]
| Sent: 18 July 2000 04:13
| To: Simon Peyton-Jones
| Cc: Michael Weber; [EMAIL PROTECTED]
| Subject: Re: What is `AClass'?
Is there currently any way of using Win32 GUI with GHC ?
...
What I really meant was UI controls, like buttons, options
box, check box, etc...
I'm looking for a library for using Win32 GUI too, because I want to write a
'normal' Windows GUI Programm in Haskell.
Ciao
Detlef
Kate
The idea is that the Renamer sucks in any declarations from
interface files that might be needed to compile the module.
It may suck in more than turn out to be necessary, but it must
not suck in fewer.
The version of GHC you have is sucking in a lot more than it
needs for a blank module!
Why it's not the default (or the only case)?
I don't have a test case to make experiments, but intuitively unboxing
strict fields should be an obvious advantage in most cases. A record
of Bools or Ints - why allocate each separately? I guess they are more
often examined directly than
What I really meant was UI controls, like buttons, options box, check box,
etc...
How about the win32 library, which comes as standard with GHC?
--
http://sc3d.org/rrt/ | plagiarism, n. the mind burgles
"Anibal Maffioletti Rodrigues de DEUS" [EMAIL PROTECTED] wrote,
What I really meant was UI controls, like buttons, options box, check box,
etc...
The Gtk+HS binding should - in theory - work on Win32, as
there is a Win port of GTK+. It provides exactly what you
want, buttons, windows,
Hi
Have you looked at TclHaskell or FranTk. Both are built on top of Tcl/Tk,
and therefore run unchanged on Unix and Windows, with native look and feel.
TclHaskell is a basic interface to Tcl/Tk, similar in style to TkGofer
(though a little simplified). FranTk is a library built on top of
IMHO GHC's documentation should clearly warn that programmers should
not depend on even basic stability and exactness of floating point
computations, and only stability is provided by -fstrictfp.
GHC is no different from any other compiler for any other language in
this respect.
Keith Wansbrough wrote:
GHC is no different from any other compiler for any other language in
this respect. Floating-point values are *not* the mathematical `real
numbers', and should not be treated as such. This is second-year CS
course material.
No, but they ARE, assuming IEEE arithmetic,
"Wilhelm B. Kloke" wrote:
IMHO you are not right in this. See W. Kahan on the ridiculous Java
restriction in FP reproducibility.
We are getting into deep waters here but I think I _am_ right in this case.
Kahan's point (I presume you are referring to his excellent (online)
paper "How JAVA's
Hmmm, I've never thought that two simple additions would lead to such
a riot... :-)
First of all: Even after re-reading the report I can't see that IEEE
arithmetic is *required* by it. The representation of floating point
values is explicitly stated as "implementation-defined", only the range
On 18-Jul-2000, Keith Wansbrough [EMAIL PROTECTED] wrote:
IMHO GHC's documentation should clearly warn that programmers should
not depend on even basic stability and exactness of floating point
computations, and only stability is provided by -fstrictfp.
GHC is no different from any other
On 18-Jul-2000, Sven Panne [EMAIL PROTECTED] wrote:
Nevertheless, there seems to be some consensus that optimization should
not change the outcome of a computation. Note that GCC's -O flag *does*
change it, at least if -ffloat-store is not given in addition. The newly
introduced GHC option
Fergus Henderson [EMAIL PROTECTED] writes:
Yes, but for any given Haskell program execution, the sum of any two
floating-point values should be the same every time you compute it.
In general it need not be the same as the sum of the equivalent real
numbers, because floating point numbers are
Keith Wansbrough wrote:
GHC is no different from any other compiler for any other language in
this respect. Floating-point values are *not* the mathematical `real
numbers', and should not be treated as such. This is second-year CS
course material.
snip One should not have to add
17 matches
Mail list logo