I think it's a bug when a compiler doesn't
understand an intermediate file it generated a
few minutes before. According to GHC:
Window.hi:114:
The constraint `GUIState.GUIObject Window' does not mention any of
the universally quantified type variables {v}
In the interface
Hi,
What's the latest on this problem? Since I've hit it too :-( Is it
possible to build ghc with egcs and glibc2.1 ?? I'm trying to build
from source using the pre-built ghc-4.02 linux binaries.
regards
Kevin
Giuliano P Procida [EMAIL PROTECTED] writes:
No improvement, I'm
Hi.
On Wed, May 26, 1999 at 04:29:01AM +1000, Kevin Glynn wrote:
What's the latest on this problem? Since I've hit it too :-( Is it
possible to build ghc with egcs and glibc2.1 ?? I'm trying to build
from source using the pre-built ghc-4.02 linux binaries.
The latest is that it is still a
This is a multi-part message in MIME format.
--9FB4D0D35F15A05DBD8B1B67
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Here is a slightly corrected version of my proposal. It has a few
grammar fixes and since I am sending it as an attachment it shouldn't
But what type does the selector 'item' have? Phil, Mark and Jeff think:
item :: Ord a = Tree a - a
This looks correct to me, too.
If an order is needed to construct a tree, say a search tree, the very same
order is (or may be) needed to select an item, e.g. by
Christian Maeder wrote:
| An abstract data type should not reveal its realization.
Indeed! And therefore, an abstract datatype should not impose silly
restrictions on the context where they are not needed. How I implement a
set (for example using ordered binary trees or a hash table), is part
I think the whole idea of making strings lists of characters is barmy, and
one of the few things which are a big disadvantage of Haskell over ML.
The consequence is that one must take a huge performance hit on any portable
code that deals with text a lot (as most code does), for the very dubious
