Re: prelude functions not in scope
Hello! On Tue, Mar 07, 2000 at 11:29:33PM -0800, Nick Eby wrote: Why is ghc not recognizing prelude functions, specifically isLower, toLower, and isUpper? When compiling, i get the message Variable not in scope: 'isLower' Look at the Haskell report. There's no isLower/toLower/isUpper in the prelude. Rather they are in the Char standard library module. thanks Regards, Hannah.
Recent Sparc breakage
Sparc users in particular: I've identified some recent breakage in the Sparc port of GHC. If you've been experiencing crashes in binaries generated by a compiler built from recent (at least February) sources, then I've checked in a fix which might help. George, Marc: this probably fixes to the bugs you've both reported. The anon cvs repository should be updated around 1700 GMT today with the fix included (look for an update to fptools/ghc/rts/StgCRun.c). Cheers, Simon
Re: Recent Sparc breakage
Simon Marlow wrote: Sparc users in particular: I've identified some recent breakage in the Sparc port of GHC. If you've been experiencing crashes in binaries generated by a compiler built from recent (at least February) sources, then I've checked in a fix which might help. George, Marc: this probably fixes to the bugs you've both reported. The anon cvs repository should be updated around 1700 GMT today with the fix included (look for an update to fptools/ghc/rts/StgCRun.c). Cheers, Simon
Re: Recent Sparc breakage
Simon Marlow wrote: Sparc users in particular: I've identified some recent breakage in the Sparc port of GHC. If you've been experiencing crashes in binaries generated by a compiler built from recent (at least February) sources, then I've checked in a fix which might help. George, Marc: this probably fixes to the bugs you've both reported. The anon cvs repository should be updated around 1700 GMT today with the fix included (look for an update to fptools/ghc/rts/StgCRun.c). Hurrah. Many thanks to Simon Marlow for tracking down a particularly tiresome bug . . . Assuming he has, that is; if not I'll be complaining this time tomorrow . . .
Re: Qualified names in foreign export
Marcin 'Qrczak' Kowalczyk wrote: Shouldn't foreign exported names be allowed to be qualified? IMHO not: module Foo where Foo.f = "This is not allowed, either." I've just accidentally reused a Prelude name for a function to be foreign exported and could not resolve the conflict with the first way that came to mind: qualifying. You can use `hiding' + qualifying instead: module Foo where import Prelude hiding(elem) foreign export elem :: Int - IO () elem = print isVowel :: Char - Bool isVowel = (`Prelude.elem` "aeiouAEIOU") BTW, with -Wall ghc gives a false alarm: Foo.hs:1: Warning: definition but no type signature for `elem' BTW. The fact that functions containing the letter z in their names will get zz in C names, unless explicitly specified differently, should be either changed or documented. There is discrepancy between the names allowed for _ccall_{,GC_} and the foreign family. In the former case varids *and* conids are allowed, in the latter only varids. My suggestion: Allow both kinds of names for foreign, too, and do no mangling at all. This change and the comment should make their way into the FFI doc. Comments/opinions? Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne