Type classes

1997-04-09 Thread Simon L Peyton Jones


Folks,

There's often been quite a bit of discussion on the Haskell mailing list
about extensions of type classes.  Erik Meijer, Mark Jones and I have
written a draft paper that explores the type-class design space, discussing
the various design decisions one must make, and their consequences. 
(Location below.)

One thing the paper needs is more concrete examples.  This message is to
encourage you to grab the paper, and 

a) Check which design choices would permit or prohibit the
   programs you wish you could write in Haskell but can't.
   (For example, many people have asked for multi-parameter
   type classes... but as the paper discusses there are numerous
   other aspects of the type-class system that affect which
   programs are expressible.)

b) Tell us your conclusions, preferably in concrete form. For
   example "The following program requires that we make
   design choice 3b, and not 3a".  (The paper identifies
   9 decisions, and several choices for each decision.)

Of course, any other feedback about the paper would be most gratefully
received too.

The paper will appear in the (informal) proceedings of the Haskell workshop
(7 June in Amsterdam).  We have to produce camera ready copy by 1 May.
So feedback before end April would be most useful.

Simon
===

Type classes: an exploration of the design space
Peyton Jones, Jones, Meijer
http://www.cse.ogi.edu/~simonpj/multi.ps.gz


When type classes were first introduced in Haskell they were regarded as a
fairly experimental language feature, and therefore warranted a fairly
conservative design.  Since that time, practical experience has convinced
many programmers of the benefits and convenience of type classes.  However,
on occasion, these same programmers have discovered examples where seemingly
natural applications for type class overloading are prevented by the
restrictions imposed by the Haskell design.

It is possible to extend the type class mechanisms of Haskell in various
ways to overcome these limitations, but such proposals must be designed with
great care.  For example, several different extensions have been implemented
in Gofer.  Some of these, particularly the support for multi-parameter
classes, have proved to be very useful, but interactions between other
aspects of the design have resulted in a type system that is both unsound
and undecidable.  Another illustration is the introduction of constructor
classes in Haskell 1.3, which came without the proper generalization of the
notion of a context.  As a consequence, certain quite reasonable programs
are not typable.

In this paper we review the rationale behind the design of Haskell's class
system, we identify some of the weaknesses in the current situation, and we
explain the choices that we face in attempting to remove them.






Big heap for a small program

1997-04-09 Thread Marc van Dongen

I just wanted to report that the erroneous and tiny
program added below can not be compiled within 6MB of
heap (Admitted it can be compiled with a bigger heap).
It was part of a bigger program that could not be
compiled within 20MB of heap.

Regards,


Marc van Dongen
[EMAIL PROTECTED]

**
ghc-2.02 -c tmp.lhs  -H6M  -K10M -recomp -v -fglasgow-exts -cpp -hi-diffs 
-ansi -syslib ghc 
The Glorious Glasgow Haskell Compilation System, version 2.02, patchlevel 0

literate pre-processor:
echo '#line 1 "tmp.lhs"'  /tmp/ghc6307.lpp  /usr/local/lib/ghc-2.02/unlit  
tmp.lhs -   /tmp/ghc6307.lpp

real0.1
user0.0
sys 0.0

Haskellised C pre-processor:
echo '#line 1 "tmp.lhs"'  /tmp/ghc6307.cpp  /usr/local/lib/ghc-2.02/hscpp 
-v   -D__HASKELL1__=4 -D__GLASGOW_HASKELL__=202 -I. -I/usr/local/lib/ghc-2.02/includes 
-I/usr/local/lib/ghc-2.02/includes /tmp/ghc6307.lpp  /tmp/ghc6307.cpp

real0.0
user0.0
sys 0.0
hscpp:CPP invoked: /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2/cpp -traditional 
-D__HASKELL1__=4 -D__GLASGOW_HASKELL__=202 -I. -I/usr/local/lib/ghc-2.02/includes 
-I/usr/local/lib/ghc-2.02/includes /tmp/ghc6307.lpp

Haskell compiler:
/usr/local/lib/ghc-2.02/hsc ,-N ,-W ,/tmp/ghc6307.cpp  -fglasgow-exts 
-hisuf-prelude=.hi -hisuf=.hi -fignore-interface-pragmas -fomit-interface-pragmas 
-fsimplify \(  -ffloat-lets-exposing-whnf -ffloat-primops-ok -fcase-of-case 
-freuse-con -fpedantic-bottoms -fsimpl-uf-use-threshold0 -fessential-unfoldings-only 
-fmax-simplifier-iterations4 \)   
-himap=.:/usr/local/lib/ghc-2.02/hslibs/ghc/imports:/usr/local/lib/ghc-2.02/hslibs/ghc/imports:/usr/local/lib/ghc-2.02/imports
   -v -hifile=/tmp/ghc6307.hi -S=/tmp/ghc6307.s +RTS -H600 -K1000
Glasgow Haskell Compiler, version 2.02, for Haskell 1.3

GHC's heap exhausted;
while trying to allocate 12 bytes in a 600-byte heap;
use the `-Hsize' option to increase the total heap size.

real   34.0
user   18.0
sys 0.1
deleting... /tmp/ghc6307.hi /tmp/ghc6307.s

rm -f /tmp/ghc6307*
make: *** [tmp.o] Error 1
**
 module Too_Kuch( too_much ) where

 too_much :: [Int] - [(Int,Int)] - [(Int,[Int])] - Bool
 too_much ds ((k,m):q1) s0
   = case (list1,list2) of
   []  - too_much ds q2m  s2m
   where list1 = [k' | k' - ds, k == k']
 list2 = [k' | k' - ds, m == k']
 s1   = aas s0 k
 raM  = []
 raKM = listUnion (\a b - a) [] []
 s1k  = s1
 q1k  = raM
 s2k  = s1
 q2k  = raM
 s2m  = s1
 q2m  = raM
 s2km = foldr (flip aas) s1 raKM
 q2km = raKM

 listUnion :: (v - v - Bool) - [v] - [v] - [v]
 listUnion _  _ _
   = []

 aas :: (a,b) - a - (a,b)
 aas s _
   = s