- Haskell - Haskell.org

IO Errors
by Steinitz, Dominic J 25 May '01

25 May '01

Can anyone tell me why this behaves as it does? In Hugs, I get C:\My Documents\functional\ldapsck1\buffer.hs Main> main Illegal operation (561 reductions, 1029 cells) Main> If the input file is the one line: 1234567812345678 the output file is: Starting logging 1234567812345678 Error In ghc, the program hangs without even creating a file. Dominic import IO main :: IO () main = do ofh <- openFile "log.txt" WriteMode logMessage ofh "Starting logging" ifh <- openFile "tst.txt" ReadMode let loop = do b <- try (getBuffer ifh 16) case b of Right msg -> do logMessage ofh msg loop Left e -> if isEOFError e then do logMessage ofh "Finishing logging" hClose ofh else do logMessage ofh "Error" ioError e in loop logMessage :: Handle -> String -> IO () logMessage hd msg = do hPutStrLn hd msg hFlush hd getBuffer :: Handle -> Int -> IO String getBuffer h n = if (n <= 0) then return "" else do c <- hGetChar h cs <- getBuffer h (n-1) return (c:cs) ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

Re: a cygwin binary package of ghc-5.00.x
by Mike Thomas 24 May '01

24 May '01

Hi. > > Do anybody have one? I failed to recompile it with ghc 4.08.x. > > > > Thank you in advance > > > > Alexander I have one, which uses the Mingw standalone GCC compiler for Windows. It seems to be capable of compiling itself. Problems: 1. It is not in an installer - you would have to hand patch the package file and install by hand. 2. It is not supported by anyone and is non-standard in the way it uses Mingw32. 3. The Win32 demo program hangs on exit under Win98 (works OK on NT4 though). 4. I haven't bootstrapped GHCi, yet (maybe by next week). 5. It is only GHC 5.00, not 5.00.1. (maybe next week). 6. You would have to install Mingw32 (and maybe Cygwin for it's shell) yourself. 7. It is very big, mainly because of the profiled libraries. 8. I don't have an FTP site to put it. 9. It doesn't do dynamic libraries, only static. etc. Unless you're desperate, I suggest waiting for the official release. Cheers Mike Thomas.

2 2

Re: ghc-5.00.1 is available
by Steinitz, Dominic J 24 May '01

24 May '01

Of course I meant hPutStr handle (map (chr .word8ToInt) protocolElement) Dominic J Steinitz@baexternal 24/05/2001 18:47 To: v-julsew cc: glasgow-haskell-users haskell bcc: Dominic Steinitz Subject: Re: ghc-5.00.1 is available Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. -------------------------------------------------------------------------------- ----------------- 21st century air travel http://www.britishairways.com _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

a cygwin binary package of ghc-5.00.x
by Alexander V. Voinov 24 May '01

24 May '01

Hi All, Do anybody have one? I failed to recompile it with ghc 4.08.x. Thank you in advance Alexander

1 0

Re: ghc-5.00.1 is available
by Steinitz, Dominic J 24 May '01

24 May '01

Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

RE: Building Programs
by Simon Peyton-Jones 24 May '01

24 May '01

It depends on which implementation you have. hmake is good, and is independent of implementation. ghc 5.0 has a make system built in, so you can say ghc --make Main to build your program. Or ghc --interactive Main to run it interactively. Hugs also follows module dependencies automatically. hbc had a similar mechanism I think. Simon | -----Original Message----- | From: Steinitz, Dominic J | [mailto:Dominic.J.Steinitz@BritishAirways.com] | Sent: 24 May 2001 10:46 | To: haskell | Subject: Building Programs | | | What's the recommended way of building a system consisting of | many Haskell modules? Should I use hmake, make or is there | some other preferred mechanism in the Haskell world? | | Dominic. | | -------------------------------------------------------------- | ----------------------------------- | 21st century air travel http://www.britishairways.com | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

2 1

Building Programs
by Steinitz, Dominic J 24 May '01

24 May '01

What's the recommended way of building a system consisting of many Haskell modules? Should I use hmake, make or is there some other preferred mechanism in the Haskell world? Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

I/O buffering (was: Endangered I/O operations)
by Simon Marlow 24 May '01

24 May '01

[ moved from glasgow-haskell-users to haskell(a)haskell.org ] Carl Witty writes: > If the report does not allow the implementation to flush buffers at > any time, I would call that a bug in the report. Indeed, perhaps the report should be clarified on this issue. Currently, in section 11.4.2 the report specifies the conditions under which a buffer is flushed, and conditions under which input is available from a buffered read handle. GHC deviates from the report in a few ways: - we don't adhere strictly to block buffering for hPutStr: we may occasionally flush the buffer early. - a line-buffered input handle doesn't wait for the newline to be available before releasing the input, unless you use hGetLine of course. However, since the report doesn't specify the *size* of a line buffer, we can't really be accused of deviating here. - a read/write handle (files only) has a single buffer which contains either pending read or write items, never both. A read from a read/write handle will cause any pending writes to be flushed, and vice versa. IMHO, the report should state that additional buffer flushes may be performed at the discretion of the implementation, but an application should not rely on any additional flushing happening. The report doesn't state whether, when discarding a read buffer, the data should be "returned to the file" (ie. the underlying file pointer moved backwards) if possible. GHC does this if possible. One other point that I noticed while re-implementing I/O: the description for hLookAhead states that "Computation hLookAhead hdl returns the next character from handle hdl without removing it from the input buffer". What if the handle is unbuffered? A working hLookAhead is more or less required in order to implement hIsEOF (at least on a stream: for a file you can check EOF without attempting to read). So for GHC I had to ensure that even an unbuffered handle has a 1-character buffer; this turned out to be not as painful as I thought. Cheers, Simon > I would much rather > use an implementation where stdout and stderr came out in the right > order, and reading from stdin flushed stdout. (As another example, an > implementation might want to flush all buffers before doing a fork(), > to avoid duplicated output.) > > The only caveat is that if such flushing is allowed but not required, > it might encourage writing sloppy, nonportable code. > > >

1 0

Re: Templates in FPL?
by cwitty＠newtonlabs.com 23 May '01

23 May '01

Jerzy Karczmarczuk <karczma(a)info.unicaen.fr> writes: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. > > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? > > Why so many people say "the C++ templates are *wrong*" (and at the same time > so many people use it every day...) I agree with Marcin about the bad points of templates. (I'd like to point out, though, that the idea that "adding new code can't change the meaning of a program" no longer holds in Haskell extended with overlapping type classes.) > Is it absolutely senseless to make a functional language with templates? > Or it is just out of fashion, and difficult to implement? There are some very cool things about C++ templates; they are more powerful than you might suspect. (Note: the following summarizes and paraphrases several papers I've read on the topic; let me know if you want more information and I'll look up references for you.) Basically, templates let you extend the compiler. You get a primitive functional programming language, with which you can do basically arbitrary computations on types and on integers; this language can be used to generate special-purpose code. One way to look at this is as a form of partial evaluation (although there's nothing which automatically decides which computation to do at compile time and which at run time). In the functional programming language, you have conditionals, the usual arithmetic operations, pairing, recursion, etc.; basically, it's a real programming language (although a very annoying one -- the syntax is atrocious). Here are a few examples of the kind of thing you can do with C++ templates: * Compute log base 2 at compile time. You can write a template such that if n is a compile-time constant, Log2<n>::val is its log base 2. * Generate FFT routines. You can write a template such that if n is a compile-time constant which is a power of 2, then FFT<n>::do_fft() is a routine which computes an FFT on an array of size n, as a single chunk of straight-line code (no loops). (Not necessarily useful -- it generates a lot of code for reasonable-sized arrays, and cache effects probably mean that something with loops is more efficient -- but cool nonetheless.) * Implement lambda (over a subset of full C++). You can make lambda(X, a*(X+b)) do "the right thing" (basically by arranging for the expression a*(X+b) to have a type like Times<Num, Plus<PlaceholderX, Num> > and then writing a function using recursion over this type). These techniques are useful when you're going for speed and generality; I would certainly imagine that such things could be useful in a functional programming language as well. In fact, over the past few weeks, people on the Haskell mailing lists have been trying to do vaguely similar kinds of compile-time computation at the type level, using type classes and functional dependencies. On the other hand, C++ templates have huge flaws for this kind of thing. As I mentioned, the syntax is atrocious; also, there are lots of things you would like to do which are apparently just out of reach (the template language is not quite powerful enough). I'd like to see somebody make a serious effort to add this kind of compile-time processing to Haskell. It might not look anything like templates; something like OpenC++ and OpenJava might be better. (These are C++ and Java compilers which are extensible; you can write compiler extension modules using a standard API, and the compiler dynamically loads your extensions.) There is a big reason why C++ templates (or any other form of compile-time arbitrary computation on types) would be hard to add to Haskell: type inference and polymorphism. For C++ templates, you need to know the argument types before you can do the template processing, and you cannot know the type of the result until the processing is done. Probably this facility would only be useful for monomorphic parts of your program, which might mean it's not appropriate for Haskell at all. Carl Witty

4 3

Cygwin Build Bug (Probably Affects other GNU GLIBC Builds)
by Brent Fulgham 23 May '01

23 May '01

For thread-safety reasons, the GNU C Library (2.2+) defines "errno" as a macro that calls a function to get the errno of the current thread. Consequently, the source file "src/runtime/Builtin/cIOExtras.c" needs to include the <errno.h> header file, rather than declaring an extern variable. Diff: ========================================================================== *** cIOExtras.old.c Wed May 23 14:54:58 2001 --- cIOExtras.c Wed May 23 14:26:54 2001 *************** *** 1,10 **** /* basic unsafe utilities, defined in IOExtras */ #include "cinterface.h" #include "mk.h" void performGC () { C_GC(0); } int unsafePtrEq (void* a, void* b) { return (a==b); } /* basic error handling via C's errno */ ! extern int errno; int getErrNo (void) { return errno; } --- 1,11 ---- /* basic unsafe utilities, defined in IOExtras */ #include "cinterface.h" #include "mk.h" + #include "errno.h" void performGC () { C_GC(0); } int unsafePtrEq (void* a, void* b) { return (a==b); } /* basic error handling via C's errno */ ! /*extern int errno;*/ int getErrNo (void) { return errno; }

1 0