ANNOUNCE: Happy version 0.7 (alpha)
A N N O U N C E M E N T
Happy v0.7 (alpha)
The LALR(1) Parser Generator for Haskell
This is the first public release of our parser generator system for
Haskell, called Happy (a dyslexic acronym for 'A Yacc-like Haskell
Parser generator'). Happy is written in Haskell, uses a parser
generated by itself, and can be compiled using ghc, hbc or gofer.
Happy cannot currently be compiled using Yale Haskell because of its
lack of support for stream IO (Happy uses an implementation of monadic
IO built on top of stream IO, but this should change when the Haskell
1.3 standard has been agreed on and implemented).
Happy can be obtained by anonymous ftp from
ftp.dcs.gla.ac.uk 130.209.240.50
in the directory
pub/haskell/happy
Happy is covered by the GNU General Public License, see the
documentation for details.
Please send any bug reports, comments, and money to
{andy,simonm}@dcs.gla.ac.uk.
This is the introduction from the manual:
---
Happy is a parser generator system for Haskell, similar to the tool
`yacc' for C. Like `yacc', it takes a file containing an annotated
BNF specification of a grammar and produces a Haskell module
containing a parser for the grammar.
Happy is flexible; unlike `yacc', you can have several Happy parsers
in the same program. Happy can work in conjunction with a lexical
analyser supplied by the user (either hand-written or generated by
another program), or it can parse a stream of characters directly
(but this isn't practical in most cases). In a future version we hope
to include a lexical analyser generator with Happy as a single
package.
Happy can currently generate three types of parser from a given
grammar, the intention being that we can experiment with different
kinds of functional code to see which is the best, and compiler
writers can use the different types of parser to tune their
compilers. The types of parser supported are:
1. `standard' Haskell (should work with any compiler that compiles
the Haskell language).
2. standard Haskell using arrays (this is not the default because we
have found this generates slower parsers than 1).
3. Haskell with ghc (Glasgow Haskell) extensions. This is a slighty
faster option than 1 for Glasgow Haskell users.
Parser type 1 will also work with Gofer, as will parser type 2 given a
suitable implementation of arrays.
-
Re: ANNOUNCE: Happy version 0.7 (alpha)
For all those having problems compiling Happy with ghc version 0.16, the solution is to compile the module ProduceCode.lhs without optimisation. A small patch to the Makefile can be found on ftp.dcs.gla.ac.uk in the file pub/haskell/happy/happy-0.7-0.7.1.patch. Also, we didn't make it clear that you need gunzip to uncompress the source. gunzip can be obtained from several ftp sites, the main one is prep.ai.mit.edu in pub/gnu. Simon
Re: A new view of guards
John Lauchbury writes: Simon's syntax also provides a viable alternative to @ patterns f x @ (Just 3) y = e f x y | Just 3 - x = e though it is slightly less convenient in certain contrived examples (but very much less ad hoc). Reversing this idea, we have another syntax for Simon's generalised guards: f x y | x@(Just 3) = e This to me is nicer than re-using - in a different setting. Ok, it means more than a one-symbol change to the grammar. Comments? Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Happy for Haskell 1.4
I've put a new version of Happy up for ftp on ftp://ftp.dcs.gla.ac.uk/pub/haskell/happy/happy-1.2alpha.tar.gz This is a pre-release of version 1.2, and is strictly hackers-only and documentation-pending. I've included a brief summary of the changes below. The source tree is designed to plug into the Glasgow Haskell compilation system (i.e. to use the configuration stuff from ghc-2.04), but I've included a standalone Makefile in Makefile.standalone for those who'd like to compile it separately. The documentation is still out of date, but there are a couple of examples to illustrate the new features: check examples/ErrorTest.ly for a demonstration of the error recovery and examples/monadtest.ly for the new monad stuff (and how to keep track of line numbers without %newline). I'd be grateful for any feedback, and with any luck I'll be able to get a proper release out soon. Cheers, Simon - Changes from version 0.9a to version 1.2 * Supports Haskell 1.4 * Lots of bugs fixed * Performance: the parser generator is at least 20% faster, and generated parsers should be faster due to the replacement of a data type with a newtype. * Simple error recovery: designed to be enough to implement the Haskell layout rule. * Revamped monad support: the monad can now be threaded through the lexer, enabling passing of state between the parser and the lexer (handy for the Haskell layout rule), and consistent error handling. * The %newline feature is removed, the same effect can be achieved using the new monad support. -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
ANNOUNCE: The Glasgow Haskell Compiler, version 2.07
The Glasgow Haskell Compiler -- version 2.07
==
We are pleased to announce a new release of the Glasgow Haskell
Compiler (GHC), version 2.07. Source distribution is freely available
via the World-Wide Web and through anon. FTP; details below.
Haskell is "the" standard lazy functional programming language; the
current language version is 1.4, agreed in April, 1997. Haskell
related information is available from the Haskell home page at
http://haskell.org/
+ What's new
=
Release 2.07 is a bug-fix release. It addresses all of the
bootstrapping/building/installation problems in 2.06.
This release is a prelude to our next binary release, which should
happen shortly. If all goes well, the next release will be a full
binary release consisting of 2.07 + essential bug fixes.
As a side effect of the minimal testing we do on source releases, I've
put together binary bundles for sparc-sun-solaris2 and
i386-unknown-freebsd, which are on the ftp site in the usual place.
They are pretty much untested, so "use at your own risk" (as with all
side effects :-).
+ Mailing lists
We run mailing lists for GHC users and bug reports; to subscribe, send
mail to [EMAIL PROTECTED]; the msg body should be:
subscribe glasgow-haskell-which Your Name [EMAIL PROTECTED]
Please send bug reports about GHC to [EMAIL PROTECTED] ; GHC
users hang out on [EMAIL PROTECTED]
+ On-line GHC-related resources
Relevant URLs on the World-Wide Web:
GHC home page http://www.dcs.gla.ac.uk/fp/software/ghc/
Haskell home page http://haskell.org/
Glasgow FP group page http://www.dcs.gla.ac.uk/fp/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/Department/Staff/mpj/faq.html
+ How to get it
The easy way is to go to the WWW GHC distribution page, which should
be self-explanatory:
ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/README.html
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release. NB:
preserve modification times when un-tarring the files (no `m' option
for tar, please)!
+ System requirements
==
To compile up this source-only release, you need a machine with 16+MB
memory, GNU C (`gcc'), `perl' plus a version of GHC installed (either
version 0.29 or 2.02 onwards). We have seen GHC work on these platforms:
* alpha-dec-osf2
* hppa1.1-hp-hpux{9,10}
* sparc-sun-{sunos4,solaris2}
* mips-sgi-irix{5,6}
* i386-unknown-{linux,solaris2,freebsd,cygwin32}.
* {rs6000,powerpc}-ibm-aix
Similar platforms should work with minimal hacking effort. The installer's
guide included in distribution gives a complete run-down of what-ports-work;
an on-line version can be found at
http://www.dcs.gla.ac.uk/fp/software/ghc/ghc-doc/install-guide.html
EOF
ANNOUNCE: ghc version 2.08
The Glasgow Haskell Compiler -- version 2.08
==
We are pleased to announce a new release of the Glasgow Haskell
Compiler (GHC), version 2.08. Source distribution is freely available
via the World-Wide Web and through anon. FTP; details below.
Haskell is "the" standard lazy functional programming language; the
current language version is 1.4, agreed in April, 1997. Haskell
related information is available from the Haskell home page at
http://haskell.org/
+ What's new
=
Release 2.08 is a bug-fix release. It addresses some of the bugs
discovered in 2.07. A detailed list of changes can be found in the
Users' Guide.
We've made standard binary releases for the following platforms:
sparc-sun-solaris2
i386-unknown-linux
i386-unknown-freebsd
i386-unknown-solaris2
check the web page as usual for downloading instructions.
+ Mailing lists
We run mailing lists for GHC users and bug reports; to subscribe, send
mail to [EMAIL PROTECTED]; the msg body should be:
subscribe glasgow-haskell-which Your Name [EMAIL PROTECTED]
Please send bug reports about GHC to [EMAIL PROTECTED] ; GHC
users hang out on [EMAIL PROTECTED]
+ On-line GHC-related resources
Relevant URLs on the World-Wide Web:
GHC home page http://www.dcs.gla.ac.uk/fp/software/ghc/
Haskell home page http://haskell.org/
Glasgow FP group page http://www.dcs.gla.ac.uk/fp/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/Department/Staff/mpj/faq.html
+ How to get it
The easy way is to go to the WWW GHC distribution page, which should
be self-explanatory:
ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/README.html
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release. NB:
preserve modification times when un-tarring the files (no `m' option
for tar, please)!
+ System requirements
==
To compile up this source-only release, you need a machine with 16+MB
memory, GNU C (`gcc'), `perl' plus a version of GHC installed (either
version 0.29 or 2.02 onwards). We have seen GHC work on these platforms:
* alpha-dec-osf2
* hppa1.1-hp-hpux{9,10}
* sparc-sun-{sunos4,solaris2}
* mips-sgi-irix{5,6}
* i386-unknown-{linux,solaris2,freebsd,cygwin32}.
* {rs6000,powerpc}-ibm-aix
Similar platforms should work with minimal hacking effort. The installer's
guide included in distribution gives a complete run-down of what-ports-work;
an on-line version can be found at
http://www.dcs.gla.ac.uk/fp/software/ghc/ghc-doc/install-guide.html
EOF
Re: Call for parsers
l.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne -- -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
ANNOUNCE: The Glasgow Haskell Compiler, Version 2.09
The Glasgow Haskell Compiler -- version 2.09
==
We are pleased to announce a new release of the Glasgow Haskell
Compiler (GHC), version 2.09. Source distribution is freely available
via the World-Wide Web and through anon. FTP; details below.
Haskell is "the" standard lazy functional programming language; the
current language version is 1.4, agreed in April, 1997. Haskell
related information is available from the Haskell home page at
http://haskell.org/
+ What's new
=
Release 2.09 contains some library changes that may break programs
using glasgow extensions. The main points:
* PrimIO has been removed, replaced by IO in all places
(including the type of C calls).
* The types of IO and ST have changed, to make them more
efficient. This won't bite you unless you go digging
around in the IO or ST monads, which you shouldn't...
* Several extension libraries have been moved to be
compatible with Hugs. See
ftp://haskell.org/pub/reid/libs971028/libs.html
for the definitions of the new libraries.
* Several of the interfaces exported by GlaExts are deprecated,
as they have been moved into common libraries (ST for instance).
GlaExts will eventually contain only extensions that are
exclusive to GHC.
We've also fixed several bugs, one space leak, and added better
handling of warnings (-W, -Wall and -Wnot flags). As usual, see the
release notes in the Users' Guide for the full story.
We have a new set of Web pages at http://www.dcs.gla.ac.uk/fp/software/ghc/,
there will probably be a few glitches for a while so bear with us.
Binaries: I've made binaries for i386-unknown-{linux,solaris2,freebsd}
and sparc-sun-solaris2. More binaries may appear later - watch the
web page.
+ Mailing lists
We run mailing lists for GHC users and bug reports; to subscribe, send
mail to [EMAIL PROTECTED]; the msg body should be:
subscribe glasgow-haskell-which Your Name [EMAIL PROTECTED]
Please send bug reports about GHC to [EMAIL PROTECTED] ; GHC
users hang out on [EMAIL PROTECTED]
+ On-line GHC-related resources
Relevant URLs on the World-Wide Web:
GHC home page http://www.dcs.gla.ac.uk/fp/software/ghc/
Haskell home page http://haskell.org/
Glasgow FP group page http://www.dcs.gla.ac.uk/fp/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/Department/Staff/mpj/faq.html
+ How to get it
The easy way is to go to the WWW GHC download page, which has pointers
to all the released binary and source distributions:
http://www.dcs.gla.ac.uk/fp/software/ghc/download.html
Alternatively, you can do it the low-level way by ftp, from
ftp.dcs.gla.ac.uk in the directory pub/haskell/glasgow/.
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release. NB:
preserve modification times when un-tarring the files (no `m' option
for tar, please)!
+ System requirements
==
To compile up this source-only release, you need a machine with 16+MB
memory, GNU C (`gcc'), `perl' plus a version of GHC installed (either
version 0.29 or 2.02 onwards). We have seen GHC work on these platforms:
* alpha-dec-osf2
* hppa1.1-hp-hpux{9,10}
* sparc-sun-{sunos4,solaris2}
* mips-sgi-irix{5,6}
* i386-unknown-{linux,solaris2,freebsd,cygwin32}.
* {rs6000,powerpc}-ibm-aix
Similar platforms should work with minimal hacking effort. The installer's
guide included in distribution gives a complete run-down of what-ports-work;
an on-line version can be found at
http://www.dcs.gla.ac.uk/fp/software/ghc/ghc-doc/install-guide.html
EOF
ANNOUNCE: The Glasgow Haskell Compiler, Version 2.10
The Glasgow Haskell Compiler -- version 2.10
==
We are pleased to announce a new release of the Glasgow Haskell
Compiler (GHC), version 2.10. Source and Binary distribution is freely
available via the World-Wide Web and through anon. FTP; details below.
Haskell is "the" standard lazy functional programming language; the
current language version is 1.4, agreed in April, 1997. Haskell
related information is available from the Haskell home page at
http://haskell.org/
+ What's new
=
Release 2.10 is a full binary release (at least for the platforms we
have access to, other builds are solicited). We hope this will be a
solid release - barring any unforseen problems this should be the end
of the 2.xx line.
Major new things in this release:
* better -fwarn-overlapping-patterns checking,
* Happy is no longer included in binary distributions:
we're making separate Happy binaries, see
ftp://ftp.dcs.gla.ac.uk/pub/haskell/happy
* lots of bug fixes.
As usual see the release notes for the full story.
The next release will likely be GHC 3.00, containing mult-parameter
type classes amongst other things. As of the next release, we will no
longer support building with GHC 0.29.
Merry Christmas and a Happy New Year from the GHC Team!
+ Mailing lists
We run mailing lists for GHC users and bug reports; to subscribe, send
mail to [EMAIL PROTECTED]; the msg body should be:
subscribe glasgow-haskell-which Your Name [EMAIL PROTECTED]
Please send bug reports about GHC to [EMAIL PROTECTED] ; GHC
users hang out on [EMAIL PROTECTED]
+ On-line GHC-related resources
Relevant URLs on the World-Wide Web:
GHC home page http://www.dcs.gla.ac.uk/fp/software/ghc/
Haskell home page http://haskell.org/
Glasgow FP group page http://www.dcs.gla.ac.uk/fp/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/Department/Staff/mpj/faq.html
+ How to get it
The easy way is to go to the WWW page, which should be
self-explanatory:
http://www.dcs.gla.ac.uk/fp/software/ghc/
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release. NB:
preserve modification times when un-tarring the files (no `m' option
for tar, please)!
+ System requirements
==
To compile up this source-only release, you need a machine with 16+MB
memory, GNU C (`gcc'), `perl' plus a version of GHC installed (either
version 0.29 or 2.02 onwards). We have seen GHC work on these platforms:
* alpha-dec-osf2
* hppa1.1-hp-hpux{9,10}
* sparc-sun-{sunos4,solaris2}
* mips-sgi-irix{5,6}
* i386-unknown-{linux,solaris2,freebsd,cygwin32}.
* {rs6000,powerpc}-ibm-aix
Similar platforms should work with minimal hacking effort. The installer's
guide included in distribution gives a complete run-down of what-ports-work;
an on-line version can be found at
http://www.dcs.gla.ac.uk/fp/software/ghc/ghc-doc/install-guide.html
EOF
ANNOUNCE: Happy Version 1.5
Happy 1.5 The LALR(1) Parser Generator for Haskell This is the nth public release of the parser generator system for Haskell, called Happy (a dyslexic acronym for 'A Yacc-like Haskell Parser generator'). What's new in Happy 1.5 (vs. Happy 0.9) * Monadic Lexical analysis * Simple Error recovery * Compiles with Haskell 1.3+ compilers * so many bugfixes and small additions that I can't remember them all. Happy is available in source form, which can be compiled with GHC version 0.29 or 2.xx, and we also provide binaries for various architectures. All available from: ftp://ftp.dcs.gla.ac.uk/pub/haskell/happy There is a Happy parser for Haskell currenly under construction - for a snapshot of the code see http://www.dcs.gla.ac.uk/~simonm/hsparse.tar.gz To keep updated about the current status of Happy, you can read its World Wide Web page: http://www.dcs.gla.ac.uk/fp/software/happy.html Please send any bug reports and comments to [EMAIL PROTECTED] Merry Christmas!
Re: Binary files in Haskell
Timothy Robin BARBOUR [EMAIL PROTECTED] writes: There is another way one might proceed. Why not just use a memory-mapped file (mmap) to make the data persistent in-place ? This would be a way of getting efficient persistence of (almost) any Haskell data structure without any code-writing and without any flattening. There are a few difficulties here, but it may well be feasible. The problems are: If I understand this right, you're suggesting essentially dumping out part of the Haskell heap to a file. Assuming the data you want to dump out is closed (i.e. has no external references) and is fully evaluated, there are still some problems remaining: - The data is location-dependent, and the exact location the data was originally resident at might not be available at load-time, so it would have to be relocated. - Heap-resident data in GHC refers (by address) to the code of the program itself, and to parts of the run-time system. You'd have to do some kind of dynamic linking to be able to load data back again. - The format of heap-resident data varies depending on things like profiling, so you wouldn't be able (for instance) to load data generated by a profiled program into one that isn't. So, you could avoid these problems by always loading the data at the same address in memory, and only using one program to save/load data. If you recompiled the program, you'd have to regenerate the persistent store. This seems overly restrictive, it might be simpler to just use the Native or Binary classes. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
ANNOUNCE: GHC Version 3.01
The Glasgow Haskell Compiler -- version 3.01
==
We are pleased to announce a new release of the Glasgow Haskell
Compiler (GHC), version 3.01. The source distribution is freely
available via the World-Wide Web and through anon. FTP; details below.
Haskell is "the" standard lazy functional programming language; the
current language version is 1.4, agreed in April, 1997. Haskell
related information is available from the Haskell home page at
http://haskell.org/
+ What's new
=
GHC 3.01 is a source-only release. Major news items:
* Lots of bug-fixes for the mult-parameter type class support.
* Re-organisation of libraries, and hslibs nuked. (see the
release notes/documentation for the full story).
* The User's Guide is now in SGML, and the literate tools are
no longer required to format any of the documentation in the
tree, hence we removed them from the distribution.
+ Mailing lists
We run mailing lists for GHC users and bug reports; to subscribe, send
mail to [EMAIL PROTECTED]; the msg body should be:
subscribe glasgow-haskell-which Your Name [EMAIL PROTECTED]
Please send bug reports about GHC to [EMAIL PROTECTED] ; GHC
users hang out on [EMAIL PROTECTED]
+ On-line GHC-related resources
Relevant URLs on the World-Wide Web:
GHC home page http://www.dcs.gla.ac.uk/fp/software/ghc/
Haskell home page http://haskell.org/
Glasgow FP group page http://www.dcs.gla.ac.uk/fp/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/Department/Staff/mpj/faq.html
+ How to get it
The easy way is to go to the WWW page, which should be
self-explanatory:
http://www.dcs.gla.ac.uk/fp/software/ghc/
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release. NB:
preserve modification times when un-tarring the files (no `m' option
for tar, please)!
+ System requirements
==
To compile up this source-only release, you need a machine with 16+MB
memory, GNU C (`gcc'), `perl' plus a version of GHC installed (version
2.10 at least). We have seen GHC work on these platforms:
* alpha-dec-osf{2,3}
* hppa1.1-hp-hpux{9,10}
* sparc-sun-{sunos4,solaris2}
* mips-sgi-irix{5,6}
* i386-unknown-{linux,solaris2,freebsd,cygwin32}.
* {rs6000,powerpc}-ibm-aix
Similar platforms should work with minimal hacking effort. The installer's
guide included in distribution gives a complete run-down of what-ports-work;
an on-line version can be found at
http://www.dcs.gla.ac.uk/fp/software/ghc/3.01/installation_guide/installing_toc.html
EOF
Re: Mixing guarded caf declaration with unguarded caf declaration
Graeme Moss [EMAIL PROTECTED] writes: Is there anything wrong with the following program? test :: Bool test | True = True test = False main :: IO () main = print test (Apart from it's apparent uselessness. :-) ghc and hbc reject it on grounds of multiple/conflicting definitions, but Hugs and nhc accept it. I think ghc and hbc are correct here. The two bindings for 'test' are pattern bindings (according to the syntax from the report), and hence constitute two separate declarations of the same variable, which is illegal. However, test | True = True | otherwise = False is of course fine. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
ANNOUNCE: GHC Version 3.02
The Glasgow Haskell Compiler -- version 3.02
==
We are pleased to announce a new release of the Glasgow Haskell
Compiler (GHC), version 3.02. The source distribution is freely
available via the World-Wide Web and through anon. FTP; details below.
Haskell is "the" standard lazy functional programming language; the
current language version is 1.4, agreed in April, 1997. Haskell
related information is available from the Haskell home page at
http://haskell.org/
+ What's new
=
GHC 3.02 is a source-only release. Major news items:
* A new specialiser,
* A new unsafeCoerce# primitive.
* A NOINLINE pragma.
* Many bugs fixed, including several performance-related ones,
GHC 3.02 produces the fastest code since 0.29, but there's still
plenty of tuning to do.
+ Mailing lists
We run mailing lists for GHC users and bug reports; to subscribe, send
mail to [EMAIL PROTECTED]; the msg body should be:
subscribe glasgow-haskell-which Your Name [EMAIL PROTECTED]
Please send bug reports about GHC to [EMAIL PROTECTED] ; GHC
users hang out on [EMAIL PROTECTED]
+ On-line GHC-related resources
Relevant URLs on the World-Wide Web:
GHC home page http://www.dcs.gla.ac.uk/fp/software/ghc/
Haskell home page http://haskell.org/
Glasgow FP group page http://www.dcs.gla.ac.uk/fp/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/Department/Staff/mpj/faq.html
+ How to get it
The easy way is to go to the WWW page, which should be
self-explanatory:
http://www.dcs.gla.ac.uk/fp/software/ghc/
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release. NB:
preserve modification times when un-tarring the files (no `m' option
for tar, please)!
+ System requirements
==
To compile up this source-only release, you need a machine with 16+MB
memory, GNU C (`gcc'), `perl' plus a version of GHC installed (version
2.10 at least). We have seen GHC work on these platforms:
* alpha-dec-osf{2,3}
* hppa1.1-hp-hpux{9,10}
* sparc-sun-{sunos4,solaris2}
* mips-sgi-irix{5,6}
* i386-unknown-{linux,solaris2,freebsd,cygwin32}.
* {rs6000,powerpc}-ibm-aix
Similar platforms should work with minimal hacking effort. The installer's
guide included in distribution gives a complete run-down of what-ports-work;
an on-line version can be found at
http://www.dcs.gla.ac.uk/fp/software/ghc/3.02/installation_guide/installing_toc.html
EOF
Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)
Fergus Henderson [EMAIL PROTECTED] writes: On the Standard Haskell site, Alastair Reid wrote: 1) Fixity declarations usually look like this: infixl 6 +, - but you can omit the precedence digit and write this instead: infixl +, - The programmer who uses this avoids having to type 2 characters. The programmers who'sre reading this code has to learn that the precedence digit can be omitted (I didn't believe it when I first saw it) and then look up the default precedence in the report. I think it is harder to understand programs that use this shortcut and that it should be removed. I don't think it's harder. Even if the number is specified explicitly, I would *still* have to look up the precedence table in the report, or at least grep the source for the standard prelude, because I don't know what the precedence of the other operators is. I think you're missing the point. Omitting the precedence digit is important because it allows the programmer to avoid making a decision about something he doesn't really care about. Most of the time, you're not interested in the relative precedence of `thenP` vs. (+), since it doesn't make any sense to mix them. If you really *want* a precedence of 9 (or whatever the default is), one would never dream of leaving it out of the declaration. ObStandardHaskellProposal: relax the restriction on precedences being in the range 0-9. Change the precedences of the Prelude operators from n to n*100. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Re: some Standard Haskell issues
[EMAIL PROTECTED] writes: * import and infix declarations anywhere in a module? I am against this proposal. Collecting all such declarations at the head of the module is better for human readers. Allowing them anywhere would also complicate and slow down program analysis that only requires module dependencies (eg. Haskell-specific `make' tools). I disagree. - on the first point that it's easier for human readers: surely it makes more sense to put the fixity declaration for an operator next to the definition of the operator itself? And for imports, it could be really handy to put the import declaration for a function next to the use of the function, especially when you're only using the function temporarily (so you don't forget to remove the import later!). In fact, I think it would be nicer to not require import declarations at at all for qualified entities. - on the second point that it's easier for computer readers: what could be simpler than 'look through the whole file and pick out the imports'. Other good reasons for relaxing this restriction: - it would simplify the grammar - parsing is easier Possible drawbacks: - with fixities and imports at the top, it might be possible to resolve infix expressions during parsing. Neither Hugs nor GHC nor nhc do this. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Re: some Standard Haskell issues
"Jeffrey R. Lewis" [EMAIL PROTECTED] writes: Yes, I think it's a fine idea to loosen up the syntax and allow import and infix anywhere. But could someone clarify what the intent is with regards to the scoping of liberally sprinkled imports/infixes? Sorry - we should have made this clear. The idea is that they scope over the entire module. All other kinds of declaration in Haskell have this property, so it's consistent. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Re: some Standard Haskell issues
"Jeffrey R. Lewis" [EMAIL PROTECTED] writes: I thought the if-the-else proposal seemed odd until I followed the link and read the exact proposal. Simon: your if-then-else example on the Standard Haskell page seems at odds with the actual proposal (e.g. isn't the point that the `else' itself needn't be indented?) That's right - there seems to be a slight bug in Simon's example on the web page, which just goes to show what a sticky issue layout is. I think the correct example is do putStr "hello" if then putStr "goodbye" else do putStr "carry" putStr "on" the point is that the 'else' needn't be indented. This would be possible too: do print n putStr " green bottle" if n 1 then putStr "s" else return () putStr " sitting on a wall" Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Re: Int vs Integer
[EMAIL PROTECTED] (Carl R. Witty) writes:
Sigbjorn Finne [EMAIL PROTECTED] writes:
Clearly there's a range of optimisations possible here; using an
efficiently implemented bignum library being one (not irrelevant) way
to improve matters. Changing the representation of Integer is another,
distinguishing at the Haskell level between ones that fit in a machine
word and those that don't. We plan to use such a representation for
GHC/Hugs.
I'm glad to hear it; do you have anything written on exactly how you
this will work?
The plan is to use something like
data Integer = Small Int# | Big { ... }
where '...' is the GMP representation. You then need a full set of
overflow-detecting primitive operations on Int. I've done a few
experiments with using gcc's 'long long' type to implement these
portably (well, portably across 32-bit architectures...), and it seems
possible.
The common case of applying a dyadic operation to small Integers would
then be pretty close in performance to that of Int (a couple of
indirect jumps, and a test/branch for the overflow detection, to be
precise).
Cheers,
Simon
--
Simon Marlow [EMAIL PROTECTED]
University of Glasgow http://www.dcs.gla.ac.uk/~simonm/
finger for PGP public key
ANNOUNCE: GHC version 4.00
The Glasgow Haskell Compiler -- version 4.00
==
We are pleased to announce a new release of the Glasgow Haskell
Compiler (GHC), version 4.00. The source distribution is freely
available via the World-Wide Web and through anon. FTP; details below.
Haskell is "the" standard lazy functional programming language; the
current language version is 1.4, agreed in April, 1997. Haskell
related information is available from the Haskell home page at
http://haskell.org/
+ What's new
=
GHC 4.00 is the culmination of several months' work - we've rewritten
the entire runtime system and major chunks of the compiler. There are
too many changes to mention here, so please take a look at the release
notes:
http://www.dcs.gla.ac.uk/fp/software/ghc/4.00/users_guide/users_guide-1.html#ss1.4
+ Mailing lists
We run mailing lists for GHC users and bug reports; to subscribe, send
mail to [EMAIL PROTECTED]; the msg body should be:
subscribe glasgow-haskell-which Your Name [EMAIL PROTECTED]
Please send bug reports about GHC to [EMAIL PROTECTED] ; GHC
users hang out on [EMAIL PROTECTED]
+ On-line GHC-related resources
Relevant URLs on the World-Wide Web:
GHC home page http://www.dcs.gla.ac.uk/fp/software/ghc/
Haskell home page http://haskell.org/
Glasgow FP group page http://www.dcs.gla.ac.uk/fp/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/Department/Staff/mpj/faq.html
+ How to get it
The easy way is to go to the WWW page, which should be
self-explanatory:
http://www.dcs.gla.ac.uk/fp/software/ghc/
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release. NB:
preserve modification times when un-tarring the files (no `m' option
for tar, please)!
+ System requirements
==
To compile up this source-only release, you need a machine with 32+MB
memory, GNU C (`gcc'), `perl' plus a version of GHC installed (version
2.10 at least). This release is known to work on the following platforms:
* i386-unknown-{linux,solaris2,freebsd,cygwin32}
* sparc-sun-{sunos4,solaris2}
Ports to the following platforms should be relatively easy, but
haven't been tested due to lack of time/hardware:
* alpha-dec-osf{2,3}
* hppa1.1-hp-hpux{9,10}
* mips-sgi-irix{5,6}
* {rs6000,powerpc}-ibm-aix
The installer's guide included in distribution gives a complete
run-down of what-ports-work; an on-line version can be found at
http://www.dcs.gla.ac.uk/fp/software/ghc/4.00/installation_guide/installing.html
Re: Haskell 98
Simon Peyton-Jones [EMAIL PROTECTED] writes: Consider the function t :: T a = T a - T a I think that it's far from clear what each of the T's mean! Worse, in Haskell 2 we'll also have t :: T T = T a - T a In (T T) one is class and the other is a type constructor. I'm not convinced by the argument "this allows you to write obfuscated Haskell". After all, Haskell is already a wonderful language for writing obfuscated code; eg. what does the following definition mean f f = f is it a static error (re-use of 'f'), a type error, or a definition of the identity function? (it's the latter). Here's to cleaning up the language, and to more exciting obfuscated Haskell competitions! Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Note from (deputy) maintainer
Haskellers, Can folk please watch who they're replying to when they answer messages on the list. Due to various quirks in the mailing list system at Glasgow, the address [EMAIL PROTECTED] appears in the message headers and tends to make its way into the CC: list of an automatic reply. This results in everyone getting several copies of the same message, and apparently the mail server at Glasgow is already croaking under the strain. So: please make sure you only reply to [EMAIL PROTECTED] in addition to any private addresses. Cheers -- Simon Marlow Microsoft Research Ltd., Cambridge, U.K.
RE: hugs and ghc compatibility and features
I have been reading about the integrated runtime system
between GHC and
Hugs. Now that GHC 4.0 is out, what is the status of the hugs ghc
integration project?
1. Does hugs now support mutually recursive modules?
Initially it'll have limited support for mutually recursive compiled
modules, by stuffing them into a single object file.
2. Does the new GHC support TREX? If yes, how does one enable it?
I'm sorry, I don't know what TREX is. The only thing that springs to mind
is the band with Marc Bolan, but AltaVista thinks it might be a "A
revolutionary new decking lumber". Neither of these seem particularly
relevant to GHC :-)
3. Are the literate modes now compatible? (they weren't before)
I believe Hugs understands the \begin{code}...\end{code} style of literate
programming, if that's what you mean?
4. Does Hugs now support MPTC, Existential types, etc?
Yes, Hugs 1.3c has these features, but there doesn't exist a released
version of Hugs 1.4 with the new typechecker merged in. The latest working
sources can however be obtained using the GHC remote CVS repository, take a
look at
http://www.dcs.gla.ac.uk/fp/software/ghc/cvs-cheat-sheet.html
in the new-rts branch of GHC.
Cheers,
Simon
--
Simon Marlow
Microsoft Research Ltd., Cambridge, U.K.
RE: Plea for Change #2: Tools
Tommy Thorn says: Even when taking the simple example from my previous^2 post ghc -c Add.hs ghc -c Main.hs ghc -o Main Main.o Add.o Actually, you can do this in one: ghc Add.hs Main.hs -o Main we notice that it takes three commands, in the right order, each with a non optional flag. The -o flag is optional, you can say ghc Add.hs Main.hs and the binary ends up in 'a.out'. Granted, the default binary name is a bit weird, but it's traditional :) There is nothing present here that couldn't be deducted directly from the contents of `Main.hs', thus a simple `ghc' (or `ghc Main' assuming my first plea) command should have sufficed. Now granted the three commands above isn't exactly rocket science and anyone with a little exposure to `C' (God forbid) would immediately feel at home. Only, this naive interface only brings the deficiencies of C to the complexity of a type checked module based language. Maintaining dependencies with makefiles is both hairy and error prone. There exists scripts like `ghcmake', but that's only patching a rotten foundation and cracks are quick to surface (try anything non trivial, like using multiple directories). It's quite trivial to extend ghcmake to deal with multiple directories. I don't think there's a fundamental problem here, except for the lack of a fully-featured Haskell IDE, and so far no-one has had the time or motivation to write one (hint :-). Cheers, Simon
RE: Returned mail: haskell@CS.YALE.EDU... aliasing/forwarding l oop broken
I would be great to get to know which address one should use for the Haskell mailing list. Could not somebody please post info about that to that list, as there has been problems with that in the past (haskell.org not working, etc.). The official address for the haskell mailing list is [EMAIL PROTECTED] other addresses, like [EMAIL PROTECTED] and [EMAIL PROTECTED] may or may not work. Please use the address above. You can subscribe/unsubscribe by sending mail to [EMAIL PROTECTED] and reach the mailing list manager (that's me, for the time being) at [EMAIL PROTECTED] Cheers, Simon
RE: lists do not respond
Sergey said: Sorry, i am testing which Haskell list is alive. [EMAIL PROTECTED] returns the mail. So are other *haskell.org lists. ? The mailing lists have just moved, which probably accounts for the problems. It may take a while for the changes to filter through. There's no change to the actual address: just carry on using [EMAIL PROTECTED] Admin requests (subscribe/unsubscribe) should now be directed to [EMAIL PROTECTED] Please send complaints/suggestions to [EMAIL PROTECTED] Cheers, Simon
RE: strict data field
It was said long ago that these strict fields help to somewhat increase the performance. For example, Ratio uses this (?). The next version of ghc will make further use of strictness annotations on constructors by unboxing/unpacking strict fields. eg. data T = T !Int will result in an unboxed integer being stored in the T constructor, and data S = S !(T,T) will result in two unboxed integers stored in the S constructor (assuming the same strictness annotation on the T constructor above). This is an optional feature, because it could in certain cases result in more allocation as the unpacked fields need to be reboxed when the fields are extracted. Cheers, Simon
RE: Another bug in the 98 Report?
Re: layout changes in Haskell 98
Having had a bit more time to muse over this issue and discuss it with Simon
P.J., we came to the conclusion that the issue is far from concluded. The
Haskell 98 layout rule still has some problems (shock! :-)
This message is indended to summarise what I think are the problems with the
current rule, and to hopefully start some discussion about fixing these for
Haskell 2.
Nested layout contexts at the same indentation level
I came across today (in the H/Direct sources) several occurrences of code
like
do
f $ \x - do
z - e
which is illegal according to Haskell 98: nested contexts must increase in
indentation and 'do' expressions cannot be empty. However, this is a
perfectly natural thing to want to write - the outer 'do' context is
subsumed by the inner one, and both contexts will be closed simultaneously
when the next line indented less is encountered. The two possible fixes to
get the code to comply with Haskell 98 are
- indent the 'z - e' and all following statements to the right
- or don't use layout
both of which are pretty ugly.
Haskell 98 introduced the restriction on nested layout contexts because if
you write
f = f where
g = g
then it isn't immediately clear whether the 'g = g' declaration belongs to
the where clause, or to the top level (and the where clause is empty). In
fact, if we changed the layout rule as Malcolm suggests in his earlier
message, the parse would unambiguously associate the declaration for g to
the where clause. In its favour, this change would fix the H/Direct
example above. The disadvantages include
- leaving a dangling 'where' on a top-level declaration would
eat up all the following declarations. The current behaviour
handles this case nicely.
- it becomes harder to write empty where clauses with layout.
I personally think the above example "looks" like a declaration with an
empty where clause.
The 'do ... if .. then .. else' problem
---
Another natural expression that is disallowed is
do
...
if p then
...
else
...
which is rejected by Haskell 98 because the 'else' introduces an extra
semicolon. A fix for this was proposed for Haskell 98, but it was rejected
as a non-urgent change. The fix essentially is to turn off layout
processing between 'if' and 'else', treating these keywords as explicit
brackets. Some other constructs can be treated similarly, eg. 'case ... of'
and '\ ... -'.
The 'case' problem
--
It seems reasonable to want to write
case e1 of (p,q) -
case e2 of (r,s) -
...
but this is rejected by Haskell 98 (and all previous versions). Most of the
time we end up writing
case e1 of { (p,q) -
case e2 of { (r,s) -
...
}}
but this is annoying because you have to adjust the number of braces at the
end of the expression when you add or remove a case. One way around this is
a =: b = b a
e1 =: \ (p,q) -
e2 =: \ (r,s) -
...
I don't know of any fix, but I just mention this here in case anyone has any
ideas.
Cheers,
Simon
Strange lexical syntax
I just uncovered a couple of strange cases in the Haskell lexical syntax. If you're not especially bothered about such things, don't bother to read on! Quick quiz: how many Haskell lexemes are represented by the following sequences of characters? 1) M.x 2) M.let 3)M.as 4) M.. 5) M... 6) M.! answers: 1) 1. This is a qualified identifier. 2) 3. 'let' is a keyword, which excludes this string from being a qualified identifier. 3) 1. 'as' is a "specialid", not a "reservedid". 4) 1. This is a qualified symbol. 5) 2. '..' is a reserved operator, so a qualified symbol is out. The sequence '...' is a valid operator and according to the maximal munch rule this must be the second lexeme. 6)1. '!' is a "specialop", not a "reservedop". I especially like case 5 :-) This is pretty bogus. I suggest as a fix for Haskell 2 that all of the above be treated as 1 lexeme, i.e. qualified identifiers/symbols. Cheers, Simon
RE: mailing list
I don't think there was a solution. At least, I'm still being mailed :-( I guess the administrators aren't paying much attention to what's going on... Poor job. Sorry, I've been away for a few days. 1. To remove yourself from this mailing list, mail "[EMAIL PROTECTED]" with the line "unsubscribe your-email-address". 2. If you have any problems, mail me directly at [EMAIL PROTECTED]. 3. Please don't send unsubscribe requests to everyone on this list - it just annoys lots of people. Thanks, Simon
RE: Again: Referential Equality
I would like to have a comparison instruction that compares the internal reference of two objects. Let's call it "req". req :: a - a - Bool By coincidence, I was just looking at GHC's documentation on stable names and pointers, and it seems relevant here. http://research.microsoft.com/users/t-simonm/ghc/Docs/latest/l ibraries/libs- 14.html Something like this might do the job for you: req a b = unsafePerformIO $ do a' - makeStableName a b' - makeStableName b return (a' == b') That's exactly what to use in a situation like this. Pointer equality loses referential transparency in general (as Simon P.J. pointed out), hence the use of the I/O monad in our Stable Name API. Furthermore, if you intend to encapsulate your use of pointer equality in a "safe" abstraction, say a memo table, then use of unsafePerformIO is entirely justified. The req function above is of course an "unsafe" abstraction, because it exposes the representation of a and b. Cheers, Simon
RE: The dreaded layout rule
Manuel Chakravarty writes: What kind of implementation did the originators of this clause envision? If the layout rule is really implemented as a filter between the scanner and the parser, it seems extremely awkward to add a dependency on the error condition of the parser - in particular, it makes a functional, ie, side-effect free implementation rather hard and a true two phase implementation impossible. So, I guess (I hope!!) there is a nifty trick that lets you achieve the same effect by using only conditions depending on local information (either during layout processing or by letting the parser insert the missing braces). GHC and Hugs both make use of yacc-style error recovery, albeit in a very limited form. The idea is to have a production in your grammar like this: close_brace : '}' | error where the '}' token is assumed to have been inserted by the lexical analyser as a result of layout (i.e. a token was found to be less indented than the current layout context). The error case fires if any other token is encountered, and the semantic action for this production will probably pop the current layout context and carry on (in practice you also have to tell yacc not to continue with error recovery, otherwise all sorts of strange things happen). Take a look at GHC's parser for the details. I believe you're right in that a true two-phase implementation of the Haskell grammar is impossible. This is consistent with Haskell's policy of making life easy for programmers and hard for compiler writers :) Cheers, Simon
RE: The dreaded layout rule
Does anybody disagree with my interpretation of the standard? Are there any implementations that actually follow the standard here? (Maybe the standard should be changed to follow the implementations in this area.) Phew. Well spotted. Of course, none of the existing Haskell implementations are in conformance here. I think this has just about convinced me that the parse-error condition is a really bad idea. The main reason for its inclusion was to allow things like let f x = x in ... and also to automatically insert the final '}' before the end of file. Perhaps the layout rule should be restricted to these two cases? Proposal: - replace t by 'in' in the parse-error rule. EOF is already handled by the last clause in the layout spec. My guess is that this would break very few programs. A simpler rule might involve automatically inserting '}' before 'in' during lexical analysis iff (a) we're in a layout context and (b) the close brace hasn't already been inserted by the layout rule. This would decouple the parser and lexer which is a Good Thing. Cheers, Simon
RE: ANNOUNCEMENT: The Glasgow Haskell Compiler, version 4.04
Now that you're an (ahem) Microsoft employee, is there any intention of allowing ghc to use Visual C++ instead of gcc, We plan to allow this, but there'll be a price to pay: the gcc extensions that we use buy us about a factor of 2 in performance and binary sizes. or supporting the Win32 platform without cygwin? You can already build binaries on Win32 that don't need cygwin. However, you'll still need cygwin in order to run the compiler (for the time being, anyway). Cheers, Simon
RE: The dreaded layout rule
Does it mean that the following expressions would be illegal?
if cond then do proc1; proc2 else do proc3; proc4
(case e of Just x - x 0; Nothing - False)
Unfortunately, yes.
Now one can forget about {} and use layout everywhere. He would no
longer be able to forget or he would have to split some expressions
into indented lines, even when they are unambiguous in one line.
Hmm, the `do x == y == z' case is a real trouble. Would it be not
too ugly to formalize the current common behavior as something like
"for the purposes of layout resolution, the syntax does not care
about fixity declarations"? I guess that treating them in any way at
this stage, as long as they don't reject non-associative operators,
would yield the same result... Ugly but practical.
One other possible solution is to remove the fixity resolution from the
grammar itself and describe it as a separate process post-parsing. This is
probably a good thing anyway: it matches the way most implementations work
and it would clean up the grammar.
Cheers,
Simon
RE: Cpp symbols for Haskell 98
In brief: Define __HASKELL__=98 and __HASKELL98__ as preprocessor macros for all Haskell 98 compilers. Ok, GHC 4.04 (in the forthcoming patchlevel 1 release) will follow suit. Cheers, Simon
RE: Question
Out of curiosity, how big is the user community? How many downloads of the software? How many are on this list? There are ~700 people on the Haskell list, ~200 on glasgow-haskell-users and ~150 on hugs-users. About 160 people downloaded ghc-4.02 for Linux last month, I'm waiting to find out how many people downloaded the new ghc-4.04 binaries which were released this month. To follow up to Mark's original message, we've noticed that external interest and support for GHC has been increasing steadily for a while. The standard joke used to be that the number of GHC users was roughly equal to its version number, which was even true for a while :) Nowadays we regularly get useful contributions from the GHC community on our mailing lists. We make a habit of integrating pretty much everything that people send us, as long as it's not too controversial. I think the one big thing that prompted the recent increase in the number of contributions has been our move to an open-development model using CVS: now that the power-users can update their source trees regularly from the master repository and see exactly what we're up to, GHC development is much less of a black box. Folk can send us patches that will integrate directly into our working copies, making it much easier for us to accept external contributions. Regular contributors, or people involved in actively devloping one part of the system, even get furnished with full read-write access to the repository. None of this is new, in fact it pretty much mirrors the FreeBSD development model (and probably other projects too, KDE for one I think), but we've found that so far it works well for GHC. Hugs is already in the process of being moved to the same repository, so hopefully we'll see a similar increase in contributions there too. Cheers, Simon
RE: Q: hugs behavior...
I think that the transformation is exactly fully laziness. Sometimes, it helps to improve space/time performance, but it needs to be tunned up due to the reasons including one given by Tweed. GHC does full laziness(*). As far as I know, no-one ever complained :) Simon (*) Well, actually it's nearly-full-laziness, since we tend not to separate adjacent lambdas if possible.
RE: Q: hugs behavior...
IIRC, GHC does the tuning, i.e. CAFs are garbage collected in a clever way (describe in SPJ's book, I think), e.g. if there is only one reference into the "middle" of a CAF left, only that part is kept alive. and not the wohle CAF. Comments from Mr. GC? :-) True, but this doesn't solve the space leak associated with full-laziness. If the entire list happens to be still required, it'll be kept around, whereas if the full-laziness transformation hadn't lifted it to the top level the list would be recomputed every time (O(n) vs. O(1) space requirements respectively). Fortunately it seems that this doesn't bite in practice, except in certain pathological cases, so implementing full-laziness is a big win on average. Cheers, Simon
Mailing lists down for a while, should be back up now
Maintainer's note: The Haskell mailing list, and all the other lists served by haskell.org, have recently moved to a new machine (the "real" haskell.org). None of the addresses have changed, and the address for admin requests is still [EMAIL PROTECTED] The lists have been down for a short while due to a configuration error in the mail setup on the new machine. If you tried to send a message recently and it bounced, please try again; things should be working now. Also, if anyone has any suggestions for new mailing lists that haskell.org could provide, please get in touch. haskell-announce, anyone? Cheers, Simon
RE: Embedding a scripting language in a Haskell program
Herbert Schuetz writes: But of course if the great merger of GHC and Hugs provides all the needed functionality (including, e.g., the possibility to load and invoke interpreted modules from within compiled code), then such a project might be superfluous, and your idea #1 becomes the best choice. (Is there any information yet about what the combined GHC/Hugs system will look like?) The Combined GHC/Hugs will certainly make this possible. The URL below is a design document for the "Haskell Execution Platform", which basically consists of Hugs and the GHC/Hugs runtime system packaged behind an API that allows several "front end" clients: the Hugs command-line interpreter, WinHugs, HaskellScript etc. The HEP is basically an API for running Haskell code, either interpreted or pre-compiled, or a mixture of the two. http://www.haskell.org/ghc/docs/papers/hep.ps.gz I don't see any problem in principle with allowing programs running inside the HEP to call back into the HEP in order to evaluate new expressions, thus letting you write eval :: String - IO () However, the full HEP implementation is still vapourware, although we have a lot of the groundwork done. Cheers, Simon
RE: [haskell] list reorg
I would like to add a vote for reorganization into two lists one of which is a proper subset of the other. I stopped reading Usenet a long time ago when the spam got too intolerable. In my experience, this sort of thing doesn't work too well in practice. People tend to cross-post, or always post to the most general list, when they aren't sure exactly which list they should be posting to. Here's my proposal: - haskell-announce (v. low volume) - haskell-chat (high volume, anything vaguely related to Haskell is acceptable) - haskell-questions (questions about the use of the language, maybe haskell-help or haskell-users) - haskell-2 (discussions related to changes/extensions to the language) - haskell (general discussion list, anything not covered above) I don't think we need to have a more restrictive charter fot the haskell list itself - just the presence of the other lists will take some of the load off straight away. Besides, 30 messages a day isn't a great deal, especially if you use a decent threaded mail reader (I recommend emacs+Gnus+procmail, but there are lots of others). Cheers, Simon
ANNOUNCE: Happy Version 1.6
Happy 1.6 The LALR(1) Parser Generator for Haskell This is the nth public release of our parser generator system for Haskell, called Happy (a dyslexic acronym for 'A Yacc-like Haskell Parser generator'). What's new in Happy 1.6 (vs. Happy 1.5) * Several bugfixes * A new backend (GHC + coercions) * A new BSD-style license. Happy is available in source form, which can be compiled with GHC version 3.xx or 4.xx, and we also provide binaries for various architectures. The Happy homepage with links to the various distributions now lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to [EMAIL PROTECTED]
RE: Dynamic scopes in Haskell
Is there any references to memoization techniques? I could not find any reference to memoization facilities in the Haskell report and library report. Neither in the Clean report. After looking at GHC, Hugs98 and nhc98, I have found that GCH provides the memo function used in the example. Looking at it, it does not look easily portable. GHC's Memo library is described in the User's Guide: http://www.haskell.org/ghc/docs/latest/users_guide/users_guide-6.html#ss6.6 This memo table implementation is primarily for applications with large (or even infinite) keys, where determining equality is not cheap or desirable. The memo table uses stable names, a kind of identity mechanism for objects which provides a pointer-equality like comparision mechanism. The library also uses weak pointers and finalization to avoid keeping stale results in the memo table. The techniques are described in the following paper: http://www.research.microsoft.com/~simonpj/papers/weak.ps.gz Cheers, Simon
RE: Hugs/ghc Int{8,16,32,64} types and overflow
A quick question: what is the intended behaviour of the Hugs/ghc extension types Int8, Int16, Int32, and Int64 with regard to overflow? The documentation for the Word* types says that they compute modulo arithmetic, but there is no similar guarantee for the Int* types. Is it the intention that their behaviour on overflow is deliberately left undefined? Or is it safe to rely on them just wrapping on overflow? They're supposed to wrap on overflow. Either way, I think it would be a good idea to clarify this in the Hugs/GHC Extension libraries documentation. Will do. Cheers, Simon
Mailing Lists
Folks, Please do not adjust your set :-) Due to problems with the haskell.org setup at Yale, all the mailing lists served by haskell.org (haskell, glasgow-haskell*, hugs* etc.) are down, as is http://www.haskell.org. Normal service will be resumed as soon as possible. Cheers, Simon
RE: live display of heap usage
i am preparing a demonstration on memory management/garbage collection, and to give the students some real life examples, i am looking for a simple patch to some Haskell runtime system so that it would display the heap *while* the program is running. like, opening an X window and mapping heap cell types to pixel colours. (i'm prepared to accept horrible slowdowns in program execution) i quickly hacked such a display into hugs, just using 3 colours (cell is in free list, cell is reachable, cell is unreachable), but i'd like to have this for some other (e. g. generational) collector as well. any hints appreciated. This is pretty easy to do in GHC. In fact, just running your program with '+RTS -Sstderr' will cause it to spew out the residency information on ach GC. You might want to use a single generation to avoid multiple generations screwing up the results (i.e. +RTS -G1). To get more detailed information, you can adapt GHC's heap profiling mechanisms: there are versions for cost-centre profiling and normal execution. Contact us for more details. Cheers, Simon
Lists back again
Haskell.org is now back up again. Simon
RE: Haskell Clean
Well, I see what you mean, no way, NO means, etc. So, the program below in Hugs would not work as it should? Too bad... -- === -- ioio.hs dump f = readFile f = putStr gimmeThat = dump "ioio.hs" -- === Well, pedantically speaking that's not a program (see Section 5 of the H98 report). Simon
Mailing list archive
A few folk have asked about an archive of this mailing list recently - the answer is that the one at Glasgow isn't being updated any more (and it was never very good anyway). There's a better archive at http://www.mail-archive.com/haskell@haskell.org and similarly for all the other mailing lists managed at haskell.org: just change [EMAIL PROTECTED] to list@haskell.org in the URL above. Cheers, Simon
RE: mail delivery
Sergey writes: Today, there came the letter by Joe English on space leak etc., dated of February 06. And today is February 22. I wonder, what is the matter with the mail lists. This was due to the filtering on haskell.org, which thought the message contained an admin request (unsubscribe etc.), and therefore had to wait for approval. I've been away for a while, so it didn't get approved until yesterday. Cheers, Simon
RE: Wanted: mmap or other fast IO
Title: RE: Wanted: mmap or other fast IO Is there any interface to mmap(2) available? Something that behaves like an immutable array would be great. An mmap may have a signature like mmap :: Ix a, ?? b = Handle - IO (Array a b) I've no idea what types should be allowed for b. It has to be some fixed size type, e.g. Int, but this would require the mmapped file's size to be a multiple of the size of Ints. The easiest way is to declare mmap as a foreign function using foreign import, then build a little wrapper around it. Unfortunately you won't be able to turn the resulting memory into an array (even a ByteArray), since these are assumed to live in GHC's heap, but you'll be able to return an Addr and use writeXXXOffAddr/readXXXOffAddr to access it(*). Cheers, Simon (*) the readXXXOffAddr functions are known to be broken at the moment (see recent discussion on ghc-bugs), we're currently working on fixing them.
RE: Unused identifiers in default case patterns
Alternatively, of course, the coding style could simply change to case e of -- ... _other - default_action or case e of -- ... _ - default_action The former is IMHO ugly, and the latter fails to indicate to the reader that this is intended to match not *all* alternatives, but just those not already matched. I like the first one - it makes it clear that you don't intend to use the identifier. Unfortunately keywords beginning with '_' don't behave like wildcards - there's nothing stopping you from using this identifier on the right-hand side, so we just have to adopt this as a convention. Perhaps when unused identifier warnings are turned on, GHC should also warn about non-binding occurrences of identifiers beginning with '_'? Cheers, Simon
New Haskell mirror
Dear Haskellites, http://www.haskell.org/ now has a mirror site in the U.K: The HASKELL mirror is now live at the UK Mirror Service at http://www.mirror.ac.uk/sites/www.haskell.org/ and will feature in this months newsletter announcing new mirrors at the end of the month. We would be very grateful if you could provide a link to our mirror from your site. Regards Claire ___ Claire Moore Information Officer UK Mirror Service Information Systems Services Lancaster University Bailrigg Lancaster LA1 4YW 01524 594287 -Original Message- From: Simon Marlow [SMTP:[EMAIL PROTECTED]] Sent: 25 February 2000 13:54 Subject:I Want A Mirror IP addr : 148.88.2.7 (no name in the DNS?) Browser : Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Referer : http://www.mirror.ac.uk/feedback/iwantamirror.html URL: http://www.haskell.org/ Discipline/Catagory: Applications/Utilities Sub-Catagory: Compilers/Languages Why: Because we don't have any mirrors :) And several folk have asked us if we could provide alternative download locations. You could either mirror the whole site, or just http://www.haskell.org/ghc/dist for the GHC distributions. Give Description?: Yes
RE: Additions to the FFI API
GHC folks, would it be a problem to allow transparent unwrapping of newtypes in foreign calls? Shouldn't be a problem, I'll be happy to do it if that's what the conclusion is. I don't understand Qrczak's comment: data CLDouble = CLD# Double# -- ugh, plain newtype won't work if we transparently pass newtypes' contents through FFI :-o could you elaborate? Simon
RE: ServiceShow for error messages
The problem with this is that there is a performance penalty to be paid for overloading a function in this way. `take' is implemented as a function of two arguments, as you would expect. It is given a number and a list; it has no idea what type the list has, nor does it need to: it just picks elements off it and returns them. In Hugs, there's no need to do the dictionary passing because it has a polymorphic show function (used to be called show', is it something like primShow now?). In GHC, you can't do this kind of built-in overloading because there isn't enough type information in the heap at run-time, so you'd have to do the dictionary passing. Cheers, Simon
RE: Type and class names
Why are type constructors and classes in the same namespace? Because otherwise the syntax module M ( T ) where would be ambiguous. I suppose it could be resolved to mean "export the class and/or data type T". It was proposed for Haskell 98 that the syntax be changed to module M ( class T ) where or module M ( type T ) where but the proposal was not adopted, because of the amount of breakage this would cause. Cheers, Simon
Haskell Web Server: please pummell
Dear Haskell folks, There's a web server written in Haskell running on haskell.org: http://www.haskell.org:8080/ Please surf on over and press reload a few times. First one to bring it down gets a gold star. I'll be watching the logs :-) The source (not properly packaged, just source code, a Makefile and an example config file) is here: http://research.microsoft.com/~simonmar/hws.tar.gz You'll need a *very* up-to-date GHC ( 2 weeks old) to compile it. All we need now is: - a better name for this thing - a "powered by Haskell" logo :-) Cheers, Simon
RE: lines --- to derive, or not to derive ;-)
Simon Marlow wrote:
| lines :: String - [String]
| lines s = lines' s ""
| where
| lines' [] acc = [acc]
| lines' ('\n':s) acc = reverse acc : lines' s ""
| lines' (c:s)acc = lines' s (c:acc)
|
| This one is more than twice as fast as the foldr
| version, despite the fact that it needs to reverse the
| accumulating parameter for each line.
Unfortunately, it is less lazy too, so it will blow out of
heapspace on very long lines.
Yes, so it is. But in fact, so is Wolfram's foldr version.
head (head (lines ('x':error "urk!")))
should yield 'x' according to the report definition.
Simon
RE: lines --- to derive, or not to derive ;-)
Yes, break is very expensive due to its pairing up of results
for every
character consumed. You didn't mention the accumulating
parameter version:
lines :: String - [String]
lines s = lines' s ""
where
lines' [] acc = [acc]
lines' ('\n':s) acc = reverse acc : lines' s ""
lines' (c:s)acc = lines' s (c:acc)
correction: that should really be
lines :: String - [String]
lines s = lines' s ""
where
---lines' [] "" = []
lines' [] acc = [acc]
lines' ('\n':s) acc = reverse acc : lines' s ""
lines' (c:s)acc = lines' s (c:acc)
Simon
RE: import List(..) ?
the grammar for import and export lists use `tycon'
and `qtycon' (respectively) rather than `gtycon'.
Is there any particular reason for this, or is this
just a defect in the Haskell 98 report?
Would changing `qtycon' to `gtycon' in the
grammar production for `export' cause any problems?
Likewise, how about changing `tycon' in the grammar
production for `import' to say `gutycon', defined by
gutycon - tycon
| () (unit type)
| [] (list constructor)
| (-) (function constructor)
| (,{,}) (tupling constructors)
?
I believe this has been noticed before, but hasn't been fixed because simply
making the above change wouldn't solve the whole problem: there's still no
way to qualify these identifiers as eg. Prelude.(,). And fixing this would
involve importing knowledge about these names into the lexical syntax, which
would be rather ugly. But perhaps that's the only way.
The good news is that ghc (4.04) does not follow the Haskell 98
report -- it accepts the following code, apparently as an
extension to Haskell 98 (even without `-fglasgow-exts'):
module Example(Prelude.[](..)) where
import Prelude([](..))
Similarly, it also accepts
module Example(Prelude.[]((:), [])) where
import Prelude([]((:), []))
Yes, GHC accepts the syntax 'Prelude.[]' (and friends, including
Prelude.-) as an extension.
Cheers,
Simon
RE: Results: poll: polymorphic let bindings in do
Thanks for everyone who participated in the recent poll. Here are the results: Never used: 6 Sometimes used: 1 Common commments: willing to give it up for something cool can be easily rewritten wouldn't make a lot of difference not sure if used ever, but wouldn't expect it to be a disaster In particular, the person who indicated that he has "sometimes used" polymorphic let-generators stated that he can always rewrite the code without using them. Since the Haskell-mailing list has a lot more than 7 subscribers, this might be considered as another indication that polymorphic let-generators are not even interesting to most people anyway. It probably has more to do with the fact that there isn't an easy way to tell whether you use polymorphic let generators or not. I for one have heaps of code lying around that I'm not going to look through by hand to find out; I suppose I could modify the compiler to tell me but that doesn't fill me with enthusiasm either :) At a guess, I'd say I probably use polymorphic let-in-do very occasionally. And in those cases where I've declared a polymorphically-typed expression in a let, I've probably only used it at one type anyway. On the other hand, I can recall very few occasions where I've needed a recursive do. There you go, just another data point. Cheers, Simon
RE: Sockets
How do I use sockets in Haskell? The ghc manual had some information in the users guide (6.7 Interfaces to C libraries) but the sentence which started tantalisingly "Various examples of networking Haskell code are provided in " had no second half. I'd prefer to use hugs during development but there didn't seem to be anything about sockets in the hugs documentation. It sounds like you might be reading the documentation for an older version of GHC. Anyway, some more up-to-date documentation on GHC's networking libraries is here: http://www.haskell.org/ghc/docs/latest/hslibs/c1207.html Cheers, Simon
ANNOUNCE: Happy version 1.8
ANNOUNCING Happy 1.8 - The LALR(1) Parser Generator for Haskell I'm pleased to announce version 1.8 of Happy, the parser generator system for Haskell. Changes in this version, relative to version 1.6 (the previous full release): * Parser table compression, and more efficient table encoding when used with GHC. Large grammars can now be compiled in much less time/space than before using GHC. * Yacc-style operator precedence, thanks to patches from Hermann Oliveira Rodrigues [EMAIL PROTECTED] and Josef Svenningsson [EMAIL PROTECTED]. * A debug option which causes the generated parser to print tracing information at each step during parsing. Happy is available in source form, which can be compiled with GHC version 4.xx (4.08 recommended), and we also provide binaries for various architectures. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to [EMAIL PROTECTED]
RE: Haskell libraries, support status, and range of applicability(was:Haskell jobs)
Simon, can you tell me how I shall link to hslibs, especially each individual library? Obviously a user would also like to download a single library. That's not so obvious to me. We're going to the effort of packaging up all these libraries into a single coherent collection, that can be distributed along with compilers, in effect to raise the baseline of libraries that the average Haskell programmer can "assume" are installed. Separating out single libraries isn't practical. There are a great deal of interdependencies. However, the libraries are organised into 7 packages which do have a well-defined dependency tree, so perhaps you could grab a single package at a time. Anyway, we'll try to make sure at least this link stays stable: http://www.haskell.org/ghc/docs/latest/set/book-hslibs.html Cheers, Simon
RE: Library for URLs?
Keith Malde writes: Apologies for not bringing up heavy theoretical issues, but is there a library routine for retrieveing URLs? I need to digest some web pages and extract a bit of data from them, and I've munged together a rather naïve XML (and soon HTML) parser[0], but I bet somebody, somewhere has a function that lets me read an URL as if it were just another file/stream/whatever. So, where are the goods, and how can I get 'em? -kzm The URI library in hslibs contains code for parsing and manipulating URIs (URI is a generalised URL). See: http://www.haskell.org/ghc/docs/latest/set/sec-uri.html Cheers, Simon
RE: simple binary IO proposition.
"Incorrect" UTF-8 in Chars is seen only by the conversion engine and sometimes by low-level I/O code. ... and by the application if it inadvertently specifies "no encoding" when the source is actually encoded. I think I agree with John here - specifying "no encoding" on a Handle shouldn't yield text (i.e. [Char]), it should give you a handle on which you can only read/write Word8, or something similar. Implementation-wise, specifying ISO8859 as the encoding is functionally equivalent to no-encoding, so the byte stream functions could be implemented as wrappers around the handle functions using ISO8859 as the encoding. So: a handle would either be no-encoding, in which case you can use hGetByte and friends, or it would have an encoding in which case you can use hGetChar and friends. Perhaps this is too much complication given that the underlying implementations are so similar, but it seems nice. Cheers, Simon
RE: Library for URLs?
Yep, the GHC stuff is a gold mine, and one which I frequent all to rarely (mostly using Hugs for development). Unfortunately, I can't find any URI - String functions - but I could probably build it on top of URI and Socket (great stuff btw, just what I (might) need) URI is an instance of Show, so you can just apply 'show' to get a string. Are any of these libraries standardised across Haskell implementations? Hugs doesn't seem to come with much. We're working on it. Unfortunately there are a lot of dependencies on GHC extensions (eg. URI uses Regex, and Regex still uses some legacy GHC features which are being superceded by the new FFI). Cheers, Simon
RE: Preemptive thread switching in concurrent haskell??
Why does this code fragment print a continous stream of b's? I thought it should print some alternation of a's and b's. I am using GHC 4.08.1 on Windows 98 with Cygwin. import Concurrent main = forkIO a b where a = putStrLn "a" a b = putStrLn "b" b --- This question was answered a while back on the glasgow-haskell-users list. See the thread starting with this post: http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg01595.html Cheers, Simon
RE: Preemptive thread switching in concurrent haskell??
On Fri 22 Sep, [EMAIL PROTECTED] wrote: Why does this code fragment print a continous stream of b's? I thought it should print some alternation of a's and b's. Sorry, I don't know the answer, but this post reminds me of something I'd been meaning to ask.. I seem to remember reading that Concurrent Haskell only needs 1 stack, rather than 1 stack per thread. Is this true? (If so I can't see how this can be done using preemptive thread switching.) GHC's implementation of concurrency uses one stack per thread. You can, however, implement the Concurrent Haskell primitives non-preemptively, using only a single stack. This is I believe what is implemented in Hugs. Cheers, Simon
Mailing list software changing
Dear Haskell Haskell-cafe, At haskell.org we're migrating the mailing lists from majordomo (which is somewhat old and clunky) to Mailman, which will amongst other things make my life a lot easier, provide better archives, add digest support and allow subscription/unsubscription via a web interface. You should all receive a notification shortly about subscription to the new lists. Unfortunately it seems we have to do this, because the confirmation contains the password for accessing modifying your personal subscription details on the web. If you *don't* receive a confirmation in the next 24 hours, please let me know. Heres hoping everything goes smoothly, and once again I apologise for the extra spam in your mailbox. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Imperative Object Destruction
That's the problem. And I think your solution is overly complicated. Why not copy what Common Lisp does, just that Haskell can do it without macros: withOpenFile :: FilePath - IOMode - (Handle - IO a) - IO a withOpenFile name mode action = do handle - openFile name mode result - (action handle) `finally` (hClose handle) return result Usage: count :: Handle - IO Int read :: Handle - IO [Byte] fileLength - withOpenFile "filename" ReadMode $ \handle - count handle fileContent - withOpenFile "filename" ReadMode $ \handle - read handle Doesn't fulfill condition 2: 2. no read or write operations are performed on file-handles that have not yet been opened, or that have already been closed. ...since you can do stealHandle = withOpenFile "filename" ReadMode (\handle - handle) stealHandle = read If you want to enforce this kind of encapsulation using the type system, you could try using the runST trick, something like: withOpenFile :: FilePath - IOMode - (forall s . OpenFile s - IO a) - IO a of course, this needs the universal quantification extensions implemented in Hugs GHC. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: ANNOUNCE: HaXml 1.00
An older version of HaXml is also included in GHC's hslibs, in package "text". This will probably be updated to 1.00 at some time. great, I assume you'll check in the new version? Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: Happy version 1.9
ANNOUNCING Happy 1.9 - The LALR(1) Parser Generator for Haskell - I'm pleased to announce version 1.9 of Happy, the parser generator system for Haskell. Changes in this version, relative to version 1.8 (the previous full release): * A grammar may now contain several entry points, allowing several parsers to share parts of the grammar. * Some bugfixes. Happy is available in source form, which can be compiled with GHC version 4.xx (4.08.1 recommended), and we also provide binaries for some architectures. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: {-# LINE 100 Foo.hs #-} vs. # 100 Foo.hs
What should be the preferred way of marking correspondence to source
positions after some preprocessing?
Here is what is currently supported:
| {-# LINE 100 "Foo.hs #-} | #
100 "Foo.hs"
+--+--
--
Released ghc, no -cpp | understand | error
Released ghc, with -cpp | understand | understand
Developed ghc | understand | understand
hbc | understand (ignore filename) |
understand (warning)
Hugs| ignore | error
Released nhc98 | error| understand
Developed nhc98 | ignore | understand
I would choose LINE pragma. In this case nhc98 should be taught
about it.
CPP generates the '# 100 "Foo.hs"' form, which is why GHC understands
them. We used to convert these into LINE pragmas automatically before
feeding to the compiler, but this required an extra script and
preprocessing step (hscpp), so we don't do that anymore.
The preferred way should presumably be LINE pragmas.
Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: An Haskell compilation server
How about turning ghc into a compilation server ? It would run as a daemon waiting for network connections, retrieve source files (through the same network socket, or nfs, or cvs, ...), compile them locally, and send back the result. This would prevent having to reload the compiler for each file - as the executable is quite large, this may already speed up compilation a bit. It could also cache .hi files, which would remove the need to parse them. It would also enable distributed compilation, on a properly configured site. That would be easy to do with hmake. There are many details to think about (should the parsing be made locally by the driver, or remotely...). How does it sound ? Funny you should say that. The next version of GHC (5.00 - to be released soon) will have hmake-like functionality enabling it to compile multiple modules without exiting, caching .hi files between compilations. This speeds up compilations by as much as a factor of 2 for large programs. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Source tar ball for Simon Marlow's Haskell Web Server??
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: The Do-Let-Braces problem
Mark Utting writes:
fb::IO ()
fb =
do {
putStr "Enter Data: ";
line - getLine;
let line2 = line;
putStr line2;
}
ERROR "f.hs" (line 13): Syntax error in definition
(unexpected symbol "putStr")
I find it hard to determine exactly from the Report whether this is
a bug in Haskell, or just a bug in ghc. For what it's worth, nhc98
parses and accepts your example exactly as you intended.
GHC and Hugs both conform to the report here. The ';' on the end of the
'let' line is interpreted as the terminator for the 'line2 = line'
declaration, the layout system inserts a '}' before 'putStr', and
there's a missing semicolon before 'putStr' since we're back in
non-layout mode now.
Arguably the layout rule is not clever enough: it only allows one token
of lookahead when deciding whether to insert a close curly or not (in
the above example, if it had two tokens of lookahead it could determine
that the close curly was required before the ';' in the 'let'
declaration). I'm not seriously suggesting that the layout rule should
be extended to cope with this, rather that since it isn't general enough
we should simplify or throw away altogether the parse error condition in
the layout rule.
In my experience, mixing layout and non-layout in nested contexts
generally leads to trouble: stick to one or the other.
Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: running for long enough...
About the program below, someone (I think Simon Marlow) said that if I run it for long enough, I'll see as rather than bs. I would like to know for how long I will have to wait, since 2 hours were not enough to see it switching from bs to as. main = forkIO a b where a = putStrLn a a b = putStrLn b b Did you watch it continuously for two hours? It might have changed quicky to as and back again without you noticing. Watch it very carefully. mischevous grin :) But seriously, don't waste your time on this example. It just doesn't work too well with GHC, because of the contention between the two threads both trying to access standard output. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: Happy 1.10 released
ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell - I'm pleased to announce version 1.10 of Happy, the parser generator system for Haskell. Changes in this version, relative to version 1.10 (the previous full release): * bugfixes, and minor performance improvements, * most of the examples work again. Happy is available in source form, which can be compiled with GHC version 4.xx (4.08 or 5.00 recommended), and we also provide binaries for some architectures. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
S. Alexander Jacobson writes: I am not a parsing expert, but given the recent discussion on macros, I have to ask: why use happy rather than monadic parsing? Monadic parsing allows you to avoid a whole additional language/compilation step and work in Hugs (where you don't have a makefile). What does Happy buy you here? It buys you (a) speed, (b) confidence that your grammar is non-ambiguous, and (c) familiar BNF notation. On the down side, as you point out, you lose Haskell's abstraction facilities. I'd be willing to sacrifice (c) in order to write parsers in Haskell, but I don't think there's a combinator library that matches Happy in terms of speed (disclaimer: I haven't exhaustively tested them all, but given the tricks Happy does I'd be surprised). AFAIK none of the combinator libraries gives you (b). Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: BAL paper available
I don't like the idea of a program working which compiles only under compilers which have certain language extensions built in. If I understand things correctly, there is a list of language extensions (FFI for example), which has been accepted by all Haskell compilers developers. If multiparameter type classes were in that list, I would agree. Besides, MArray.lhs uses ST and ST requires not only multiparameter type classes, but also explicit universal quantification. ST doesn't require multiparameter type classes (although MArray does). It also doesn't require full support for explicit universal quantification, if runST is known to the compiler. Also, the ST array types are really an optional part of the MArray interface - it works perfectly well with just the IO array types. I don't like ST and the idea that someone who wants to use arrays outside of IO has to use ST gives me creeps. What would you suggest as an alternative? I suppose you could have a monad which just supported a single array, but special-purpose monads tend to be a pain in practice (eg. what happens when you want two arrays?). By the way, I'm really surprised by the lack of time complexity information in MArray. I mean, that's the most important thing in arrays - that one can update/read a data in O(1). Point taken, I'll update the documentation to include more of this info. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
I/O buffering (was: Endangered I/O operations)
[ moved from glasgow-haskell-users to [EMAIL PROTECTED] ] Carl Witty writes: If the report does not allow the implementation to flush buffers at any time, I would call that a bug in the report. Indeed, perhaps the report should be clarified on this issue. Currently, in section 11.4.2 the report specifies the conditions under which a buffer is flushed, and conditions under which input is available from a buffered read handle. GHC deviates from the report in a few ways: - we don't adhere strictly to block buffering for hPutStr: we may occasionally flush the buffer early. - a line-buffered input handle doesn't wait for the newline to be available before releasing the input, unless you use hGetLine of course. However, since the report doesn't specify the *size* of a line buffer, we can't really be accused of deviating here. - a read/write handle (files only) has a single buffer which contains either pending read or write items, never both. A read from a read/write handle will cause any pending writes to be flushed, and vice versa. IMHO, the report should state that additional buffer flushes may be performed at the discretion of the implementation, but an application should not rely on any additional flushing happening. The report doesn't state whether, when discarding a read buffer, the data should be returned to the file (ie. the underlying file pointer moved backwards) if possible. GHC does this if possible. One other point that I noticed while re-implementing I/O: the description for hLookAhead states that Computation hLookAhead hdl returns the next character from handle hdl without removing it from the input buffer. What if the handle is unbuffered? A working hLookAhead is more or less required in order to implement hIsEOF (at least on a stream: for a file you can check EOF without attempting to read). So for GHC I had to ensure that even an unbuffered handle has a 1-character buffer; this turned out to be not as painful as I thought. Cheers, Simon I would much rather use an implementation where stdout and stderr came out in the right order, and reading from stdin flushed stdout. (As another example, an implementation might want to flush all buffers before doing a fork(), to avoid duplicated output.) The only caveat is that if such flushing is allowed but not required, it might encourage writing sloppy, nonportable code. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Building Programs Again
I am going to install hmake and upgrade to ghc 5 but in the meantime I decided to use make. I am puzzled however. Presumably building a module that imports a module needs the .hi file and therefore the makefile should be something like this: Tagsv1.o : Tagsv1.hs ghc -c Tagsv1.hs -package lang Basev1.o : Tagsv1.hi Basev1.hs ghc -c Basev1.hs -package lang But if I do this then make complains if I want to see what it will generate [dom@lhrtba8fd85 maketest]$ make -n ghc -c Tagsv1.hs -package lang make: *** No rule to make target `Tagsv1.hi', needed by `Basev1.o'. Stop. Running make works as by the time the rule gets executed the .hi file exists. Can anyone suggest something better? GHC's documentation has some useful tips on using make with Haskell: http://www.haskell.org/ghc/docs/latest/set/separate-compilation.html#USI NG-MAKE Chees, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: infelicity in module imports
Malcolm Wallace writes: I submit that the way `hiding' clauses are ignored is a vestige from the days when it was not possible to have overlapped module renamings. Now that overlapped renamings are possible, the `hiding' clauses should be permitted to take effect. I think you're right. It's inconsistent that you can specify which qualified identifiers are imported using 'import A ( foo, bar )' but not using the hiding form. The following two sentences could just be deleted from point 2, section 5.3: The hiding clause only applies to unqualified names. In the previous example, the name M.C is brought into scope. A hiding clause has no effect in an import qualified declaration. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: infelicity in module imports
Simon Peyton Jones writes: In short, an import *always* brings the entire *qualified* set of names into scope. Hiding and revealing applies only to unqualified names. I must say that I thought GHC implemented this rule; if not I should fix it. That's not my reading of the report, and it's not what GHC implements. import A (f) brings only f and A.f into scope. Relevant quotes from the report, section 5.3.1: An import declaration that uses the qualified keyword brings into scope only the qualified names of the imported entities (Section 5.5.1); if the qualified keyword is omitted, both qualified and unqualified names are brought into scope and section 5.5.1: An import declaration, whether qualified or not, always brings into scope the qualified names of the imported entity. [ aside: should that last word be entities? ] I'm taking the term the imported entities to mean those entities specified in the import list, or all the exported entities if the import list is omitted. If it doesn't mean this, what's the point of allowing import specifications on a qualified import? If it does mean this, then GHC is correct, but the report's comments about the effect of hiding on qualified names is inconsistent and should be removed (GHC doesn't implement this rule either). Perhaps this is the wrong interpretation, and Simon's is the correct one. But no where that I can find does the report say that an import always brings into scope *all* the qualified names from the imported module regardless of the import list. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Profiles in GHC
Can anyone give me a brief explanation (or show me where in the web I can find some info) about using the profiling library in GHC? Is it avaible for Windows 98/NT? There's documentation on GHC's profiling facilities here: http://www.haskell.org/ghc/docs/latest/set/profiling.html And yes, profiling is available with the Windows version of GHC. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Haskell 98 Report possible errors, part one
3. A precedence table says that case (rightwards) has higher
precedence
than operators and right associativity. If it's meaningful to talk
about precedence of such syntactic constructs as case at all,
it should
probably be told to have a lower precedence, so case x+1 of ...
is valid as case (x+1) of At least I don't see a difference
between case (rightwards) and if (rightwards). I'm not sure if
it makes sense to explain parsing of case in terms of precedence.
Interesting. The table seems to say that case(rightwards) has a higher
precedence than infix operators, so that eg.
case x of p - x + y
would parse as
(case x of p - x) + y
which is in conflict with the longest parse rule. I have no idea why
case(rightwards) is given a different precedence, and the inclusion of
'case alternative' in the list is confusing.
4.3.1. A class declaration with no where part [...]
The instance declaration must be given explicitly with no where part.
Actually the where part may be present but empty, with the
same meaning
as no where part.
Generally I'm not sure that having a layout rule which says that {} is
inserted when the next indentation level is about to start and the new
indent is smaller than the outer one is necessary; in all useful cases
the keyword which triggered the layout could be omitted, and writing
let x = case x of
foo - ...
should be either an error or it should be allowed to have the next
indent smaller than the previous one - it's not useful to let it mean
let {x = case x of {}}
foo - ...
and in case one really wants to have empty alts in case, he
can write {}
explicitly.
I agree, but this isn't really a bug so there's no need to change the
report. Besides, GHC is the only compiler which actually implements the
layout rule as specified :-)
Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: getting started with the glasgow haskell compiler
I'm just getting started using the glasgow haskell compiler and when I try to compile a simple program, named Hello.lhs, like this: module Main (main) where main = putStrLn Hello World end with the command ghc Hello.lhs I get the message on standard output: No definitions in file perhaps you forgot the ''s? The extension '.lhs' means Literate Haskell source which is described here: http://www.haskell.org/onlinereport/literate.html Normal Haskell source files, like the code example you give above, should be placed in a file with a '.hs' extension. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: The future of Haskell discussion
Jeffrey Palmer writes: I think the question is more along the lines of Why doesn't Haskell come bundled with complete, useful and _supported_ libraries? There's an ongoing effort to rectify the situation. There is a mailing list: [EMAIL PROTECTED], which you can join by going to http://www.haskell.org/mailman/listinfo/libraries (there are archives of previous discussion there too). A draft document describes the current plan: http://www.haskell.org/~simonmar/libraries/libraries.html and what source code we have so far is in CVS: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/ Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Prelude and (:) and []((:), []) bugs?
As far as I can tell, the report doesn't allow (:) or []((:), []) in the export list, yet the hugs prelude has the first and the GHC prelude has the second. Have I missed something that allows them or is this a bug in the preludes or the report? (:) is allowed in an export list; it is just a normal operator. GHC has a couple of extensions to export lists: we allow gcon instead of just qcon, and gtycon instead of qtycon. These are quite natural extensions, and just reduce the amount of built-in compiler magic needed to express the Prelude. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Prelude and (:) and []((:), []) bugs?
Ian Lynagh writes: On Thu, Sep 20, 2001 at 01:32:54PM +0100, Simon Marlow wrote: (:) is allowed in an export list; it is just a normal operator. An export is export - qvar | qtycon [(..) | ( qcname1 , ... , qcnamen )] (n=0) | qtycls [(..) | ( qvar1 , ... , qvarn )] (n=0) | module modid and we need to match (:). We can clearly reduce this to [ proof that this isn't possible deleted ] Ah, I forgot that you can't export a constructor on its own. In which case, I would like to submit a bug report for Hugs: Hugs allows constructors to be named in an export list, and it shouldn't (see Section 5.2 in The Report, point 2 in the enumerated list). Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: Happy version 1.11
ANNOUNCING Happy 1.11 - The LALR(1) Parser Generator for Haskell - I'm pleased to announce version 1.11 of Happy, the parser generator system for Haskell. This is a minor update from version 1.10, with - a bugfix for using Happy with GHC on 64-bit platforms - a minor change to the way that precedence parsing is handled: tokens no longer have a default precedence. Happy is available in source form, which can be compiled with GHC version 4.xx (4.08+ recommended), and binaries for certain platforms are also provided. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: ANNOUNCE: Happy version 1.11
ANNOUNCING Happy 1.11 - The LALR(1) Parser Generator for Haskell - Owing to a rather embarrassing bug related to precedence parsing in the 1.11 release, I've uploaded new versions of the packages with the bug fixed. My apologies to anyone who already downloaded/installed 1.11 - please re-install with the updated packages. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI Library Task Force
Great. So that is something that goes into some library conventions document. Such a document is here: http://www.haskell.org/~simonmar/libraries/libraries.html If there are comments on the design (which is by no means finalised), please take them to the libraries mailing list. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell tutorial
Just spotted this Haskell tutorial at IBM developerWorks (free registration required): http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-b ytitle/9A31A3C4A0CE683E86256AD400822942?opent=grl,l=805,t=haskell (hope that URL doesn't get mangled by Exchange...). Looks like it's aimed at non-functional-programmers. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GHC doesn't compile Happy example
Carlos Scheidegger writes:
First, the Happy example uses some functions that exist in
Hugs but not in GHC, like isAlpha, isDigit and isSpace (I think so,
at least, because i type ':t isAlpha' in GHCi and get
'variable not in
scope'), so I created a module called CharClasses with these
functions.
This is a long-standing known bug in Hugs. These functions are
available from the Char module.
So, I ran happy and generated calc.hs without any problems.
When I try to compile calc.hs, by doing
ghc -o calc.exe calc.hs CharClasses.hs
I get:
c:/ghc/ghc-
5.02/libHSstd.a(PrelMain__1.o)(.text+0x16)://c/tmp/ghc1756.hc:
undefined reference to `__stginit_Main'
c:/ghc/ghc-
5.02/libHSstd.a(PrelMain__2.o)(.text+0x4)://c/tmp/ghc1756.hc:
undefined reference to `Main_main_closure'
c:/ghc/ghc-
5.02/libHSstd.a(PrelMain__2.o)(.text+0x33)://c/tmp/ghc1756.hc:
undefined reference to `Main_main_closure'
It looks like perhaps the calc.hs module isn't declared as module Main.
Another strange behavior is that I can only call the main function
once. Any other call I get:
Happy main
*** Exception: illegal operation
Action: hGetContents
Handle: {loc=stdin,type=semi-closed,binary=False,buffering=line}
Reason: handle is closed
File: stdin
This is the defined behaviour of getContents: it puts the stdin Handle
in a state known as semi-closed, wherein any further I/O operations on
it are forbidden. Because I/O state is retained between computations,
the semi-closed state persists until the next :load or :reload command.
You can make these handles reset themselves after every evaluation by
giving GHCi the command ':set +r'. This works because stdin, stdout and
stderr are just top-level expressions that can be reverted to their
unevaluated state in the same way as any other top-level expression
(CAF).
Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: suggestion
What do you all think about activating the mechanism that automatically includes the name of the list before the subject of a mailing list email? For example: [hugs-users] Installation problems or [haskell] newbie question. I don't like the extra prefixes, but if most folk would prefer them then I can turn them on. Let me know if you have a preference one way or the other (don't mail to the list). Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Enum class
i_succ' = succ i' -- ghc : 2147483648 -- hugs: -2147483648 -- nhc98: -2147483648 -- hbc: -2147483648 I think Hugs is wrong. Integer shouldn't wrap. (Actually, ghc is `wrong': hbc, hugs and nhc98 match the Report's specification here: succ = toEnum . (+1) . fromEnum This is confirmed by the description of the semantics in section 3.10.) Indeed. But the default definitions of enumFrom friends also don't make much sense for Integer. With nhc98, which presumably is using the default definitions from the report: Prelude [2147483647 .. 2147483649] [] according to the report, this should yield an error (section 6.3.4 states that fromEnum should report an error if its argument is out of range). Both behaviours seem less than useful to me. GHC returns [2147483647, 2147483648, 2147483649], which is also wrong. Is there a good reason why toEnum fromEnum convert to/from Int rather than Integer? Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: bug in displaying fixed numbers
I was very surprised when I discovered (writing a bit more complicated program) that a program like import Numeric ( floatToDigits ) print $ showFFloat Nothing 0.01 enters in to infinite loop. I found that (formatRealFloat FFFixed Nothing) do not like displaying numbers less than 0.1. Yes, the code was recently discovered to be buggy and has been fixed in the revised Haskell 98 report. GHC 5.02 is using the fixed version. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
