- Haskell - Haskell.org

Knight Problem
by Christoph M. 02 Feb '01

02 Feb '01

Hi ! Does anybody know how to solve the "Knight Problem" ? Cheers, Christoph

4 3

RE: Source tar ball for Simon Marlow's Haskell Web Server??
by Simon Marlow 01 Feb '01

01 Feb '01

> I looked on www.haskell.org for the Simon Marlow's Web Server, > but couldn't find. Did I overlook it? The source is here: http://research.microsoft.com/~simonmar/hws.tar.gz Cheers, Simon

1 0

Source tar ball for Simon Marlow's Haskell Web Server??
by Bill Halchin 01 Feb '01

01 Feb '01

Hello, I looked on www.haskell.org for the Simon Marlow's Web Server, but couldn't find. Did I overlook it? Regards, Bill Halchin _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

ANNOUNCE: O'Hugs 0.5
by Johan Nordlander 01 Feb '01

01 Feb '01

Dear all, I'm pleased to announce the release of ======================================== O'Hugs 0.5 -- the O'Haskell interpreter. ======================================== O'Haskell is an object-oriented extension to Haskell, offering monadic reactive objects and polymorphic subtyping in addition to the Haskell core. O'Hugs is an implementation for this language. New features in O'Hugs 0.5 include: - A more refined interface to Tk, including support for the optional Tk extension Tix. - Support for network programming via TCP and UDP. - Much improved library documentation. - Local universal quantification in records. - Local existential quantification in datatypes. - Templates with automatic instantiation of local sub-objects. - Overloading using smallest supertypes for contravariant type classes. - Recursive generator syntax. - Macintosh and Windows binaries. - Several bug-fixes. For more information and dowload options, please visit http://www.cs.chalmers.se/~nordland/ohaskell/ Bug reports and comments should be sent to nordland(a)cse.ogi.edu. Enjoy, Johan Nordlander PS Please don't confuse this release with today's concurrent release of a new beta version of Hugs98!

1 0

ANNOUNCE: Hugs 98 January 2001 beta
by Johan Nordlander 01 Feb '01

01 Feb '01

================================================================== __ __ __ __ ____ ___ || || || || || || ||__ ||___|| ||__|| ||__|| __|| ||---|| ___|| || || || || Version: January 2001 beta ================================================================== Dear all, I'm pleased to announce the availability of a new beta release of Hugs98. This is a beta release that aims at giving as many people as possible a chance to react to the changes and additions that have recently been incorporated, before the next major version is released on February 14 2001. A list of the most important new features looks as follows: - A Foreign Function Interface closely modelled after the one provided by GHC. - Built-in, Hood-like debugging support. - A new syntax for recursive monad bindings. - A new GUI under Windows that doesn't consume all CPU time. See the release notes in the "docs" directory of the distribution for more information on some of these features. Send email to hugs-users-request(a)haskell.org to join the hugs-users mailing list. Bug reports should be sent to hugs-bugs(a)haskell.org. Send email to hugs-bugs-request(a)haskell.org to subscribe to the hugs-bugs list. The home page and download site for Hugs is at http://www.haskell.org/hugs/ Enjoy, Johan Nordlander PS Please don't confuse this release with today's concurrent release of a new version of O'Hugs, the O'Haskell interpreter!

1 0

What does "Compiled code too complex" error message of Hugs mean?
by Laaser Christian 31 Jan '01

31 Jan '01

When loading some Haskell files with Hugs, I get the error message "Compiled code too complex". However, the compilation with GHC 4.08.1 succeeds. What does this message mean? What can I do about it? Christian

2 1

Problems with GHC-4.08.1 on Windows 2000 Professional
by Eugene Nonko 30 Jan '01

30 Jan '01

Dear Colleagues, I've encountered some problems after ghc-4.08.1 installation on by w2kpro. When I'm trying to compile simple 'Hello world!' program (ghc main.hs -o main.exe), linker outputs messages: === gcc: D:/ghc/lib/Main.dll_o: No such file or directory gcc: D:/ghc/lib/PrelMain.dll_o: No such file or directory === When I'm trying to compile it with -static command line switch (ghc main.hs -o main.exe -static), it compiles, but resulting .exe does nothing (it doesn't displays message). What's the problem, can someone explain me? PS. Just in case, this is full source code of this 'Hello world!' program. ;) === module Main (main) where main = putStrLn "Hello, world!" === Best regards, Eugene Nonko Novosoft Inc.

2 1

RE: Problems with GHC-4.08.1 on Windows 2000 Professional
by Simon Peyton-Jones 30 Jan '01

30 Jan '01

You have to compile with the flag -static, I'm afraid. 4.08.2 will have this built in. Simon | -----Original Message----- | From: Eugene Nonko [mailto:cm@pochta.net] | Sent: 30 January 2001 12:30 | To: haskell(a)haskell.org | Subject: Problems with GHC-4.08.1 on Windows 2000 Professional | | | Dear Colleagues, | | I've encountered some problems after ghc-4.08.1 installation | on by w2kpro. | When I'm trying to compile simple 'Hello world!' program (ghc | main.hs -o | main.exe), linker outputs messages: | === | gcc: D:/ghc/lib/Main.dll_o: No such file or directory | gcc: D:/ghc/lib/PrelMain.dll_o: No such file or directory | === | | When I'm trying to compile it with -static command line switch (ghc | main.hs -o main.exe -static), it compiles, but resulting .exe | does nothing | (it doesn't displays message). | | What's the problem, can someone explain me? | | PS. Just in case, this is full source code of this 'Hello | world!' program. | ;) | === | module Main (main) where | | main = putStrLn "Hello, world!" | === | | Best regards, | Eugene Nonko | Novosoft Inc. | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell |

1 0

FW: Consortium Caml
by Simon Peyton-Jones 29 Jan '01

29 Jan '01

Here's an interesting model for collaboration which the Caml folk are taking up. Simon -----Original Message----- From: Michel Mauny [mailto:Michel.Mauny@inria.fr] Sent: 26 January 2001 21:38 To: caml-list(a)inria.fr Subject: Consortium Caml -- [ English version below ] --- Dear Colleagues, We are pleased to announce the creation of the Caml Consortium, whose aim is to federate the design and development efforts around the Caml programming language. The Caml Consortium will therefore try to bring together, around the language development team, industries, research centres and educational establishments interested in contributing their support to the design and development of the language and related tools. Comprising a group of highly-motivated users, the Consortium will be the place where the members can identify their common requirements, exchange their experiences and solutions, and co-operate to propose a particular development of general interest. One of the Consortium's roles is therefore to be a place where users of the language can meet and exchange information. It is here that a true community will be created with the specific intention of assisting in the development of the language and to provide it with such a visibility that this community will expand by itself. The motivation and industrial importance of its members will also attract companies to the Consortium which want to be present on the Caml applications and training market. Another role of the Consortium will therefore be to attract new members, whether they are users of the language or service providers. Finally, the Consortium will provide a response to the question on the language's continuity. The essential elements for the continuity of a programming language are the continuity of its compilers (or their free availability), its user base, and the volume of existing (stable) codes. The success of the Caml Consortium will make it possible to measure the user base and the volume of the existing Caml code. As for the availability and development of the Caml compilers, these are already freely distributed with their sources. If INRIA decides at some point to withdraw from Caml development, and therefore to dissolve the Caml Consortium as it presently stands, the members of the Consortium will be sufficiently numerous, they will have sufficiently diversified profiles, and the market for the language will be such that the members of the Consortium will have no difficulty in continuing the existence and development of the language. INRIA will facilitate this transition, which is in the general interest. For more information, I suggest that you consult http://caml.inria.fr/consortium/ Best regards, -- Michel Mauny

2 1

RE: Question about 'Tackling the Awkward Squad'
by Steinitz, Dominic J 29 Jan '01

29 Jan '01

This is probably superfluous now but I still don't understand Hugs' behaviour. I ran the following with ghc 4.08.1: module Main(main) where import Concurrent main = do chan <- newChan writeChan chan "One" dup <- dupChan chan writeChan chan "Two" x <- readChan dup y <- readChan chan z <- readChan chan putStrLn (x++y++z) I expected the answer "TwoOneTwo" but instead got $ ./main d:\dom\hugs98\concurrent\main.exe: no threads to run: infinite loop or deadlock? which confirmed the problem that Don highlighted. With Hugs I got the following: Main> main (232 reductions, 458 cells) which was puzzling. I'm running Version: May 1999 with -98. Dominic. simonpj(a)microsoft.com on 28/01/2001 11:18:00 To: don_wakefield haskell cc: bcc: Dominic Steinitz Subject: RE: Question about 'Tackling the Awkward Squad' Don Crumbs! You're right! The MVars that are drawn as heavy black boxes in Figure 7 of Tackling the Awkward Squad are used to block the consumer when it catches up with the producer. But if there is more than one consumer, it's not OK to leave these MVars empty. Instead, getChan should do a put after its take; or, more elegantly, should use readMVar, which has the semantics of take-followed-by-put: getchan (read, write) = do { head_var <- takeMVar read ; MkItem val new_head <- readMVar head_var ; putMVar read new_head ; return val } Concurrent programming is tricky. I owe you a beer! I'll fix the version on the Web Simon | when I ran across what appears to be an error. On page 34, while | discussing Channels, he proposes a function called dupChan: | | dupChan (read, write) | = do { new_read <- newEmptyMVar ; | hole <- takeMVar write ; | putMVar write hole ; | putMVar new_read hole ; | return (new_read, write) } | | The rationale is given thusly: | | "For example, consider a multi-cast channel, in which there are | multiple readers, each of which should see all the values written to | the channel ... The idea is that the channel returned by dupChan can | be read independently of the original, and sees all (and only) the | data written to the channel after the dupChan call." | | But earlier he has defined getChan thusly: | | getchan (read, write) | = do { head_var <- takeMVar read ; | MkItem val new_head <- takeMVar head_var ; | putMVar read new_head ; | return val } | | Since the line which performs the 'takeMVar head_var' leaves the MVar | referenced by head_var empty, the dupChan 'new_read' Stream | should block | when the reader tries to *also* use getChan on this Stream, isn't this | so? Am I missing some subtlety? I drew all the pictures :^)~ | | -- | Don Wakefield Mentor Graphics Corporation | (503) 685-1262 8005 S.W. Boeckman Road | don_wakefield(a)mentorg.com Wilsonville, OR 97070-7777 | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell | _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0