- Haskell - Haskell.org

ANNOUNCE: O'Hugs 0.5
by Johan Nordlander 31 Jan '01

31 Jan '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 31 Jan '01

31 Jan '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

Re: Combinator library gets software prize
by Ronald Legere 27 Jan '01

27 Jan '01

--- "C.Reinke" <C.Reinke(a)ukc.ac.uk> wrote: >Even within combinator languages, I am not always > sure whether those > reporting on the paper are aware how much the DSL > gains by being > embedded in a full functional language, and how > simply exporting the > core DSL to another context would severe all those > useful connections. > Heh, this is something that I ran into when trying to write a combinator language for Java based on Haskore. I gave up when I realized i really needed those other features of a functinal language to :). It is a bit difficult in many domains to seperate what you are defining from the language you are defining it in, so I guess this is not such a large suprise. __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/

1 0

Re: Combinator library gets software prize
by C.Reinke 26 Jan '01

26 Jan '01

[oops, somehow this ended up in my drafts folder, not on the list; sorry for the delay] First, to avoid confusion: I'm not criticising the work described. I'm just pointing out that, in my view, the major advantages of functional programming lie beyond what is used in this application (in other words, there is yet more to be gained, and we should not underestimate the role of the facilities imported from the functional host language, such as functional abstraction). [one quibble: I don't like the idea of using floating point numbers to represent real money without further comments. Even after avoiding representation error surprises by using base10 instead of binary floating points, aren't there precise standards for rounding in the financial market? Or have I missed an explanation of this in the paper?] > > Am I the only one who finds the exclusive emphasis on combinator > > languages slightly disappointing (in fact, the article seems to equate > > functional language with domain-specific combinator languages, which is > > more than a bit mistleading)? > > What declarative approach(es) (other than combinators) are you > referring to here? Mostly lambda-calculus; more generally, all approaches that deal explicitly with variables and variable binding, and the resulting languages, which are general enough that DSLs for many domains can be embedded in them. Even within combinator languages, I am not always sure whether those reporting on the paper are aware how much the DSL gains by being embedded in a full functional language, and how simply exporting the core DSL to another context would severe all those useful connections. In the present context, most of the excitement seems to focus on the contract combinators, because they bring a new approach towards order in the application domain. They can be viewed as a first-order functional language on contracts. This core part of the DSL could be used in other modern languages as well, provided their expression sub-language is sufficiently expressive (although the syntax, e.g., new And(..) and new Give(..) in Java, or <Give>..</Give> in other contexts, would quite likely annoy the user). But the paper goes beyond that, e.g., it defines and uses some higher-order features for observables. Also, functional programmers will be tempted to use partially applied contract combinators in higher-order compositions (as a simple example, take "all = foldr and zero :: [Contract] -> Contract" -- acquiring "all contracts" acquires a list of contracts). Such uses are already slightly more difficult (and typically much more ugly) in non-functional languages, so simply providing the same basic DSL as a library embedded in a non-functional language will not necessarily give the same flexibility (and a dedicated implementation of the DSL would have to decide between supporting only simple uses of the combinators or adding some more advanced features). Of course, in addition to combinators, we also need definitions, so that we can give names to useful combinations of combinators. This comes for free if the DSL is embedded in Haskell, but if we take it out of this context, we need to start thinking about what kind of definitions we can or want to support: parameters? certainly. what types of parameters? what types of things can be defined? how are parameters passed?.. And suddenly, we're into the definition and implementation of a little (higher-order?) functional language, with support for functional abstraction (how much support?). Does the host language (or the dedicated implementation) support all the things we want in the way we expect? In any case, the core contract combinator DSL doesn't stand in isolation - we need to work with the contracts, operate on dates, evaluate options, iterate through sequences or alternatives, .. Do we do this in functional style, or by shouting imperatives at those poor contract combinations? > > The consequence (and the intention, as far as one can gather from the > > paper) of the limitation to combinators is that this language can and > > will be used mainly in non-functional languages, not inheriting all > > that much from a functional style of programming. The same will > > probably hold for any communication standards based on it. > > Why is that? I'm new to the functional programming world, and haven't > reallystruck the concept of combinator libraries elsewhere. I assumed > they were largely a functional programming concept. Even though I can > see how they could be implemented in imperative languages, it doesn't > seem that they would be a nice fit. That's my point. But so far, I don't see any external commitment to a functional host language for the core combinators. Of course, that impression could well be wrong.. The paper suggests the Haskell implementation as a prototype to help the development of an existing C++ implementation as well as a new implementation in OCaml (implementation language, not host language). Most positive external comments seem to focus on the core contract combinators as a possible means to standardize the way professionals and software are talking about contracts (XML-like). Now, if you cut out the contract combinators from the DSL embedded in Haskell and try to find something that can be used across C++,OCaml,XML-processing Java, etc., you might end up writing for-loops, assigning contract combinations to global variables, sending messages to contract objects, and all the other funny non-functional things that are so happily used outside the Haskell world. > > [Several interesting elided] > > More generally, is there any more information or forums on declarative > approaches to financial engineering? I found this paper intriguing, as > it focuses on both my current academic interests, and my work! I'm not an expert in this area, but from the few references in the paper, it seems that there hasn't been much work, and from the comments on the paper, it seems there there is a growing interest. Perhaps there are enough people interested now to warrant setting up such a forum. Claus

1 0

RE: Yet more on functional dependencies
by Simon Peyton-Jones 26 Jan '01

26 Jan '01

| | I am finding functional dependencies confusing. (I suspect I am | | not alone.) Should the following code work? | | | | class HasConverter a b | a -> b where | | convert :: a -> b | | | | instance (HasConverter a b,Show b) => Show a where | | show value = show (convert value) | | It's a separate issue. There's no reason why a system using | functional dependencies *should* support this. But it is an | attractive and useful extension that such a system would | probably *want* to include. (i.e., it's a desirable feature, | not a requirement.) There are two things going on here a) The 'head' of the instance declaration is just "Show a", so this purports to give an instance declaration for all types "a". So it overlaps with other instance declarations, and GHC currently rejects it for that reason. (Arguably, if you accept overlapping instance declarations, then this should be acceptable too.) b) There's a "b" in the instance declaration context that doesn't appear in the head. This is quite OK, because the functional dependency ensures that "a" uniquely determines "b". So here's a variant that works in the (as-yet-unreleased) GHC 5.0: data Foo a = MkFoo a instance (HasConverter a b,Show b) => Show (Foo a) where show (MkFoo value) = show (convert value) [Incidentally, functional dependencies don't work at all in GHC 4.08; don't even try.] Simon

1 0