- Haskell - Haskell.org

Re: Wish list: expanded defaulting, dependent types, reflection
by Mike Gunter 29 Sep '01

29 Sep '01

> You know about fundeps, right? This may help: > > class Add a b c | a b -> c where {add :: a -> b -> c;}; Indeed, it's quite hopeless without fundeps. They don't solve with the ambiguous-literal problem, though. mike

1 0

Re: Wish list: expanded defaulting, dependent types, reflection
by Ashley Yakeley 29 Sep '01

29 Sep '01

At 2001-09-29 09:11, Mike Gunter wrote: > class Add a b c where add :: a -> b -> c > >There does not seem to be a way to do everything I'd like in GHC even >in its most permissive mode (I'm using "-fallow-overlapping-instances >-fallow-undecidable-instances".) In particular, I'd like to use bare You know about fundeps, right? This may help: class Add a b c | a b -> c where {add :: a -> b -> c;}; -- Ashley Yakeley, Seattle WA

1 0

Wish list: expanded defaulting, dependent types, reflection
by Mike Gunter 29 Sep '01

29 Sep '01

I would like define arithmetic operations with heterogenous types. (I'm interested in sized types for an embedded hardware description language.) One approach would be to use multiple-parameter type classes; e.g: class Add a b c where add :: a -> b -> c There does not seem to be a way to do everything I'd like in GHC even in its most permissive mode (I'm using "-fallow-overlapping-instances -fallow-undecidable-instances".) In particular, I'd like to use bare integer literals together with values of the types I define. The more straightforward approach, using the standard fromInteger definition, runs up against the limitation of default mechanism to standard classes. What's the purpose of this limitation? Any chance GHC could optionally relax it? (Absent an implementation it's hard to be sure this is sufficient for my purposes.) Another scheme is to give GHC the -fno-implicit-prelude option and redefine fromInteger to return a type, say, ConstInteger, for which all of the operations have an instance. This seems to work for operations I am defining but makes it impossible to use bare literals as arguments to functions defined elsewhere (which are expecting an Int/Integer/Double/...) I think (I have no experience here!) I'd be happiest if GHC implemented dependent types. That would seem to solve this problem and others. Even if this broke most Haskell 98 code, I think I'd turn on the -fdependent-types option. A completely different approach would be to use the standard Haskell numeric classes (with homogeneous types) with the size-constraint system implemented in my Haskell code. This approach would be more attractive if my Haskell implementation provided a small amount of reflective capability. In particular, I would want to generate error messages with the source file, line number, and function. GHC does a very good job of reporting this information for type errors. Could it be made available to the program being compiled? (I could also use such a mechanism to make it possible to give sensible names to entities (wires, gate instances) in the output generated from the HDL.) So, my wish list is (1) dependent types, or (2) remove the restriction that default only works on standard classes and (3) a small amount of reflection (file,line number,function name) or (4) (best) a way to do what I need without (1)-(3). Thanks. mike

1 0

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

28 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.

2 1

RE: Haskell report (August release)
by Simon Peyton-Jones 28 Sep '01

28 Sep '01

A reasonable suggestion, but I'm afraid I don't want to make structural changes to the Report. Simon | -----Original Message----- | From: Mark Tullsen [mailto:mtullsen@cse.ogi.edu] | Sent: 27 September 2001 20:35 | To: Simon Peyton-Jones | Cc: haskell(a)haskell.org | Subject: Re: Haskell report (August release) | | | Simon, | | Here's a minor quibble with the organization of the Report | and Library, not with the content. Sorry if this has been | brought up before. | | In section 4.3.3, Derived Instances, of the Report there is | | The only classes in the Prelude for which derived instances are | allowed are Eq, Ord, Enum, Bounded, Show, and Read, all mentioned in | Figure 5, ... Classes defined by the standard libraries may also be | derivable. | | In the introduction to the Library Report there is | | Classes defined in libraries may be derivable. This report includes | the derivation of such classes when appropriate. | | Now, unless I missed something, the only class in the Library | Report which is derivable is Ix. | | I would argue for bringing the Ix class into the Report for | these reasons | | * One does not have to search through the Library Report to | determine | what is derivable. | | * I think one would expect that the Libraries contain stuff | that could be | implemented in Haskell by the user. Until Haskell has | the ability | to allow for user-defined derivable classes, Ix cannot be | defined by the user. | | - Mark |

1 0

Happy 1.11 InstallShield released
by Reuben Thomas 28 Sep '01

28 Sep '01

A Happy 1.11 InstallShield is now available (including the post hoc bug fix!). -- http://sc3d.org/rrt/ | competent, a. underpromoted

1 0

Final CFP: FOOL 9 -- Foundations of Object-Oriented Languages
by Martin Odersky 28 Sep '01

28 Sep '01

FINAL CALL FOR PAPERS The Ninth International Workshop on Foundations of Object-Oriented Languages FOOL 9 Sponsored by ACM SIGPLAN January 19, 2002 Portland, Oregon, USA Following POPL '02 http://www.cs.williams.edu/~kim/FOOL/fool9.html Deadlines Submissions: October 12, 2001 Notifications: November 12, 2001 Final versions: December 10, 2001 The search for sound principles for object-oriented languages has given rise to much work on the theory of programming languages during the past 15 years, leading to a better understanding of the key concepts of object-oriented languages and to important developments in type theory, semantics, and program verification. The FOOL workshops bring together researchers to share new ideas and results in these areas. The next workshop, FOOL 9, will be held in Portland, Oregon, on Saturday January 19, 2002, the day after POPL '02. Submissions for this event are invited in the general area of foundations of object-oriented languages; topics of interest include language semantics, type systems, program analysis and verification, programming calculi, concurrent and distributed languages, and database languages. The main focus in selecting workshop contributions will be the intrinsic interest and timeliness of the work, so authors are encouraged to submit polished descriptions of work in progress as well as papers describing completed projects. A web page will be created and made available as informal electronic conference proceedings. Submission procedure We solicit submissions on original research not previously published or currently submitted for publication elsewhere, in the form of extended abstracts. These extended abstracts should not exceed 5000 words (approximately 10 pages); shorter extended abstracts (e.g., 2000 words) are often sufficient. Submissions should be e-mailed to fool9(a)lampsun1.epfl.ch by Friday, October 12, 2001, using Postscript or PDF. Each submission may be included inline in a message or as a MIME attachment only. We may not be able to consider late submissions, or submissions that do not have a working and attended return e-mail address. (If electronic submission is impossible, please contact the program chair in September.) Receipt of the submissions will be acknowledged by e-mail. Authors should inquire in case a prompt acknowledgment is not received. Correspondence and questions should be sent to fool9(a)lampsun1.epfl.ch Steering Committee Martin Abadi, Bell Labs Kim Bruce, Williams College Luca Cardelli, Microsoft Research Kathleen Fisher, AT&T Labs Benjamin Pierce, University of Pennsylvania (chair) Didier Remy, INRIA Rocquencourt Program Chair Martin Odersky, Swiss Federal Institute of Technology Lausanne, fool9(a)lampsun1.epfl.ch Program Committee Viviana Bono, Universita di Torino Craig Chambers, University of Washington Erik Ernst, University of Aalborg Giorgio Ghelli, University of Pisa Atsushi Igarashi, University of Tokyo Shriram Krishnamurthi, Brown University Clemens Szyperski, Microsoft Research Jan Vitek, Purdue University

1 0

> Re: Joy and Concatenative Programming
by Manfred von Thun 28 Sep '01

28 Sep '01

> From: Wolfgang Jeltsch <wolfgang(a)jeltsch.net> > Date: Wed, 26 Sep 2001 18:57:16 +0200 [..] > SAJ told that Joy is functional. If I unterstood him correctly, he said > functional languages eliminated state and Joy IN ADDITION TO THIS eliminated > variables and environments. So there must be a important difference to > Forth because AFAIK Forth didn't eliminate state. Of course the particular > idea of transforming stacks is not new. If you like equations of the kind started by Wirth: Joy = Forth - state - lots_of_other_good_things + (nested) lists + GC + program_quotation + combinators. Joy = (pure) Lisp/Scheme - lambda_abstraction - function_application + program_quotation + function_composition. Comparisons with ML, Miranda and Haskell are not so useful because Joy is weakly and dynmically typed. http://www.latrobe.edu.au/philosophy/phimvt/joy.html - Manfred

1 0

Re: 0-based versus 1-based
by Ashley Yakeley 27 Sep '01

27 Sep '01

At 2001-09-27 15:16, Tom Pledger wrote: >Just as a matter of idle curiosity, is there a particular reason for >tuples starting at element 1 (fst) whereas lists start at element 0? 'fst' (first) is an ordinal. It actually corresponds to the cardinal 'zero'. The element at zero is the first element. The element at 37 is the 38th element. It's quite consistent. -- Ashley Yakeley, Seattle WA

2 1

0-based versus 1-based
by Tom Pledger 27 Sep '01

27 Sep '01

Just as a matter of idle curiosity, is there a particular reason for tuples starting at element 1 (fst) whereas lists start at element 0? fst ('x', 'y') --> 'x' "xy" !! 1 --> 'y'

2 1