Re: GHC doesn't understand a .hi file
Line 114 of Window.hi says:
1 zdfHasTextWindow :: __forall [v] {GUIValue.GUIValue v, GUIState.GUIObject
Window} = {GUIBaseClasses.HasText Window v} ;
ghc --version says
The Glorious Glasgow Haskell Compilation System, version 4.03, patchlevel 0
I downloaded it around 18th May from the CVS repository and compiled it
for sparc-solaris.
On the 11th May the .hi format changed from what you have above,
slightly; this shouldn't cause the problem you mention but it does mean
that your ghc is older than you think. It should look like this:
1 zdfHasTextWindow :: __forall [v] = {GUIValue.GUIValue v} - {GUIState.GUIObject
Window} - {GUIBaseClasses.HasText Window v} ;
HTH.
--KW 8-)
--
: Keith Wansbrough, MSc, BSc(Hons) (Auckland) :
: PhD Student, Computer Laboratory, University of Cambridge, England. :
: (and recently of the University of Glasgow, Scotland. [] ) :
: Native of Antipodean Auckland, New Zealand: 174d47' E, 36d55' S.:
: http://www.cl.cam.ac.uk/users/kw217/ mailto:[EMAIL PROTECTED] :
:-:
RE: GHC doesn't understand a .hi file
I think it's a bug when a compiler doesn't
understand an intermediate file it generated a
few minutes before. According to GHC:
It's a bug all right. I've just fixed it. In principle there
is absolutely nothing wrong with types like
zdfHasTextWindow :: __forall [v]
{GUIValue.GUIValue v, GUIState.GUIObject
Window} =
{GUIBaseClasses.HasText Window v}
but at the moment GHC doesn't let you write them. This one
arose because (I think) you had something like
class GUIObject w = HasText w v where ...
instance GUIValue v = HasText Window v where ...
The dictionary function arising from the instance decl takes
no only the GUIValue v dictionary, but also the superclasses
of HasText, in this case (GUIObject Window); but since the latter
is constant there's no point in passing it.
If you update your compiler later today you should get the
new code (it's in mkDictFunId in MkId.lhs).
Thanks for reporting it.
Simon
Re: ghc 4.02 compilation failure (linux i386 glibc)
On Tue, May 25, 1999 at 02:08:19PM +0100, I wrote: However, it may have been a miscompiled glibc (this is the libc6-2.1.1-7 Debian build), more news tomorrow when I find the relevant mail messages. It still does not work with the 2.1.1-9 build, so it may have been something introduced since libHS was built, or it may be a compiler problem. I will try to hack hsc with a binary editor to remove the fflush call and see what happens. Giuliano.
Re: ghc 4.02 compilation failure (linux i386 glibc)
On Wed, May 26, 1999 at 11:18:34AM +0100, Giuliano P Procida wrote: I will try to hack hsc with a binary editor to remove the fflush call and see what happens. OK, one hacked hsc and a couple more hours of compilation later and I've run into another problem (compiling ghc/lib/posix/PosixTTY.lhs). The last few lines of the build log are: /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/cc1 /tmp/ccWi8YKZ.i -quiet -dumpbase ghc5854.c -O -Wimplicit -version -fomit-frame-pointer -fno-defer-pop -o ghc5854.s GNU C version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release) (i486-linux) compiled by GNU C version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release). Epilogue junk?: popl %ecx .Lfe337: .sizec91T_ret,.Lfe337-c91T_ret .section.rodata .align 4 .typec91S_info,@object .sizec91S_info,12 make[3]: *** [PosixTTY.o] Error 2 Further details on request. Giuliano. -- [EMAIL PROTECTED]
Re: Contexts on data type declarations
On 25-May-1999, Koen Claessen [EMAIL PROTECTED] wrote: 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 of the concrete representation of the datatype. Certainly we should never impose _silly_ restrictions where they are not needed. But not all restrictions are silly. Some restrictions constitute an important part of the interface. Saying that a particular abstract data type requires an ordering relation on its elements may well be an important part of the interface. And doing so does not reveal the implementation. The implementation could be a list, a red-black tree, a 23-tree, a 234-tree, an AVL tree, or some other kind of data structure. Stating the requirement for an ordering is just specifying the interface requirements for that type, not disclosing the implementation. Of course, the presence or absense of particular interface requirements will certainly constrain the kinds of implementations that are possible, but that should come as no surprise. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Kind Question
I have a question for the Haskell experts on the list. (Especially Haskell compiler writers). Is it possible to have a kind more complicated than: kind = kind' | kind' - kind kind' = * | ( kind'' ) kind'' = * | * - kind'' If so could you give me an example of a type which has a more complicated kind as I sure can't find one. Thanks in advance. I look forward to a yes or no. -- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
Please don't post
Kevin Atkinson wrote on Wed, 26 May 1999 03:05:17 -0400: I have a question for the Haskell experts on the list. (Especially Haskell compiler writers). Is it possible to have a kind more complicated than: kind = kind' | kind' - kind' I made a mistake here. Please don't post this one. Post the one sent 6 minutes latter (on Wed, 26 May 1999 03:11:31 -0400). The latter one has the above line fixed to read: kind = kind' | kind' - kind kind' = * | ( kind'' ) kind'' = * | * - kind'' If so could you give me an example of a type which has a more complicated kind as I sure can't find one. Thanks in advance. I look forward to a yes or no. -- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/ -- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
Re: Kind Question
Lennart Augustsson wrote: Kevin Atkinson wrote: I have a question for the Haskell experts on the list. (Especially Haskell compiler writers). Is it possible to have a kind more complicated than: kind = kind' | kind' - kind kind' = * | ( kind'' ) kind'' = * | * - kind'' Yes, kinds are generated by the grammar kind ::= * | kind - kind | (kind) If so could you give me an example of a type which has a more complicated kind as I sure can't find one. Your grammar does not seem to cover ((*-*) - *) - * which you could get (as the kind of D) e.g. from data D c = C (c []) Thanks. Now how would I use a type considering its constructor has a signature of: C :: a [] - D a -- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
Re: Kind Question
Kevin Atkinson wrote: Lennart Augustsson wrote: Your grammar does not seem to cover ((*-*) - *) - * which you could get (as the kind of D) e.g. from data D c = C (c []) Now how would I use a type considering its constructor has a signature of: C :: a [] - D a I answered my own question. data D c = C (c []) data E c = F (c Int) a = C (F [10]) But what can such a type be used for? -- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
Re: Proposal: Substring library for Haskell
George Russell wrote: | 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 benefit of having unevaluated | thunks in the middle of strings. I am not so sure this benefit is dubious! I deal a lot with big files (to generate huge inputs to several circuit-processing tools). I find it unmissable that the Strings I deal with are lazy streams of characters. If you have "strict" Strings, you will have to deal with these issues yourself, that is, explicitly generating the string line-by-line or block-by-block or so to avoid space issues. Not to mention lazily reading a file... I think there are a lot of cases in which you would want to use char-vectors for Strings, but do not underestimate the benefit of having lazy streams of characters. Koen. -- Koen Claessen, [EMAIL PROTECTED], http://www.cs.chalmers.se/~koen, Chalmers University of Technology.
Kind Question
I have a question for the Haskell experts on the list. (Especially Haskell compiler writers). Is it possible to have a kind more complicated than: kind = kind' | kind' - kind' kind' = * | ( kind'' ) kind'' = * | * - kind'' If so could you give me an example of a type which has a more complicated kind as I sure can't find one. Thanks in advance. I look forward to a yes or no. -- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
Re: Kind Question
Kevin Atkinson wrote: Kevin Atkinson wrote: Lennart Augustsson wrote: Your grammar does not seem to cover ((*-*) - *) - * which you could get (as the kind of D) e.g. from data D c = C (c []) Now how would I use a type considering its constructor has a signature of: C :: a [] - D a I answered my own question. data D c = C (c []) data E c = F (c Int) a = C (F [10]) But what can such a type be used for? This particular example is not very useful, but there are examples where higher kinds are used. Chris Okasaki have some for representing square matrices. -- -- Lennart
Re: Kind Question
Now how would I use a type considering its constructor has a signature of: C :: a [] - D a data L1 f = C1 (f Int) x :: D L1 x = C (C1 []) -- Lennart
Re: Kind Question
Lennart Augustsson wrote: But what can such a type be used for? This particular example is not very useful, but there are examples where higher kinds are used. Chris Okasaki have some for representing square matrices. Here's a simpler example. Consider the type of non-empty, multiway trees (often called "rose trees"). data Tree a = Node a [Tree a] Now, let's generalize this to replace the list type constructor with a type constructor for some arbitrary kind of collection. data GTree coll a = Node a (coll (GTree coll a)) This type is useful for extending certain properties of the underlying collection type. For example, if H is a type constructor for priority queues that supports insert in O(1) time, then Maybe (GTree H a) gives priority queues that support both insert and merge in O(1) time. Similarly, if Q is a type constructor for FIFO queues that support "snoc" in O(1) time, then Maybe (GTree Q a) gives FIFO queues that support cons, snoc, and append in O(1) time. These are both described in Section 10.2 of my book... Chris
Re: Kind Question
Kevin Atkinson wrote: I have a question for the Haskell experts on the list. (Especially Haskell compiler writers). Is it possible to have a kind more complicated than: kind = kind' | kind' - kind kind' = * | ( kind'' ) kind'' = * | * - kind'' Yes, kinds are generated by the grammar kind ::= * | kind - kind | (kind) If so could you give me an example of a type which has a more complicated kind as I sure can't find one. Your grammar does not seem to cover ((*-*) - *) - * which you could get (as the kind of D) e.g. from data D c = C (c []) -- -- Lennart
