Algebraic datatype declaration without constructor

2000-07-18 Thread Tim Geisler
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

Re: green-card in fptools-4.08

2000-07-18 Thread trb
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

RE: What is `AClass'?

2000-07-18 Thread Simon Peyton-Jones
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'?

AW: Win 32 GUI for GHC

2000-07-18 Thread Wilkening, Detlef
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

RE: GHC Renamer

2000-07-18 Thread Simon Peyton-Jones
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!

RE: -funbox-strict-fields

2000-07-18 Thread Simon Marlow
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

Re: Win 32 GUI for GHC

2000-07-18 Thread Reuben Thomas
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

Re: Win 32 GUI for GHC

2000-07-18 Thread Manuel M. T. Chakravarty
"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,

Re: Win 32 GUI for GHC

2000-07-18 Thread Meurig Sage
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

Re: Precision problem

2000-07-18 Thread Keith Wansbrough
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.

Re: Precision problem

2000-07-18 Thread George Russell
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,

Re: Precision problem

2000-07-18 Thread George Russell
"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

Re: Precision problem

2000-07-18 Thread Sven Panne
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

Re: Precision problem

2000-07-18 Thread Fergus Henderson
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

Re: Precision problem

2000-07-18 Thread Fergus Henderson
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

Re: Precision problem

2000-07-18 Thread Carl R. Witty
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

Re: Precision problem

2000-07-18 Thread Julz
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