Re: prelude functions not in scope

2000-03-08 Thread Hannah Schroeter

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

2000-03-08 Thread Simon Marlow

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

2000-03-08 Thread George Russell

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

2000-03-08 Thread George Russell

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

2000-03-08 Thread Sven Panne

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