January 2005 - Glasgow-haskell-users

RE: self-import
by Simon Peyton-Jones 18 Jan '05

18 Jan '05

| And if it turns out we are in the mood to look at extending the | inport/export/module syntax perhaps we could also consider the qualified | export idea posted a few weeks ago. | | That was so that you could say: | | import Graphics.UI.Gtk | | and then use Button.setText (rather than buttonSetText) as $DEITY | intended. Down with the moduleNamePrefix! :-) How would the programmer express that intent? In the export from module X.Y.Button? Simon

2 1

package installation
by Sean Bowman 17 Jan '05

17 Jan '05

hello, I'm trying to install HUnit to use with ghci and hugs and having some trouble. It works if I use the -i option with ghci, but I'd rather not have to specify that on the command line every time. Putting it in a ~/.ghci file doesn't seem to work. How can I set the search path for 3rd party Haskell modules? Thanks very much, Sean

1 0

recursive group context bug?
by Ashley Yakeley 17 Jan '05

17 Jan '05

I suspect someone's come across this before, so maybe there's an explanation for it. This does not compile: module Bug where { p :: IO (); p = q >>= id; q :: (Monad m) => m (IO ()); q = return p; } Bug.hs:3: Mismatched contexts When matching the contexts of the signatures for p :: IO () q :: forall m. (Monad m) => m (IO ()) The signature contexts in a mutually recursive group should all be identical When generalising the type(s) for p, q The code looks correct to me. Why must the signature contexts be identical in this case? -- Ashley Yakeley, Seattle WA

4 6

RE: How expensive are MVars ?
by Simon Marlow 17 Jan '05

17 Jan '05

On 13 January 2005 23:36, Nick Main wrote: > I'm planning to implement a small OO language on top of GHC (think > JavaScript) and need to decide on how to implement the mutable object > graph that is required. > > The two approaches I'm considering are: > - something on top of Data.Graph > - using MVars as the object references. > > The MVar approach is the most appealing, since it would also allow the > OO language to contain threads. How expensive is an MVar access (in > GHC), compared to the graph navigation that would be required to > resolve a reference using Data.Graph ? > > I know this is a fairly nebulous question, but any comments or > suggestions are appreciated. So here's a nebulous answer: I don't know, measure it :-) Each MVar operation involves a function call right now, so you might class it as "expensive". Personally for your application, I think I'd use a mutable array to represent the heap. That amounts to almost the same as using Data.Graph, but I imagine you'll need the mutability for speed. Perhaps providing a mutable Graph data structure implemented using an array would be a nice abstraction. Cheers, Simon

1 0

RE: Unicode in GHC: need more advice
by Simon Marlow 17 Jan '05

17 Jan '05

On 14 January 2005 12:58, Dimitry Golubovsky wrote: > Now I need more advice on which "flavor" of Unicode support to > implement. In Haskell-cafe, there were 3 flavors summarized: I am > reposting the table here (its latest version). > > |Sebastien's| Marcin's | Hugs > -------+-----------+----------+------ > alnum | L* N* | L* N* | L*, M*, N* <1> > alpha | L* | L* | L* <1> > cntrl | Cc | Cc Zl Zp | Cc > digit | N* | Nd | '0'..'9' > lower | Ll | Ll | Ll <1> > punct | P* | P* | P* > upper | Lu | Lt Lu | Lu Lt <1> > blank | Z* \t\n\r | Z*(except| ' ' \t\n\r\f\v U+00A0 > U+00A0 > U+2007 > U+202F) > \t\n\v\f\r U+0085 > > <1>: for characters outside Latin1 range. For Latin1 characters > (0 to 255), there is a lookup table defined as > "unsigned char charTable[NUM_LAT1_CHARS];" > > I did not post the contents of the table Hugs uses for the Latin1 > part. However, with that table completely removed, Hugs did not work > properly. So its contents somehow differs from what Unicode defines > for that character range. If needed, I may decode that table and post > its mapping of character categories (keeping in mind that those are > Haskell-recognized character categories, not Unicode) I don't know enough to comment on which of the above flavours is best. However, I'd prefer not to use a separate table for Latin-1 characters if possible. We should probably stick to the Report definitions for isDigit and isSpace, but we could add a separate isUniDigit/isUniSpace for the full Unicode classes. > One more question that I had when experimenting with Hugs: if a > character (like those extra blank chars) is forced into some category > for the purposes of Haskell language compilation (per the Report), > does this mean that any other Haskell application should recognize > Haskell-defined category of that character rather than > Unicode-defined? > > For Hugs, there were no choice but say Yes, because both compiler and > interpreter used the same code to decide on character category. In GHC > this may be different. To be specific: the Report requires that the Haskell lexical class of space characters includes Unicode spaces, but that the implementation of isSpace only recognises Latin-1 spaces. That means we need two separate classes of space characters (or just use the report definition of isSpace). GHC's parser doesn't currently use the Data.Char character class predicates, but at some point we will want to parse Unicode so we'll need appropriate class predicates then. > Since Hugs got there first, does it make sense just follow what was > done here, or will a different decision be adopted for GHC: say, for > the Parser, extra characters are forced to be blank, but for the rest > of the programs compiled by GHC, Unicode definitions are adhered to. Does what I said above help answer this question? Cheers, Simon

1 0

RE: More HaXml trouble
by Simon Marlow 14 Jan '05

14 Jan '05

On 14 January 2005 13:35, Peter Simons wrote: > after rebuilding ghc-current, I got an intact Cabal version > and managed to install HaXml successfully. However, when I > try to link a program that actually uses the package, the > linker stage fails with these errors: > > /usr/local/ghc-current/lib/HaXml-1.12.1/libHSHaXml-1.12.1.a(Combinators. o)(.text+0x3aa9): > In function `__stginit_TextziXMLziHaXmlziCombinators_': : undefined > reference to `__stginit_Maybe_' > /usr/local/ghc-current/lib/HaXml-1.12.1/libHSHaXml-1.12.1.a(Escape.o)(.t ext+0x22b9): > In function `__stginit_TextziXMLziHaXmlziEscape_': : undefined > reference to `__stginit_Char_' > /usr/local/ghc-current/lib/HaXml-1.12.1/libHSHaXml-1.12.1.a(Generate.o)( .text+0x37f1): > In function `__stginit_TextziXMLziHaXmlziHtmlziGenerate_': : > undefined reference to `__stginit_Char_' [...] collect2: ld returned > 1 exit status *** Deleting temp files Deleting: > > I've tried adding "-package base" to the command line, but > that didn't help. Any other idea? Looks like the HaXml package spec is missing a dependency on haskell98. Cheers, Simon

2 1

More HaXml trouble
by Peter Simons 14 Jan '05

14 Jan '05

Hi, after rebuilding ghc-current, I got an intact Cabal version and managed to install HaXml successfully. However, when I try to link a program that actually uses the package, the linker stage fails with these errors: /usr/local/ghc-current/lib/HaXml-1.12.1/libHSHaXml-1.12.1.a(Combinators.o)(.text+0x3aa9): In function `__stginit_TextziXMLziHaXmlziCombinators_': : undefined reference to `__stginit_Maybe_' /usr/local/ghc-current/lib/HaXml-1.12.1/libHSHaXml-1.12.1.a(Escape.o)(.text+0x22b9): In function `__stginit_TextziXMLziHaXmlziEscape_': : undefined reference to `__stginit_Char_' /usr/local/ghc-current/lib/HaXml-1.12.1/libHSHaXml-1.12.1.a(Generate.o)(.text+0x37f1): In function `__stginit_TextziXMLziHaXmlziHtmlziGenerate_': : undefined reference to `__stginit_Char_' [...] collect2: ld returned 1 exit status *** Deleting temp files Deleting: I've tried adding "-package base" to the command line, but that didn't help. Any other idea? Peter

1 0

RE: Unicode in GHC: need some advice on building
by Simon Marlow 14 Jan '05

14 Jan '05

On 11 January 2005 02:29, Dimitry Golubovsky wrote: > Bad thing is, LD_PRELOAD does not work on all systems. So I tried to > put the code directly into the runtime (where I believe it should be; > the Unicode properties table is packed, and won't eat much space). I > renamed foreign function names in GHC.Unicode (to avoid conflict with > libc functions) adding u_ to them (so now they are u_iswupper, etc). > I placed the new file into ghc/rts, and the include file into > ghc/includes. I could not avoid messages about missing prototypes for > u_... functions , but finally I was able to build ghc. Now when I > compiled my test program with the rebuilt ghc, it worked without the > LD_PRELOADed library. However, GHCi could not start complaining that > it could not see these u_... symbols. I noticed some other entry > points into the runtime like revertCAFs, or getAllocations, declared > in the Haskell part of GHCi just as other foreign calls, so I just > followed the same style - partly unsuccessfully. > > Where am I wrong? You're doing fine - but a better place for the tables is as part of the base package, rather than the RTS. We already have some C files in the base package: see libraries/base/cbits, for example. I suggest just putting your code in there. Cheers, Simon

2 1

How expensive are MVars ?
by Nick Main 13 Jan '05

13 Jan '05

I'm planning to implement a small OO language on top of GHC (think JavaScript) and need to decide on how to implement the mutable object graph that is required. The two approaches I'm considering are: - something on top of Data.Graph - using MVars as the object references. The MVar approach is the most appealing, since it would also allow the OO language to contain threads. How expensive is an MVar access (in GHC), compared to the graph navigation that would be required to resolve a reference using Data.Graph ? I know this is a fairly nebulous question, but any comments or suggestions are appreciated. --Nick Main

1 0

Unboxed Tuples
by Adrian Hey 13 Jan '05

13 Jan '05

Hello, Does the user guide documentation for these reflect current ghc compiler? Para. 7.2.2 says they can only be deconstructed using case expressions but by accident I've found they seem to work fine in let bindings too (with ghc version 6.2.2). Not that I'm complaining (I always thought using case expressions was just too painful :-). I just wanted to check that this is a feature I can rely on in future (and if so suggest the user guide should be ammended to reflect this). Regards -- Adrian Hey

1 0