September 2001 - Haskell

ANNOUNCE: Happy version 1.11
by Simon Marlow 25 Sep '01

25 Sep '01

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 simonmar(a)microsoft.com.

1 0

ANNOUNCE: Hat and nhc98 version 1.08
by Malcolm Wallace 25 Sep '01

25 Sep '01

Hat + nhc98 version 1.08 ======================== We are pleased to announce a new release of Hat and the nhc98 compiler. This is a stable release, containing many bugfixes in both the compiler and the Hat tracing and debugging tools. If you have not yet tried out the Hat tracing system, this is a good opportunity to give it a workout. New features of note in release 1.08 are: * There are "tunnels" between hat-observe, hat-detect, and hat-trail, enabling the user to jump directly from one view to another at exactly the point of interest. * You can now have multiple copies of hat-trail running simultaneously. * The nhc98 compiler implements the recent revisions of the Haskell'98 Report. nhc98 is a full compiler for Haskell'98, with extensive support for space profiling, time profiling, and tracing your programs. The system is available as source code, which can be built with the Gnu C compiler on any 32-bit platform, or with any already-installed Haskell compiler. Binary packages are also currently available for ix86-Linux and sparc-solaris2. http://www.cs.york.ac.uk/fp/nhc98/ Further information about Hat is available at http://www.cs.york.ac.uk/fp/hat/ Happy tracing, The ART team in York (Malcolm Wallace, Olaf Chitil, Thorsten Brehm, Colin Runciman)

1 0

Re: RFC: GUI Library Task Force
by Ashley Yakeley 25 Sep '01

25 Sep '01

At 2001-09-24 05:44, Manuel M. T. Chakravarty wrote: > *** The GUI Library Task Force Strategy Proposal *** It's worth pointing out that I'm covering much of the same ground with my bridge to the Java VM. http://sourceforge.net/projects/jvm-bridge/ Of course there are differences: >* Development of a GUI library API for Haskell that is > portable across Haskell systems and operating/windowing > systems Same. >* The library focuses on graphical *user interfaces* (ie, > buttons, menus, scrollbars, selection lists, etc) as > opposed to drawing and animation routines. Java has APIs for both, I believe. >* Verification of the design by at least one implementation > of a library that exports the GUI API This has already been done for the Java APIs. >* Minimal use of features that are not included in Haskell > 98 (in fact, we currently believe that we can keep the API > completely free of any non-H98 features; however, > application programs that use the API will need some > non-H98 functionality) I admit I am using some non-H98 features... in fact right now I'm working solely with GHC. >* While we do not require support of concurrency by Haskell > systems implementing the API, the use and behaviour of the > API must be well-defined on systems that do support > concurrency I will be using Java's threading. This means the Haskell system needs to support concurrency. >* Core library: > - Due to the complexity of modern GUIs, we cannot hope to > cover a fully-fledged GUI library in reasonable time and > with reasonably effort; thus, we concentrate on a core > library (what exactly constitutes the core remains to be > defined) Inasmuch as the AWT/JFC/Swing counts as 'fully-fledged', I will have it. >* Openness for tools support; for example, it should be > possible to support graphical interface builders (such > tools are not part of the API, but we need to ensure that > we do not seriously complicate the construction of such > tools) Same. >Non-goals >~~~~~~~~~ >* We will not design a fully-fledged GUI library from > scratch: Hopefully, I will be simply picking up a fully-fledged GUI library. >* We will not design a "purely functional GUI": Same. >The Plan >~~~~~~~~ >* Handling of state altered by both the application and by > GUI widgets: I'm not sure what the issue is here. >* Start from the API of GTK+ as a base line: > - This is an API that has a proven track record of being > suitable for small, medium, and large-scale applications Same for Java. I think. > - The API does not overly rely on object-oriented language > features This is the biggest sticking point for Java. The JVM-Bridge will allow you to create and load Java classes at run-time, even then, this may turn out to be complicated for the user. > - A large body of free documentation exists for the API, > which can be adapted to our purpose Same for Java. http://web2.java.sun.com/docs/books/tutorial/ > - A working Haskell binding exists that can be extended to > provide a first implementation of the Haskell GUI API I don't have anything usable yet. The JVM-Bridge will have to be code-complete before it is usable. > - GTK+ itself is already reasonably platform independent Same or better for Java. >* Ensure platform independence: Same. >* Haskell-ise the API: > - C-ish functionality will be cut out > - Full use will be made of Haskell's type system and, in > particular, type classes Same. >* Convenience libraries >- The API will include a set of convenience libraries on top > of the basic API (eg, by providing layout combinators) A straightforward addition, but not part of my core effort. -- Ashley Yakeley, Seattle WA

3 2

Joy language. Reply
by S.D.Mechveliani 25 Sep '01

25 Sep '01

S. Alexander Jacobson <alex(a)shop.com> writes > I just found out about a functional programming language called > Joy (see http://www.latrobe.edu.au/philosophy/phimvt/joy.html) > > Joy differs from Haskell in that it has no variables. Instead, all > functions are postfix, taking a stack as their argument and returning a > stack as a result. > [..] > tree-rewriting rules go away), faster development, easier optimization > (search and replace lists of functions) and even simple meta-programming. > Here is a quick example program to give a flavor for how it works. > > [1 2 3 4] [dup *] map == [1 2 3 4] [square] map > > is the same as Haskell's > > map (\x->x*x) [1,2,3,4] == map square [1,2,3,4] > [..] They say FP language and internal language of Miranda (S, K combinators) also avoid variables. What is the difference to Joy? I thought it may be a good strategy for a compiler to get free of variables, but it is hard for a programmer to write programs avoiding variables. Is Joy programming a joy? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: RFC: GUI Library Task Force
by cwitty＠newtonlabs.com 24 Sep '01

24 Sep '01

"Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > + More sophisticated approaches (that often require > language extensions or are still experimental) can be > implemented on top of this basic API - eg, FranTk, > Yahu, Fruit, iHaskell, etc. I keep seeing references to Fruit (as a "functional" Haskell GUI) but I can't find any real information about it. Is there a web page for it? Carl Witty

3 2

FW: Literate scripts not handled correctly
by Simon Peyton-Jones 24 Sep '01

24 Sep '01

Folks, Back to the H98 grindstone: > > Then I think hugs and nhc98 are wrong. The report states that the > > unliterate version of the file is recovered by "taking only > those lines > > beginning with '>', and removing the first character of > those lines", > > which would leave the lines indented by a single space, not two. > > This would appear to be an un-remarked change to the Report since > version 1.2. That version states that "program lines have the leading > '>' replaced by a leading space, to preserve tab alignments". Version > 1.3 removed this specification, and the changed specification only > appeared in Haskell'98. This does indeed seem peculiar. I propose to revert to the Haskell 1.2 story, in which '>' is replaced by ' ' (not simply deleted) Not a big issue. Any objections? Simon

1 0

RE: Prelude and (:) and []((:), []) bugs?
by Simon Peyton-Jones 24 Sep '01

24 Sep '01

The Report quite deliberately does not allow you to write the type constructors for built-in syntax in import or export lists. The idea is that the types [Int] and [] Int always mean "list of Int" regardless of what module fiddling you have done. So [] is not an ordinary type constructor, to be imported or hidden at will. It always means "list as defined in the Prelude". I'll add a paragraph to 4.1.2 to make this explicit. Simon | -----Original Message----- | From: Ian Lynagh [mailto:igloo@earth.li] | Sent: 19 September 2001 13:14 | To: haskell(a)haskell.org | Subject: 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? | | | Thanks | Ian | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

Your Bid 4 Placement Account
by AccountInfo＠bid4placement.com 23 Sep '01

23 Sep '01

1 0

Your Bid 4 Placement Account
by AccountInfo＠bid4placement.com 23 Sep '01

23 Sep '01

1 0

Re: Student Programming Projects
by Johannes Waldmann 21 Sep '01

21 Sep '01

> Next Semester, I am supposed to teach a short course in Haskell. > Can anyone recommend interesting programming projects which can > be completed in about a month? Thank you very much. apart from "pure" programming exercise (see Haskell textbooks http://haskell.org/bookshelf/) here are a few suggestions in the area of experimental mathematics. also, check with your introductory discrete mathematics course (or equivalent). a lot of combinatorial problems on finite structures can be illustrated by finding (counter-)examples by computer. say Ramsey colorings, Monochromatic arithmetic subsequences (van der Waerden's theorem), words avoiding patterns, and so on. http://www-igm.univ-mlv.fr/~berstel/Lothaire/ChapitresACW/C3.ps next, perhaps some game theory? nim (and variants), other take-and-break games (octal games). you can safely ignore all of the Sprague-Grundy theory, and just define the game, and ask for some method to determine quickly who wins. or graph theory: finding hamiltonian paths (knights tours on a x b chessboards, for instance) if the students alreay took some computability theory, then a nice topic is Posts Correspondence Problem, see http://www.cs.ualberta.ca/~zhao/PCP/intro.htm http://www.informatik.uni-leipzig.de/~pcp/pcpcontest_en.html also string rewriting: finding/avoiding loops. this (open!) problem is easily stated: http://www.lri.fr/~rtaloop/95.html hope this helps. I'm happy to provide more detail. -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

3 2