- Glasgow-haskell-users

GHC 5.02 is released
by Julian Seward (Intl Vendor) 21 Sep '01

21 Sep '01

============================================================ The (Interactive) Glasgow Haskell Compiler -- version 5.02 ============================================================ We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 5.02. This is the first version of GHC that has all of the following: * An interactive read-eval-print loop, similar to Hugs. You can load a mixture of compiled and interpreted modules; in particular, you automatically use the precompiled libraries, so your "interpreted" programs often run pretty fast. * Works solidly on Windows platforms. Installation is simple (Installshield); you don't have to install anything else; and GHC does not get confused if you also happen to have (say) Cygwin installed. * Implements the changes adopted for the (now almost finalised) Revised Haskell 98 Language and Library Reports. * The ability to emit "External Core", a documented typed intermediate language, suitable for slurping up into other tools. [Andrew Tolmach's work.] * A particularly thorough pre-release test programme. Some releases are more solid than others; this one is at the solid end of the spectrum. We fondly hope. So if you have been waiting to upgrade your GHC 4.08, this is the moment. 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. 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. More details about what's new ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 5.02 incorporates many small refinements and bug fixes over the previous stable release (5.00.2). There are no major language changes. - Implements Haskell 98 (revised) - Ability to emit External Core. GHC can't read External Core back in. Yet. - Much improved support for Windows platforms. Binary builds are now entirely freestanding. There's no need to install Cygwin or Mingwin to use it. It's a one-click-install-and-off-you-go story now. - Several small changes to bring GHC into line with the newest Haskell 98 report. - GHCi (the interactive system) now works on Windows. - Partial FFI support in GHCi. At the moment, foreign import (both static and dynamic) is supported on x86 and sparc platforms. - A compacting garbage collector, to try and reduce space use. - Ability to disconnect built-in numeric syntax from the supplied Prelude. This allows you to define your own arithmetic packages, which Haskell98 doesn't quite support. - Experimental: partial support for hierarchical module names. - Experimental: following heroic hacking by Ken Shan, 5.02 now works on Alpha (Tru64 only). Many 64-bit bugs have been shaken out. At the moment only the batch-mode compiler works -- no GHCi or native code generator yet. We've found and fixed more bugs than you could possibly imagine. A big thank-you to all those who reported bugs in the 5.00.X series. We claim to have fixed almost all reported bugs. In general we've spent a large amount of effort trying to improve the stability of the system relative to 5.00.X. (Famous last words ...) For full details see the release notes: http://www.haskell.org/ghc/docs/5.02/set/release-5-02.html Background ~~~~~~~~~~ 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, 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/ 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 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 * alpha-dec-osf{2,3} * 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/5.02/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.

1 0

Re: Alternative Design for Finalisation
by Marcin 'Qrczak' Kowalczyk 21 Sep '01

21 Sep '01

Thu, 20 Sep 2001 12:56:55 +0100, Simon Marlow <simonmar(a)microsoft.com> pisze: > (apologies for the different spelling of finalize - apparently both are > correct and I randomly settled on the 'z' version some time ago). I guess 's' is British and 'z' is American. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Student Programming Projects
by Barbara Nostrand 21 Sep '01

21 Sep '01

Hi. Next Semester, I am supposed to teach a short course in Haskell. Can anyone recommend interesting programming projects which can be completed in about a month? Thank you very much. Barbara Nostrand -- +----------------------------------+----------------------------------+ | Dr. Barbara Nostrand | Department of Computer Science | | Assistant Professor | SUNY College at Potsdam | | Computer Science and Engineering | Potsdam, New York | | (315) 267-2216 | 13676 | +----------------------------------+----------------------------------+ | Ignored domains: bestbiz.net, pop.net, hotmail.com, aibusiness.com | | vdi.net, usa.net, tpnet.pl, myremarq.com | | netscape.net, excite.com, bigfoot.com, public.com | | com.tw, eranet.net, yahoo.com, success.net | | mailcity.com, net.tw, twac.com, netcenter.com | | techie.com, msn.com | +---------------------------------------------------------------------+

2 1

unterminated {-
by George Russell 21 Sep '01

21 Sep '01

Seems to me it would make more sense for the message XXXX.hs:214: unterminated `{-' message to tell me where the {- is, rather than where the EOF is.

1 0

RE: Alternative Design for Finalisation
by Simon Marlow 21 Sep '01

21 Sep '01

> OK, you are saying that the ForeignObj# is a representation > of a 'Ptr a', > but in a way such that the compiler can't optimise away the > box. Is that > correct? Yes, that's right. > Could ForeignPtr be generalised so that its ForeignObj# could > represent any type, rather than just a Ptr? Unfortunately no. The ForeignObj# type is unlifted, which means it doesn't have _|_ as a possible value. The same restrictions as for unboxed types apply: you can't instantiate a polymorphic type variable with ForeignObj#, or indeed any primitive type. Cheers, Simon

1 0

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 21 Sep '01

21 Sep '01

At 2001-09-21 01:39, Manuel M. T. Chakravarty wrote: >That's ok. All I am saying is that the FFI doesn't ensure >any concistency between the Haskell and the C type. Well it can't can it? There's no type information in object-code symbols (unless you use C++ identifier mangling, which Haskell doesn't). -- Ashley Yakeley, Seattle WA

2 1

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 21 Sep '01

21 Sep '01

At 2001-09-20 19:32, Manuel M. T. Chakravarty wrote: >What I meant with the remark that you quote is that if you >would use > > foreign import foo :: Ptr Int -> IO Float > >with > > float foo (float *x) > { > return *x; > } > >the system will not complain, but your program may dump >core. What if the C looked like this: float foo (int *x) { return *x; } ...? -- Ashley Yakeley, Seattle WA

2 1

Re: Student Programming Projects
by Albert Lai 21 Sep '01

21 Sep '01

Consider goal-directed theorem prover (or proof checker). Two existing samples are in Lawrence Paulson's ML for the Working Programmer, and yours truly's http://www.cs.utoronto.ca/~trebla/fp/prover/index.html The advantage of mine is it illustrates monads. The advantage of Paulson's is it doesn't scare people with monads :) and it includes a substitution library (yet another monad, but shhh) for use in first-order logic.

1 0

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 21 Sep '01

21 Sep '01

At 2001-09-20 06:55, Manuel M. T. Chakravarty wrote: >The FFI does not ensure any type consistency between the >arguments to `Ptr'/`ForeignPtr' and the corresponding C >types. I've been using 'Ptr Word8' with newArray to pass lists of bytes to C functions. They appear as unsigned char arrays in the C function. Is this wrong, or not guaranteed? -- Ashley Yakeley, Seattle WA

2 1

RE: Alternative Design for Finalisation
by Ashley Yakeley 21 Sep '01

21 Sep '01

At 2001-09-20 04:56, Simon Marlow wrote: >ForeignPtrs are defined like this > > data ForeignPtr a = ForeignPtr ForeignObj# > >where ForeignObj# is a *boxed* address, it corresponds to a real heap >object. The heap object is primitive from the point of view of the >compiler - it can't be optimised away. So it works to attach a >finalizer to the ForeignObj# (but not to the ForeignPtr!). OK, you are saying that the ForeignObj# is a representation of a 'Ptr a', but in a way such that the compiler can't optimise away the box. Is that correct? Could ForeignPtr be generalised so that its ForeignObj# could represent any type, rather than just a Ptr? -- Ashley Yakeley, Seattle WA

1 0