- Haskell - Haskell.org

ANNOUNCE: Hugs98 for .NET
by Sigbjorn Finne 10 Apr '02

10 Apr '02

We are pleased to announce the first release of Hugs98 for .NET, April 2002. It sports the following: * A version of the popular Haskell interpreter, Hugs98 (http://haskell.org/hugs) targetted at the Microsoft .NET platform. * Hugs98 for .NET lets you use .NET classes and objects from within the comforts of Haskell. * Hugs98 for .NET lets you wrap up Haskell functions as .NET classes / delegators, providing any .NET language with the ability to call and use Haskell. The distribution comes with documentation and examples demonstrating how to access and interact with .NET -- all available via the Hugs98 for .NET homepage: http://galois.com/~sof/hugs98.net/ One of the main objectives behind this first release is to gauge the level of interest in having a good .NET story for Haskell. Feedback, suggestions for improvements, bug reports etc. are most welcome -- please e-mail these to the author: sof(a)galois.com -------------------------------------------------------------------------- The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, the Yale Haskell Group, and the Oregon Graduate Institute of Science and Technology, 1994-2001, All rights reserved. It is distributed as free software under the license in the file "License", which is included in the distribution. The .NET extension is Copyright (c) Sigbjorn Finne, 2002, All rights reserved. It is distributed as free software under the license in the file "License.net", which is included in the distribution. --------------------------------------------------------------------------

1 0

ANNOUNCE: GHC 5.02.3 released
by Simon Marlow 10 Apr '02

10 Apr '02

The (Interactive) Glasgow Haskell Compiler -- version 5.02.3 ============================================================== We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 5.02.3. The source distribution is freely available via the World-Wide Web, under a BSD-style license. See below for download details. Pre-built packages for Linux, FreeBSD, Solaris and Win32 are also available (or will appear shortly). Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, C++, whatever). A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page at http://www.haskell.org/ GHC's Web page lives at http://www.haskell.org/ghc/ What's new in 5.02.3 ====================== Some important bugfixes: - now works with gcc 3.x - works with newer glibc releases on Linux - loading parsers generated by Happy with the -ag flags into GHCi now works - fix for excessive recompilation when using --make - tryTakeMVar now works - fix some problems with the dynamic linker when loading C libraries into GHCi (using Gtk+HS from GHCi should now work). and various other minor fixes. NOTE: object files created by this vesrion of GHC may be incompatible with object files created by older versions of GHC, so be sure to recompile any pre-compiled libraries you may have lying around. How to get it =============== The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in InstallShield form for Windows folks. Everybody else gets a .tar.gz which can be installed where you want. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. On-line GHC-related resources =============================== Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ===================== To compile programs with GHC, you need a machine with 64+MB memory, GNU C and perl. This release is known to work on the following platforms: * i386-unknown-{linux,freebsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide included in distribution gives a complete run-down of what ports work; an on-line version can be found at http://www.haskell.org/ghc/docs/latest/building/building-guide.html Mailing lists =============== We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

4 3

Re: deriving over renamed types
by Ashley Yakeley 09 Apr '02

09 Apr '02

At 2002-04-09 04:53, C T McBride wrote: >There's a plentiful supply of good examples arising naturally from >higher-hind polymorphism. * -> * is full of functions with good >properties (eg being functorial or monadic) which aren't datatype >constructors. Haskell's inability to express them and to instantiate type >schemes with them is a serious hindrance to the good functional >programming practice of identifying and abstracting common structure. >Similarly, it's not too hard to find examples where the potential >of local `forall' is thwarted by the lack of the corresponding lambda. I agree. I've come across them. ... >Ashley wrote: > >> > data Zero; >> > data Succ n; >> > >> > type Add Zero b = b; >> > type Add (Succ a) b = Succ (Add a b); > >...you can write this program with type classes, but much less clearly >and directly. For instance: <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/truth-framework/ Source/TypeCalc/NaturalType.hs?rev=HEAD&content-type=text/plain> There's more in that folder, including concatenatable mixed lists: <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/truth-framework/Source/Type Calc/> This would have all been _much_ easier with typed lambda and pattern-matching. The biggest problem is that instances are unordered and must be disjoint, whereas pattern cases are of course ordered and don't need to be disjoint. >They're a good tool, but the wrong tool for this job, and >but this job is worth doing well. > >In that respect, I'd caution against pattern matching over * and >higher-kinds, because these kinds are not closed. That's why I argue >in favour of datakinds (given that using genuine term-level data would >involve a seismic shift in Haskell's static/dynamic divide). Hmm. After value lambda and type lambda, are we going to one day want datakind lambda? Alternatively, could one extend classes to be datakinds? Some way of closing them? >But, imagining that Zero and Suc are the constructors of a datakind >Nat over which we can write these programs safely... > >> > data Foo f = MkFoo (f ()); >> > >> > type Succ' = Succ; >> > type Succ'' n = Succ n; >> > >> > -- which of these types are the same? >> > f1 = MkFoo undefined :: Foo Succ; >> > f2 = MkFoo undefined :: Foo Succ'; >> > f3 = MkFoo undefined :: Foo Succ''; >> > f4 = MkFoo undefined :: Foo (Add (Succ Zero)); > >...as has already been pointed out, they all have the same eta-long normal >form, being Foo (/\n -> Succ n). ...and what about this one: f5 = MkFoo undefined :: Foo (/\a ::: Nat => Add a (Succ Zero)); ...? Depending on how 'Add' is defined, f5 may very well be extensionally equivalent to the others. Isn't this going to trip up the programmer some time? >Machines are good at figuring this stuff out, which is why I like their >help when I'm programming. OK. But there needs to be a line drawn in what Haskell is going to figure out. We know it's never going to be able to calculate whether any two functions are extensionally equivalent. -- Ashley Yakeley, Seattle WA

1 0

ObjectIO moved (was: Re: ANNOUNCE: Object I/O released)
by Krasimir Angelov 09 Apr '02

09 Apr '02

See http://www.haskell.org/ObjectIO __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

1 0

Fwd: Re: Doubt of`the book "The Haskell School of Expression", Paul Hudak
by Eray Ozkural 09 Apr '02

09 Apr '02

Where else should I forward your message so you don't do this again? Maybe your instructor is not too stupid to miss this mailing list so that you don't try plagiarism in front of the whole Internet? ---------- Forwarded Message ---------- Subject: Re: Doubt of`the book "The Haskell School of Expression", Paul Hudak Date: Tue, 09 Apr 2002 16:21:00 GMT From: "Euler" <emarinho(a)iceb.ufop.br> To: Eray Ozkural <erayo(a)cs.bilkent.edu.tr> Certainly! -- Eray Ozkural <erayo(a)cs.bilkent.edu.tr> Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C

1 0

CFP: CLIMA'02 - Computational Logic in Multi-Agent Systems
by Jo�o Alexandre Leite 09 Apr '02

09 Apr '02

[We apologize if you receive multiple copies of this message.] ****************************************************************** Second Call for Papers Computational Logic in Multi-Agent Systems (CLIMA'02) Copenhagen, Denmark August 1, 2002 http://centria.di.fct.unl.pt/~jleite/clima02/ Affiliated with FLOC'2002 and ICLP'2002 Submission Deadline: April 30th, 2002 ****************************************************************** Multi-agent systems (MAS) have become an increasingly important area of research, not least because of the advances in the Internet and Robotics. However multi-agent systems can become very complicated, and, consequently, reasoning about the behaviour of such systems can become extremely difficult. Therefore, it is important to be able to formalise multi-agent systems and, to do so in such a way that allows automated reasoning about agents' behaviour. The purpose of this workshop is to present techniques, based on computational logic (CL), for multi-agent systems in a formal way. In 1999, the ICLP'99 Workshop on Multi-Agent Systems in Logic Programming was held and constituted the first in this series. It was followed by CLIMA'00 at CL2000 and CLIMA'01 at ICLP'01. In 2000, we announced a special issue of the Annals of Math and AI and we especially invited all accepted papers of CLIMA'00 for submission to this issue. We got over 20 submissions and the issue will appear early in 2002. We are planning to continue this series of workshops in the following years in order to foster interaction between the multi-agent and the computational logic communities. We solicit unpublished papers that address formal approaches to multi-agent systems. The approaches as well as being formal must make a significant contribution to the practice of multi-agent systems. Relevant techniques include the following: * Non-monotonic reasoning in multi-agent systems * Planning under incomplete information in multi-agent systems * Usage of abduction in multi-agent systems * Representation of knowledge and belief in multi-agent systems * Temporal reasoning for multi-agent systems * Theory of argumentation for multi-agent negotiation and co-operation * Communication languages for multi-agent systems * Distributed constraint satisfaction in multi-agent systems * Decision theory for multi-agents * Distributed theorem proving for multi-agent systems ------------------------------ SUBMISSION INSTRUCTIONS ------------------------------ Papers should be written in English, unpublished, and not simultaneously submitted for publication elsewhere. Papers should be formatted according to the Springer LNCS style and not exceed 12 pages including figures, references, etc. Please send your paper in PostScript (PS) or Portable Document Format (PDF) file format to jleite(a)di.fct.unl.pt. ------------------------------ IMPORTANT DATES ------------------------------ * Submission: April 30th, 2002 * Notification of Acceptance: May 31st, 2002 * Final version due: June 20th, 2002 * CLIMA'02: August 1st, 2002 ------------------------------ PROCEEDINGS ------------------------------ Informal workshop proceedings will be available. As in 2000, we are planning to have a special issue of the Annals of Math and AI on "Computational Logic and Multi-Agency". Authors of the best CLIMA'02 papers will be invited to submit extended drafts for the special issue as a part of the volume. Further details can be found at http://centria.di.fct.unl.pt/~jleite/amai03/. ------------------------------ PROGRAM COMMITTEE ------------------------------ * Thomas Eiter, Vienna University of Technology, Austria * Klaus Fischer, DFKI, Germany * Michael Fisher, University of Liverpool, UK * James Harland, Royal Melbourne Institute of Technology, Australia * Wiebe van der Hoek, Utrecht University, The Netherlands * Katsumi Inoue, Kobe University, Japan * Luís Moniz Pereira, New University of Lisbon, Portugal * V.S. Subrahmanian, University of Maryland, USA * Francesca Toni, Imperial College, UK * Paolo Torroni, University of Bologna, Italy ------------------------------ WORKSHOP ORGANIZERS: ------------------------------ * Jürgen Dix The University of Manchester UK dix(a)cs.man.ac.uk * João Alexandre Leite New University of Lisbon Portugal jleite(a)di.fct.unl.pt * Ken Satoh National Institute of Informatics, Japan ksatoh(a)nii.ac.jp ------------------------------ INQUIRIES: ------------------------------ Please send program suggestions and inquires to either of the organizers.

1 0

Re: Doubt of`the book "The Haskell School of Expression", Paul Hudak
by Euler 09 Apr '02

09 Apr '02

I´m a student of Computer Science of Federal University of Ouro Preto, Minas Gerais, Brazil. I need contact anybody which study the book "The Haskell School of Expression Paul Hudak" and implements the examples of chapter 15. Please, Help me. Euler Horta Marinho

2 1

RE: ANNOUNCE: Object I/O released
by Peter Achten 09 Apr '02

09 Apr '02

Hello Krasimir, I am very curious about your implementation of the Object I/O system, but unfortunately could not open the .zip files either (same symptoms as Arjan van IJzendoorn wrote). Could you check the formats of these files? Thanks in advance. Simon Peyton-Jones wrote: >Krasimir > >| The version that I release is based entirely on LS >| version. I think that it is more elegant and more >| useful for customer. > >I'm delighted and impressed that you have completed the Object I/O >port, but I don't think I agree with you about the MVar/LS issue. > > A note to other readers: the issue is whether it is better, from > the programmer's point of view, to use MVars to manipulate > state, or to use the state parameterisation that Clean uses. > This issue is discussed in the paper by Peter Achten and mself > http://research.microsoft.com/~simonpj/Papers/haskellobjectio.htm > >My defence of the MVar approach is not because I simply >think that MVars are best for everything! >It's because I have really struggled to understand the types in the >Clean I/O system, and they become *so* much simpler when the >state parameterisation is left out. And if I struggle, then I fear that >novice programmers may be in real difficulty. > >I think that even Peter Achten thought this too, having done it both >ways (but I should let him speak for himself). This issue was one of the key design issues Simon and I had to resolve when porting the Clean Object I/O system to Haskell. The arguments in the above mentioned paper are still valid. Briefly, one can summarise them as: MVar-s offer many significant advantages (simpler types, simpler implementation, more expressive power, programming style similar to handling of identifier values) but have one disadvantage (state management is done by the programmer). As it happens, I am about to spend a couple of weeks (re)designing/implementing/bug-fixing the Object I/O library, and this issue is high on my priority list. I think this is a delicate design decision that should be taken with care, as it has impact on all existing programs and all implementations :-). Regards, Peter Additional remarks to those of Simon: >To respond to your points: > >| 1) In the MVAR version each event handler must like >| this: >| >| eventHandler state = do >| st <- takeMVar state >| ... >| ... >| putMVAR state st' >| >| In LS version there isn't need of takeMVar/putMVAR and >| the handler is more easy. But the reverse case is also true: in the LS version, an event handler must modify local state. So a function that is really not interested in the local state is either polymorphic in the local state or uses the local state lifting function (noLS and noLS1). In the MVAR version one wouldn't be bothered with this. >| >| 2) In MVAR version the event handlers in the device >| definitions must be defined as curry functions >| >| Example MVAR: >| state <- newMVAR (0::Int) >| openWindow (Window NilLS [WindowClose (closeWin >| state)]) >| >| Example LS: >| openWindow (0::Int) (Window NilLS [WindowClose >| closeWin]) > >Both are true, but you can easily wrap up the state passing >if that is what you want: > > state <- newMVAR (0::Int) > openWindow (Window NilLS [WindowClose (handle state closeWin)]) > > handle :: MVar a -> (a -> IO a) -> IO () > handle m t = do { s <- getMVar m; r <- t s'; putMVar m s' } > >Now you can write closeWin :: WinState -> IO WinState >if you want. > >Of course the reference to the state is still explicit, but I do not >think that is a bad thing. It tells you where that MVar can be modified >(and where it can't!). There might be two pieces of state for one >component, >one modified by one set of events and one by another, and it would be >nice >to make that apparent. > > >| 3) Modification of local state doesn't mean >| modification of device behaviour. The behaviour of the >| device is described with both local state and internal >| device data. This means that direct access to the >| state isn't a good idea. In the LS version the local >| state is encapsulated in the device and I think that >| this is more OOP style. > >I don't understand this; you can encapsulate the MVars too, in just >the same way: > >windowDevice = do { s <- newMVar 0; > openWindow ... } > >No caller of WindowDevice can see the encapsulated MVar. The main point of 'LS advocates' is that encapsulation is guaranteed by construction, while it is a program property in the MVAR system. This is of course a GOOD thing. However, this characteristic of LS is also its weakness: one simply can't (partially) share local state between GUI components of different top-level parents (except of course on the highest level within the interactive process) even though in practice this would make a lot of sense. One also can't easily modify event handlers once a GUI structure has been created, even if one would `know' the proper local state type because of the strong encapsulation (you can do it, but this requires quite some overhead, using typed message passing). In short, we have the following: MVAR subsumes LS (we can write more programs), but the price to pay is at least: less static error checking and more proof obligations wrt. locality of state. Perhaps there is an interesting alternative that covers all GOOD points and has fewer BAD points.

4 6

Re: deriving over renamed types
by Ashley Yakeley 09 Apr '02

09 Apr '02

At 2002-04-08 12:45, Lennart Augustsson wrote: >I just just wanted to say that I agree with almost everything Conor said. >I find it a little odd that the extension to Haskell that allows explicit >forall >does not also allow you use explicit type application (and type lanbda). What did you have in mind? data Zero; data Succ n; type Add Zero b = b; type Add (Succ a) b = Succ (Add a b); type Mult Zero b = Zero; type Mult (Succ a) b = Add b (Mult a b); type Fact Zero = Zero; type Fact (Succ n) = Mult (Succ n) (Fact n); data Foo f = MkFoo (f ()); type Succ' = Succ; type Succ'' n = Succ n; -- which of these types are the same? f1 = MkFoo undefined :: Foo Succ; f2 = MkFoo undefined :: Foo Succ'; f3 = MkFoo undefined :: Foo Succ''; f4 = MkFoo undefined :: (Add (Succ Zero)); -- Ashley Yakeley, Seattle WA

4 3

docon-2.04 announcement
by Serge D. Mechveliani 09 Apr '02

09 Apr '02

Announcement ------------ The Algebraic Domain Constructor DoCon-2.04, a computer algebra program written in Haskell, is available at http://www.botik.ru/pub/local/Mechveliani/docon/2.04/ ftp.botik.ru/pub/local/Mechveliani/docon/2.04/ What is new ----------- * Performancec tests for comparison to popular Axiom and MuPAD computer algebra programs (`strict' and non-functional systems) are refreshed and extended (see manual.ps); * DoCon was tested under the releases of ghc-5.02.2, 5.02.3; * Manual has become more readable, and it is in Postscript format; * Manual explains the relation of DoCon to Aldor language and Axiom system. DoCon-2.04 is a program package written in what we call Haskell-2-pre - certain functional extension of Haskell-98. Haskell-2-pre includes the multiparametric classes, overlapping instances, other minor features. DoCon-2.04 was tested under ghc-5.02.2, 5.02.3. Probably, it can be ported (with some effort) to other implementations. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0