- Glasgow-haskell-users

RE: ANNOUNCE: GHC version 5.04 released
by Simon Marlow 19 Jul '02

19 Jul '02

> > Can we expect ghc-5.04 SuSE rpms soon? > > Thanks. > > > > J.A. > > Sorry. I've simply forgotten to announce them. The following > RPMs were built under SuSE 8.0. These are now available from the GHC download page. Thanks Ralf! Cheers, Simon

1 0

CHAT AND SEXSCHOOL LIVE
by LECCORNIA 18 Jul '02

18 Jul '02

http://www.ragazze-sexy.tv nuova chat multitasking con multiriprese nuova area interna per lezioni di sesso live nuova sezione per allungamento del pene tutto manuale 100% naturale nuove chattiste mai viste in rete http://www.ragazze-sexy.tv La Tua email � stata rilasciata sui nostri portali se non vui pi� ricevere news scrivi a deletemail(a)libero.it

1 0

fno-implicit-prelude and literal numeric patterns
by Bernard James POPE 18 Jul '02

18 Jul '02

Hi again, I know I'm becoming a pest with this, but another question about -fno-implicit-prelude: What happens with literal numeric patterns? For this part of the prelude: gcd :: (Integral a) => a -> a -> a gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined" gcd x y = gcd' (abs x) (abs y) where gcd' x 0 = x gcd' x y = gcd' y (x `rem` y) I'm getting this error (which refers to the transformed version of the code of course but I don't think the transformation has anything to do with it). Prel_Buddha.hs:459: Could not deduce (GHC.Base.Eq a) from the context (Integral a) Probable fix: Add (GHC.Base.Eq a) to the type signature(s) for `gcd' arising from the pattern `0' at Prel_Buddha.hs:459 When checking the pattern: (0, 0) In a case alternative: (0, 0) -> error "Prelude.gcd: gcd 0 0 is undefined" I'm sure my version of class Integral, Real, Num, Eq is the same as the example Prelude from the Language Report. I'm still using 5.03, perhaps it has changed in 5.04? (My apology if it has - it turns out to be quite hard for me to test in 5.04 because my transformation doesn't uses the old convention with desugaring do notation ...) If I get rid of the literal numeric patterns the error disappears. Cheers, Bernie.

1 0

RE: package name mismatch
by Simon Marlow 18 Jul '02

18 Jul '02

> Simon Marlow wrote: > > > > > It must have been only a warning in 5.02.3, or I could never have > > > compiled it there. (Before 5.02.3 we didn't use the package > > > system like this at all.) > [snip] > > > > Can't you just fix your build so that the situation doesn't occur? > [snip] > In fact I have been unable to reproduce the problem with > ghc5.04 anyway. > My guess would be that GHC now searches the package > directories before the > current directory. So we're all happy, unless someone wants > to override a > module in an imported package. Even then a better solution > would be to > write another package containing the altered module, and put > it first in > the search path. > > Is the order in which GHC looks for imported modules > specified anywhere? No, but our position is that you shouldn't have more than one module with the same name, regardless of whether they are in separate packages or not, and that the import path for the home package should not overlap with the import path for any other package. The only exception is perhaps two packages that aren't intended to be used together. Cheers, Simon

1 0

Re: replacing the Prelude (again)
by Bernard James POPE 18 Jul '02

18 Jul '02

Dylan writes: > On Tue, Jul 16, 2002 at 04:02:44PM +1000, Bernard James POPE wrote: > > I would like to use do-notation in the transformed program, but have it > > refer to Prelude.Monad and not MyPrelude.Monad which is also in scope. > > Why do you have a MyPrelude.Monad (different from Prelude.Monad) if > you don't want to use it? Hi, This is part of a debugger for haskell. The approach taken is to transform the original program. Under transformation the types of functions change. If the user's program calls >>=, then in the debugged program that is a call to a transformed version of >>= (ie MyPrelude.Monad - don't worry it isn't really called "MyPrelude"). Btw all do notation from the original program is desugared during transformation. It just turns out that the transformed code is neater if I can use do notation in it. Which is quite helpful because it makes it easier to check that the transformation is doing the right thing! However, for this I have to use Prelude.Monad instead of MyPrelude.Monad, because the latter is transformed and all the types are changed. It really isn't a big deal. I can do without the do notation. I just have to change the transformation. If there were more fine grained control about how desugaring worked then that would help, but that would also add a lot of extra complexity to the compiler and I doubt the benefits would outweigh the costs. Cheers, Bernie.

1 0

Re: replacing the Prelude (again)
by Bernard James POPE 17 Jul '02

17 Jul '02

Malcolm writes: > Bernie writes: > > I did wonder how Hat tackled this. > > Out of curiosity what is the solution that Hat uses? > > Hat doesn't have a solution. When the lack of correct defaulting > causes Hat to generate type-incorrect code, the underlying compiler > will complain vociferously. Our advice to users is to write `default > ()' at the top of the module, then resolve the type errors they > get from the normal compilation so that defaulting is completely > eliminated. The code will then go through Hat smoothly. > > It isn't very satisfactory, but in practice, defaulting doesn't > really occur very often, so it isn't too much of a hardship. That was going to be my fallback strategy, I'm glad I'm not the only one! > > This adds an extra element of difficulty to the problem. I am trying > > my hardest to avoid needing the to import the original Prelude in > > a transformed module - this requires quite a bit of desugaring in the > > transformation. > > > > For what reasons do you require the original prelude? > > Exactly the same reasons. We want to do as little desugaring as > necessary in the transformation, so inevitably we need at least a > small part of the Prelude in scope. I would like to use do-notation in the transformed program, but have it refer to Prelude.Monad and not MyPrelude.Monad which is also in scope. The reason I mention this is that the behviour of -fno-implicit-prelude seems to have changed with respect to desugaring do notation, at least according to this post from Simon Peyton-Jones: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-July/003688.html In the upcoming 5.04 release you'll be able to do exactly that. GHC will use whatever >>= is in scope if you say -fno-implicit-prelude. Sure I can always get by without do notation, but the transformed program is then a lot uglier and harder to comprehend. Does hat work with ghc 5.04? Cheers, Bernie.

2 1

RE: package name mismatch
by Simon Marlow 17 Jul '02

17 Jul '02

> It must have been only a warning in 5.02.3, or I could never have > compiled it there. (Before 5.02.3 we didn't use the package > system like this at all.) > > Actually I would like this message to go away altogether in this case, > if possible. The actual situation is that GetPut.hs is in fact part > of the package "uni-events-test", and the compiler is told to load > uni-events-test on the command line. However GetPut.hs is *also* in > the current directory during this compilation, so GHC loads > it from there > instead. I'm not sure what logic would be best here, but my > suggestion > would be that where a .hi file is found in an import declaration and > has an unexpected package name, GHC keeps on searching. If it finds > a .hi file with a matching package name, it accepts it, otherwise > accept the .hi file with the wrong package name and issue a warning. > > If that's too complicated, just ignore .hi files with the > wrong package name. But then people might complain . . . I think this is all way too complicated. GHC's view of modules is fairly simple: they either reside in the home package or another package. If a module occurs in both, then previously it was an error, now it is just a warning. If we were using packages for dynamic libraries, one of the reasons we originally added packages, then it really *would* be an error and you'd be in trouble if you did this! Can't you just fix your build so that the situation doesn't occur? Cheers, Simon

2 2

RE: Document -optl-static
by Simon Marlow 17 Jul '02

17 Jul '02

> I think it would be a good idea to add -optl-static to the flags > described in > http://www.haskell.org/ghc/docs/latest/html/users_guide/option > s-phases.html#OPTIONS-LINKER > perhaps in the vincinity of -static & -dynamic. Although this > could be considered > redundant, it might save some time trying out how to build > entirely static > binaries. Opinions? I think the -static flag probably ought to be passed to the linker, so you wouldn't need -optl-static. Is there any reason you might need -static but not -optl-static? Cheers, Simon

2 1

RE: RTS interface followup...
by Simon Marlow 17 Jul '02

17 Jul '02

> rts_mkAddr is used by Linker.o in libHSrts.a (it looks like in the > resolveObjs call - I in turn am calling this... (this was > from doing an nm on the library)... Hmm, yes the Linker does refer to it, just in case the dynamically linked program requires it. I think you should probably arrange that the missing symbols get linked in from HSlang.o, something like: ghc -package lang -optl-u -optl Addr_Azh_con_info does that help? > with regards to the threading, I was wondering if the default file > buffering mode has changed, as text IO to the console seems slower > (you can see characters 'printing' left to right, rather than just > lines flying past)... No, the default buffering has not changed. Can you quantify the slowdown, or provide an example? Does it only happen when --enable-threaded-rts is on? Cheers, Simon

2 1

RE: RTS interface followup...
by Simon Marlow 17 Jul '02

17 Jul '02

> The code (which is what I am assuming is where the error is > comming from) is > lifted > from Linker.lhs, namely (lookupSymbol :: CString -> IO (Ptr > a)) this is used > in the > following: > > hobj <- lookupSymbol c_objsym > case hobj of > o | o == nullPtr -> return Nothing > Ptr o -> case (addrToHValue# o) of > (# h #) -> return (Just h) > > [I am not 100% certain this is where the error is comming > from - but its the only reference to an Addr I can find...] There isn't a reference to Addr in the above code, only the primitive type Addr# (which isn't deprecated). > this compiles fine, however in the final link (i'm doing a 2 > stage compile with -c to > generate all the .o files then a link - using ghc) the > following error is generated: > > .../ghc-5.04/libHSrts.a(RtsAPIDeprec.o): In function 'rts_mkAddr': > RtsAPIDeprec.o(.text+0x14): undefined reference to 'Addr_Azh_con_info' RtsAPIDeprec should only be linked in if something requires it - i.e. if one of the symbols rts_getAddr or rts_mkAddr is used elsewhere. Do you have any code which uses one of those functions? > ...same for rts_getAttr, with the addition of the symbol > Addr_Azh_static_info > which is also undefined... > > Hope this makes it a bit clearer. A second problem I > have just found - using > a threaded runtime, my code now hangs after getting a connection on a > socket, and forking > a haskell-thread to handle it. The reply is not sent until another > connection attempt > occurs... where does the behavior of the threaded runtime > differ from the non-threaded? I'm afraid I don't know about this one, I haven't done much testing of the threaded RTS myself (due to lack of time and trying to get 5.04 out of the door). Cheers, Simon

2 1