September 2002 - Haskell

RE: Haskell 98: Behaviour of hClose
by Simon Peyton-Jones 24 Sep '02

24 Sep '02

Glynn writes: | 2. Regarding the buffering issue, I suggest adding something along the | lines of the following to section 11.4.2 of the library report: | | > For a stream which is associated with a terminal device, setting the | > mode to no-buffering will also disable any line-buffering which may | > be performed by the operating system's terminal driver. | > | > Similarly, setting the mode to line-buffering or block-buffering | > will enable any line-buffering which may be performed by the | > operating system's terminal driver. | | However, it was only when analysing the existing behaviour in order to | write that above that I became aware of the second half. This is | potentially more problematic than the first half. ...and there are several more paragraphs (below). I conclude that this is all very tricky, and there is no chance of getting something that is obviously sensible into 11.4.2 in the next few days. Again, the swamp beckons, and we've struggled by without any such words for many years now. So I propose to do nothing here, rather than risk making the situation worse. Thank you to Glynn for trying! There's a gold medal waiting for someone who designs a better (portable) I/O library. Simon | | While there isn't much point disabling buffering at the stream level | if it's still being performed by the terminal driver, there *are* | reasons why you might wish to enable buffering at the stream level | without enabling canonical mode (which is what the terminal driver's | "line buffering" actually corresponds to). | | E.g. in canonical mode, the EOF character (typically Ctrl-D) will | result in a read() from the OS-level descriptor indicating EOF. In | "raw" mode, the EOF character will be read literally (i.e. '\004' for | Ctrl-D). | | IOW, while canonical mode results in line-buffering, it also has other | side-effects. | | Another consequence, which has just sprung to mind, is that whereas | the buffering mode of a stream is strictly user-space, and therefore | internal to the program, the terminal driver settings are a property | of the device, and will affect other programs which use that device. | | Example: a Haskell program is run on a terminal for which canonical | mode is enabled (which is normally the case), and that program does | "hSetBuffering stdin NoBuffering", thereby disabling canonical mode. | After the program terminates, canonical mode will still be disabled | for that device. | | Similar issues arise in C, i.e. you need to explicitly restore the | terminal settings when the program terminates or is suspended (via | SIGTSTP). However, in C, you would have to have explicitly change the | terminal settings (with e.g. tcsetattr()), whereas Haskell does this | "under the hood". | | -- | Glynn Clements <glynn.clements(a)virgin.net>

1 0

RE: Haskell 98: Behaviour of hClose
by Simon Peyton-Jones 24 Sep '02

24 Sep '02

On the matter of echoing, in Section 7.1 there seem to be two possibilities: 1. Delete the sentence "By default, these input functions echo to standard output." altogether. 2. Replace the sentence by If the standard input (stdin) is a terminal device, any input on stdin is normally echoed on that device, unless the operating system or environment has disabled such echoing. My original inclination was for (2), so that Joe's first program will always work. However, Glynn and Ross and Ferenc all favour (1). Virtually no one has said anything else. I therefore propose to adopt (1). It's clear that (2) is leading into a swamp of caveats which we just do not have time to resolve. Any implementation will probably do something sensible (i.e. behave like other languages). Simon

1 0

ANN: H98 FFI Addendum 1.0, Release Candidate 7
by Manuel M T Chakravarty 24 Sep '02

24 Sep '02

Dear Haskellers, RC 7 of the FFI Addendum is now available from http://www.cse.unsw.edu.au/~chak/haskell/ffi/ The change log since RC 4, which was the last version circulated via haskell(a)haskell.org, is appended below. Please review this specification carefully. If no suggestion that leads to a serious change is made within a month, I will freeze this addendum. Thanks, Manuel -=- Changes since RC6: * fixed typos Changes since RC5: * Author list: changed Alastair Reid's institution * 1.4: Clarified the wording * 4.1: Explicitly stated that access to pre-processor symbols is not provided by the FFI * 4.1.1: Removed [lib] from impent syntax and discussion * 4.1.3: Added parentheses round FunPtr ft to make it easier to understand a tolerably complex type. * 4.1.4: Removed all mention of library objects; clarified that header files do not impact the semantics of foreign calls, but may be required for correct code generation by some systems * 5.2: Clarified that all operations in Bits are member functions of the type class. Reverse the meaning of the sign of the second argument for `rotate' and `shift' (this makes it the same as GHC used all the time). `bitSize' on `Integer' etc is now undefined. * 5.5: Finalisers must be external functions to facilitate the implementation on Haskell systems that do not support pre-emptive concurrency. Added mallocForeignPtr and mallocForeignPtrBytes. * 6: Specified that HsBool==int in table2 Relabelled column 1 in table 3 (C symbol -> CPP symbol) Replaced 0 and 1 with HS_BOOL_FALSE/TRUE * 6.1: Clarified that nullPtr (nullFunPtr) coincides with (HsPtr) NULL and (HsFunPtr) NULL, respectively. Allowing multiple calls to hs_init() and clarified the constraints on the relative timing between hs_set_argv() and getProgName/getArgs. Added hs_perform_gc(). Changes since RC4: * 5.6: Clarified documentation of `StablePtr's (RC 5)

3 7

2002 Haskell Workshop
by Manuel M T Chakravarty 23 Sep '02

23 Sep '02

The detailed programme for the 2002 Haskell Workshop is available at http://www.cse.unsw.edu.au/~chak/hw2002/ It turns out that we still have one free slot for a 10min talk. Please email me if you are interested. First come, first served. See you soon in Pittsburgh! Manuel

1 0

ANN: Gtk+HS 0.14.10
by Manuel M T Chakravarty 22 Sep '02

22 Sep '02

I am pleased to announce version 0.14.10 of Gtk+HS, the Haskell binding for the GUI toolkit GTK+. This release features a range of new widgets over the previous release and supports the use of the library as a GHC package. Gtk+HS includes code contributions from many people. See <http://cvs.gnome.org/lxr/source/gtk%2bhs/AUTHORS> for details. The underlying toolkit, GTK+, implements a mature, high-end widget set, which forms the basis of the Gnome desktop environment, and is used in cutting-edge open source applications, such as the Gimp, Gnumeric, and Abiword. Gnome (and, thus, GTK+) is not only one of the two main desktop environments for Linux, but has also been selected by Sun as the new standard desktop for Solaris. Moreover, there is a port of GTK+ available for Win32. The present distribution includes an example application (The Boolean Editor) that demonstrates how GTK+ can be used from Haskell. It illustrates concepts, such as callbacks, the handling of global GUI state, and synchronisation between the different windows of an application. The code is available directly from the Web page without need to download the complete release. More information (including screenshots!) as well as source and binary packages are available from http://www.cse.unsw.edu.au/~chak/haskell/gtk/ Happy Hacking! Manuel

1 0

RE: Haskell 98: Behaviour of hClose
by Simon Peyton-Jones 20 Sep '02

20 Sep '02

Glynn Thanks for your input. If you think it is important, could you please propose one or more concrete changes to the wording of the Language Report or the Library Report or both. Then we'll get a better idea of what you have in mind. (Start from the current draft at http://research.microsoft.com/~simonpj/haskell98-revised) The H98 report is deficient in many respects. It's been improved steadily over the last three years, but still has gaps. This may be one of them. But since the report is about to go over the wall to CUP and get printed as a book (end of Sept) the overriding priority is not to introduce new errors and accidentally make things worse. With that in mind, I think we can only add a sentence here and there to clarify, nothing big. Simon | -----Original Message----- | From: Glynn Clements [mailto:glynn.clements@virgin.net] | Sent: 18 September 2002 20:50 | To: Simon Peyton-Jones | Cc: haskell(a)haskell.org | Subject: RE: Haskell 98: Behaviour of hClose | | | Simon Peyton-Jones wrote: | | | > | 2. Is there actually anything special about the treatment of stdin, or | > | does this apply to any input stream which is associated with a | > | terminal? | > | > I'm proposing just stdin. My motivation is to make simple stupid | > programs work right. | | Argh. Too much of this and you end up with a language which isn't | suitable for anything other than "simple stupid programs". | | If you're considering adding "magic" behaviour, the first question | should be "if this behaviour is completely unacceptable in a certain | context, how hard is it for the programmer to disable it, or to work | around it?". | | If you were to forcibly enable echoing on stdin, how hard would it be | for the programmer to restore the terminal driver to its original | state? AFAICT, it's impossible; the original state simply wouldn't be | available. In such a situation, the only option available to the | programmer is to not use Haskell. | | Part of the reason for C's popularity is that it lets the programmer | take care of the details, rather than being stuck with the language | developer's idea of "the right thing". IOW, there is a complete | absence of problems for which the only solution is "don't use C". | | > If people open other terminal devices they are | > much more likely to know what they are doing. It would be reasonable to | > pin down what happens in that case, but I'm desperately afraid of | > opening Pandora's box when I have to deliver the final bits to CUP in a | > couple of weeks. So, stdin only for now. | > | > | 3. In general, "magic" behaviour (e.g. clearing the ICANON flag when | > | disabling buffering) should at least be documented, otherwise it's | > | likely to confuse experienced programmers. | > | > Well I have never heard of the ICANON flag! I don't expect to put it in | > the Haskell report unless someone tells me it's absolutely unavoidable! | | You don't necessarily have to mention the details, just point out that | hSetBuffering may change the terminal driver's settings. | | Because it looks so similar to ANSI C's setvbuf(), someone who is | migrating from C to Haskell may assume that it's roughly equivalent | (i.e. that it only affects the user-space stream, and not the | underlying OS descriptor). | | -- | Glynn Clements <glynn.clements(a)virgin.net>

2 1

RE: Q: Forcing repeated evaluation
by Simon Marlow 20 Sep '02

20 Sep '02

> From: D. Tweed [mailto:tweed@compsci.bristol.ac.uk] > > Note that (assuming that I'm not missing something) you can > prevent the > moving of expressions involving l in a very ugly way by > noting that these > `dummy argument functions' are polymorphic so that you could write > > x1 = f1 (l 1) > x2 = f2 x1 (l 2) > x3 = f3 x2 (l 3) Please don't encourage this sort of thing. If two expressions are semantically equivalent, there's always a chance that the compiler will replace one by the other or common them up. In this case, I believe GHC's worker-wrapper transformation will do it. Cheers, Simon

4 3

Haskell 98
by Simon Peyton-Jones 20 Sep '02

20 Sep '02

Folks As you know, we're in the home straight for Haskell 98. With the exception of the recent discussion of echoing, there have been very, very few changes since the May release. (Check out the bugs list.) Cambridge University Press are going to publish the Language and Library Reports, both as a book, and as the Jan 2003 issue of the Journal of Functional Programming. I have to deliver the source files to them by end of Sept. The current draft is at http://research.microsoft.com/~simonpj/haskell98-revised It includes one new thing: a single integrated book-style document that includes both the language and library reports, with a single index. This book also has a new preface; this is my attempt to combine stuff from both old prefaces, eliminating some old material at the same time. CUP do not want to have a dozen authors for the book, and indeed there are past members of the Haskell committee who deserve credit, as well as many people on the Haskell mailing list who have made substantial contributions. So the book currently shows me as editor, while the preface attempts to give credit where credit is due. Please help me to improve it. The copyright notice is, I believe, agreed with CUP, but I must check that. The online versions will remain available. Please take a look. Simon

3 2

Exceptions with Hugs 98
by juan albornoz 19 Sep '02

19 Sep '02

Hello I need to catch some exceptions which I've "thrown" with the error function. I am using WinHugs 98. Can any one help me? JUAN ALBORNOZ - Bogota - Colombia

2 1

Re: layout problem
by Hal Daume III 19 Sep '02

19 Sep '02

Here's one error: > _______________|n>1 do putChar '' > _______________________putSpc (n-1) > ________________return() this needs to line up. if that doesn't fix your problem, please try to narrow it down to just one or two function definitions and point out exactly which line is causing the error; otherwise, it's hard to debug.

1 0