Tom Moertel wrote:
> Okay, then, what is the *right* way to reason about these things?
I will take the oppurtunity to advertise some recent work I have been
doing together with David Sands.
I think that the call-by-need lambda calculus is a very good starting
point for gaining intuition about call-by-need beacuse it gives a way to
reason about call-by-need computation at the term level. But the
call-by-need lambda calculus was not designed for reasoning about space -
there are terms which are considered equivalent which when you replace
one by the other in a whole program may change the asymptotic space
behaviour of the program. Therefore, we have been working on a theory of
space equivalence based on an operational semantics for a small subset of
Haskell. We have used the theory to reason about the to different
definitions of the function any that were discussed on the list some
months ago and I think it could be used in this case too. If you are
interested you can find a draft paper at www.cs.chalmers.se/~gustavss/.
We will submit the final version to ICFP in a few weeks so we would be
very grateful for any comments.
Regards,
Jörgen Gustavsson.
From iscp9157@nus.edu.sg Thu Jun 7 03:30:42 2001
From: iscp9157@nus.edu.sg (Saswat Anand)
Date: Wed, 6 Jun 2001 19:30:42 -0700
Subject: Functional Dependency
Message-ID: <001701c0eefa$815d8b80$bd3e8489@saswat>
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C0EEBF.2CC13E40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I am trying to define a commutative operator :
(%+) :: a -> b -> c
(%+) :: b -> a -> c
instead of defining a class and instantiating twice every time, I am =
trying to do the following:
class Commutative a b c where
(%+) :: a -> b -> c
class Operation a b c | a b -> c where
(%+%) :: a -> b -> c
instance (Operation a b c) =3D> Commutative a b c where
(%+) =3D (%+%)
instance (Operation b a c) =3D> Commutative a b c where
(%+) =3D flip (%+%)
--=20
instance Operation Int (Maybe Int) Int where
i %+% (Just s) =3D i + s
---
With hugs -98 +mo
((2::Int) %+ (Just (2::Int)))::Int gives 4
But (2::Int) %+ (Just (2::Int)) is of type Commutative Int (Maybe Int) =
a =3D> a. So is (Just (2::Int)) %+ (2::Int)
Is the dependency in Operation class not sufficient. Any work around?
Which flags to be set for Ghc to accept this code. I tried =
-fallow-overlapping-instances and
-fallow-undecidable-instances.
Thanks,
S
------=_NextPart_000_0007_01C0EEBF.2CC13E40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I am trying to define a =
commutative operator=20
:
(%+) :: a -> b -> c
(%+) :: b -> a ->=20
c
instead of defining a class and =
instantiating twice=20
every time, I am trying to do the following:
class Commutative a b c =
where
(%+) ::=20
a -> b -> c
class Operation a b c | a b -> c=20
where
(%+%) :: a -> b -> c
instance (Operation a b c) =3D> =
Commutative a b c=20
where
(%+) =3D (%+%)
instance (Operation b a c) =3D> =
Commutative a b c=20
where
(%+) =3D flip (%+%)
--
instance Operation Int (Maybe Int) Int=20
where
i %+% (Just s) =3D i + s
---
With hugs -98 +mo
((2::Int) %+ =
(Just=20
(2::Int)))::Int gives 4
But (2::Int) %+ (Just (2::Int)) is of =
type =20
Commutative Int (Maybe Int) a =3D> a. So is (Just (2::Int)) %+=20
(2::Int)
Is the dependency in Operation class =
not=20
sufficient. Any work around?
Which flags to be set for Ghc to accept =
this code.=20
I tried -fallow-overlapping-instances=20
and
-fallow-undecidable-instances.
Thanks,
S
------=_NextPart_000_0007_01C0EEBF.2CC13E40--
From cwitty@newtonlabs.com Wed Jun 6 19:30:34 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 06 Jun 2001 11:30:34 -0700
Subject: Why is there a space leak here?
In-Reply-To: "S. Alexander Jacobson"'s message of "Tue, 5 Jun 2001 15:37:41 -0400 (Eastern Daylight Time)"
References:
Message-ID:
"S. Alexander Jacobson" writes:
> For example w/ foldl:
>
> foldl + 0 [1..10000]
> foldl (+) ((+) 0 1) [2..10000]
> foldl (+) ((+) ((+) 0 1) 2) [3..10000]
>
> Can't the implementation notice that each iteration leads to a
> larger closure and, if it is running out of space go ahead an just
> evaluate (+) 0 1?
It's complicated. You can't (in general) know whether application of
a function will increase or decrease the space used. If you were
running out of space, would you just search the whole unevaluated
program graph for reductions which somehow seemed "likely" to reduce
the space used? Would you add such reduction nodes to some global
list at the time they were created?
> I realize that there is a risk of evaluating _|_ unnecessarily, but if you
> are otherwise going to run out of memory, you might as well give it a
> shot.
>
> In practice, how often do you expect to see growing expressions that cover
> a _|_ that are not actually an error in any case?
It's certainly possible.
One portable way to implement a memoizing function in Haskell (if the
domain of the function is countable) is to lazily build a data
structure that contains the results of the function on every possible
argument. Then you evaluate the portions of the data structure that
you need; the result on each argument is only evaluated once. This
probably would count as a "growing expression", and it's certainly
possible that the function on some arguments would be bottom.
> Hunting down memory leaks is already so obscure, that you might as well
> take a shot at solving the problem automatically...
>
> Alternatively, is there some magical way of warning about leaky
> expressions at compile time? You don't have to ban them, but it would be
> nice if the programmer were aware of which parts of the code are likely to
> grow...
In general, this problem is uncomputable. It might be possible to
come up with some useful approximation, but I bet that's a very
difficult research problem.
Carl Witty
From Malcolm.Wallace@cs.york.ac.uk Thu Jun 7 12:11:12 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 7 Jun 2001 12:11:12 +0100
Subject: Why is there a space leak here? (fwd)
In-Reply-To:
Message-ID:
Hi Claus,
I've had a look at this example in GHood, and you are right, nhc98
does seem to create several copies of v-in.
> import Observe
>
> foo1 m
> = take m (observe "v-out" v)
> where
> v = 1 : concat (map triple (observe "v-in" v))
> triple x = [x,x,x]
>
> main = printO $ (foo1 100::[Int])
> Perhaps Malcolm can explain what nhc98 does with this example?
At a guess, I think the answer lies in lambda-lifting.
nhc98 -c Leak.hs +CTS -lift -CTS
shows this code for `v' (reformatted a little to make it easier to read):
Main.Prelude.173.v = \ v223 v224 ->
Prelude.:
(Prelude._apply1 (Prelude.fromInteger v223) 1L)
(Prelude._apply1
(Prelude.concat)
(Prelude.map (Main.Prelude.174.triple)
(Observe.observe (Observe.Observable.Prelude.[] v224)
(LAMBDA225)
(Prelude._apply2
(Main.Prelude.173.v) v223 v224))))
v takes two arguments; v223 represents the numeric dictionary, and
v224 the Observer dictionary. The recursive reference to v is not
a cyclic pointer to a constant structure, but actually a function call.
I believe the real culprit is that nhc98 does not implement the
monomorphism restriction. IIRC, the DMR applies to every group
of simple pattern bindings at the same let-bound scope, not just
the top-level, so really we ought to default-away the dictionaries,
which would solve this particular space oddity.
Regards,
Malcolm
From giorgio@etabeta.disi.unige.it Thu Jun 7 16:09:58 2001
From: giorgio@etabeta.disi.unige.it (Giorgio Delzanno)
Date: Thu, 7 Jun 2001 17:09:58 +0200 (CEST)
Subject: CFP: ICLP ws SAVE 2001
Message-ID: <200106071509.RAA19748@etabeta.disi.unige.it>
===============================================================================
We apologize for multiple copies of this message
===============================================================================
ICLP 2001 workshop SAVE 2001
Specification, Analysis and Validation for Emerging Technologies
in Computational Logic
http://www.disi.unige.it/person/DelzannoG/save.html
Dec 1, 2001 , Coral Beach Hotel and Resort, Paphos, Cyprus
Submission Deadline: August 25, 2001
The huge increase in interconnectivity we have witnessed in the last decade has boosted the development of
systems which are often large-scale, distributed, time-critical, and possibly acting in an unreliable or malicious
environment. Furthermore, software and hardware components are often mobile, and have to interact with a
potentially arbitrary number of other entities.
These systems require solid formal techniques for their verification and analysis. In this respect, computational
logic plays an increasingly important role, both providing formal methods for proving system's correctness and
tools - e.g. using techniques like constraint programming and theorem proving - for verifying their properties.
In addition, computational logic is gaining importance as tool for the specification of (part) of these systems. For
instance, one can think at the specification, in a form of temporal logic, of a communication protocol. Such
specification offers the advantage that one can reason about it using formal methods, and at the same time it is
often easily executable by rewriting it into a logic-based programming language.
Extending and shifting slightly from the scope of the predecessors (on verification and logic languages) held in
the context of past editions of ICLP, the aim of this workshop is to bring together researchers interested in the
use of computational logicas a tool for the specification, analysis and validation of systems, with particular
emphasis on (but not restricted to) emerging technologies like World Wide Web and E-Commerce, (protocols
for) Smart Cards and Mobile Telephony, Wireless Technology, Hybrid Systems, Real-Time and Distributed
systems etc.
Topics
The topics of interest include but are not limited to:
Specification languages and rapid prototyping:
Logic programming and its extensions
First-order, constructive, modal and temporal logic
Constraints
Type theory
Analysis:
Abstract interpretation
Static analysis
Validation:
Simulation and testing
Deductive methods
Model checking
Theorem proving
The preferred issues include, but are not limited to:
Mobility: specification and verification of mobile code.
Security: access rights, information flow, and security protocols.
Interaction, coordination, negotiation, communication and exchange on the Web.
Open and infinite-state systems.
Real-time systems.
Important Dates:
Deadline for submissions: August 25, 2001.
Notification of acceptance/rejection: September 15, 2001.
Final papers due: October 5, 2001.
Authors should submit papers of at most 15 pages, in postscript format,
formatted for A4 paper, to Giorgio Delzanno (giorgio@disi.unige.it) by
31st July 2001. The proceedings will be published in electronic format.
A printed version will be distributed to all
participants of the workshop.
On the basis of the number and quality of the submissions, we could also consider the
possibility of inviting submissions for a special issue of an international journal
dedicated to the workshop.
Workshop Organizers/PC Chairs:
Giorgio Delzanno
Dipartimento di Informatica e Scienze dell'Informazione
Universita' di Genova
giorgio@disi.unige.it
Sandro Etalle
Department of Computer Science
University of Twente and CWI
etalle@cs.utwente.nl
Maurizio Gabbrielli
Dipartimento di Matematica ed Informatica
Universita' di Udine
gabbri@dimi.uniud.it
Program Committee:
Radhia Cousot, CNRS & École Polytechnique, France
Giorgio Delzanno, University of Genova, Italy
Sandro Etalle, University of Twente and CWI, The Netherlands
Maurizio Gabbrielli, University of Udine, Italy
Thierry Massart, University of Brussels, Belgium
Frank Pfenning, Carnegie Mellon University, USA
Andreas Podelski, Max Planck Institute, Germany
Sriram Rajamani, Microsoft Research, USA
Jean-Francois Raskin, University of Brussels, Belgium
From alex@shop.com Fri Jun 8 15:41:48 2001
From: alex@shop.com (S. Alexander Jacobson)
Date: Fri, 8 Jun 2001 10:41:48 -0400 (Eastern Daylight Time)
Subject: Why is there a space leak here?
In-Reply-To:
Message-ID:
On 6 Jun 2001, Carl R. Witty wrote:
> "S. Alexander Jacobson" writes:
>
> > For example w/ foldl:
> >
> > foldl + 0 [1..10000]
> > foldl (+) ((+) 0 1) [2..10000]
> > foldl (+) ((+) ((+) 0 1) 2) [3..10000]
> >
> > Can't the implementation notice that each iteration leads to a
> > larger closure and, if it is running out of space go ahead an just
> > evaluate (+) 0 1?
>
> It's complicated. You can't (in general) know whether application of
> a function will increase or decrease the space used. If you were
> running out of space, would you just search the whole unevaluated
> program graph for reductions which somehow seemed "likely" to reduce
> the space used? Would you add such reduction nodes to some global
> list at the time they were created?
I'm not clear why you can't in general notice that you are using
more space after function application than before. I it hard to see why a
program couldn't do the analysis I just did on foldl.
You could accumulate statistics on funtions that increase/decrease space
used at runtime and evaluate those that do reduce space used...
> > I realize that there is a risk of evaluating _|_ unnecessarily, but if you
> > are otherwise going to run out of memory, you might as well give it a
> > shot.
> >
> > In practice, how often do you expect to see growing expressions that cover
> > a _|_ that are not actually an error in any case?
>
> It's certainly possible.
You are trading off the likelihood that an exploding expression contains a
bottom against the liklihood that the programmer would prefer the
exploding expression not to explode. Much of this type of work can be
done as test-time warnings....
> One portable way to implement a memoizing function in Haskell (if the
> domain of the function is countable) is to lazily build a data
> structure that contains the results of the function on every possible
> argument. Then you evaluate the portions of the data structure that
> you need; the result on each argument is only evaluated once. This
> probably would count as a "growing expression", and it's certainly
> possible that the function on some arguments would be bottom.
I don't think I understood this. Can you clarify?
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
From jcab@roningames.com Sun Jun 10 03:39:42 2001
From: jcab@roningames.com (Juan Carlos Arevalo Baeza)
Date: Sat, 09 Jun 2001 19:39:42 -0700
Subject: Why is there a space leak here?
In-Reply-To:
References:
Message-ID: <4.3.2.7.2.20010609192951.03907a70@207.33.235.243>
At 10:41 AM 6/8/2001 -0400, S. Alexander Jacobson wrote:
> > One portable way to implement a memoizing function in Haskell (if the
> > domain of the function is countable) is to lazily build a data
> > structure that contains the results of the function on every possible
> > argument. Then you evaluate the portions of the data structure that
> > you need; the result on each argument is only evaluated once. This
> > probably would count as a "growing expression", and it's certainly
> > possible that the function on some arguments would be bottom.
>
>I don't think I understood this. Can you clarify?
I believe I know what he's talking about. The example I've read about
this technique is random-number generators. Because typical generators will
need a state (the seed), they can be awkward to use in functional
languages. Instead, you can just generate an infinite list of the random
numbers, and extract them from that list lazily.
Specifically, what he's talking about is the fact that a function like
"Natural -> a" corresponds to a list where all the possible results for
each number are stored in the corresponding position in the list. If you
generate that list lazily, and then access it, each element will only be
computed once (the compiler/interpreter takes care of this in a very
natural way). But if you do this, the program will (or can) grow as more
elements get computed.
Am I making sense?
Salutaciones,
JCAB
---------------------------------------------------------------------
Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com
Senior Technology programmer | mailto:jcab@roningames.com
Ronin Entertainment | ICQ: 10913692
(my opinions are only mine)
JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html
From ashley@semantic.org Sun Jun 10 06:55:48 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Sat, 9 Jun 2001 22:55:48 -0700
Subject: Monomorphism Restriction
Message-ID: <200106100555.WAA05519@mail4.halcyon.com>
Is there a point to the "monomorphism restriction" in GHC and Hugs? In
practice, all it seems to mean is "occasionally require unnecessary
explicit type signatures".
--
Ashley Yakeley, Seattle WA
From bjpop@cs.mu.OZ.AU Mon Jun 11 05:34:23 2001
From: bjpop@cs.mu.OZ.AU (Bernard James POPE)
Date: Mon, 11 Jun 2001 14:34:23 +1000 (EST)
Subject: Monomorphism Restriction
Message-ID: <200106110434.OAA06216@mulga.cs.mu.OZ.AU>
Ashley Yakeley, Seattle WA, writes:
> Is there a point to the "monomorphism restriction" in GHC and Hugs? In
> practice, all it seems to mean is "occasionally require unnecessary
> explicit type signatures".
I think the point is made clearly enough in section 4.5.5 of the Haskell 98
language report, you can find it at www.haskell.org. Whether you are
satisified with this explanation is another matter.
Regards Bernie.
From kahl@heraklit.informatik.unibw-muenchen.de Mon Jun 11 10:22:38 2001
From: kahl@heraklit.informatik.unibw-muenchen.de (kahl@heraklit.informatik.unibw-muenchen.de)
Date: 11 Jun 2001 09:22:38 -0000
Subject: Haskell 98 Report
In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com>
(simonpj@microsoft.com)
References: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <20010611092238.11279.qmail@demokrit.informatik.unibw-muenchen.de>
Simon Peyton-Jones wrote:
> I've finished what I hope is the final version of the Haskell 98
> Language and Library Reports
> http://research.microsoft.com/~simonpj/haskell98-revised
haskell98-library-html/index.html still contains the following line:
The Haskell Library Report 1.4
By my count, it should be ``1.6'' ;-)
Cheers,
Wolfram
From radhia@lix.polytechnique.fr Sat Jun 9 19:38:00 2001
From: radhia@lix.polytechnique.fr (radhia@lix.polytechnique.fr)
Date: Sat, 9 Jun 2001 20:38:00 +0200 (CEST)
Subject: SAS'01: Early registration 15th June
Message-ID: <200106091838.UAA11019@albatros.polytechnique.fr>
___________________________________________________________________________
[We apologize for any inconvience caused by multiple copies]
SAS'01
Eigth International Static Analysis Symposium
La Sorbonne, Paris, 16-18 July, 2001
http://www.ens.fr/sas01/
Registration information is available on the SAS'01 website.
Early registration ends soon (15th June).
___________________________________________________________________________
From claire@CoLi.Uni-SB.DE Mon Jun 11 09:46:06 2001
From: claire@CoLi.Uni-SB.DE (Claire Gardent)
Date: Mon, 11 Jun 2001 10:46:06 +0200 (MET DST)
Subject: CFP ESSLLI02 (Trento, Italy)
Message-ID:
[An HTML version of the Call for Proposals is available via the
FoLLI page .
Usual apologies apply if you receive multiple copies of this message.]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Fourteenth European Summer School in Logic, Language and Information
ESSLLI-2002
August 4-17, 2002, Trento, Italy
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
CALL FOR COURSE and WORKSHOP PROPOSALS
--------------------------------------
The main focus of the European Summer Schools in Logic, Language and
Information is on the interface between linguistics, logic and
computation. Foundational, introductory and advanced courses together
with workshops cover a wide variety of topics within the three areas
of interest: Language and Computation, Language and Logic, and Logic
and Computation.
Previous summer schools have been highly successful, attracting up to
500 students from Europe and elsewhere. The school has developed into
an important meeting place and forum for discussion for students and
researchers interested in the interdisciplinary study of Logic,
Language and Information. ESSLLI-2002 is organised under the auspices
of the European Association for Logic, Language and Information
(FoLLI).
The ESSLLI-2002 Programme Committee invites proposals for foundational,
introductory, and advanced courses, and for workshops for the 14th annual
Summer School on a wide range of topics in the following fields:
LANGUAGE & COMPUTATION LANGUAGE & LOGIC LOGIC & COMPUTATION
In addition to courses and workshops there will be a Student Session. A Call
for Papers for the Student Session will be distributed separately.
PROPOSAL SUBMISSION: Proposals should be submitted through a web form located
at
All proposals should be submitted no later than July 22, 2001.
Authors of proposals will be notified of the committee's decision no
later than September 17, 2001. Proposers should follow the guidelines
below while preparing their submissions; proposals that deviate can
not be considered.
GUIDELINES FOR SUBMISSION: Anyone interested in lecturing or organising a
workshop during ESSLLI-2002, please read the following information carefully.
ALL COURSES: Courses are taught by 1 or max. 2 lecturers. They typically
consist of five sessions (a one-week course) or ten sessions (a two-week
course). Each session lasts 90 minutes.
Timetable for Course Proposal Submission:
Jul 22, 2001: Proposal Submission Deadline
Sep 17, 2001: Notification
Nov 15, 2001: Deadline for receipt of title, abstract, lecturer(s)
information, course description and prerequisites
Jun 1, 2002: Deadline for receipt of camera-ready course material
FOUNDATIONAL COURSES: These are really elementary courses not assuming any
background knowledge. They are intended for people to get acquainted with the
problems and techniques of areas new to them. Ideally, they should allow
researchers from other fields to acquire the key competences of neighbouring
disciplines, thus encouraging the development of a truly interdisciplinary
research community. Foundational courses may presuppose some experience with
scientific methods in general, so as to be able to concentrate on the issues
that are germane to the area of the course.
INTRODUCTORY COURSES: Introductory courses are central to the
activities of the Summer School. They are intended to equip students
and young researchers with a good understanding of a field's basic
methods and techniques. Introductory courses in, for instance,
Language and Computation, can build on some knowledge of the component
fields; e.g., an introductory course in computational linguistics
should address an audience which is familiar with the basics of
linguistics and computation.
Proposals for introductory courses should indicate the level of
the course as compared to standard texts in the area.
ADVANCED COURSES: Advanced courses should be pitched at an audience of
advanced Masters or PhD students. Proposals for advanced courses
should specify the prerequisites in some detail.
WORKSHOPS: The aim of the workshops is to provide a forum for advanced
Ph.D. students and other researchers to present and discuss their
work. A workshop has a theme. At most one organiser is paid. The
organisers should be specialists in the theme of the workshop and give
a general introduction in the first session. They are also
responsible for the programme of the workshop, i.e., for finding
speakers.
Each workshop organiser will be responsible for producing a Call for
Papers for the workshop by November 15, 2001. The call must make it
clear that the workshop is open to all members of the LLI community.
It should also note that all workshop contributors must register for
the Summer School.
A workshop consists of five sessions (a one-week workshop) or ten
sessions (a two-week workshop). Sessions are normally 90 minutes.
Timetable for Workshop Proposal Submissions
Jul 22, 2001: Proposal Submission Deadline
Sep 15, 2001: Notification
Nov 15, 2001: Deadline for receipt of Call for Papers
Dec 1, 2001: Send out Call for Papers
Mar 15, 2002: Deadline for Papers (suggested)
May 1, 2002: Notification of Workshop Contributors (suggested)
May 15, 2002: Deadline for Provisional Workshop Programme
Jun 1, 2002: Deadline for receipt of camera-ready copy of Workshop
notes
Jun 1, 2002: Deadline for Final Workshop Programme
FORMAT FOR PROPOSALS:
The web-based form for submitting course and workshop proposals is accessible
at . You will be required
to submit the following information:
* Name (name(s) of proposed lecturer(s)/organiser)
* Address (contact addresses of proposed lecturer(s)/organiser;
where possible, please include phone and fax numbers)
* Title (title of proposed course/workshop)
* Type (is this a workshop, a foundational course, an introductory
course, or an advanced course?)
* Section (does your proposal fit in Language & Computation,
Language & Logic or Logic & Computation? name only one)
* Description (describe the proposed contents in at most 150 words)
* External funding (will you be able to find external funding to
help fund your travel and accommodation expenses? if so, how?)
* Further particulars (any further information that is required by
the above guidelines should be included here)
FINANCIAL ASPECTS: Prospective lecturers and workshop organisers
should be aware that all teaching and organising at the summer schools
is done on a voluntary basis in order to keep the participants fees as
low as possible. Lecturers and organisers are not paid for their
contribution, but are reimbursed for travel and accommodation. Please
note the following: In case a course is to be taught by two lecturers,
a lump sum is paid to cover travel and accommodation expenses. The
splitting of the sum is up to the lecturers. However, please note
that the organisers highly appreciate it if, whenever possible,
lecturers and workshop organisers find alternative funding to cover
travel and accommodation expenses.
Workshop speakers are required to register for the Summer School;
however, workshop speakers will be able to register at a reduced rate
to be determined by the Organising Committee.
Finally, it should be stressed that while proposals from all over the
world are welcomed, the Summer School can in general guarantee only to
reimburse travel costs for travel from destinations within Europe to
Trento. Exceptions will be made depending on the financial situation.
PROGRAM COMMITTEE:
Claire Gardent (chair)
Attn: ESSLLI-2002
LORIA
BP 239 Campus Scientifique
54506 Vandoeuvre-les-Nancy (France)
Tel: +33-3-83-59-2039
Fax: +33-3-83-27-5652
Email: claire.gardent@loria.fr
Local co-chair:
Paolo Bouquet (bouquet@cs.unitn.it)
Language & Computation:
Hinrich Schuetze (me@hinrichschuetze.com)
Gerry Altmann (g.altmann@psych.york.ac.uk)
Language & Logic:
Fabio Pianesi (pianesi@irst.itc.it)
Steve Pulman (stephen.pulman@somerville.ox.ac.uk)
Logic & Computation:
Simon Parsons (S.D.Parsons@csc.liv.ac.uk )
Frank Wolter (wolter@jaist.ac.jp)
ORGANISING COMMITTEE:
Luciano Serafini (chair)
Email: serafini@itc.it
FURTHER INFORMATION: To obtain further information, visit the web site
for ESSLLI-2002 .
For this year's summer school, please see the web site for ESSLLI-2001
.
http://www.loria.fr/~gardent
From cwitty@newtonlabs.com Mon Jun 11 23:58:14 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 11 Jun 2001 15:58:14 -0700
Subject: Why is there a space leak here?
In-Reply-To: "S. Alexander Jacobson"'s message of "Fri, 8 Jun 2001 10:41:48 -0400 (Eastern Daylight Time)"
References:
Message-ID:
"S. Alexander Jacobson" writes:
> On 6 Jun 2001, Carl R. Witty wrote:
>
> > "S. Alexander Jacobson" writes:
> >
> > > For example w/ foldl:
> > >
> > > foldl + 0 [1..10000]
> > > foldl (+) ((+) 0 1) [2..10000]
> > > foldl (+) ((+) ((+) 0 1) 2) [3..10000]
> > >
> > > Can't the implementation notice that each iteration leads to a
> > > larger closure and, if it is running out of space go ahead an just
> > > evaluate (+) 0 1?
> >
> > It's complicated. You can't (in general) know whether application of
> > a function will increase or decrease the space used. If you were
> > running out of space, would you just search the whole unevaluated
> > program graph for reductions which somehow seemed "likely" to reduce
> > the space used? Would you add such reduction nodes to some global
> > list at the time they were created?
>
> I'm not clear why you can't in general notice that you are using
> more space after function application than before. I it hard to see why a
> program couldn't do the analysis I just did on foldl.
I wasn't worried about foldl; you assumed that (+) 0 1 got smaller if
you carried out the application. Even for (+) on Integer, this is not
guaranteed (for large integers, if something else happens to be
holding on to the summands, evaluating the addition can increase total
space usage).
> You could accumulate statistics on funtions that increase/decrease space
> used at runtime and evaluate those that do reduce space used...
Right, that's the sort of thing I meant about "likely" above. But how
do you find such function applications in the global program graph, if
you seem to be running low on space? (And you also need to realize
that some functions might usually have "small" outputs, and sometimes
have "large" outputs.)
> > One portable way to implement a memoizing function in Haskell (if the
> > domain of the function is countable) is to lazily build a data
> > structure that contains the results of the function on every possible
> > argument. Then you evaluate the portions of the data structure that
> > you need; the result on each argument is only evaluated once. This
> > probably would count as a "growing expression", and it's certainly
> > possible that the function on some arguments would be bottom.
>
> I don't think I understood this. Can you clarify?
Let me know if JCAB's response wasn't enough here.
Carl Witty
From heron_carvalho@bol.com.br Thu Jun 14 14:02:18 2001
From: heron_carvalho@bol.com.br (Heron)
Date: Thu, 14 Jun 2001 10:02:18 -0300
Subject: Ray Tracing
Message-ID: <002401c0f4d2$400bd280$66a1fea9@heron>
This is a multi-part message in MIME format.
------=_NextPart_000_0021_01C0F4B9.18E100E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Haskell & GHC people,
I need the source code of a Ray Tracing written in Haskell. This =
code was used for parallelization using Caliban and Eden. Can you help =
me on how or where I can obtain it ?
Heron de Carvalho, Msc.
------=_NextPart_000_0021_01C0F4B9.18E100E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Haskell=20
& GHC people,
I need =
the source=20
code of a Ray Tracing written in Haskell. This code was =
used for=20
parallelization using Caliban and Eden. Can you help me on how or where =
I can=20
obtain it ?
Heron de Carvalho, =
Msc.
------=_NextPart_000_0021_01C0F4B9.18E100E0--
From simonpj@microsoft.com Fri Jun 15 17:21:39 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 15 Jun 2001 09:21:39 -0700
Subject: Eq instance for (a,b,c,d,e) and upwards
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D730AA@red-msg-09.redmond.corp.microsoft.com>
Folks
It seems that people are happy with the draft Haskell report (I'm=20
glad to say). There seem to be two outstanding issues:
* Tuples. I've decided to specify that tuples up to size 15 exist,
along with all their Eq, Ord, etc instances up to that size.
* The Prelude types of=20
deleteBy
deleteFirstsBy
intersectBy
Although these could be given more general types, it's an
unforced change, and Fergus points out that the more general
types could change error messages for the worse. I'm going to=20
let sleeping dogs lie and make no change here. [Recall that
no-change is the *strong* default.]
The final version of everything is at
http://research.microsoft.com/~simonpj/haskell98-revised
I'm ready to call it a day, but of course I may have made some=20
stupid error. Take a look please and let me know.
I have not yet made PDF; there are issues I don't understand
about how to get PDF to look right. Help sought!
Simon
From patrikj@cs.chalmers.se Mon Jun 18 09:48:04 2001
From: patrikj@cs.chalmers.se (Patrik Jansson)
Date: Mon, 18 Jun 2001 10:48:04 +0200 (MET DST)
Subject: Haskell report typo (bad law for readsPrec)
In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D730AA@red-msg-09.redmond.corp.microsoft.com>
Message-ID:
In short: change the eq. for readsPrec in appendix D.4
In detail:
>From "The Haskell 98 Report: Derived Instances: D.4"
...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty. It
should be the case that
fst (head (readsPrec d (showsPrec d x r))) == x
That is, readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...
Note that the equation stated is not true unless the string r starts with
some token-ending combination.
Counter-examples:
> testreadshow :: (Show a, Read a) => a -> String -> a
> testreadshow x r = fst (head (readsPrec 0 (showsPrec 0 x r)))
A simple one that just fails: the problem is that "Nothingx" can't be
parsed.
> bad1 :: Maybe Int
> bad1 = testreadshow Nothing "x"
> test1 = bad1 == Nothing
Using this we can make the law really false by inventing a datatype
where one constructor is a prefix of another constructor:
> data T = Bad | Badger deriving (Show, Read, Eq)
> bad2 = testreadshow Bad "ger"
> test2 = bad2 == Bad
Actually there is a predefined type with lots of constructors (Int)
where many values are prefixes of others:
> bad3 :: Int
> bad3 = testreadshow 1 "2"
> test3 = bad3 == 1
> main = do print (bad3, test3)
> print (bad2, test2)
> print (bad1, test1)
OK, so the falsity of the claim is proved - what could we write instead?
The sentence explaining the equation is correct:
... readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
Thus a simple way out is to remove the equation and the preceding
sentence leaving the paragraph as:
[Alternative A:]
...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty.
Function readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...
Another simple alternative is to weaken the the equation by replacing
the variable r by the empty string:
[Alternative B:]
...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty. It
should be the case that
fst (head (readsPrec d (showsPrec d x ""))) == x
That is, readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...
[Alternative C:]
A third alternative would be to keep the equation unchanged but to add
the requirement that the string variable r should start with a "token
ending sequence of characters". But what does "token" mean? As an
explanation it might be OK, but the report should be pretty formal and
self-contained so I think this is might be undesirable.
A more complicated alternative would be to state (in words or in
equations) a more detailed correctness requirement, but I think that
would lead too far. The Haskell Show and Read classes are not detailed
enough to capture this - we would need a standardized level of
tokenizing (lexing) and this is clearly out of the scope for any
report changes at this stage.
My vote is for [Alternative B] - weaken the equation, but keep it as a
help to understand the interplay between showsPrec and readsPrec.
/Patrik Jansson
From denicola@dsi.unifi.it Fri Jun 15 08:37:38 2001
From: denicola@dsi.unifi.it (Rocco De Nicola)
Date: Fri, 15 Jun 2001 09:37:38 +0200
Subject: PLI 2001 in Firenze
Message-ID:
CALL FOR PARTICIPATION AND EARLY REGISTRATION
PLI 2001
Principles, Logics, and Implementations
of high-level programming languages
Firenze, ITALY September 2 - 8, 2001
http://music.dsi.unifi.it/pli01/
The colloquium on Principles, Logics, and Implementations of high-
level programming languages is a collection of events aimed at the
advancement of high-level programming languages.
PLI 2001 includes the following conferences and workshops:
ACM Sponsored Conferences:
ICFP (September 3-5)
Int. Conf. on Functional Programming
General chair: Benjamin Pierce (Univ. Pennsylvania)
Program chair: Xavier Leroy (INRIA Rocquencourt)
Invited speakers: To be announced
PPDP (September 5-7)
Int. Conf. on Principles and Practice of Declarative Programming
Conference chair: Rocco De Nicola (Univ. Firenze)
Program chair: Harald S=F8ndergaard (Univ. Melbourne)
Invited speakers: J. Esparza, A. Gordon, and D.A. Schmidt.
ACM Sponsored Workshops:
=B7 BABEL (Multi-language Infrastructure and Interoperability)
=B7 HASKELL
=B7 QAPL (Quantitative Aspects of Programming Languages)
=B7 RULE (Rule-Based Programming)
=B7 SAIG (Semantics, Applications, and Implementation of Program
Generation)
=B7 SCHEME (Scheme and Functional Programming)
=B7 VCL (Verification and Computational Logic)
Co-located Workshops:
=B7 ERLANG
=B7 FICS (Fixed Points in Computer Science)
A detailed presentation of PLI2001, including schedule of events,
travel and tourist information, is available at the WEB page
http://music.dsi.unifi.it/pli01/.
Registration and accommodation information and forms are available at
http://music.dsi.unifi.it/pli01/registration/
Early registration rates apply until July 25.
=46or informations about hotels please contact (mentioning PLI 2001)
Giubbi Jet di Volo Viaggi
Piazza San Jacopino, 34/r - 50144 Firenze
Telephone: +39 055 3249074 - +39 055 350577
Fax: +39 055 366807
E-mail: incoming@voloviaggi.com
=46or all other informations mail to pli-org@gdn.dsi.unifi.it
-------------------------------------------------------------------
=46irenze is packed in September; do book accommodation as soon as possible.
-------------------------------------------------------------------
--
<><><><><><><><><><><><><><><><><><><><><><><><><><>
Prof. Rocco De Nicola
Dip. Sistemi e Informatica Univ. di Firenze
Via C. Lombroso 6/17 I-50134 FIRENZE (ITALY)
tel. +39 055 4796733 fax +39 055 4796730
Web Page: http://www.dsi.unifi.it/~denicola/
<><><><><><><><><><><><><><><><><><><><><><><><><><>
From simonpj@microsoft.com Mon Jun 18 10:28:19 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 18 Jun 2001 02:28:19 -0700
Subject: Haskell report typo (bad law for readsPrec)
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D730B5@red-msg-09.redmond.corp.microsoft.com>
| Another simple alternative is to weaken the the equation by=20
| replacing the variable r by the empty string: [Alternative B:]
|=20
| ...
| should be the case that
|=20
| fst (head (readsPrec d (showsPrec d x ""))) =3D=3D x
Yes, I like this alternative too. I'll implement it.
Thank you for spotting it.
Simon
From johan@jeuring.net Mon Jun 18 12:17:11 2001
From: johan@jeuring.net (Johan Jeuring)
Date: Mon, 18 Jun 2001 13:17:11 +0200
Subject: Working Conference on Generic Programming: first call for
papers
Message-ID: <20010618111707.85D844518@mail.cs.uu.nl>
WCGP '02
IFIP TC2 Working Conference on
GENERIC PROGRAMMING
http://www.generic-programming.nl/wcgp/cfp.html
Organised in conjunction with MPC'02
July 8 - July 13, 2002
Dagstuhl, Germany
CALL FOR PAPERS
Generic programming is about making programs more
adaptable by making them more general. Generic
programs often embody non-traditional kinds of
polymorphism; ordinary programs are obtained from
them by suitably instantiating their parameters.
In contrast with normal programs, the parameters
of a generic programs are often quite rich in
structure. For example they may be other programs,
types or type constructors, class hierarchies, or
even programming paradigms.
Generic programming techniques have always been of
interest, both to practitioners and to theoreticians,
but only recently have generic programming
techniques become a specific focus of research in
the functional and object-oriented programming
language communities. This working conference will
bring together leading researchers in generic
programming from around the world, and feature
papers capturing the state of the art in this
important emerging area.
We welcome contributions on all aspects, theoretical
as well as practical, of generic programming,
aspect-oriented programming, polytypic programming,
adaptive object-oriented programming, generic
components, and so on.
SUBMISSION
Full papers should be submitted in Postscript or pdf
format by e-mail to reach Jeremy.Gibbons@comlab.ox.ac.uk
by February 16, 2002. The details of the submission
procedure can be found at
http://www.generic-programming.nl/wcgp/submit.html
Although there is no page limit, submissions should
strive for brevity and clarity.
IMPORTANT DATES
Submission February 16, 2002
Notification April 12, 2002
Final version due May 24, 2002
PROGRAMME COMMITTEE
Matt Austern
Eerke Boiten
Ulrich Eisenecker
Jeremy Gibbons (co-chair)
Ralf Hinze
Johan Jeuring (co-chair)
Gary Leavens
Karl Lieberherr
Lambert Meertens
Eugenio Moggi
Bernhard Moeller
Oege de Moor
David Musser
Martin Odersky
Ross Paterson
Simon Peyton Jones
Colin Runciman
Doaitse Swierstra
Stephanie Weirich
LOCAL ORGANISATION
Jeremy Gibbons
Johan Jeuring
Bernhard Moeller
CORRESPONDENCE
Jeremy Gibbons (Jeremy.Gibbons@comlab.ox.ac.uk)
Johan Jeuring (johan@jeuring.net)
From kh@dcs.st-and.ac.uk Mon Jun 18 15:30:19 2001
From: kh@dcs.st-and.ac.uk (Kevin Hammond)
Date: Mon, 18 Jun 2001 15:30:19 +0100
Subject: 3 Lectureships at St Andrews
Message-ID:
St Andrews University has three lectureships available in Computer Science.
We are
looking for good researchers, with an emphasis on practical skills:
functional programmers
would obviously be very good from my perspective! The deadline is the 22nd
of June, but
a late application may be acceptable if there is a good reason. Further
details are available at.
http://www.dcs.st-and.ac.uk/jobs/#lec
or send me email if you'd like to discuss it. The salary is on the
standard UK Lecturer scale:
currently UK pounds 18,731 to 30,967
Best Wishes,
Kevin
From kh@dcs.st-and.ac.uk Mon Jun 18 15:37:38 2001
From: kh@dcs.st-and.ac.uk (Kevin Hammond)
Date: Mon, 18 Jun 2001 15:37:38 +0100
Subject: Ray Tracing
In-Reply-To: <002401c0f4d2$400bd280$66a1fea9@heron>
Message-ID:
At 10:02 am -0300 14/6/01, Heron wrote:
> Hello Haskell &=A0GHC=A0people, =A0 =A0=A0=A0=A0=A0 I need the source =
code of a Ray
>Tracing written in Haskell.=A0This=A0code was used=A0for parallelization u=
sing
>Caliban and Eden. Can you help me on how or where I can obtain it ? =A0
>Heron de Carvalho, Msc.
Yes, we can let you have the sources (there are two different versions, one
with spheres
originally written in Id, the other is the one derived from Caliban).
Hans-Wolfgang Loidl is
probably the best contact, failing which I will look through my own archives=
=2E
Best Wishes,
Kevin
From v-julsew@microsoft.com Mon Jun 18 15:46:42 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Mon, 18 Jun 2001 07:46:42 -0700
Subject: GHC version 5.00.2 is available
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60302A9E9@red-msg-06.redmond.corp.microsoft.com>
The (Interactive) Glasgow Haskell Compiler -- version 5.00.2
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 5.00.2. The source distribution is
freely available via the World-Wide Web and through anon. FTP, under a
BSD-style license. See below for download details. Pre-built
packages for Linux, FreeBSD, and Solaris(sparc) are also available.
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.
GHC is a state-of-the-art programming suite for Haskell. Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, C++, whatever).
A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page at
http://www.haskell.org/
GHC's Web page lives at
http://www.haskell.org/ghc/
What's new in 5.00.2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Fixed a few more bugs which turned out to be showstoppers for various
people. Symptoms of the fixed bugs are:
* Panics in the bytecode (interactive) linker (two different bugs).
* Compiled code dies with a segfault (two different bugs).
* Interpreted code crashes or acts weird.
* A panic in the CPR analyser.
* An infinite loop in the strictness analyser.
* Nested comments are not properly handled during module chasing.
* :module command doesn't accept underscores in module names.
* -L doesn't work on the ghci command line.
* Posix.executeFile mistakenly propagates SIGVTALRM to children.
* Exceptions during an interactive session cause the UI to forget
some important state information.
* (a new feature) Packages can now loaded at the ghci prompt.
Do ":s -package ".
What's new in 5.00.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This is a bug-fix release. Most reported bugs in 5.00 have been
fixed, including a substantial number of show-stopping bugs. The
system should be much more usable for more people. Upgrading to
5.00.1 is recommended. To all those who tried out 5.00 and reported
bugs, we thank you for your feedback and patience.
At the moment there is no Win32 build of 5.00 or 5.00.1 available. We
decided to push Win32 support to the 5.02 release, so as not to delay
5.00.1 any further.
What's new in 5.00
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.00 has been majorly revamped since the previous stable version,
4.08.2.
This should be a stable release. Major changes since 4.08.2 are:
- An interactive system, similar in style to Hugs. You can
interactively
load and unload modules, run expressions, ask the types of things.
Module dependencies are tracked and chased automatically.
Combinations of compiled and interpreted modules may be used.
All the GHC libraries are available in interactive mode, as are
most of the Glasgow extensions to Haskell 98. Compilation in
interactive mode (to bytecode) is about three times faster than
compiling to object code.
- Batch compilation of multiple modules at once, with automatic
dependency chasing. For large programs this can halve compilation
times, and removes the need for Makefiles.
- Enhanced package (library) management system. Packages may be
installed and removed from an installation using the ghc-pkg tool.
- Initial Unicode support - the Char type is now 31 bits.
- Sparc native code generator, giving much faster compilation on
sparcs.
(Native code generation for x86s has been available for a while).
- Improved heap profiling - you can restrict heap profiles
by type, closure description, cost centre, and module.
- Support for the latest Foreign Function Interface (FFI)
proposals. Marcin Kowalczyk's hsc2hs tool is included.
- Language extensions: parallel list comprehensions and functional
dependencies.
- The usual huge collection of bug fixes. Most reported bugs have
been fixed.
For full details see the release notes:
http://www.haskell.org/ghc/docs/5.00/set/release-5-00.html
How to get it
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The easy way is to go to the WWW page, which should be
self-explanatory:
http://www.haskell.org/ghc/
We supply binary builds in .rpm/.deb form for all you Linux junkies
out there, and in InstallShield form for Windows folks. Everybody
else gets a .tar.gz which can be installed where you want.
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release.
On-line GHC-related resources
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
Relevant URLs on the World-Wide Web:
GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html
System requirements
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To compile programs with GHC, you need a machine with 32+MB memory, GNU
C
and perl. This release is known to work on the following platforms:
* i386-unknown-{linux,freebsd,mingw32}
* sparc-sun-solaris2
Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:
* hppa1.1-hp-hpux{9,10}
* i386-unknown-solaris2
* alpha-dec-osf{2,3}
* mips-sgi-irix{5,6}
* {rs6000,powerpc}-ibm-aix
The builder's guide included in distribution gives a complete
run-down of what ports work; an on-line version can be found at
http://www.haskell.org/ghc/docs/5.00/building/building-guide.html
Mailing lists
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see
http://www.haskell.org/mailman/listinfo/
Please send bug reports about GHC to glasgow-haskell-bugs@haskell.org;
GHC users hang out on glasgow-haskell-users@haskell.org. Bleeding
edge CVS users party on cvs-ghc@haskell.org.
From jcab@roningames.com Mon Jun 18 21:16:01 2001
From: jcab@roningames.com (Juan Carlos Arevalo Baeza)
Date: Mon, 18 Jun 2001 13:16:01 -0700
Subject: GHC version 5.00.2 is available
In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60302A9E9@red-msg-06.redmon
d.corp.microsoft.com>
Message-ID: <4.3.2.7.2.20010618131134.02aa3f08@207.33.235.243>
At 07:46 AM 6/18/2001 -0700, Julian Seward (Intl Vendor) wrote:
>The (Interactive) Glasgow Haskell Compiler -- version 5.00.2
>
>[...]
>
>Pre-built
>packages for Linux, FreeBSD, and Solaris(sparc) are also available.
>
>[...]
>
> What's new in 5.00.1
>======================
>
>[...]
>
>At the moment there is no Win32 build of 5.00 or 5.00.1 available. We
>decided to push Win32 support to the 5.02 release, so as not to delay
>5.00.1 any further.
So, what's up? I've been completely unable to build it (the previous
version) on my own... It says it requires Happy, and no matter what I do
(Happy build just fine), it doesn't see it.
No hurry, but still, I'd like to play with this new version.
Salutaciones,
JCAB
---------------------------------------------------------------------
Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com
Senior Technology Engineer | mailto:jcab@roningames.com
Ronin Entertainment | ICQ: 10913692
(my opinions are only mine)
JCAB's Rumblings is so off-line O:-(
From Nicole.Gabler@web.de Tue Jun 19 09:23:30 2001
From: Nicole.Gabler@web.de (Nicole Gabler)
Date: Tue, 19 Jun 2001 10:23:30 +0200
Subject: library Directory.hs
Message-ID: <200106190823.f5J8NUj22145@mailgate4.cinetic.de>
Hi all,
I have a problem: I need the library Directory.hs. But there is no directory.hs in {Hugs}/lib/ !! All standard libraries are there expect of this one. I downloaded Hugs from http://www.haskell.org/hugs/. Is there any alternative?? Or did I understand something wrong?? I hope you can help me!
Best regards,
Nicole
______________________________________________________________________________
Sie surfen im Internet statt im Meer? Selbst schuld!
Auf zum Strand: http://lastminute.de/?PP=1-0-100-105-1
From wlux@uni-muenster.de Tue Jun 19 11:30:59 2001
From: wlux@uni-muenster.de (Wolfgang Lux)
Date: Tue, 19 Jun 2001 12:30:59 +0200
Subject: Haskell report typo (bad law for readsPrec)
In-Reply-To: "Your message of Mon, 18 Jun 2001 02:28:19 PDT."
<37DA476A2BC9F64C95379BF66BA26902D730B5@red-msg-09.redmond.corp.microsoft.com>
References: <37DA476A2BC9F64C95379BF66BA26902D730B5@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <20010619103101.BFA8F255AB@www.haskell.org>
Sorry, it hit the wrong button so the following didn't go to the list.
> "Simon Peyton-Jones" wrote
>
> >
> > | Another simple alternative is to weaken the the equation by
> > | replacing the variable r by the empty string: [Alternative B:]
> > |
> > | ...
> > | should be the case that
> > |
> > | fst (head (readsPrec d (showsPrec d x ""))) == x
> >
> > Yes, I like this alternative too. I'll implement it.
>
> Why not require
>
> readsPrec d (showPrec d x "") == [(x,"")]
>
> in this case? At least it should be
>
> head (readsPrec d x "") == (x,"")
>
> Regards
> Wolfgang
>
--
Wolfgang Lux Phone: +49-251-83-38263
Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259
Universitaet Muenster Email: wlux@uni-muenster.de
From wolfgang@jeltsch.net Tue Jun 19 13:48:52 2001
From: wolfgang@jeltsch.net (Wolfgang Jeltsch)
Date: Tue, 19 Jun 2001 14:48:52 +0200
Subject: library Directory.hs
In-Reply-To: <200106190823.f5J8NUj22145@mailgate4.cinetic.de>
References: <200106190823.f5J8NUj22145@mailgate4.cinetic.de>
Message-ID: <01061914485203.00617@home>
Hello,
according to
http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/libs.html
Hugs does not contain all standard libraries. Especially the Directory module
is missing.
Wolfgang
On Tuesday, 19. June 2001 10:23, you wrote:
> Hi all,
>
> I have a problem: I need the library Directory.hs. But there is no
> directory.hs in {Hugs}/lib/ !! All standard libraries are there expect of
> this one. I downloaded Hugs from http://www.haskell.org/hugs/. Is there any
> alternative?? Or did I understand something wrong?? I hope you can help me!
>
> Best regards,
>
> Nicole
From Nicole.Gabler@web.de Tue Jun 19 15:01:51 2001
From: Nicole.Gabler@web.de (Nicole Gabler)
Date: Tue, 19 Jun 2001 16:01:51 +0200
Subject: library Directory.hs
References: <200106190823.f5J8NUj22145@mailgate4.cinetic.de> <01061914485203.00617@home>
Message-ID: <004d01c0f8c8$6431d930$e4a79cc2@icsag.de>
> Hello,
> according to
> http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/libs.html
> Hugs does not contain all standard libraries. Especially the Directory
module
> is missing.
>
> Wolfgang
O.k. thank you Wolfgang!!
Then I will tell you my problem exactly. Perhaps anybody can help me:
My haskell programm is in the root directory. I want to parse from several
files in different directories. How can I do this??
Thank you
Nicole
From qrczak@knm.org.pl Tue Jun 19 18:06:39 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 19 Jun 2001 17:06:39 GMT
Subject: library Directory.hs
References: <9gnnde$3ts$1@qrnik.zagroda>
Message-ID:
Tue, 19 Jun 2001 10:23:30 +0200, Nicole Gabler pisze:
> I have a problem: I need the library Directory.hs. But
> there is no directory.hs in {Hugs}/lib/ !! All standard
> libraries are there expect of this one.
Not exactly: Time and CPUTime are also missing.
> Is there any alternative??
You can use another Haskell implementation:
ghc - A big and rich compiler. May be hard to install because of
dependencies on various tools. Provides many language extensions
and libraries.
nhc98 - Smaller than ghc but larger than Hugs. Provides a little
more than Haskell 98. Compiles faster than ghc but programs execute
more slowly.
hbc - No longer maintained. Didn't reach Haskell 98. Compiles fast
and programs run quite fast.
A note about sources of these compilers: nhc98 is written in nice and
clean standard Haskell (but I haven't looked deeply); ghc is written
in itself and sometimes can be hard to understand; hbc is written in
LazyML and almost nobody except its author understands it. Hugs is
an interpreter written in C and I'm not sure how clearly it is written.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From jans@numeric-quest.com Tue Jun 19 14:35:32 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Tue, 19 Jun 2001 09:35:32 -0400 (EDT)
Subject: library Directory.hs
In-Reply-To: <004d01c0f8c8$6431d930$e4a79cc2@icsag.de>
Message-ID:
On Tue, 19 Jun 2001, Nicole Gabler wrote:
> O.k. thank you Wolfgang!!
> Then I will tell you my problem exactly. Perhaps anybody can help me:
> My haskell programm is in the root directory. I want to parse from several
> files in different directories. How can I do this??
That depends what you want to do. If you know the names
and locations of files, you can easily access them
by specifying full FilePaths. And this is definitely
supported by Hugs. With some gymnastic you can even
get directory listings - if you are willing to use Hugs
as a string server.
Jan
From awfurtado@uol.com.br Tue Jun 19 23:52:49 2001
From: awfurtado@uol.com.br (Andre W B Furtado)
Date: Tue, 19 Jun 2001 19:52:49 -0300
Subject: hbc
References: <9gnnde$3ts$1@qrnik.zagroda>
Message-ID: <003901c0f912$91eb0500$38dff9c8@windows9>
Why hbc did not succeeded? It is still possible to make it reach Haskell 98?
Or why doesn't ghc uses some of its techniques to compile/run programs
faster?
Andre W B Furtado
From patrikj@cs.chalmers.se Wed Jun 20 09:06:24 2001
From: patrikj@cs.chalmers.se (Patrik Jansson)
Date: Wed, 20 Jun 2001 10:06:24 +0200 (MET DST)
Subject: hbc
In-Reply-To: <003901c0f912$91eb0500$38dff9c8@windows9>
Message-ID:
On Tue, 19 Jun 2001, Andre W B Furtado wrote:
> It is still possible to make hbc reach Haskell 98?
In short: Hbc is not quite dead yet, and there is a H98 version.
In detail:
[Note: I'm no expert in compiler writing, nor do I support hbc. I just
happen to work at Chalmers in the office between Lennart Augustsson's
(main architect and implementor of hbc, now in industry) and Thomas
Hallgren's (still actively using and sometimes hacking hbc).
]
The latest unofficial release is a Haskell 98 version of hbc, from 1999.
Below are some links.
There has been no official release for the last few years and the support
level is pretty low, but the compiler exists and can be used.
Unfortunately the web-pages and the documentation has not been updated the
last few years!
One notable feature in hbc still missing in ghc is Unicode support (hbc
has supported Unicode from early on). I hope ghc will follow up the recent
change to Unicode-sized Chars with some library support soon.
Many years ago a big benefit of hbc was its interactive variant hbi, only
very recently implemented by ghc, but hbi is even less supported than hbc
and I have only tried it once or twice. [I'd be very happy to hear someone
more involved in developing hbc and hbi come forward and disprove this
claim by providing a new release.]
When it comes to speed I am pretty sure ghc produces faster code (it used
to be different, but that is a while ago) and I think hbc compiles faster
nowadays "only" because it does less work in producing good code.
/Patrik Jansson
Versions of hbc98:
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/
Binary distributions of the latest unofficial release: 0.9999.5b
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-libcv6.tar.gz
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-redhat-6.tar.gz
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-netbsdELF.tar.gz
Source snapshot:
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/snapshot/1999-09-10/
From john@repetae.net Wed Jun 20 10:35:54 2001
From: john@repetae.net (John Meacham)
Date: Wed, 20 Jun 2001 02:35:54 -0700
Subject: hbc
In-Reply-To: ; from patrikj@cs.chalmers.se on Wed, Jun 20, 2001 at 10:06:24AM +0200
References: <003901c0f912$91eb0500$38dff9c8@windows9>
Message-ID: <20010620023554.J710@mark.ugcs.caltech.edu>
you forget one other essential quality of hbc.
As far as I know it is the only compiler that even has a chance of
compiling Fudgets, and hence programs dependent on them such as
the very cool (IMHO) Alfa proof editor
(http://www.cs.chalmers.se/~hallgren/Alfa/)
and its assosiated improvments to Fudgets. If there is any effort to
port these tools to a modern haskell system then I cheer you on.
John
On Wed, Jun 20, 2001 at 10:06:24AM +0200, Patrik Jansson wrote:
> On Tue, 19 Jun 2001, Andre W B Furtado wrote:
> > It is still possible to make hbc reach Haskell 98?
>
> In short: Hbc is not quite dead yet, and there is a H98 version.
>
> In detail:
>
> [Note: I'm no expert in compiler writing, nor do I support hbc. I just
> happen to work at Chalmers in the office between Lennart Augustsson's
> (main architect and implementor of hbc, now in industry) and Thomas
> Hallgren's (still actively using and sometimes hacking hbc).
> ]
>
> The latest unofficial release is a Haskell 98 version of hbc, from 1999.
> Below are some links.
>
> There has been no official release for the last few years and the support
> level is pretty low, but the compiler exists and can be used.
> Unfortunately the web-pages and the documentation has not been updated the
> last few years!
>
> One notable feature in hbc still missing in ghc is Unicode support (hbc
> has supported Unicode from early on). I hope ghc will follow up the recent
> change to Unicode-sized Chars with some library support soon.
>
> Many years ago a big benefit of hbc was its interactive variant hbi, only
> very recently implemented by ghc, but hbi is even less supported than hbc
> and I have only tried it once or twice. [I'd be very happy to hear someone
> more involved in developing hbc and hbi come forward and disprove this
> claim by providing a new release.]
>
> When it comes to speed I am pretty sure ghc produces faster code (it used
> to be different, but that is a while ago) and I think hbc compiles faster
> nowadays "only" because it does less work in producing good code.
>
> /Patrik Jansson
>
> Versions of hbc98:
>
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/
>
> Binary distributions of the latest unofficial release: 0.9999.5b
>
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-libcv6.tar.gz
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-redhat-6.tar.gz
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-netbsdELF.tar.gz
>
> Source snapshot:
>
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/snapshot/1999-09-10/
>
>
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@repetae.net
--------------------------------------------------------------
From aaron.roth@lexys.com Wed Jun 20 19:58:47 2001
From: aaron.roth@lexys.com (Aaron Roth)
Date: Wed, 20 Jun 2001 14:58:47 -0400
Subject: Haskell GUI's
Message-ID:
I'm sure this topic has been discussed ad nauseum. I've only been
subscribing since January, so forgive me if I reintroduce it. Is there any
place where various approaches for a Haskell GUI are being actively
discussed? I've seen fragments here and there, namely pages on FranTk,
Fudgets, GTK+Haskell, and a request to port the Clean I/O library. I've also
read that there is no consensus view on how to do GUI's in Haskell, but is
there an active debate somewhere? Or a few other papers? Thanks.
Aaron
From steph@cs.uchicago.edu Wed Jun 20 19:59:59 2001
From: steph@cs.uchicago.edu (Stephen Bailey)
Date: Wed, 20 Jun 2001 14:59:59 -0400
Subject: hbc
In-Reply-To: Message from "Andre W B Furtado"
of "Tue, 19 Jun 2001 19:52:49 -0300." <003901c0f912$91eb0500$38dff9c8@windows9>
References: <9gnnde$3ts$1@qrnik.zagroda> <003901c0f912$91eb0500$38dff9c8@windows9>
Message-ID: <20010620190006.5B6DC94006@sandmail.sandburst.com>
> Why hbc did not succeeded?
I heard rumors that the author went off to some cushy industrial job,
or is spending all his time writing NetBSD drivers, or something like
that :^)
Steph
From nikhil@acm.org Thu Jun 21 01:52:20 2001
From: nikhil@acm.org (Rishiyur S. Nikhil)
Date: Wed, 20 Jun 2001 20:52:20 -0400
Subject: hbc
References: <9gnnde$3ts$1@qrnik.zagroda> <003901c0f912$91eb0500$38dff9c8@windows9> <20010620190006.5B6DC94006@sandmail.sandburst.com>
Message-ID: <3B314544.B2FDA770@mediaone.net>
Stephen Bailey wrote:
>
> > Why hbc did not succeeded?
>
> I heard rumors that the author went off to some cushy industrial job,
> or is spending all his time writing NetBSD drivers, or something like
> that :^)
>
> Steph
I heard that he had become a recluse and was chasing eclipses
somewhere in South Africa!
Nikhil
From chak@cse.unsw.edu.au Thu Jun 21 02:15:16 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 21 Jun 2001 11:15:16 +1000
Subject: Haskell GUI's
In-Reply-To:
References:
Message-ID: <20010621111516X.chak@cse.unsw.edu.au>
"Aaron Roth" wrote,
> I'm sure this topic has been discussed ad nauseum. I've only been
> subscribing since January, so forgive me if I reintroduce it. Is there any
> place where various approaches for a Haskell GUI are being actively
> discussed? I've seen fragments here and there, namely pages on FranTk,
> Fudgets, GTK+Haskell, and a request to port the Clean I/O library. I've also
> read that there is no consensus view on how to do GUI's in Haskell, but is
> there an active debate somewhere? Or a few other papers?
There is a mailing list for Gtk+Haskell:
http://haskell.org/mailman/listinfo/gtkhs
The list is mainly used for annoucements and questions
regarding Gtk+HS, but I would welcome any discussion
relating to the GTK+ binding. In particular, it is
certainly the right place to discuss the iHaskell high-level
API, which is being defined on top of Gtk+HS:
http://www.cse.unsw.edu.au/~chak/haskell/gtk/#iHaskell
Cheers,
Manuel
From chak@cse.unsw.edu.au Thu Jun 21 03:01:45 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 21 Jun 2001 12:01:45 +1000
Subject: GHC version 5.00.2 is available
In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60302A9E9@red-msg-06.redmond.corp.microsoft.com>
References: <68B95AA1648D1840AB0083CC63E57AD60302A9E9@red-msg-06.redmond.corp.microsoft.com>
Message-ID: <20010621120145S.chak@cse.unsw.edu.au>
"Julian Seward (Intl Vendor)" wrote,
> The (Interactive) Glasgow Haskell Compiler -- version 5.00.2
> ==============================================================
>
> We are pleased to announce a new patchlevel release of the Glasgow
> Haskell Compiler (GHC), version 5.00.2.
For your installation pleasure, RPM packages built on RedHat
are now available. Binary packages built for RedHat 7.x are at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.00.2-1.i386.rpm
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.00.2-1.i386.rpm
and those for RedHat 6.2 are at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-5.00.2-1.i386.rpm
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-prof-5.00.2-1.i386.rpm
The ghc-prof-* packages contain optional libraries for
profiling. The packages for 6.2 are courtesy of Tom Moertel.
The source rpm used to built the above binaries is at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.00.2-1.src.rpm
If you build from the source rpm using an older version of
GHC, note that you have to build the system twice if you
like to use the interactive environment. The second build
should use the compiler generated in the first.
Manuel
From v-julsew@microsoft.com Thu Jun 21 09:50:23 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Thu, 21 Jun 2001 01:50:23 -0700
Subject: hbc
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F233D@red-msg-06.redmond.corp.microsoft.com>
| > I heard rumors that the author went off to some cushy industrial
job,=20
| > or is spending all his time writing NetBSD drivers, or something
like=20
| > that :^)
|=20
| I heard that he had become a recluse and was chasing eclipses=20
| somewhere in South Africa!
I heard rumours that the author had nearly completed writing a
whole new Haskell compiler, in Haskell, which (presumably)=20
allowed him to move on from the by-now byzantine complexity
of hbc. It is further rumoured that this new compiler could
boot itself.
J
From v-julsew@microsoft.com Thu Jun 21 09:55:38 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Thu, 21 Jun 2001 01:55:38 -0700
Subject: RPMs for: GHC version 5.00.2 is available
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F233E@red-msg-06.redmond.corp.microsoft.com>
Thanks once again to Tom and Manuel for building RH6.2 and
RH7.x RPMs of ghc-5.00.2. I'll shortly put these RPMs at
the usual place, the download pages at http://www.haskell.org/ghc,
so you can get them from there too.
Note also that a build for Solaris 2.7 (sparc) is also now
available.
J
| -----Original Message-----
| From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au]=20
| Sent: Thursday, June 21, 2001 3:02 AM
| To: Julian Seward (Intl Vendor)
| Cc: glasgow-haskell-users@haskell.org; haskell@haskell.org
| Subject: Re: GHC version 5.00.2 is available
|=20
|=20
| "Julian Seward (Intl Vendor)" wrote,
|=20
| > The (Interactive) Glasgow Haskell Compiler -- version 5.00.2
| > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| >=20
| > We are pleased to announce a new patchlevel release of the Glasgow=20
| > Haskell Compiler (GHC), version 5.00.2.
|=20
| For your installation pleasure, RPM packages built on RedHat=20
| are now available. Binary packages built for RedHat 7.x are at
|=20
=20
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.00.2-1.i38
6.rpm
=20
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.00.2-
1.i386.rpm
and those for RedHat 6.2 are at
=20
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-5.00.2
-1.i386.rpm
=20
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-prof-5
.00.2-1.i386.rpm
The ghc-prof-* packages contain optional libraries for profiling. The
packages for 6.2 are courtesy of Tom Moertel.
The source rpm used to built the above binaries is at
=20
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.00.2-1.src.
rpm
If you build from the source rpm using an older version of
GHC, note that you have to build the system twice if you
like to use the interactive environment. The second build should use
the compiler generated in the first.
Manuel
From Sven.Panne@informatik.uni-muenchen.de Thu Jun 21 18:34:51 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Thu, 21 Jun 2001 19:34:51 +0200
Subject: hbc
References:
Message-ID: <3B32303B.9C8E4796@informatik.uni-muenchen.de>
Patrik Jansson wrote:
> [...]
> One notable feature in hbc still missing in ghc is Unicode support (hbc
> has supported Unicode from early on). I hope ghc will follow up the recent
> change to Unicode-sized Chars with some library support soon. [...]
*ahem* Just to get rumours correct: Starting from 5.00, GHC *has* Unicode
support (Char is even 31bits now), and there is some library support, too,
but Marcin should better comment on the latter...
Cheers,
S.
From jcohn@estrategypartners.com Sat Jun 23 03:28:37 2001
From: jcohn@estrategypartners.com (Jeff Cohn)
Date: Fri, 22 Jun 2001 19:28:37 -0700
Subject: User Generated Database of Internet Social Communities
Message-ID:
This is a multi-part message in MIME format.
------=_NextPart_000_0119_01C0FB51.890C95C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
We have launched a new research database and would appreciate the
contribution of you and your students.
http://ecultures.homestead.com/ecultures.html
A User Generated Database of Internet Social Communities
eCultures is a research tool established to address growing need to discover
the Internet's vast network of virtual communities around the world. Unlike
today's commercialized and non-collaborative search engines, eCultures has
taken a new approach to collaborative research by allowing users to
immediately share and search under one common database. All submissions are
subject to a review.
eCultures is a web property of eStrategy Partners, LLC
Comments are appreciated!
Regards,
Jeff Cohn
President & Founder
eStrategy Partners, LLC
Office: 310-546-7539
jcohn@estrategypartners.com
www.estrategypartners.com
"Solutions for eBusiness"
------=_NextPart_000_0119_01C0FB51.890C95C0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
We have launched a new research =
database and=20
would appreciate the contribution of you and your=20
students.
http://ecultures.h=
omestead.com/ecultures.html
A User Generated =
Database of=20
Internet Social Communities
eCultures is a research tool=20
established to address growing=20
need to discover the Internet's vast network of virtual communities =
around the=20
world. Unlike today's =
commercialized and=20
non-collaborative search engines, eCultures has taken a new approach to collaborative =
research by=20
allowing users to immediately share=20
and search under one common database. All submissions are =
subject=20
to a review.
eCultures=20
is a web property of =
eStrategy Partners, =
LLC
Comments are=20
appreciated!
Regards,
Jeff=20
Cohn
President & Founder
eStrategy Partners, =
LLC
Office: =20
310-546-7539
jcohn@estrategypartners.com
www.estrategypartners.com
"Solutions for =
eBusiness"=20
------=_NextPart_000_0119_01C0FB51.890C95C0--
From doaitse@cs.uu.nl Sat Jun 23 09:31:57 2001
From: doaitse@cs.uu.nl (S. Doaitse Swierstra)
Date: Sat, 23 Jun 2001 10:31:57 +0200
Subject: new version of parser combinators
Message-ID:
We have been working hard on new versions of the Parser Combinators
and AG system, with the following improvements:
even better error repairs
much faster and simpler basic parsing machine
permutation (of different types) and list combinators
extensive reporting about repairs made and what was expected
the possibility to manipulate your own state during parsing
and result construction, using classed based (like monads) interfaces
As an example of the permutation combinators we parse a permutation
of three elements:
1) a list of 'a's
2) a 'b'
3) an optional 'c'
which is described by:
permtest :: Parser Char (String, Char, Char)
permtest = permute $ (,,) ~$~ pList (pSym 'a') ~*~ pSym 'b' ~*~ pOptSym 'c'
pOptSym :: Char -> Parser Char Char
pOptSym x = pSym x <|> pSucceed '_'
which we try on several inputs resulting in:
t permtest "acb"
Result:
("a",'b','c')
t permtest "cdaa"
Errors:
Symbol 'd' before 'a' was deleted, because 'b' or ('a')* was expected.
Symbol 'b' was inserted at end of file, because 'a' or 'b' was expected.
Result:
("aa",'b','c')
t permtest "abd"
Errors:
Symbol 'd' at end of file was deleted, because 'c' or eof was expected.
Result:
("a",'b','_')
t permtest ""
Errors:
Symbol 'b' was inserted at end of file, because 'c' or 'b' or ('a')*
was expected.
Result:
("",'b','_')
The manual is still of an earlier version and will be adapted soon.
As an example of the combinators we provide a parser for bibtex
files, that returns the repairs made to the erroneous entries (as
far as we understand the bibtex format).
I hope this is useful to you,
Doaitse Swierstra
From iyermanjula@hotmail.com Mon Jun 25 07:02:40 2001
From: iyermanjula@hotmail.com (Manjula Iyer)
Date: Mon, 25 Jun 2001 01:02:40 -0500
Subject: (no subject)
Message-ID:
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C0FD12.8862F840
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
------=_NextPart_000_0007_01C0FD12.8862F840
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
------=_NextPart_000_0007_01C0FD12.8862F840--
From stanley_goof@yahoo.fr Mon Jun 25 10:25:26 2001
From: stanley_goof@yahoo.fr (=?iso-8859-1?q?stanley=20goof?=)
Date: Mon, 25 Jun 2001 11:25:26 +0200 (CEST)
Subject: adventure game
Message-ID: <20010625092526.36421.qmail@web14810.mail.yahoo.com>
Hi everybody,
I am planning to write a text-adventure game in
haskell.
This is the type of game in which you can execute many
commands like 'take'(to take an object), 'goto' to
move from a room to another room, 'look'(to see the
objects in a room), 'open'(to open a drawer), ...
I'm currently studying haskell, so i'm a beginner. If
you know any hints or any sources which can help
writing this game, write me.
Thank you very much
___________________________________________________________
Do You Yahoo!? -- Pour faire vos courses sur le Net,
Yahoo! Shopping : http://fr.shopping.yahoo.com
From Nicole.Gabler@web.de Wed Jun 27 08:47:00 2001
From: Nicole.Gabler@web.de (Nicole Gabler)
Date: Wed, 27 Jun 2001 09:47:00 +0200
Subject: library Directory.hs
References: <68B95AA1648D1840AB0083CC63E57AD60F233A@red-msg-06.redmond.corp.microsoft.com>
Message-ID: <005801c0fedd$59ba1a10$e4a79cc2@icsag.de>
Hello All,
thank you for all your answers. I solved the problem without using
Directory.hs, but now I have a new problem and now I need Directory.hs. I
only have the name of a directory and I have to search for any files in this
directory! Unfortunately, the business concern, where I'm doing an
industrial practical, don't use Unix but Windows NT. So, what can I do??
Thanks,
Nicole
From lennart@mail.augustsson.net Wed Jun 27 09:28:55 2001
From: lennart@mail.augustsson.net (Lennart Augustsson)
Date: Wed, 27 Jun 2001 10:28:55 +0200
Subject: hbc
References: <9gnnde$3ts$1@qrnik.zagroda> <003901c0f912$91eb0500$38dff9c8@windows9> <20010620190006.5B6DC94006@sandmail.sandburst.com> <3B314544.B2FDA770@mediaone.net>
Message-ID: <3B399947.2B4592C4@mail.augustsson.net>
"Rishiyur S. Nikhil" wrote:
> Stephen Bailey wrote:
> >
> > > Why hbc did not succeeded?
> >
> > I heard rumors that the author went off to some cushy industrial job,
> > or is spending all his time writing NetBSD drivers, or something like
> > that :^)
> >
> > Steph
>
> I heard that he had become a recluse and was chasing eclipses
> somewhere in South Africa!
I heard that he got trampled by a crazy rhino in Africa, but I'm not sure
if that rumour can be trusted.
-- Lennart
From sof@galconn.com Wed Jun 27 18:49:57 2001
From: sof@galconn.com (Sigbjorn Finne)
Date: Wed, 27 Jun 2001 10:49:57 -0700
Subject: library Directory.hs
Message-ID: <03dc01c0ff31$946e9790$6332a8c0@sofbox>
Nicole Gabler Nicole.Gabler@web.de writes:
>
> thank you for all your answers. I solved the problem without
> using Directory.hs, but now I have a new problem and now
> I need Directory.hs. I only have the name of a directory and I
> have to search for any files in this directory! Unfortunately, the
> business concern, where I'm doing an industrial practical, don't
> use Unix but Windows NT. So, what can I do??
Hi,
I'd suggest either waiting for the next release of Hugs98, or grab
a copy of the Hugs98 sources from the CVS repository
(http://cvs.haskell.org/ & compile it up. It has a complete set
of Haskell98 modules, including Directory.
If neither of these options are practical, let me know & I'll send
you a copy of the files you need.
hth
--sigbjorn
From coldblue@freemail.com.au Fri Jun 1 00:14:20 2001
From: coldblue@freemail.com.au (Shirley Widyaningsih)
Date: Thu, 31 May 2001 19:14:20 -0400 (EDT)
Subject: Information
Message-ID: <20010531231420.CCAE1255AB@www.haskell.org>
This is a multipart message in MIME format.
------------APMIME1
Content-type: text/plain
Dear Sir/Mdm,
I would like to ask some information about Haskell. For the information, I'm a student that currently studying at Bina Nusantara University, Jakarta, Indonesia and taking computer science as my subject. In Indonesia, we've never learned about Haskell. It's not populer in Indonesia, many people don't know about it. I know it from my friend that studying in Sydney, Australia. I would to install/download this program, could you give me some info where i can get this software ? If i have to but the software, what is the software name ? Is it haskell too??
Thank you.
Sincerely,
Shirley
---------------------------------------------
WANT A NEW JOB? THEN LET THE JOB FIND YOU
Visit www.ecruit.com.au and register your
profile. Then the headhunters can find you.
---------------------------------------------
Get your own free email account at
http://www.freemail.com.au/ now part of the
Webuser.com.au independent portal. Visit at…
http://www.webuser.com.au
---------------------------------------------
------------APMIME1--
From dscarlett@optushome.com.au Fri Jun 1 00:43:28 2001
From: dscarlett@optushome.com.au (David Scarlett)
Date: Fri, 1 Jun 2001 09:43:28 +1000
Subject: Information
References: <20010531231420.CCAE1255AB@www.haskell.org>
Message-ID: <00a001c0ea2b$7ddf1880$0100a8c0@CO3003288A>
Hugs is the standard Haskell interpreter.......
http://www.haskell.org/hugs/
See here for more info on Haskell.....
http://www.haskell.org/
From iscp9157@nus.edu.sg Fri Jun 1 23:25:24 2001
From: iscp9157@nus.edu.sg (Saswat Anand)
Date: Fri, 1 Jun 2001 15:25:24 -0700
Subject: fromInteger
Message-ID: <003101c0eae9$c248bbc0$733d8489@saswat>
This is a multi-part message in MIME format.
------=_NextPart_000_002E_01C0EAAF.1478A080
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I can't understand how the arithmatic operators like (+),(-) are =
defined and fromInteger works in that context.
Type Fun a =3D Int -> a
fun :: Fun Int
fun =3D (+1)
instance (Num a) =3D> Num (Fun a) where
.........
(fun + 2) 10 and (2 + fun) 10 works fine. But how does it know it has to =
use fromInteger?
But If I want these,
(Just 2 + fun) 10 and (fun + Just 2) 10
to work, then is there a way to tell which conversion function to use?
Thanks,
Saswat
------=_NextPart_000_002E_01C0EAAF.1478A080
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I can't understand how =
the arithmatic=20
operators like (+),(-) are defined and fromInteger works in that=20
context.
Type Fun a =3D Int -> a
fun :: Fun Int
fun =3D =
(+1)
instance (Num a) =3D> Num (Fun a)=20
where
.........
(fun + 2) 10 and (2 + fun) 10 works =
fine. But how=20
does it know it has to use fromInteger?
But If I want these,
(Just 2 =
+ fun) 10=20
and (fun + Just 2) 10
to work, then is there a way to tell which =
conversion=20
function to use?
Thanks,
Saswat
------=_NextPart_000_002E_01C0EAAF.1478A080--
From coldblue@freemail.com.au Fri Jun 1 09:10:20 2001
From: coldblue@freemail.com.au (Shirley Widyaningsih)
Date: Fri, 1 Jun 2001 04:10:20 -0400 (EDT)
Subject: Problem
Message-ID: <20010601081020.62E1E255AF@www.haskell.org>
This is a multipart message in MIME format.
------------APMIME1
Content-type: text/plain
Dear Sir/Mdm,
I've got some problem here, after i install the hugs98, i want to open file "Fact.hs", but there's an error.
It's written "ERROR Fact.hs - Unable to open file "Fact.hs" .
So what should i do???
Thank you.
Sincerely,
Shirley
---------------------------------------------
WANT A NEW JOB? THEN LET THE JOB FIND YOU
Visit www.ecruit.com.au and register your
profile. Then the headhunters can find you.
---------------------------------------------
Get your own free email account at
http://www.freemail.com.au/ now part of the
Webuser.com.au independent portal. Visit at…
http://www.webuser.com.au
---------------------------------------------
------------APMIME1--
From ross@soi.city.ac.uk Fri Jun 1 11:04:34 2001
From: ross@soi.city.ac.uk (Ross Paterson)
Date: Fri, 1 Jun 2001 11:04:34 +0100
Subject: unfoldr in Library Report
Message-ID: <20010601110434.A6870@soi.city.ac.uk>
While looking through the List module, I came across
The unfoldr function undoes a foldr operation. Note that, in general,
only invertible functions can be unfolded.
[followed by an equation about undoing foldr]
This is quite inadequate: unfoldr is very useful with non-invertible
functions. I suggest something like:
The unfoldr function is a `dual' to foldr: while foldr reduces a list
to a summary value, unfoldr builds a list from a seed value, e.g.,
iterate f == unfoldr (\x -> Just (x, f x))
In some cases unfoldr can undo a foldr operation:
[followed by the existing equation]
From coldblue@freemail.com.au Fri Jun 1 11:08:19 2001
From: coldblue@freemail.com.au (Shirley Widyaningsih)
Date: Fri, 1 Jun 2001 06:08:19 -0400 (EDT)
Subject: Problem
Message-ID: <20010601100819.C02D0255CC@www.haskell.org>
This is a multipart message in MIME format.
------------APMIME1
Content-type: text/plain
At 01 Jun 2001 11:18:00 +0200,
Bruno Barbier (barbier@comte.univ-fcomte.fr) wrote:
>
> When hugs is not able to find a file, it says this.
> In the interpreter, type ':?' for help, then you can change the
> current
> path or update the paths where hugs looks for files.
>
>
>
Can you teach me how to change the current path or updates the paths?
when i go to interpreter-> option, this below are appear.
Current settings: +fewuiA -stgl.qQkR -h250000 -p"%s> " -r$$ -c40
Search path : -P{Hugs}\lib;{Hugs}\lib\hugs;{Hugs}\lib\exts;{Hugs} \lib\win32
Editor setting : -EC:\WINDOWS\notepad.exe
Preprocessor : -F
For the information, my hugs directory is in C:\Program Files\HUGS98
Thank You
Sincerely,
Shirley
---------------------------------------------
WANT A NEW JOB? THEN LET THE JOB FIND YOU
Visit www.ecruit.com.au and register your
profile. Then the headhunters can find you.
---------------------------------------------
Get your own free email account at
http://www.freemail.com.au/ now part of the
Webuser.com.au independent portal. Visit at…
http://www.webuser.com.au
---------------------------------------------
------------APMIME1--
From barbier@comte.univ-fcomte.fr Fri Jun 1 11:37:50 2001
From: barbier@comte.univ-fcomte.fr (Bruno Barbier)
Date: 01 Jun 2001 12:37:50 +0200
Subject: Problem
In-Reply-To: Shirley Widyaningsih's message of "Fri, 1 Jun 2001 12:16:05 +0200 (MET DST)"
References: <200106011016.MAA24026@comte.univ-fcomte.fr>
Message-ID:
For hugs related questions, you should write at
hugs-users@haskell.org
See also
http://haskell.org/mailman/listinfo/
for a list of haskell related mailing lists.
For your problem,
(works fine with linux, but I guess it's the same for Windows)
I do
:s
to get the search paths and I get
| Search path : -P{Hugs}/lib:{Hugs}/lib/hugs:{Hugs}/lib/exts
then I type,
:s -P{Hugs}/lib:{Hugs}/lib/hugs:{Hugs}/lib/exts:mypath1:mypath2
to add the paths 'mypath1' and 'mypath2' into the search paths;
i.e. absolute paths separated by ':' (for Windows, you should probably use ';')
Shirley Widyaningsih writes:
> Content-type: text/plain
>
>
>
> At 01 Jun 2001 11:18:00 +0200,
> Bruno Barbier (barbier@comte.univ-fcomte.fr) wrote:
> >
> > When hugs is not able to find a file, it says this.
> > In the interpreter, type ':?' for help, then you can change the
> > current
> > path or update the paths where hugs looks for files.
> >
> >
> >
>
> Can you teach me how to change the current path or updates the paths?
> when i go to interpreter-> option, this below are appear.
> Current settings: +fewuiA -stgl.qQkR -h250000 -p"%s> " -r$$ -c40
> Search path : -P{Hugs}\lib;{Hugs}\lib\hugs;{Hugs}\lib\exts;{Hugs} \lib\win32
> Editor setting : -EC:\WINDOWS\notepad.exe
> Preprocessor : -F
>
> For the information, my hugs directory is in C:\Program Files\HUGS98
> Thank You
>
>
> Sincerely,
>
>
> Shirley
>
> ---------------------------------------------
> WANT A NEW JOB? THEN LET THE JOB FIND YOU
>
> Visit www.ecruit.com.au and register your
> profile. Then the headhunters can find you.
>
> ---------------------------------------------
> Get your own free email account at
> http://www.freemail.com.au/ now part of the
> Webuser.com.au independent portal. Visit at…
> http://www.webuser.com.au
> ---------------------------------------------
--
Bruno Barbier
Laboratoire d'Informatique de Besancon, Universite de Franche-Comte, France
Phone/Fax : (33) 381.662.087 / (33) 381.666.450
Mailto : barbier@lifc.univ-fcomte.fr
From Dominic.J.Steinitz@BritishAirways.com Fri Jun 1 16:27:48 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 01 Jun 2001 15:27:48 Z
Subject: Socket Behaviour
Message-ID: <"003753B17B474001*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Apologies if you have received this request for help already.
Can anyone tell me why the following code doesn't work as expected? Both the server and client hang.
[dom@lhrtba8fd85 simptest]$ server 20000 &
[1] 2694
[dom@lhrtba8fd85 simptest]$ client lhrtba8fd85 20000
client: interrupted
[1]+ Broken pipe server 20000
[dom@lhrtba8fd85 simptest]$ more log.txt
Starting logging
Hello world
[dom@lhrtba8fd85 simptest]$
So it looks like the hPutStrLn to the server's socket never completes. What's stopping it? On the client side, "Hello world" gets sent but the hGetLine never completes. I guess because the server for some reason can't send.
Dominic.
module Main(main) where
import System
import IO
import Socket
main :: IO ()
main = do prog <- getProgName
args <- getArgs
if (length args /= 2)
then do putStrLn ("Use: " ++ prog ++ " ")
exitWith (ExitFailure (-1))
else return ()
let host = args !! 0
port = read (args !! 1) :: Int in
client host (PortNumber (mkPortNumber port))
client :: Hostname -> PortID -> IO ()
client host port =
do sh <- connectTo host port
hPutStr sh "Hello world"
hFlush sh
x <- hGetLine sh
putStrLn x
module Main (main) where
import System
import IO
import Socket
main :: IO ()
main = do prog <- getProgName
args <- getArgs
if (length args /= 1)
then do putStrLn ("Use: " ++ prog ++ " ")
exitWith (ExitFailure (-1))
else return ()
let port = read (args !! 0) :: Int in
server (PortNumber (mkPortNumber port))
-- The server function creates a socket to listen on the port and
-- loops to log messages.
server :: PortID -> IO ()
server port =
do ofh <- openFile "log.txt" WriteMode
hPutStrLn ofh "Starting logging"
hFlush ofh
socket <- listenOn port
(sh,host,portid) <- accept socket
let loop = do b <- getBuffer sh 16
case b of
Full msg ->
do hPutStrLn ofh msg
hFlush ofh
loop
Partial msg ->
do hPutStrLn ofh msg
hFlush ofh
hPutStrLn sh "Finishing Logging"
hFlush sh
hPutStrLn ofh "Finishing logging"
hClose ofh
in loop
data Buffer = Full String | Partial String
getBuffer :: Handle -> Int -> IO Buffer
getBuffer h n =
if (n <= 0)
then return (Full "")
else do x <- try (hGetChar h)
case x of
Right c ->
do xs <- getBuffer h (n-1)
case xs of
Full cs -> return (Full (c:cs))
Partial cs -> return (Partial (c:cs))
Left e -> if isEOFError e
then return (Partial "")
else ioError e
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From qrczak@knm.org.pl Fri Jun 1 19:36:01 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 1 Jun 2001 18:36:01 GMT
Subject: Haskell 98 Report
References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> <20010601041923.A10308@hg.cs.mu.oz.au> <9f7cla$81t$1@qrnik.zagroda>
Message-ID:
31 May 2001 16:10:43 -0600, Alastair David Reid pisze:
> and
>
> if foo has type
>
> foo :: (Ord a) => ty
>
> then fooBy has type
>
> fooBy :: (a -> a -> Bool) -> ty
It's (a -> a -> Ordering) -> ty, with the default value being
compare.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From qrczak@knm.org.pl Fri Jun 1 19:34:46 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 1 Jun 2001 18:34:46 GMT
Subject: fromInteger
References: <9f7jgp$94q$1@qrnik.zagroda>
Message-ID:
Fri, 1 Jun 2001 15:25:24 -0700, Saswat Anand pisze:
> I can't understand how the arithmatic operators like (+),(-) are =
> defined and fromInteger works in that context.
They are all in class Num. fromInteger is automatically
inserted before all integer literals, e.g. '42' is equivalent to
'fromInteger (42::Integer)' and has type 'Num a => a', i.e. the
context can provide any numeric type and 42 will have that type
by using the appropriate fromInteger.
> Type Fun a = Int -> a
>
> fun:: Fun Int
> fun = (+1)
>
> instance (Num a) => Num (Fun a) where
> .........
>
> (fun + 2) 10 and (2 + fun) 10 works fine. But how does it know it
> has to use fromInteger?
(+):: Num a => a -> a -> a
>From this type it follows that both arguments of '+' must have the
same type (and that this type must be Num).
The first argument of '+' in 'fun + 2', i.e. 'fun', has a fully
determined type: 'Fun Int'. It follows that the second argument of
'+', i.e. '2', must be 'Fun Int' too.
It's an integral literal, so it can have any Num type. Unifying
'Num a => a' with 'Fun Int' succeeds and gives an answer what 'a'
is here: it's 'Fun Int', and it's ok because it's Num.
> But If I want these,
> (Just 2 + fun) 10 and (fun + Just 2) 10
> to work, then is there a way to tell which conversion function
> to use?
No: 'Just 2' has type 'Num a => Maybe a', 'fun' has type 'Fun Int',
i.e. 'Int -> Int'. In no way 'Maybe something' can be the same type as
'arg -> result'.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From s350366@student.uq.edu.au Sat Jun 2 14:03:29 2001
From: s350366@student.uq.edu.au (Sean Seefried)
Date: Sat, 02 Jun 2001 23:03:29 +1000
Subject: A problem with the typing system.
Message-ID: <3B18E421.16040DB7@student.uq.edu.au>
Dear Haskell users,
I am playing around with a variation of the Church numerals and it is
giving me grief.
Usually the definitions for Church numerals appear as follows.
zero = \s z -> z
succ x = \s z -> s (x s z)
But what I would like to do is define them this way.
zero = \s z ->z
succ x = \s z -> s x (x s z).
I don't think it's important that I explain why I want the extra
occurrence of x there.
Just typing this in hugs or ghci gives problems. In ghci the error
message is
Occurs check: cannot construct the infinite type:
t = (t -> t3 -> t2) -> t2 -> t1
Expected type: t
Inferred type: (t -> t3 -> t2) -> t2 -> t1
In the first argument of `x', namely `s'
In the second argument of `s', namely `(x s z)'
I know about rank-2 polymorphic types. (I don't really understand it
but I have used them). I attempted to create a type with the following
declaration.
data Church = Ch (forall a.(a -> a -> a) -> a -> a)
I declared an unCh
unCh (Ch a) = a
I then declared succ as
succ x = Ch(\s z -> s x (unCh x s z)
which gives the strange typing error:
Inferred type is less polymorphic than expected
Quantified type variable `a' is unified with `Church'
Signature type: forall a. (a -> a -> a) -> a -> a
Type to generalise: (Church -> Church -> Church)
-> Church -> Church
When checking an expression type signature
In the first argument of `Ch', namely `(\ s z -> s x (unCh x s z))'
in the definition of function `succ':
Ch (\ s z -> s x (unCh x s z))
Doesn't the "type to generalise" fit within the framework of forall
a.(a->a->a) ->a ->a. Why should it matter if something is
_less_ polymorphic than expected. This is something I do not
understand.
Now, if I modify the definition to
succ = \s z -> s x (unCh x s z)
I can at least load the file.
succ zero
gives me _no_ typing errors.
However
succ (succ zero)
gives me a typing error again. (And I know why)
Because the type of succ zero is "(Church -> Church -> Church) -> Church
-> Church" and not just simply "Church". (that is what the constructor
Ch is supposed to do but it complains of the typing being less
polymorphic than expected).
Is this sort of typing possible within Haskell. I realise that it is
sort of an infinite data type but in my opinion these sorts of things
should be able to be typed.
Thanks in advance.
Sean Seefried.
From ltaesch@europemail.com Sun Jun 3 00:05:12 2001
From: ltaesch@europemail.com (luc)
Date: Sat, 02 Jun 2001 23:05:12 +0000
Subject: proof in haskell ?
Message-ID: <3B197128.D390CE78@europemail.com>
chapter 12 of birds book mention mike spivey' theorem prover.
are there anything available in source code about proof in haskell ?
(btw , haskell is a great language ! one of the rare that try to
"improve lazyness " ! (chaperter 11)
thanks
Luc
From qrczak@knm.org.pl Sun Jun 3 12:13:26 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 3 Jun 2001 11:13:26 GMT
Subject: A problem with the typing system.
References: <9fapjj$tf6$1@qrnik.zagroda>
Message-ID:
Sat, 02 Jun 2001 23:03:29 +1000, Sean Seefried pisze:
> zero = \s z ->z
> succ x = \s z -> s x (x s z).
>
> I don't think it's important that I explain why I want the extra
> occurrence of x there.
I don't understand what the extra x means, so I can only explain what
errors mean. I don't know what do you want to archieve.
> Occurs check: cannot construct the infinite type:
> t = (t -> t3 -> t2) -> t2 -> t1
The type of 's' is requested to take as its first argument 'x',
which is a function which takes as its first argument 's' again.
So the type of 's' would have to appear as a proper part of itself.
> data Church = Ch (forall a.(a -> a -> a) -> a -> a)
I would expect
data Church = Ch (forall a. (a -> a) -> a)
but perhaps it has something to do with your extra 'x'...
> succ x = Ch(\s z -> s x (unCh x s z)
>
> which gives the strange typing error:
>
> Inferred type is less polymorphic than expected
> Quantified type variable `a' is unified with `Church'
The constructor Ch has type
(forall a. (a -> a -> a) -> a -> a) -> Church
and must be applied to a value which is polymorphic itself, i.e. which
could be assigned the type '(a -> a -> a) -> a -> a' for any 'a',
without knowing anything about the particular choice of 'a'. The type
allows a user of the resulting Church value to choose any type for
'a' and use this argument on this type - that's why it must work for
all of them. But
\s z -> s x (unCh x s z)
doesn't have sufficiently general type: 'x' has type Church (because
'unCh' is applied to 'x'), so 's' takes only Church as argument, so
what should happen if the user instantiates it with something other
than Church?
> Is this sort of typing possible within Haskell.
I don't know how it's supposed to behave with the extra 'x', so I
can't tell what type it could have.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From t-atolm@microsoft.com Mon Jun 4 10:31:44 2001
From: t-atolm@microsoft.com (Andrew Tolmach)
Date: Mon, 4 Jun 2001 02:31:44 -0700
Subject: GHC core representation
Message-ID: <8D7D23D65C1CEB44ABEE89F137A5D32815E71E@red-msg-09.redmond.corp.microsoft.com>
Dear Haskellers,
Many months after the topic was first raised, there is finally a draft
document describing a formal external syntax for GHC's "Core"
intermediate language. It is available from
http://www.cs.pdx.edu/~apt/ext-core.ps
Those who wish to experiment seriously with the format described
can download the latest "HEAD" experimental version of GHC.
Using the "-fext-core" option when compiling "foo.hs" will generate
a file "foo.core" (in additition to any other outputs specified).
The document currently gives only an informal semantics "Core;"
a much more formal semantics -- which I view as
a very important thing to have in practice -- is in progress=20
but not quite ready for public scrutiny.=20
As this is very much a draft (you'll see the holes!), feedback is
welcome,=20
but due to the GHC-internals nature of this topic, please direct your
comments
to glasgow-haskell-users@haskell.org or to me personally
at apt@cs.pdx.edu. I'll be out of email contact for the next
month, though, so don't expect replies until July!
- Andrew Tolmach
From ross@soi.city.ac.uk Mon Jun 4 11:07:42 2001
From: ross@soi.city.ac.uk (Ross Paterson)
Date: Mon, 4 Jun 2001 11:07:42 +0100
Subject: proof in haskell ?
In-Reply-To: <3B197128.D390CE78@europemail.com>
Message-ID: <20010604110742.A30820@soi.city.ac.uk>
On Sat, Jun 02, 2001 at 11:05:12PM +0000, luc wrote:
> chapter 12 of birds book mention mike spivey' theorem prover.
> are there anything available in source code about proof in haskell ?
The calculator in the book is available on the book's web page
http://web.comlab.ox.ac.uk/oucl/publications/books/functional/
I also have an improved version I can send on request (our web server
was incinerated last week).
From ger@tzi.de Tue Jun 5 17:32:22 2001
From: ger@tzi.de (George Russell)
Date: Tue, 05 Jun 2001 18:32:22 +0200
Subject: Advantages of Paper
Message-ID: <3B1D0996.2D1F0B03@tzi.de>
I don't want to seem incredibly Luddite, but there are some things the World Wide
Web is not good at, and one of them is permanence. Try for example finding out
about Glasgow Haskell from http://www.dcs.gla.ac.uk, which was I think the
standard URL a few years ago. In 2050 we may not even have a World Wide Web
(remember Gopher?), or if we do URLs as we have them may be as outdated as
those e-mail addresses I remember which included lots of percent signs telling
the network to send your message to Birmingham via Beachy Head. I find it
therefore of concern that many crucial Haskell documents, including the
standard and, for example, the various Glasgow Haskell manuals, are only
available online. I therefore suggest that they at least be printed out
in the form of technical reports, and made available in this form to
libraries, which are well-used to storing information long-term. Otherwise
the curious in 2050 will be able to locate manuals for FORTRAN II and
Simula (as I can do in 5 minutes in the local library), but getting Haskell
documentation will be about as easy as reading 5-track paper tape.
I don't think it matters if Haskell itself is obsolete in the year
2050, as it probably will be. But it will be a pity if most of the papers
written using it are hard to figure out because the documentation itself
is missing.
From reid@cs.utah.edu Tue Jun 5 18:14:03 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 05 Jun 2001 11:14:03 -0600
Subject: Why is there a space leak here?
In-Reply-To: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout>
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout>
Message-ID:
Executive summary: David's program has an incredibly subtle space leak
in it (or I'm being incredibly dumb). I encourage the honchos (and
would be honchos) to have a look. Users of other compilers might give
it a shot too.
David Bakin writes:
> Why is there a space leak in foo1 but not in foo2? (I.e., in Hugs
> Nov '99) foo1 eats cells (and eventually runs out) where foo2
> doesn't. That is, if I do (length (foo1 1000000)) I eventually run
> out of cells but (length (foo2 1000000)) runs fine (every GC returns
> basically the same amount of space). Something must be wrong in
> flatten but it follows the pattern of many functions in the prelude
> (which I'm trying to learn from). I have been puzzling over this
> for nearly a full day (getting this reduced version from my own code
> which wasn't working). In general, how can I either a) analyze code
> looking for a space leak or b) experiment (e.g., using Hugs) to find
> a space leak? Thanks! -- Dave
Interesting question. The functions certainly look as though either
both should leak or neither should leak. As for how to chase this
sort of problem, I'll try to describe everything I do in trying to
chase the problem down in the hope that this might be instructive.
1) Is there really a problem?
Using Feb 2001 Hugs, I run "hugs +g /tmp/leak.hs" and type
length (foo1 1000000)
output is:
{{Gc:235464}}{{Gc:227548}}{{Gc:219900}}{{Gc:212509}}{{Gc:205364}}{{Gc:198465}}{{Gc:191793}}{{Gc:185343}}{{Gc:179119}}{{Gc:173090}}{{Gc:167274}}{{Gc:161653}}{{Gc:156217}}{{Gc:150968}}{{Gc:145888}}{{Gc:140989}}{{Gc:136245}}{{Gc:131668}}{{Gc:127238}}{{Gc:122965}}{{Gc:118832}}{{Gc:114844}}{{Gc:110976}}{{Gc:107248}}{{Gc:103648}}{{Gc:100165}}{{Gc:96796}}{{Gc:93542}}{{Gc:90391}}{{Gc:87353}}{{Gc:84419}}{{Gc:81583}}{Interrupted!}
Yup, it leaks.
I then quit (just to be certain), restart and type:
length (foo2 1000000)
output is:
{{Gc:239721}}{{Gc:239718}}{{Gc:239722}}{{Gc:239725}}{{Gc:239713}}{{Gc:239717}}{{Gc:239717}}{{Gc:239722}}{{Gc:239725}}{{Gc:239713}}{{Gc:239717}}{{Gc:239717}}{{Gc:239722}}{{Gc:239725}}{Interrupted!}
Nope, it doesn't leak.
2) Could it be something to do with CAFs and the monmomorphism restriction?
Check the type:
Main> :t foo1
foo1 :: Num a => Int -> [a]
Main> :t foo2
foo2 :: Num a => Int -> [a]
Same type, almost certainly not.
(The fact that all definitions are of the form "foo m = ..." makes it
even less likely. The fact that I tried this at all shows that I'm
already grasping for straws.)
3) Could it be a bug in the garbage collector or code generator?
1) Try swapping the two definitions and see if it still leaks.
Yes, still leaks.
2) Try adding a third definition in the hope that it will perturb
code generation and heap allocation enough to make the problem show up.
(This definition is based on "double x = [x,x]")
Both foo1 (triple) and foo2 (double) leak, foo3 (single) still
doesn't leak.
3) Try a different compiler (ghc) and run with +RTS -Sstderr flags:
foo1: leaks (6Mb maximum residency)
foo2: leaks (5Mb maximum residency)
foo3: doesn't leak (1,112 bytes maximum residency)
4) Maybe there's something funny in your definition of flatten - write
my own.
f1 :: [[a]] -> [a]
f1 [] = []
f1 ([]:xss) = f1 xss
f1 ((x:xs):xss) = x : f1 (xs:xss)
Nope, foo1 still leaks and foo3 doesn't leak.
5) Cut and paste code for map and take from language definition into
this module in case Hugs (and GHC) are doing something funny.
(The straws are getting smaller and further away.)
No change.
(Actually, I wrote the definitions from memory - effect should be
the same.)
Well, I thought I understood lazy evaluation, garbage collectors, Hugs
and GHC but I'm at a complete loss for why one definition leaks and
the other doesn't. I would be really fascinated to learn what is
going on here.
I'm attaching my revised version of David's program and David's
original version.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
David's version:
----------------------------------------------------------------
-- This has a space leak, e.g., when reducing (length (foo1 1000000))
foo1 m
= take m v
where
v = 1 : flatten (map triple v)
triple x = [x,x,x]
-- This has no space leak, e.g., when reducing (length (foo2 1000000))
foo2 m
= take m v
where
v = 1 : flatten (map single v)
single x = [x]
-- flatten a list-of-lists
flatten :: [[a]] -> [a]
flatten [] = []
flatten ([]:xxs) = flatten xxs
flatten ((x':xs'):xxs) = x' : flatten' xs' xxs
flatten' [] xxs = flatten xxs
flatten' (x':xs') xxs = x': flatten' xs' xxs
----------------------------------------------------------------
The Haggoidal version:
----------------------------------------------------------------
module Main( main ) where
import Prelude hiding ( take, map )
take :: Int -> [a] -> [a]
take 0 xs = []
take m [] = []
take m (x:xs) | m > 0 = x : take (m-1) xs
map :: (a -> b) -> ([a] -> [b])
map f [] = []
map f (x:xs) = f x : map f xs
main :: IO ()
main = do
print (length (foo1 1000000))
-- This has a space leak, e.g., when reducing (length (foo1 1000000))
foo1 m
= take m v
where
v = 1 : f1 (map triple v)
triple x = [x,x,x]
-- This has no space leak, e.g., when reducing (length (foo2 1000000))
foo2 m
= take m v
where
v = 1 : flatten (map double v)
double x = [x,x]
-- This has no space leak, e.g., when reducing (length (foo3 1000000))
foo3 m
= take m v
where
v = 1 : f1 (map single v)
single x = [x]
-- This has no space leak, e.g., when reducing (length (foo3 1000000))
foo4 m
= take m v
where
v = 1 : f1 (map single v)
single x = [x,x,x]
-- flatten a list-of-lists
flatten :: [[a]] -> [a]
flatten [] = []
flatten ([]:xxs) = flatten xxs
flatten ((x':xs'):xxs) = x' : flatten' xs' xxs
flatten' :: [a] -> [[a]] -> [a]
flatten' [] xxs = flatten xxs
flatten' (x':xs') xxs = x': flatten' xs' xxs
f1 :: [[a]] -> [a]
f1 [] = []
f1 ([]:xss) = f1 xss
f1 ((x:xs):xss) = x : f1 (xs:xss)
----------------------------------------------------------------
From reid@cs.utah.edu Tue Jun 5 18:28:40 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 05 Jun 2001 11:28:40 -0600
Subject: Advantages of Paper
In-Reply-To: <3B1D0996.2D1F0B03@tzi.de>
References: <3B1D0996.2D1F0B03@tzi.de>
Message-ID:
> I find it therefore of concern that many crucial Haskell documents,
> including the standard and, for example, the various Glasgow Haskell
> manuals, are only available online.
My printed copy of the Haskell 98 report is numbered:
YaleU/DCS/RR-1106
Copies can no doubt be obtained from the Yale Haskell Group though I'm
afraid I don't know who you should write to or how much money to send.
It would be a good idea if haskell.org described how to get a copy but
I don't know who maintains those pages. As it is, you have to infer
the existence of a Yale tech report for the language from the fact
that the language report cites a tech report for the library :-)
[I'm less concerned about GHC documentation because it comes with the
compiler and it seems unlikely that you'd want one and not the other.]
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From peterson-john@cs.yale.edu Tue Jun 5 18:35:24 2001
From: peterson-john@cs.yale.edu (John Peterson)
Date: Tue, 5 Jun 2001 13:35:24 -0400
Subject: Advantages of Paper
In-Reply-To: (message from Alastair David
Reid on 05 Jun 2001 11:28:40 -0600)
References: <3B1D0996.2D1F0B03@tzi.de>
Message-ID: <200106051735.NAA06517@ragged.cs.yale.edu>
We're not really in a position to mail out bound copies of the Haskell
report. We generally distribute our tech reports in electronic form
and haven't even been asked for paper copies in years. I've got a few
bound Haskell reports that I give to visitors but we don't plan to
print any more. It would be nice if the report was published in book
form someday!
The original problem here is that there's no comprehensive archive of
Haskell related research papers. At one point we were maintaining a
set of useful papers at haskell.org by hand (Olaf did all the hard
work ...) but it's not really feasable to do any of the haskell.org
maintainence by hand anymore.
I've been slowly putting together software to automate haskell.org -
forms for adding new applications, libraries, documents, and anything
else that you could want. However, I'm not done and really need help
to get things finished. In general, haskell.org is open to anyone
that wants to work on these things and I would highly encourage anyone
with time available to pitch in! I think haskell.org is the right
place to give documents a permant home and will be glad to assist
anyone that wants to work on this with me.
John
From jans@numeric-quest.com Tue Jun 5 13:42:07 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Tue, 5 Jun 2001 08:42:07 -0400 (EDT)
Subject: Advantages of Paper
In-Reply-To: <3B1D0996.2D1F0B03@tzi.de>
Message-ID:
Judging from my logs, some libraries, such as University
of Chicago library, do their own indexing of WWW.
Jan
From ger@tzi.de Tue Jun 5 18:50:33 2001
From: ger@tzi.de (George Russell)
Date: Tue, 05 Jun 2001 19:50:33 +0200
Subject: Advantages of Paper
References: <3B1D0996.2D1F0B03@tzi.de>
Message-ID: <3B1D1BE9.A7F88F18@tzi.de>
Alastair David Reid wrote:
>
> > I find it therefore of concern that many crucial Haskell documents,
> > including the standard and, for example, the various Glasgow Haskell
> > manuals, are only available online.
>
> My printed copy of the Haskell 98 report is numbered:
>
> YaleU/DCS/RR-1106
[snip]
Er, are you sure? According to
ftp://ftp.cs.yale.edu/pub/TR/LISTING
TR1106 is "The Haskell 1.3 Language Version" and comes from 1996.
(Earlier versions of the Haskell Report also appear with separate
numbers in this listing).
http://citeseer.nj.nec.com
doesn't appear to know of any later print versions.
From jans@numeric-quest.com Tue Jun 5 14:38:48 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Tue, 5 Jun 2001 09:38:48 -0400 (EDT)
Subject: A pecular algebraic data structure
Message-ID:
I've been working with one pecular algebraic data structure,
named Register, which is described in currently upgraded
http://www.numeric-quest.com/haskell/QuantumComputer.html.
or in gzipped version of the same document
http://www.numeric-quest.com/haskell/QuantumComputer.html.gz.
Section 13 of that document outlines the background for
the topic of this message. But the section is just way too
long to quote it in here.
But to summarize it: data Register is pecular because
it is indexable but not observable in a standard way,
and because two different representations can describe the same
state. In theory there should be well defined transformation
from one representation to another. This seems to me as a good
subject for some research work.
Granted that there are many experts on functional data
structures out there (I do not want to pressure any
of you gurus, so I am not naming anyone :-)), could you please
look at the write-up and help me with the following questions?
+ Is the Register data structure strangely unique,
or does it fit somewhere into a hierarchy of known
functional data structures? I would be happy to learn
that the latter is the case, since I could then start
looking at it at a more formal, well known and tested way.
+ Is a non-uniqness of representation amenable to formal
treatment, such as deforestation?
Jan
From tom-list-haskell@moertel.com Tue Jun 5 20:05:52 2001
From: tom-list-haskell@moertel.com (Tom Moertel)
Date: Tue, 05 Jun 2001 15:05:52 -0400
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout>
Message-ID: <3B1D2D90.BA7F8BEC@moertel.com>
Alastair David Reid wrote:
>
> Executive summary: David's program has an incredibly subtle space leak
> in it (or I'm being incredibly dumb). I encourage the honchos (and
> would be honchos) to have a look. Users of other compilers might give
> it a shot too.
> David Bakin wrote:
>
> Why is there a space leak in foo1 but not in foo2?
The reason that foo1 "leaks" space is because the middle of v grows
faster than its head. So taking elements from v causes its in-memory
footprint to grow. To see why this is the case, evaluate foo1 by hand:
> -- This has a space leak, e.g., when reducing (length (foo1 1000000))
> foo1 m
> = take m v
> where
> v = 1 : flatten (map triple v)
> triple x = [x,x,x]
Focusing on just v for now, and letting f = flatten for notation
purposes, we have
(1) v = 1 : f (map triple v)
(2) = { unwrap v }
1 : f (map triple (1 : f (map triple v)))
(3) = { eval map }
1 : f (triple 1 : map triple (f (map triple v)))
(4) = { eval triple }
1 : f ([1,1,1] : map triple (f (map triple v)))
(5) = { eval f (= flatten = foldr (++) []) }
1 : 1 : 1 : 1 : f (map triple (f (map triple v))))
In order to expose elements 2-4 of v, we had to evaluate v to the extent
that the overall expression held in memory *grew*. Notice how in (1) we
had a single (f (map triple ...)) expression in the tail of v but in (5)
there are two such expressions, nested.
Continuing further, if we want to expose the 5th-7th elements of v, we
have to expand the expression yet even more. Noticing that the (f (map
triple v)) subexpression in (5) is identical to the tail of (1), we can
apply the same expansion that we derived in (1)-(5) to yield
(6) = { repeat (1)-(5) for f (map triple v) in (5) }
1 : 1 : 1 : 1 :
f (map triple (1 : 1 : 1 :
f (map triple (
f (map triple v)))))))
(7) = { eval map }
1 : 1 : 1 : 1 :
f (triple 1 : map triple (
f (map triple (
f (map triple v))))))))
(8) = { eval triple }
1 : 1 : 1 : 1 :
f ([1,1,1] : map triple (
f (map triple (
f (map triple v))))))))
(9) = { eval f }
1 : 1 : 1 : 1 : 1 : 1 : 1 :
f (map triple (
f (map triple (
f (map triple v)))))))))
Notice how in (9) we have three nested (f (map triple (...)))
expressions in the tail of v whereas in (5) we had only two and in (1)
we had but one?
Now you can see why foo1 has a space "leak": In order to take the Nth
element of v, v's definition must be expanded to the point where there
are 1+(N+1)/3 (f (map triple (...))) subexpressions in the tail of v
*that will never be reached*. In other words, v's "middle" grows faster
than its head, ensuring that take will never consume the tail. Taking
elements from the head only makes the middle grow larger. The more your
take, the larger it grows.
So the problem isn't Hugs but rather the definition of v, which grows
faster than it can be consumed.
Cheers,
Tom
From alex@shop.com Tue Jun 5 20:37:41 2001
From: alex@shop.com (S. Alexander Jacobson)
Date: Tue, 5 Jun 2001 15:37:41 -0400 (Eastern Daylight Time)
Subject: Why is there a space leak here?
In-Reply-To: <3B1D2D90.BA7F8BEC@moertel.com>
Message-ID:
This whole discussion seems strange...
Is laziness an operational or a semantic issue?
Why can't haskell implementations reduce some expressions to save space?
In particular, why can't haskell mark expressions that grow after
evaluation, and reduce them if too much space is being consumed.
For example w/ foldl:
foldl + 0 [1..10000]
foldl (+) ((+) 0 1) [2..10000]
foldl (+) ((+) ((+) 0 1) 2) [3..10000]
Can't the implementation notice that each iteration leads to a
larger closure and, if it is running out of space go ahead an just
evaluate (+) 0 1?
I realize that there is a risk of evaluating _|_ unnecessarily, but if you
are otherwise going to run out of memory, you might as well give it a
shot.
In practice, how often do you expect to see growing expressions that cover
a _|_ that are not actually an error in any case?
Hunting down memory leaks is already so obscure, that you might as well
take a shot at solving the problem automatically...
Alternatively, is there some magical way of warning about leaky
expressions at compile time? You don't have to ban them, but it would be
nice if the programmer were aware of which parts of the code are likely to
grow...
-Alex-
On Tue, 5 Jun 2001, Tom Moertel wrote:
> Alastair David Reid wrote:
> >
> > Executive summary: David's program has an incredibly subtle space leak
> > in it (or I'm being incredibly dumb). I encourage the honchos (and
> > would be honchos) to have a look. Users of other compilers might give
> > it a shot too.
>
> > David Bakin wrote:
> >
> > Why is there a space leak in foo1 but not in foo2?
>
> The reason that foo1 "leaks" space is because the middle of v grows
> faster than its head. So taking elements from v causes its in-memory
> footprint to grow. To see why this is the case, evaluate foo1 by hand:
>
> > -- This has a space leak, e.g., when reducing (length (foo1 1000000))
> > foo1 m
> > = take m v
> > where
> > v = 1 : flatten (map triple v)
> > triple x = [x,x,x]
>
> Focusing on just v for now, and letting f = flatten for notation
> purposes, we have
>
> (1) v = 1 : f (map triple v)
>
> (2) = { unwrap v }
> 1 : f (map triple (1 : f (map triple v)))
>
> (3) = { eval map }
> 1 : f (triple 1 : map triple (f (map triple v)))
>
> (4) = { eval triple }
> 1 : f ([1,1,1] : map triple (f (map triple v)))
>
> (5) = { eval f (= flatten = foldr (++) []) }
> 1 : 1 : 1 : 1 : f (map triple (f (map triple v))))
>
> In order to expose elements 2-4 of v, we had to evaluate v to the extent
> that the overall expression held in memory *grew*. Notice how in (1) we
> had a single (f (map triple ...)) expression in the tail of v but in (5)
> there are two such expressions, nested.
>
> Continuing further, if we want to expose the 5th-7th elements of v, we
> have to expand the expression yet even more. Noticing that the (f (map
> triple v)) subexpression in (5) is identical to the tail of (1), we can
> apply the same expansion that we derived in (1)-(5) to yield
>
> (6) = { repeat (1)-(5) for f (map triple v) in (5) }
> 1 : 1 : 1 : 1 :
> f (map triple (1 : 1 : 1 :
> f (map triple (
> f (map triple v)))))))
>
> (7) = { eval map }
> 1 : 1 : 1 : 1 :
> f (triple 1 : map triple (
> f (map triple (
> f (map triple v))))))))
>
> (8) = { eval triple }
> 1 : 1 : 1 : 1 :
> f ([1,1,1] : map triple (
> f (map triple (
> f (map triple v))))))))
>
> (9) = { eval f }
> 1 : 1 : 1 : 1 : 1 : 1 : 1 :
> f (map triple (
> f (map triple (
> f (map triple v)))))))))
>
> Notice how in (9) we have three nested (f (map triple (...)))
> expressions in the tail of v whereas in (5) we had only two and in (1)
> we had but one?
>
> Now you can see why foo1 has a space "leak": In order to take the Nth
> element of v, v's definition must be expanded to the point where there
> are 1+(N+1)/3 (f (map triple (...))) subexpressions in the tail of v
> *that will never be reached*. In other words, v's "middle" grows faster
> than its head, ensuring that take will never consume the tail. Taking
> elements from the head only makes the middle grow larger. The more your
> take, the larger it grows.
>
> So the problem isn't Hugs but rather the definition of v, which grows
> faster than it can be consumed.
>
> Cheers,
> Tom
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
From khaliff@astercity.net Tue Jun 5 20:50:34 2001
From: khaliff@astercity.net (Wojciech Moczydlowski, Jr)
Date: Tue, 5 Jun 2001 19:50:34 +0000 (UTC)
Subject: Why is there a space leak here?
In-Reply-To: <3B1D2D90.BA7F8BEC@moertel.com>
Message-ID:
On Tue, 5 Jun 2001, Tom Moertel wrote:
> The reason that foo1 "leaks" space is because the middle of v grows
> faster than its head. So taking elements from v causes its in-memory
> footprint to grow. To see why this is the case, evaluate foo1 by hand:
>
> So the problem isn't Hugs but rather the definition of v, which grows
> faster than it can be consumed.
> Tom
How come then that the very program compiled under nhc98 evaluates without
any problem, with memory usage below 1M during its execution?
Wojciech Moczydlowski, Jr
From tullsen@cs.yale.edu Tue Jun 5 22:03:24 2001
From: tullsen@cs.yale.edu (Mark Tullsen)
Date: Tue, 05 Jun 2001 17:03:24 -0400
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout>
Message-ID: <3B1D491C.EB097D54@cs.yale.edu>
Alastair David Reid wrote:
>
> Executive summary: David's program has an incredibly subtle space leak
> in it (or I'm being incredibly dumb). I encourage the honchos (and
> would be honchos) to have a look. Users of other compilers might give
> it a shot too.
>
> David Bakin writes:
>
> > Why is there a space leak in foo1 but not in foo2? (I.e., in Hugs
> > Nov '99) foo1 eats cells (and eventually runs out) where foo2
> > doesn't. That is, if I do (length (foo1 1000000)) I eventually run
> > out of cells but (length (foo2 1000000)) runs fine (every GC returns
> > basically the same amount of space). Something must be wrong in
> > flatten but it follows the pattern of many functions in the prelude
> > (which I'm trying to learn from). I have been puzzling over this
> > for nearly a full day (getting this reduced version from my own code
> > which wasn't working). In general, how can I either a) analyze code
> > looking for a space leak or b) experiment (e.g., using Hugs) to find
> > a space leak? Thanks! -- Dave
>
I certainly don't have tons of experience tracking down and fixing
space leaks. But I can show you how one could attack the problem
in a brute-force kind of way. Let's use the following definitions
(from Alastair) to make things simpler:
flatten :: [[a]] -> [a]
flatten [] = []
flatten ([]:xss) = flatten xss
flatten ((x:xs):xss) = x : flatten (xs:xss)
-- This has a space leak, e.g., when reducing (length (foo2 1000000))
foo2 m
= take m v
where
v = 1 : flatten (map double v)
double x = [x,x]
-- This has no space leak, e.g., when reducing (length (foo3 1000000))
foo3 m
= take m v
where
v = 1 : f1 (map single v)
single x = [x]
We just start evaluating the program by hand and observe what's happening.
I'm being a little informal in my hand evaluations (and there's probably
a number of mistakes) but I think I've done well enough to visualize the
space behavior of these programs.
Regarding my derivations:
* I'm using let's to simulate the sharing done by something like the STG
machine. If you're curious about why exactly evaluation is proceeding
as it is, you might want to look at some of the work on "call by need
calculi".
* I'm showing the evaluation steps using "p1 -> p2" to indicate that
p1 reduces to p2. Also, I "embed" evaluation steps into programs
as follows so as to save repetition (where C[] is any context):
C[ p1
-> p2
]
which is the same as
C[p1] -> C[p2]
Hopefully the indentation will disambiguate things.
So, let's simulate the evaluation of (length $ foo3 100):
length $ foo3 100
-> foldl' (\n _ -> n + 1) 0 $
foo3 100
-> take 100 v
-> let v = 1 : v2
v2 = flatten (map single v)
in take 100 (1:v2)
-> 1 : take 99 v2
-> foldl' (\n _ -> n + 1) 1 $
let v = 1 : v2
v2 = flatten (map single v)
-> flatten (map single (1:v2))
-> flatten ([1] : map single v2))
-> 1 : flatten ([] : map single v2))
in take 99 v2
->
let v = 1 : v2
v2 = 1 : v3
v3 = flatten ([] : map single v2))
in take 99 (1 : v3)
-> {GC}
let v2 = 1 : v3
v3 = flatten ([] : map single v2))
in take 99 (1 : v3)
-> 1 : take 98 v3
-> foldl' (\n _ -> n + 1) 2 $
let v2 = 1 : v3
v3 = flatten ([] : map single v2))
-> flatten (map single v2))
in take 98 v3
So, there is no space leak here because at this point we have a program
which is the same as a previous program (up to variable naming and integer
values). So the program isn't growing.
Note that for every foldl' reduction, there will be a GC (garbage collection)
step.
Now, let's simulate the evaluation of (length $ foo2 100):
length $ foo2 100
-> foldl' (\n _ -> n + 1) 0 $
foo2 100
-> take 100 v
-> let v = 1 : v2
v2 = flatten (map double v)
in take 100 (1:v2)
-> 1 : take 99 v2
-> foldl' (\n _ -> n + 1) 1 $
let v = 1 : v2
v2 = flatten (map double v)
-> flatten (map double (1:v2))
-> flatten ([1,1] : map double v2)
-> 1 : flatten ([1] : map double v2)
in take 99 v2
->
let v = 1 : v2
v2 = 1 : v3
v3 = flatten ([1] : map double v2)
in take 99 (1 : v3)
-> 1 : take 98 v3
-> {GC}
let v2 = 1 : v3
v3 = flatten ([1] : map double v2)
in take 99 (1 : v3)
-> 1 : take 98 v3
-> foldl' (\n _ -> n + 1) 2 $
let v2 = 1 : v3
v3 = flatten ([1] : map double v2)
-> 1 : flatten ([] : map double v2)
in take 98 v3
->
let v2 = 1 : v3
v3 = 1 : v4
v4 = flatten ([] : map double v2)
in take 98 (1:v4)
-> 1 : take 97 v4
-> foldl' (\n _ -> n + 1) 3 $
let v2 = 1 : v3
v3 = 1 : v4
v4 = flatten ([] : map double v2)
-> flatten (map double v2)
-> flatten (map double (1:v3))
-> flatten ([1,1] : map double v3)
-> 1 : flatten ([1] : map double v3)
in take 97 v4
->
let v2 = 1 : v3
v3 = 1 : v4
v4 = 1 : v5
v5 = flatten ([1] : map double v3)
in take 97 (1:v5)
-> {GC}
let v3 = 1 : v4
v4 = 1 : v5
v5 = flatten ([1] : map double v3)
in take 97 (1:v5)
-> 1 : take 96 v5
-> foldl' (\n _ -> n + 1) 4 $
let v3 = 1 : v4
v4 = 1 : v5
v5 = flatten ([1] : map double v3)
-> 1 : flatten ([] : map double v3)
in take 96 v5
->
let v3 = 1 : v4
v4 = 1 : v5
v5 = 1 : v6
v6 = flatten ([] : map double v3)
in take 96 (1:v6)
-> 1 : take 95 v6
-> foldl' (\n _ -> n + 1) 5 $
let v3 = 1 : v4
v4 = 1 : v5
v5 = 1 : v6
v6 = flatten ([] : map double v3)
in take 95 v6
I've done a few more reduction steps here. Note that for every two foldl'
reductions there is only one {GC} step! So, the program is growing.
Thus, we have a space leak.
- Mark
From tom-list-haskell@moertel.com Tue Jun 5 22:17:41 2001
From: tom-list-haskell@moertel.com (Tom Moertel)
Date: Tue, 05 Jun 2001 17:17:41 -0400
Subject: Why is there a space leak here?
References:
Message-ID: <3B1D4C75.D8AD6C91@moertel.com>
"Wojciech Moczydlowski, Jr" wrote:
>
> How come then that the very program compiled under nhc98 evaluates without
> any problem, with memory usage below 1M during its execution?
My claim was that v (as defined) grew faster than it could be consumed,
not that (length (foo1 n)) couldn't be evaluated in constant space.
Even so, your results suggest that nhc98 is doing something
interesting. Does the memory usage remain constant even if you take 10
or 100 times the number of elements? If so, perhaps nhc98 is smart
enough to know that
length (take n x) = n
for all infinite lists x. It might apply those smarts to optimize out
the expansion of v in foo1 when foo1's result is used as the argument of
length. Out of curiosity, what happens if you consume those elements
with foldl' (+) 0 rather than length?
Alternatively, if nhc98 were smart enough to prove that
foo1 n = replicate n 1
it could do away with v altogether, which would also explain the
interesting behavior. And if nhc does *that*, my hat's off to the nhc98
folks.
Or, if your constants are hard-coded, perhaps nhc98 is evaluating the
(length foo1 1000000) expression at compile time. What happens to
memory consumption if foo1's argument is supplied at run time?
Or maybe I'm mistaken about v. Wouldn't be the first time I've done
something boneheaded. ;-)
In any case, I am curious about what nhc98 is doing internally. Any
ideas?
Cheers,
Tom
From tullsen@cs.yale.edu Tue Jun 5 22:23:57 2001
From: tullsen@cs.yale.edu (Mark Tullsen)
Date: Tue, 05 Jun 2001 17:23:57 -0400
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> <3B1D2D90.BA7F8BEC@moertel.com>
Message-ID: <3B1D4DED.337CC06C@cs.yale.edu>
Tom,
I noticed this post after I had just posted my own response.
You have to realize that Alastair Reid is one of the truly
great Haskell programmers on planet earth. I'm serious.
So, when he says "incredibly subtle space leak" I wouldn't
expect the solution to be simple. As far as I can tell, your
argument would also apply to foo2, which doesn't have a space leak.
I'd be happy to be proven wrong, but I think this space leak
really /is/ subtle and in order to see the problem seems to
require some /tedious/ hand-reductions, taking into account both
the sharing and the strictness properties. See my recent posting
for a very brute-force "analysis".
- Mark
Tom Moertel wrote:
>
> Alastair David Reid wrote:
> >
> > Executive summary: David's program has an incredibly subtle space leak
> > in it (or I'm being incredibly dumb). I encourage the honchos (and
> > would be honchos) to have a look. Users of other compilers might give
> > it a shot too.
>
> > David Bakin wrote:
> >
> > Why is there a space leak in foo1 but not in foo2?
>
> The reason that foo1 "leaks" space is because the middle of v grows
> faster than its head. So taking elements from v causes its in-memory
> footprint to grow. To see why this is the case, evaluate foo1 by hand:
>
> > -- This has a space leak, e.g., when reducing (length (foo1 1000000))
> > foo1 m
> > = take m v
> > where
> > v = 1 : flatten (map triple v)
> > triple x = [x,x,x]
>
> Focusing on just v for now, and letting f = flatten for notation
> purposes, we have
>
> (1) v = 1 : f (map triple v)
>
> (2) = { unwrap v }
> 1 : f (map triple (1 : f (map triple v)))
>
> (3) = { eval map }
> 1 : f (triple 1 : map triple (f (map triple v)))
>
> (4) = { eval triple }
> 1 : f ([1,1,1] : map triple (f (map triple v)))
>
> (5) = { eval f (= flatten = foldr (++) []) }
> 1 : 1 : 1 : 1 : f (map triple (f (map triple v))))
>
> In order to expose elements 2-4 of v, we had to evaluate v to the extent
> that the overall expression held in memory *grew*. Notice how in (1) we
> had a single (f (map triple ...)) expression in the tail of v but in (5)
> there are two such expressions, nested.
>
> Continuing further, if we want to expose the 5th-7th elements of v, we
> have to expand the expression yet even more. Noticing that the (f (map
> triple v)) subexpression in (5) is identical to the tail of (1), we can
> apply the same expansion that we derived in (1)-(5) to yield
>
> (6) = { repeat (1)-(5) for f (map triple v) in (5) }
> 1 : 1 : 1 : 1 :
> f (map triple (1 : 1 : 1 :
> f (map triple (
> f (map triple v)))))))
>
> (7) = { eval map }
> 1 : 1 : 1 : 1 :
> f (triple 1 : map triple (
> f (map triple (
> f (map triple v))))))))
>
> (8) = { eval triple }
> 1 : 1 : 1 : 1 :
> f ([1,1,1] : map triple (
> f (map triple (
> f (map triple v))))))))
>
> (9) = { eval f }
> 1 : 1 : 1 : 1 : 1 : 1 : 1 :
> f (map triple (
> f (map triple (
> f (map triple v)))))))))
>
> Notice how in (9) we have three nested (f (map triple (...)))
> expressions in the tail of v whereas in (5) we had only two and in (1)
> we had but one?
>
> Now you can see why foo1 has a space "leak": In order to take the Nth
> element of v, v's definition must be expanded to the point where there
> are 1+(N+1)/3 (f (map triple (...))) subexpressions in the tail of v
> *that will never be reached*. In other words, v's "middle" grows faster
> than its head, ensuring that take will never consume the tail. Taking
> elements from the head only makes the middle grow larger. The more your
> take, the larger it grows.
>
> So the problem isn't Hugs but rather the definition of v, which grows
> faster than it can be consumed.
>
> Cheers,
> Tom
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From khaliff@astercity.net Tue Jun 5 22:06:50 2001
From: khaliff@astercity.net (Wojciech Moczydlowski, Jr)
Date: Tue, 5 Jun 2001 21:06:50 +0000 (UTC)
Subject: Why is there a space leak here?
In-Reply-To: <3B1D4C75.D8AD6C91@moertel.com>
Message-ID:
On Tue, 5 Jun 2001, Tom Moertel wrote:
> "Wojciech Moczydlowski, Jr" wrote:
> >
> Even so, your results suggest that nhc98 is doing something
> interesting. Does the memory usage remain constant even if you take 10
> or 100 times the number of elements? If so, perhaps nhc98 is smart
I was just writing that it stayed constant, when the executing program
ran out of heap :). Seems that my claim about nhc98 was false - I didn't
wait long enough to see the program stop. Sorry for mistaking you.
> Tom
Wojciech Moczydlowski, Jr
From Dominic.J.Steinitz@BritishAirways.com Tue Jun 5 22:40:28 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 05 Jun 2001 21:40:28 Z
Subject: Why is there a space leak here?
Message-ID: <"027723B1D51CC00F*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
I'd love it if someone could write a tutorial paper on space leaks. Even with the explanations that have been provided, I find it difficult to understand why expressions get evaluated in a particular order and why garbage collections happen at a given point.
Dominic.
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From reid@cs.utah.edu Tue Jun 5 22:45:42 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 05 Jun 2001 15:45:42 -0600
Subject: Why is there a space leak here?
In-Reply-To: <3B1D4DED.337CC06C@cs.yale.edu>
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout>
<3B1D2D90.BA7F8BEC@moertel.com>
<3B1D4DED.337CC06C@cs.yale.edu>
Message-ID:
Mark Tullsen writes:
> You have to realize that Alastair Reid is one of the truly great
> Haskell programmers on planet earth. I'm serious. So, when he says
> "incredibly subtle space leak" I wouldn't expect the solution to be
> simple. As far as I can tell, your argument would also apply to
> foo2, which doesn't have a space leak.
Yeah, well, in this case this allegedly "truly great Haskell
programmer" happened to be looking at the problem the wrong way. I
started out assuming it was a compiler or garbage collector bug and
didn't even think of trying to actually reason about the program using
the CBN calculus.
Blush!
--
Alastair Reid
ps Tell you what, I'll make up for it by making most of the fptools/hslib
libraries work in Hugs. If you have read-write access to the cvs
repository, all you have to do (as of 20 minutes ago) is:
cvs -d checkout hugs98
cvs -d checkout fptools/hslibs
cd hugs98/src/unix
./convert_hslibs ../../.. # path points to base of fptools tree
./configure --prefix=$HOME
cd ..
make install
where is whatever you normally use to get the CVS
repository. Something like this
:ext:@cvs.haskell.org:/home/cvs/root
If you only have read access, you'll need to wait until it gets updated
(sometime tonight) and then use
:pserver:anoncvs@cvs.haskell.org:/cvs
with the password "cvs".
From tom-list-haskell@moertel.com Tue Jun 5 23:08:44 2001
From: tom-list-haskell@moertel.com (Tom Moertel)
Date: Tue, 05 Jun 2001 18:08:44 -0400
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> <3B1D2D90.BA7F8BEC@moertel.com> <3B1D4DED.337CC06C@cs.yale.edu>
Message-ID: <3B1D586C.A49A480B@moertel.com>
Mark Tullsen wrote:
>
> You have to realize that Alastair Reid is one of the truly
> great Haskell programmers on planet earth. I'm serious.
> So, when he says "incredibly subtle space leak" I wouldn't
> expect the solution to be simple.
Whoops. Now don't I feel foolish.
> As far as I can tell, your argument would also apply to foo2,
> which doesn't have a space leak.
Hmmm... Let's see.
foo2 m
= take m v
where
v = 1 : flatten (map single v)
single x = [x]
v = 1 : flatten (map single v)
= 1 : flatten (map single (1 : flatten (map single v)))
= 1 : flatten (single 1 : map single (flatten (map single v)))
= 1 : flatten ([1] : map single (flatten (map single v)))
= 1 : 1 : flatten (map single (flatten (map single v)))
= Aaaarrggggh! You're right.
Now don't I feel double foolish. :P
Okay, then, what is the *right* way to reason about these things?
Cheers,
Tom
From tullsen@cs.yale.edu Tue Jun 5 23:18:01 2001
From: tullsen@cs.yale.edu (Mark Tullsen)
Date: Tue, 05 Jun 2001 18:18:01 -0400
Subject: Why is there a space leak here?
References: <"027723B1D51CC00F*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Message-ID: <3B1D5A99.74803A38@cs.yale.edu>
"Steinitz, Dominic J" wrote:
> I'd love it if someone could write a tutorial paper on space
> leaks.
I agree that would be very useful.
> Even with the explanations that have been provided, I find it
> difficult to understand why expressions get evaluated in a
> particular order and why garbage collections happen at a given
> point.
In my "traces" I did the garbage collections as soon as possible, basically
removing unused let bindings.
The ordering of evaluations is a bit more tricky ... I would
recommend becoming familiar with the various call-by-need calculi.
For me, it was more intuitive than trying to understand what's going
on at some lower level (such as the STG Machine) and then relate that
lower level to my program. With call-by-need calculi you can
understand what's going on at the source level. Here's a starting
point:
The Call-by-Need Lambda Calculus,
POPL 95, Ariola, Felleisen, Maraist, Odersky, & Wadler
@article{maraist-odersky-wadler:need-JFP98,
author = "John Maraist and Martin Odersky and Philip Wadler",
title = "The Call-by-Need Lambda Calculus",
journal = "Journal of Functional Programming",
volume = 8,
number = 3,
month = may,
year = 1998,
publisher = "Cambridge University Press",
}
- Mark
From claus.reinke@talk21.com Tue Jun 5 23:37:14 2001
From: claus.reinke@talk21.com (Claus Reinke)
Date: Tue, 5 Jun 2001 23:37:14 +0100
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> <3B1D2D90.BA7F8BEC@moertel.com>
Message-ID: <009a01c0ee10$127f6480$80f17ad5@vaio>
> Alastair David Reid wrote:
> > Executive summary: David's program has an incredibly subtle space leak
> > in it (or I'm being incredibly dumb). I encourage the honchos (and
> > would be honchos) to have a look. Users of other compilers might give
> > it a shot too.
I think there have been several good explanations already, or
is there anything wrong with them?
As Olaf pointed out, one might use GHood for the job:
http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/GHood/
An example on how to add observations in this case, and
how to interpret the results might be helpful to those who
haven't used GHood.
1. Code:
import Observe
foo1 m
= take m (observe "v-out" v)
where
v = 1 : concat (map triple (observe "v-in" v))
triple x = [x,x,x]
main = printO $ (foo1 100::[Int])
2. Interpretation:
Using Hugs to generate the observations, you should see the two
views of v evolving just as other mails in this thread have explained,
i.e., "v-out" grows at three times the rate of "v-in". Remembering
that these are two views of the same structure, the problem is that
generating "v-out" depends on "v-in", which is "v-out";-) which means
that the program execution should hold on to whatever "v-out"
delivers until observers of "v-in" are through with it. In simpler words:
"v-out to v-in: you ain't seen nothing yet!".
3. Variation:
Wojciech suggested that nhc's behaviour seems to differ slightly,
which prompted me to try whether this would be visible in GHood.
For explanation: Hood is portable, in that it works with most Haskell
implementations (special version make use of more features, when
available, and cater for renamed IOExtras..), but as it instruments
those Haskell implementations to do its work, its observations can
actually depend on what the implementation does.
As GHood shows you observations in more detail, you'll see even
more differences (such as: evaluation order of additions in nhc98
seems to depend on the type;-).
Trying the code above with nhc98-1.02 and the matching variant
of Observe.lhs, you'll see something odd: instead of two views of
v evolving in parallel, further copies of the "v-in"-view are created.
So, every three elements in "v-out", we need another element of
"v-in"(1), every three elements in "v-in"(1), we seem to need another
element of "v-in"(2), etc.
Perhaps Malcolm can explain what nhc98 does with this example?
Oh, and for all the honchos Alastairs referred to: I seem to
remember that the work on preserving cycles with lazy memo
functions also had some comments about avoiding unnecessary
growth of cyclic structures. Can anyone figure out how to apply
that to this example (or tell me that it is impossible)?
Hth,
Claus
PS: Getting new email in before sending this off, I see that
some explainers now refer to themselves as foolish, but
I'll send this off anyway, at the risk of adding myself to
that foolish Haskell programmers club:-)
From tullsen@cs.yale.edu Tue Jun 5 23:54:31 2001
From: tullsen@cs.yale.edu (Mark Tullsen)
Date: Tue, 05 Jun 2001 18:54:31 -0400
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> <3B1D2D90.BA7F8BEC@moertel.com> <3B1D4DED.337CC06C@cs.yale.edu> <3B1D586C.A49A480B@moertel.com>
Message-ID: <3B1D6327.DBB516C2@cs.yale.edu>
Tom Moertel wrote:
>
> Mark Tullsen wrote:
> >
> > You have to realize that Alastair Reid is one of the truly
> > great Haskell programmers on planet earth. I'm serious.
> > So, when he says "incredibly subtle space leak" I wouldn't
> > expect the solution to be simple.
>
> Whoops. Now don't I feel foolish.
>
> > As far as I can tell, your argument would also apply to foo2,
> > which doesn't have a space leak.
>
> Hmmm... Let's see.
>
> foo2 m
> = take m v
> where
> v = 1 : flatten (map single v)
> single x = [x]
>
> v = 1 : flatten (map single v)
> = 1 : flatten (map single (1 : flatten (map single v)))
> = 1 : flatten (single 1 : map single (flatten (map single v)))
> = 1 : flatten ([1] : map single (flatten (map single v)))
> = 1 : 1 : flatten (map single (flatten (map single v)))
> = Aaaarrggggh! You're right.
>
> Now don't I feel double foolish. :P
>
> Okay, then, what is the *right* way to reason about these things?
>
> Cheers,
> Tom
Tom,
I don't know if this approach is the *right* way but it's one
way. This approach is very brute force, and I'm sure there are experts
out there who can think and reason at a much higher level than
this. But the brute force approach is this:
Start evaluating your program symbolically
You can do this at the source level using a CBN (call-by-need)
calculus.
If the program (the program in CBN includes the "heap") starts
growing in size faster than expected then you have a space leak.
Simple, but a bit tedious. It would be great if we had a tool that
could output such a trace.
- Mark
From claus.reinke@talk21.com Wed Jun 6 10:51:32 2001
From: claus.reinke@talk21.com (Claus Reinke)
Date: Wed, 6 Jun 2001 10:51:32 +0100
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> <3B1D2D90.BA7F8BEC@moertel.com> <3B1D4DED.337CC06C@cs.yale.edu> <3B1D586C.A49A480B@moertel.com>
Message-ID: <001501c0ee6e$456a9500$0b06073e@vaio>
From: "Tom Moertel"
> Okay, then, what is the *right* way to reason about these things?
(Non?-)strictly speaking, there is no *right* way to reason about
these things, as Haskell somehow seems to have neglected to acquire
a semantics (blush - even Java has one, kind of..). The reason, as far
as I can tell, is that everyone assumed that the core of Haskell is
sufficiently similar to "standard" calculi (some of which were developed
to make this so), so that those or "standard" works on
implementation implicitly define what everyone assumes to be Haskell's
semantics (I find it funny that the report, which equates "non-strict" and
"lazy", refers to potential loss of sharing in two places, without ever
bothering to explain how such sharing might come about in the first
place.. or am I missing anything?).
Perhaps one could say that Haskell was too lazy to acquire a
semantics before it was needed?-) But call-by-need lambda-calculus,
refered to in other replies, was developed in anticipation or
awareness of that need, I think, and is a good place to get started
without having to worry about implementation details.
> v = 1 : flatten (map single v)
> = 1 : flatten (map single (1 : flatten (map single v)))
> = 1 : flatten (single 1 : map single (flatten (map single v)))
> = 1 : flatten ([1] : map single (flatten (map single v)))
> = 1 : 1 : flatten (map single (flatten (map single v)))
> = Aaaarrggggh! You're right.
In essence, call-by-need is normal-order evaluation plus sharing of
parameters, so you can adapt your deduction (which follows
normal-order reduction, but ignores sharing) by taking care of
sharing (I'll use where for that here):
v = 1 : flatten (map single v)
->
v = 1 : tl_v
where tl_v = flatten (single 1 : map single tl_v) -- don't lose that sharing
->
v = 1 : tl_v
where tl_v = flatten ([1] : map single tl_v)
->
v = 1 : tl_v
where tl_v = 1 : flatten (map single tl_v) -- this looks familiar
..
->
v = 1 : tl_v
where tl_v = 1 : tl_tl_v -- there is now only one reference to this
tl_tl_v = 1 : flatten (map single tl_tl_v)
=
v = 1 : 1 : tl_tl_v
where tl_tl_v = 1:flatten (map single tl_tl_v)
..
I've tried to stay close to your own derivation, but otherwise this
should really correspond to Mark Tullsen's earlier posting. This
might already enable you to adapt your derivation for the version
with triple instead of single, but I would still suggest to have a
look at the CBN papers.
To complement my own earlier posting, GHood builds on Hood,
which doesn't observe sharing or garbage-collection, so if one of
these is important to the argument, observations have to be
interpreted with more care than usual.Still, it can be quite helpful
because it can give you some input about your program's behaviour
Hth,
Claus
From gustavss@cs.chalmers.se Wed Jun 6 11:52:30 2001
From: gustavss@cs.chalmers.se (=?ISO-8859-1?Q?J=F6rgen_Gustavsson?=)
Date: Wed, 6 Jun 2001 12:52:30 +0200 (MET DST)
Subject: Why is there a space leak here?
In-Reply-To: <3B1D586C.A49A480B@moertel.com>
Message-ID:
Tom Moertel wrote:
> Okay, then, what is the *right* way to reason about these things?
I will take the oppurtunity to advertise some recent work I have been
doing together with David Sands.
I think that the call-by-need lambda calculus is a very good starting
point for gaining intuition about call-by-need beacuse it gives a way to
reason about call-by-need computation at the term level. But the
call-by-need lambda calculus was not designed for reasoning about space -
there are terms which are considered equivalent which when you replace
one by the other in a whole program may change the asymptotic space
behaviour of the program. Therefore, we have been working on a theory of
space equivalence based on an operational semantics for a small subset of
Haskell. We have used the theory to reason about the to different
definitions of the function any that were discussed on the list some
months ago and I think it could be used in this case too. If you are
interested you can find a draft paper at www.cs.chalmers.se/~gustavss/.
We will submit the final version to ICFP in a few weeks so we would be
very grateful for any comments.
Regards,
Jörgen Gustavsson.
From iscp9157@nus.edu.sg Thu Jun 7 03:30:42 2001
From: iscp9157@nus.edu.sg (Saswat Anand)
Date: Wed, 6 Jun 2001 19:30:42 -0700
Subject: Functional Dependency
Message-ID: <001701c0eefa$815d8b80$bd3e8489@saswat>
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C0EEBF.2CC13E40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I am trying to define a commutative operator :
(%+) :: a -> b -> c
(%+) :: b -> a -> c
instead of defining a class and instantiating twice every time, I am =
trying to do the following:
class Commutative a b c where
(%+) :: a -> b -> c
class Operation a b c | a b -> c where
(%+%) :: a -> b -> c
instance (Operation a b c) =3D> Commutative a b c where
(%+) =3D (%+%)
instance (Operation b a c) =3D> Commutative a b c where
(%+) =3D flip (%+%)
--=20
instance Operation Int (Maybe Int) Int where
i %+% (Just s) =3D i + s
---
With hugs -98 +mo
((2::Int) %+ (Just (2::Int)))::Int gives 4
But (2::Int) %+ (Just (2::Int)) is of type Commutative Int (Maybe Int) =
a =3D> a. So is (Just (2::Int)) %+ (2::Int)
Is the dependency in Operation class not sufficient. Any work around?
Which flags to be set for Ghc to accept this code. I tried =
-fallow-overlapping-instances and
-fallow-undecidable-instances.
Thanks,
S
------=_NextPart_000_0007_01C0EEBF.2CC13E40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I am trying to define a =
commutative operator=20
:
(%+) :: a -> b -> c
(%+) :: b -> a ->=20
c
instead of defining a class and =
instantiating twice=20
every time, I am trying to do the following:
class Commutative a b c =
where
(%+) ::=20
a -> b -> c
class Operation a b c | a b -> c=20
where
(%+%) :: a -> b -> c
instance (Operation a b c) =3D> =
Commutative a b c=20
where
(%+) =3D (%+%)
instance (Operation b a c) =3D> =
Commutative a b c=20
where
(%+) =3D flip (%+%)
--
instance Operation Int (Maybe Int) Int=20
where
i %+% (Just s) =3D i + s
---
With hugs -98 +mo
((2::Int) %+ =
(Just=20
(2::Int)))::Int gives 4
But (2::Int) %+ (Just (2::Int)) is of =
type =20
Commutative Int (Maybe Int) a =3D> a. So is (Just (2::Int)) %+=20
(2::Int)
Is the dependency in Operation class =
not=20
sufficient. Any work around?
Which flags to be set for Ghc to accept =
this code.=20
I tried -fallow-overlapping-instances=20
and
-fallow-undecidable-instances.
Thanks,
S
------=_NextPart_000_0007_01C0EEBF.2CC13E40--
From cwitty@newtonlabs.com Wed Jun 6 19:30:34 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 06 Jun 2001 11:30:34 -0700
Subject: Why is there a space leak here?
In-Reply-To: "S. Alexander Jacobson"'s message of "Tue, 5 Jun 2001 15:37:41 -0400 (Eastern Daylight Time)"
References:
Message-ID:
"S. Alexander Jacobson" writes:
> For example w/ foldl:
>
> foldl + 0 [1..10000]
> foldl (+) ((+) 0 1) [2..10000]
> foldl (+) ((+) ((+) 0 1) 2) [3..10000]
>
> Can't the implementation notice that each iteration leads to a
> larger closure and, if it is running out of space go ahead an just
> evaluate (+) 0 1?
It's complicated. You can't (in general) know whether application of
a function will increase or decrease the space used. If you were
running out of space, would you just search the whole unevaluated
program graph for reductions which somehow seemed "likely" to reduce
the space used? Would you add such reduction nodes to some global
list at the time they were created?
> I realize that there is a risk of evaluating _|_ unnecessarily, but if you
> are otherwise going to run out of memory, you might as well give it a
> shot.
>
> In practice, how often do you expect to see growing expressions that cover
> a _|_ that are not actually an error in any case?
It's certainly possible.
One portable way to implement a memoizing function in Haskell (if the
domain of the function is countable) is to lazily build a data
structure that contains the results of the function on every possible
argument. Then you evaluate the portions of the data structure that
you need; the result on each argument is only evaluated once. This
probably would count as a "growing expression", and it's certainly
possible that the function on some arguments would be bottom.
> Hunting down memory leaks is already so obscure, that you might as well
> take a shot at solving the problem automatically...
>
> Alternatively, is there some magical way of warning about leaky
> expressions at compile time? You don't have to ban them, but it would be
> nice if the programmer were aware of which parts of the code are likely to
> grow...
In general, this problem is uncomputable. It might be possible to
come up with some useful approximation, but I bet that's a very
difficult research problem.
Carl Witty
From Malcolm.Wallace@cs.york.ac.uk Thu Jun 7 12:11:12 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 7 Jun 2001 12:11:12 +0100
Subject: Why is there a space leak here? (fwd)
In-Reply-To:
Message-ID:
Hi Claus,
I've had a look at this example in GHood, and you are right, nhc98
does seem to create several copies of v-in.
> import Observe
>
> foo1 m
> = take m (observe "v-out" v)
> where
> v = 1 : concat (map triple (observe "v-in" v))
> triple x = [x,x,x]
>
> main = printO $ (foo1 100::[Int])
> Perhaps Malcolm can explain what nhc98 does with this example?
At a guess, I think the answer lies in lambda-lifting.
nhc98 -c Leak.hs +CTS -lift -CTS
shows this code for `v' (reformatted a little to make it easier to read):
Main.Prelude.173.v = \ v223 v224 ->
Prelude.:
(Prelude._apply1 (Prelude.fromInteger v223) 1L)
(Prelude._apply1
(Prelude.concat)
(Prelude.map (Main.Prelude.174.triple)
(Observe.observe (Observe.Observable.Prelude.[] v224)
(LAMBDA225)
(Prelude._apply2
(Main.Prelude.173.v) v223 v224))))
v takes two arguments; v223 represents the numeric dictionary, and
v224 the Observer dictionary. The recursive reference to v is not
a cyclic pointer to a constant structure, but actually a function call.
I believe the real culprit is that nhc98 does not implement the
monomorphism restriction. IIRC, the DMR applies to every group
of simple pattern bindings at the same let-bound scope, not just
the top-level, so really we ought to default-away the dictionaries,
which would solve this particular space oddity.
Regards,
Malcolm
From giorgio@etabeta.disi.unige.it Thu Jun 7 16:09:58 2001
From: giorgio@etabeta.disi.unige.it (Giorgio Delzanno)
Date: Thu, 7 Jun 2001 17:09:58 +0200 (CEST)
Subject: CFP: ICLP ws SAVE 2001
Message-ID: <200106071509.RAA19748@etabeta.disi.unige.it>
===============================================================================
We apologize for multiple copies of this message
===============================================================================
ICLP 2001 workshop SAVE 2001
Specification, Analysis and Validation for Emerging Technologies
in Computational Logic
http://www.disi.unige.it/person/DelzannoG/save.html
Dec 1, 2001 , Coral Beach Hotel and Resort, Paphos, Cyprus
Submission Deadline: August 25, 2001
The huge increase in interconnectivity we have witnessed in the last decade has boosted the development of
systems which are often large-scale, distributed, time-critical, and possibly acting in an unreliable or malicious
environment. Furthermore, software and hardware components are often mobile, and have to interact with a
potentially arbitrary number of other entities.
These systems require solid formal techniques for their verification and analysis. In this respect, computational
logic plays an increasingly important role, both providing formal methods for proving system's correctness and
tools - e.g. using techniques like constraint programming and theorem proving - for verifying their properties.
In addition, computational logic is gaining importance as tool for the specification of (part) of these systems. For
instance, one can think at the specification, in a form of temporal logic, of a communication protocol. Such
specification offers the advantage that one can reason about it using formal methods, and at the same time it is
often easily executable by rewriting it into a logic-based programming language.
Extending and shifting slightly from the scope of the predecessors (on verification and logic languages) held in
the context of past editions of ICLP, the aim of this workshop is to bring together researchers interested in the
use of computational logicas a tool for the specification, analysis and validation of systems, with particular
emphasis on (but not restricted to) emerging technologies like World Wide Web and E-Commerce, (protocols
for) Smart Cards and Mobile Telephony, Wireless Technology, Hybrid Systems, Real-Time and Distributed
systems etc.
Topics
The topics of interest include but are not limited to:
Specification languages and rapid prototyping:
Logic programming and its extensions
First-order, constructive, modal and temporal logic
Constraints
Type theory
Analysis:
Abstract interpretation
Static analysis
Validation:
Simulation and testing
Deductive methods
Model checking
Theorem proving
The preferred issues include, but are not limited to:
Mobility: specification and verification of mobile code.
Security: access rights, information flow, and security protocols.
Interaction, coordination, negotiation, communication and exchange on the Web.
Open and infinite-state systems.
Real-time systems.
Important Dates:
Deadline for submissions: August 25, 2001.
Notification of acceptance/rejection: September 15, 2001.
Final papers due: October 5, 2001.
Authors should submit papers of at most 15 pages, in postscript format,
formatted for A4 paper, to Giorgio Delzanno (giorgio@disi.unige.it) by
31st July 2001. The proceedings will be published in electronic format.
A printed version will be distributed to all
participants of the workshop.
On the basis of the number and quality of the submissions, we could also consider the
possibility of inviting submissions for a special issue of an international journal
dedicated to the workshop.
Workshop Organizers/PC Chairs:
Giorgio Delzanno
Dipartimento di Informatica e Scienze dell'Informazione
Universita' di Genova
giorgio@disi.unige.it
Sandro Etalle
Department of Computer Science
University of Twente and CWI
etalle@cs.utwente.nl
Maurizio Gabbrielli
Dipartimento di Matematica ed Informatica
Universita' di Udine
gabbri@dimi.uniud.it
Program Committee:
Radhia Cousot, CNRS & École Polytechnique, France
Giorgio Delzanno, University of Genova, Italy
Sandro Etalle, University of Twente and CWI, The Netherlands
Maurizio Gabbrielli, University of Udine, Italy
Thierry Massart, University of Brussels, Belgium
Frank Pfenning, Carnegie Mellon University, USA
Andreas Podelski, Max Planck Institute, Germany
Sriram Rajamani, Microsoft Research, USA
Jean-Francois Raskin, University of Brussels, Belgium
From alex@shop.com Fri Jun 8 15:41:48 2001
From: alex@shop.com (S. Alexander Jacobson)
Date: Fri, 8 Jun 2001 10:41:48 -0400 (Eastern Daylight Time)
Subject: Why is there a space leak here?
In-Reply-To:
Message-ID:
On 6 Jun 2001, Carl R. Witty wrote:
> "S. Alexander Jacobson" writes:
>
> > For example w/ foldl:
> >
> > foldl + 0 [1..10000]
> > foldl (+) ((+) 0 1) [2..10000]
> > foldl (+) ((+) ((+) 0 1) 2) [3..10000]
> >
> > Can't the implementation notice that each iteration leads to a
> > larger closure and, if it is running out of space go ahead an just
> > evaluate (+) 0 1?
>
> It's complicated. You can't (in general) know whether application of
> a function will increase or decrease the space used. If you were
> running out of space, would you just search the whole unevaluated
> program graph for reductions which somehow seemed "likely" to reduce
> the space used? Would you add such reduction nodes to some global
> list at the time they were created?
I'm not clear why you can't in general notice that you are using
more space after function application than before. I it hard to see why a
program couldn't do the analysis I just did on foldl.
You could accumulate statistics on funtions that increase/decrease space
used at runtime and evaluate those that do reduce space used...
> > I realize that there is a risk of evaluating _|_ unnecessarily, but if you
> > are otherwise going to run out of memory, you might as well give it a
> > shot.
> >
> > In practice, how often do you expect to see growing expressions that cover
> > a _|_ that are not actually an error in any case?
>
> It's certainly possible.
You are trading off the likelihood that an exploding expression contains a
bottom against the liklihood that the programmer would prefer the
exploding expression not to explode. Much of this type of work can be
done as test-time warnings....
> One portable way to implement a memoizing function in Haskell (if the
> domain of the function is countable) is to lazily build a data
> structure that contains the results of the function on every possible
> argument. Then you evaluate the portions of the data structure that
> you need; the result on each argument is only evaluated once. This
> probably would count as a "growing expression", and it's certainly
> possible that the function on some arguments would be bottom.
I don't think I understood this. Can you clarify?
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
From jcab@roningames.com Sun Jun 10 03:39:42 2001
From: jcab@roningames.com (Juan Carlos Arevalo Baeza)
Date: Sat, 09 Jun 2001 19:39:42 -0700
Subject: Why is there a space leak here?
In-Reply-To:
References:
Message-ID: <4.3.2.7.2.20010609192951.03907a70@207.33.235.243>
At 10:41 AM 6/8/2001 -0400, S. Alexander Jacobson wrote:
> > One portable way to implement a memoizing function in Haskell (if the
> > domain of the function is countable) is to lazily build a data
> > structure that contains the results of the function on every possible
> > argument. Then you evaluate the portions of the data structure that
> > you need; the result on each argument is only evaluated once. This
> > probably would count as a "growing expression", and it's certainly
> > possible that the function on some arguments would be bottom.
>
>I don't think I understood this. Can you clarify?
I believe I know what he's talking about. The example I've read about
this technique is random-number generators. Because typical generators will
need a state (the seed), they can be awkward to use in functional
languages. Instead, you can just generate an infinite list of the random
numbers, and extract them from that list lazily.
Specifically, what he's talking about is the fact that a function like
"Natural -> a" corresponds to a list where all the possible results for
each number are stored in the corresponding position in the list. If you
generate that list lazily, and then access it, each element will only be
computed once (the compiler/interpreter takes care of this in a very
natural way). But if you do this, the program will (or can) grow as more
elements get computed.
Am I making sense?
Salutaciones,
JCAB
---------------------------------------------------------------------
Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com
Senior Technology programmer | mailto:jcab@roningames.com
Ronin Entertainment | ICQ: 10913692
(my opinions are only mine)
JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html
From ashley@semantic.org Sun Jun 10 06:55:48 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Sat, 9 Jun 2001 22:55:48 -0700
Subject: Monomorphism Restriction
Message-ID: <200106100555.WAA05519@mail4.halcyon.com>
Is there a point to the "monomorphism restriction" in GHC and Hugs? In
practice, all it seems to mean is "occasionally require unnecessary
explicit type signatures".
--
Ashley Yakeley, Seattle WA
From bjpop@cs.mu.OZ.AU Mon Jun 11 05:34:23 2001
From: bjpop@cs.mu.OZ.AU (Bernard James POPE)
Date: Mon, 11 Jun 2001 14:34:23 +1000 (EST)
Subject: Monomorphism Restriction
Message-ID: <200106110434.OAA06216@mulga.cs.mu.OZ.AU>
Ashley Yakeley, Seattle WA, writes:
> Is there a point to the "monomorphism restriction" in GHC and Hugs? In
> practice, all it seems to mean is "occasionally require unnecessary
> explicit type signatures".
I think the point is made clearly enough in section 4.5.5 of the Haskell 98
language report, you can find it at www.haskell.org. Whether you are
satisified with this explanation is another matter.
Regards Bernie.
From kahl@heraklit.informatik.unibw-muenchen.de Mon Jun 11 10:22:38 2001
From: kahl@heraklit.informatik.unibw-muenchen.de (kahl@heraklit.informatik.unibw-muenchen.de)
Date: 11 Jun 2001 09:22:38 -0000
Subject: Haskell 98 Report
In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com>
(simonpj@microsoft.com)
References: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <20010611092238.11279.qmail@demokrit.informatik.unibw-muenchen.de>
Simon Peyton-Jones wrote:
> I've finished what I hope is the final version of the Haskell 98
> Language and Library Reports
> http://research.microsoft.com/~simonpj/haskell98-revised
haskell98-library-html/index.html still contains the following line:
The Haskell Library Report 1.4
By my count, it should be ``1.6'' ;-)
Cheers,
Wolfram
From radhia@lix.polytechnique.fr Sat Jun 9 19:38:00 2001
From: radhia@lix.polytechnique.fr (radhia@lix.polytechnique.fr)
Date: Sat, 9 Jun 2001 20:38:00 +0200 (CEST)
Subject: SAS'01: Early registration 15th June
Message-ID: <200106091838.UAA11019@albatros.polytechnique.fr>
___________________________________________________________________________
[We apologize for any inconvience caused by multiple copies]
SAS'01
Eigth International Static Analysis Symposium
La Sorbonne, Paris, 16-18 July, 2001
http://www.ens.fr/sas01/
Registration information is available on the SAS'01 website.
Early registration ends soon (15th June).
___________________________________________________________________________
From claire@CoLi.Uni-SB.DE Mon Jun 11 09:46:06 2001
From: claire@CoLi.Uni-SB.DE (Claire Gardent)
Date: Mon, 11 Jun 2001 10:46:06 +0200 (MET DST)
Subject: CFP ESSLLI02 (Trento, Italy)
Message-ID:
[An HTML version of the Call for Proposals is available via the
FoLLI page .
Usual apologies apply if you receive multiple copies of this message.]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Fourteenth European Summer School in Logic, Language and Information
ESSLLI-2002
August 4-17, 2002, Trento, Italy
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
CALL FOR COURSE and WORKSHOP PROPOSALS
--------------------------------------
The main focus of the European Summer Schools in Logic, Language and
Information is on the interface between linguistics, logic and
computation. Foundational, introductory and advanced courses together
with workshops cover a wide variety of topics within the three areas
of interest: Language and Computation, Language and Logic, and Logic
and Computation.
Previous summer schools have been highly successful, attracting up to
500 students from Europe and elsewhere. The school has developed into
an important meeting place and forum for discussion for students and
researchers interested in the interdisciplinary study of Logic,
Language and Information. ESSLLI-2002 is organised under the auspices
of the European Association for Logic, Language and Information
(FoLLI).
The ESSLLI-2002 Programme Committee invites proposals for foundational,
introductory, and advanced courses, and for workshops for the 14th annual
Summer School on a wide range of topics in the following fields:
LANGUAGE & COMPUTATION LANGUAGE & LOGIC LOGIC & COMPUTATION
In addition to courses and workshops there will be a Student Session. A Call
for Papers for the Student Session will be distributed separately.
PROPOSAL SUBMISSION: Proposals should be submitted through a web form located
at
All proposals should be submitted no later than July 22, 2001.
Authors of proposals will be notified of the committee's decision no
later than September 17, 2001. Proposers should follow the guidelines
below while preparing their submissions; proposals that deviate can
not be considered.
GUIDELINES FOR SUBMISSION: Anyone interested in lecturing or organising a
workshop during ESSLLI-2002, please read the following information carefully.
ALL COURSES: Courses are taught by 1 or max. 2 lecturers. They typically
consist of five sessions (a one-week course) or ten sessions (a two-week
course). Each session lasts 90 minutes.
Timetable for Course Proposal Submission:
Jul 22, 2001: Proposal Submission Deadline
Sep 17, 2001: Notification
Nov 15, 2001: Deadline for receipt of title, abstract, lecturer(s)
information, course description and prerequisites
Jun 1, 2002: Deadline for receipt of camera-ready course material
FOUNDATIONAL COURSES: These are really elementary courses not assuming any
background knowledge. They are intended for people to get acquainted with the
problems and techniques of areas new to them. Ideally, they should allow
researchers from other fields to acquire the key competences of neighbouring
disciplines, thus encouraging the development of a truly interdisciplinary
research community. Foundational courses may presuppose some experience with
scientific methods in general, so as to be able to concentrate on the issues
that are germane to the area of the course.
INTRODUCTORY COURSES: Introductory courses are central to the
activities of the Summer School. They are intended to equip students
and young researchers with a good understanding of a field's basic
methods and techniques. Introductory courses in, for instance,
Language and Computation, can build on some knowledge of the component
fields; e.g., an introductory course in computational linguistics
should address an audience which is familiar with the basics of
linguistics and computation.
Proposals for introductory courses should indicate the level of
the course as compared to standard texts in the area.
ADVANCED COURSES: Advanced courses should be pitched at an audience of
advanced Masters or PhD students. Proposals for advanced courses
should specify the prerequisites in some detail.
WORKSHOPS: The aim of the workshops is to provide a forum for advanced
Ph.D. students and other researchers to present and discuss their
work. A workshop has a theme. At most one organiser is paid. The
organisers should be specialists in the theme of the workshop and give
a general introduction in the first session. They are also
responsible for the programme of the workshop, i.e., for finding
speakers.
Each workshop organiser will be responsible for producing a Call for
Papers for the workshop by November 15, 2001. The call must make it
clear that the workshop is open to all members of the LLI community.
It should also note that all workshop contributors must register for
the Summer School.
A workshop consists of five sessions (a one-week workshop) or ten
sessions (a two-week workshop). Sessions are normally 90 minutes.
Timetable for Workshop Proposal Submissions
Jul 22, 2001: Proposal Submission Deadline
Sep 15, 2001: Notification
Nov 15, 2001: Deadline for receipt of Call for Papers
Dec 1, 2001: Send out Call for Papers
Mar 15, 2002: Deadline for Papers (suggested)
May 1, 2002: Notification of Workshop Contributors (suggested)
May 15, 2002: Deadline for Provisional Workshop Programme
Jun 1, 2002: Deadline for receipt of camera-ready copy of Workshop
notes
Jun 1, 2002: Deadline for Final Workshop Programme
FORMAT FOR PROPOSALS:
The web-based form for submitting course and workshop proposals is accessible
at . You will be required
to submit the following information:
* Name (name(s) of proposed lecturer(s)/organiser)
* Address (contact addresses of proposed lecturer(s)/organiser;
where possible, please include phone and fax numbers)
* Title (title of proposed course/workshop)
* Type (is this a workshop, a foundational course, an introductory
course, or an advanced course?)
* Section (does your proposal fit in Language & Computation,
Language & Logic or Logic & Computation? name only one)
* Description (describe the proposed contents in at most 150 words)
* External funding (will you be able to find external funding to
help fund your travel and accommodation expenses? if so, how?)
* Further particulars (any further information that is required by
the above guidelines should be included here)
FINANCIAL ASPECTS: Prospective lecturers and workshop organisers
should be aware that all teaching and organising at the summer schools
is done on a voluntary basis in order to keep the participants fees as
low as possible. Lecturers and organisers are not paid for their
contribution, but are reimbursed for travel and accommodation. Please
note the following: In case a course is to be taught by two lecturers,
a lump sum is paid to cover travel and accommodation expenses. The
splitting of the sum is up to the lecturers. However, please note
that the organisers highly appreciate it if, whenever possible,
lecturers and workshop organisers find alternative funding to cover
travel and accommodation expenses.
Workshop speakers are required to register for the Summer School;
however, workshop speakers will be able to register at a reduced rate
to be determined by the Organising Committee.
Finally, it should be stressed that while proposals from all over the
world are welcomed, the Summer School can in general guarantee only to
reimburse travel costs for travel from destinations within Europe to
Trento. Exceptions will be made depending on the financial situation.
PROGRAM COMMITTEE:
Claire Gardent (chair)
Attn: ESSLLI-2002
LORIA
BP 239 Campus Scientifique
54506 Vandoeuvre-les-Nancy (France)
Tel: +33-3-83-59-2039
Fax: +33-3-83-27-5652
Email: claire.gardent@loria.fr
Local co-chair:
Paolo Bouquet (bouquet@cs.unitn.it)
Language & Computation:
Hinrich Schuetze (me@hinrichschuetze.com)
Gerry Altmann (g.altmann@psych.york.ac.uk)
Language & Logic:
Fabio Pianesi (pianesi@irst.itc.it)
Steve Pulman (stephen.pulman@somerville.ox.ac.uk)
Logic & Computation:
Simon Parsons (S.D.Parsons@csc.liv.ac.uk )
Frank Wolter (wolter@jaist.ac.jp)
ORGANISING COMMITTEE:
Luciano Serafini (chair)
Email: serafini@itc.it
FURTHER INFORMATION: To obtain further information, visit the web site
for ESSLLI-2002 .
For this year's summer school, please see the web site for ESSLLI-2001
.
http://www.loria.fr/~gardent
From cwitty@newtonlabs.com Mon Jun 11 23:58:14 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 11 Jun 2001 15:58:14 -0700
Subject: Why is there a space leak here?
In-Reply-To: "S. Alexander Jacobson"'s message of "Fri, 8 Jun 2001 10:41:48 -0400 (Eastern Daylight Time)"
References:
Message-ID:
"S. Alexander Jacobson" writes:
> On 6 Jun 2001, Carl R. Witty wrote:
>
> > "S. Alexander Jacobson" writes:
> >
> > > For example w/ foldl:
> > >
> > > foldl + 0 [1..10000]
> > > foldl (+) ((+) 0 1) [2..10000]
> > > foldl (+) ((+) ((+) 0 1) 2) [3..10000]
> > >
> > > Can't the implementation notice that each iteration leads to a
> > > larger closure and, if it is running out of space go ahead an just
> > > evaluate (+) 0 1?
> >
> > It's complicated. You can't (in general) know whether application of
> > a function will increase or decrease the space used. If you were
> > running out of space, would you just search the whole unevaluated
> > program graph for reductions which somehow seemed "likely" to reduce
> > the space used? Would you add such reduction nodes to some global
> > list at the time they were created?
>
> I'm not clear why you can't in general notice that you are using
> more space after function application than before. I it hard to see why a
> program couldn't do the analysis I just did on foldl.
I wasn't worried about foldl; you assumed that (+) 0 1 got smaller if
you carried out the application. Even for (+) on Integer, this is not
guaranteed (for large integers, if something else happens to be
holding on to the summands, evaluating the addition can increase total
space usage).
> You could accumulate statistics on funtions that increase/decrease space
> used at runtime and evaluate those that do reduce space used...
Right, that's the sort of thing I meant about "likely" above. But how
do you find such function applications in the global program graph, if
you seem to be running low on space? (And you also need to realize
that some functions might usually have "small" outputs, and sometimes
have "large" outputs.)
> > One portable way to implement a memoizing function in Haskell (if the
> > domain of the function is countable) is to lazily build a data
> > structure that contains the results of the function on every possible
> > argument. Then you evaluate the portions of the data structure that
> > you need; the result on each argument is only evaluated once. This
> > probably would count as a "growing expression", and it's certainly
> > possible that the function on some arguments would be bottom.
>
> I don't think I understood this. Can you clarify?
Let me know if JCAB's response wasn't enough here.
Carl Witty
From heron_carvalho@bol.com.br Thu Jun 14 14:02:18 2001
From: heron_carvalho@bol.com.br (Heron)
Date: Thu, 14 Jun 2001 10:02:18 -0300
Subject: Ray Tracing
Message-ID: <002401c0f4d2$400bd280$66a1fea9@heron>
This is a multi-part message in MIME format.
------=_NextPart_000_0021_01C0F4B9.18E100E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Haskell & GHC people,
I need the source code of a Ray Tracing written in Haskell. This =
code was used for parallelization using Caliban and Eden. Can you help =
me on how or where I can obtain it ?
Heron de Carvalho, Msc.
------=_NextPart_000_0021_01C0F4B9.18E100E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Haskell=20
& GHC people,
I need =
the source=20
code of a Ray Tracing written in Haskell. This code was =
used for=20
parallelization using Caliban and Eden. Can you help me on how or where =
I can=20
obtain it ?
Heron de Carvalho, =
Msc.
------=_NextPart_000_0021_01C0F4B9.18E100E0--
From simonpj@microsoft.com Fri Jun 15 17:21:39 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 15 Jun 2001 09:21:39 -0700
Subject: Eq instance for (a,b,c,d,e) and upwards
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D730AA@red-msg-09.redmond.corp.microsoft.com>
Folks
It seems that people are happy with the draft Haskell report (I'm=20
glad to say). There seem to be two outstanding issues:
* Tuples. I've decided to specify that tuples up to size 15 exist,
along with all their Eq, Ord, etc instances up to that size.
* The Prelude types of=20
deleteBy
deleteFirstsBy
intersectBy
Although these could be given more general types, it's an
unforced change, and Fergus points out that the more general
types could change error messages for the worse. I'm going to=20
let sleeping dogs lie and make no change here. [Recall that
no-change is the *strong* default.]
The final version of everything is at
http://research.microsoft.com/~simonpj/haskell98-revised
I'm ready to call it a day, but of course I may have made some=20
stupid error. Take a look please and let me know.
I have not yet made PDF; there are issues I don't understand
about how to get PDF to look right. Help sought!
Simon
From patrikj@cs.chalmers.se Mon Jun 18 09:48:04 2001
From: patrikj@cs.chalmers.se (Patrik Jansson)
Date: Mon, 18 Jun 2001 10:48:04 +0200 (MET DST)
Subject: Haskell report typo (bad law for readsPrec)
In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D730AA@red-msg-09.redmond.corp.microsoft.com>
Message-ID:
In short: change the eq. for readsPrec in appendix D.4
In detail:
From "The Haskell 98 Report: Derived Instances: D.4"
...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty. It
should be the case that
fst (head (readsPrec d (showsPrec d x r))) == x
That is, readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...
Note that the equation stated is not true unless the string r starts with
some token-ending combination.
Counter-examples:
> testreadshow :: (Show a, Read a) => a -> String -> a
> testreadshow x r = fst (head (readsPrec 0 (showsPrec 0 x r)))
A simple one that just fails: the problem is that "Nothingx" can't be
parsed.
> bad1 :: Maybe Int
> bad1 = testreadshow Nothing "x"
> test1 = bad1 == Nothing
Using this we can make the law really false by inventing a datatype
where one constructor is a prefix of another constructor:
> data T = Bad | Badger deriving (Show, Read, Eq)
> bad2 = testreadshow Bad "ger"
> test2 = bad2 == Bad
Actually there is a predefined type with lots of constructors (Int)
where many values are prefixes of others:
> bad3 :: Int
> bad3 = testreadshow 1 "2"
> test3 = bad3 == 1
> main = do print (bad3, test3)
> print (bad2, test2)
> print (bad1, test1)
OK, so the falsity of the claim is proved - what could we write instead?
The sentence explaining the equation is correct:
... readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
Thus a simple way out is to remove the equation and the preceding
sentence leaving the paragraph as:
[Alternative A:]
...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty.
Function readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...
Another simple alternative is to weaken the the equation by replacing
the variable r by the empty string:
[Alternative B:]
...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty. It
should be the case that
fst (head (readsPrec d (showsPrec d x ""))) == x
That is, readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...
[Alternative C:]
A third alternative would be to keep the equation unchanged but to add
the requirement that the string variable r should start with a "token
ending sequence of characters". But what does "token" mean? As an
explanation it might be OK, but the report should be pretty formal and
self-contained so I think this is might be undesirable.
A more complicated alternative would be to state (in words or in
equations) a more detailed correctness requirement, but I think that
would lead too far. The Haskell Show and Read classes are not detailed
enough to capture this - we would need a standardized level of
tokenizing (lexing) and this is clearly out of the scope for any
report changes at this stage.
My vote is for [Alternative B] - weaken the equation, but keep it as a
help to understand the interplay between showsPrec and readsPrec.
/Patrik Jansson
From denicola@dsi.unifi.it Fri Jun 15 08:37:38 2001
From: denicola@dsi.unifi.it (Rocco De Nicola)
Date: Fri, 15 Jun 2001 09:37:38 +0200
Subject: PLI 2001 in Firenze
Message-ID:
CALL FOR PARTICIPATION AND EARLY REGISTRATION
PLI 2001
Principles, Logics, and Implementations
of high-level programming languages
Firenze, ITALY September 2 - 8, 2001
http://music.dsi.unifi.it/pli01/
The colloquium on Principles, Logics, and Implementations of high-
level programming languages is a collection of events aimed at the
advancement of high-level programming languages.
PLI 2001 includes the following conferences and workshops:
ACM Sponsored Conferences:
ICFP (September 3-5)
Int. Conf. on Functional Programming
General chair: Benjamin Pierce (Univ. Pennsylvania)
Program chair: Xavier Leroy (INRIA Rocquencourt)
Invited speakers: To be announced
PPDP (September 5-7)
Int. Conf. on Principles and Practice of Declarative Programming
Conference chair: Rocco De Nicola (Univ. Firenze)
Program chair: Harald S=F8ndergaard (Univ. Melbourne)
Invited speakers: J. Esparza, A. Gordon, and D.A. Schmidt.
ACM Sponsored Workshops:
=B7 BABEL (Multi-language Infrastructure and Interoperability)
=B7 HASKELL
=B7 QAPL (Quantitative Aspects of Programming Languages)
=B7 RULE (Rule-Based Programming)
=B7 SAIG (Semantics, Applications, and Implementation of Program
Generation)
=B7 SCHEME (Scheme and Functional Programming)
=B7 VCL (Verification and Computational Logic)
Co-located Workshops:
=B7 ERLANG
=B7 FICS (Fixed Points in Computer Science)
A detailed presentation of PLI2001, including schedule of events,
travel and tourist information, is available at the WEB page
http://music.dsi.unifi.it/pli01/.
Registration and accommodation information and forms are available at
http://music.dsi.unifi.it/pli01/registration/
Early registration rates apply until July 25.
=46or informations about hotels please contact (mentioning PLI 2001)
Giubbi Jet di Volo Viaggi
Piazza San Jacopino, 34/r - 50144 Firenze
Telephone: +39 055 3249074 - +39 055 350577
Fax: +39 055 366807
E-mail: incoming@voloviaggi.com
=46or all other informations mail to pli-org@gdn.dsi.unifi.it
-------------------------------------------------------------------
=46irenze is packed in September; do book accommodation as soon as possible.
-------------------------------------------------------------------
--
<><><><><><><><><><><><><><><><><><><><><><><><><><>
Prof. Rocco De Nicola
Dip. Sistemi e Informatica Univ. di Firenze
Via C. Lombroso 6/17 I-50134 FIRENZE (ITALY)
tel. +39 055 4796733 fax +39 055 4796730
Web Page: http://www.dsi.unifi.it/~denicola/
<><><><><><><><><><><><><><><><><><><><><><><><><><>
From simonpj@microsoft.com Mon Jun 18 10:28:19 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 18 Jun 2001 02:28:19 -0700
Subject: Haskell report typo (bad law for readsPrec)
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D730B5@red-msg-09.redmond.corp.microsoft.com>
| Another simple alternative is to weaken the the equation by=20
| replacing the variable r by the empty string: [Alternative B:]
|=20
| ...
| should be the case that
|=20
| fst (head (readsPrec d (showsPrec d x ""))) =3D=3D x
Yes, I like this alternative too. I'll implement it.
Thank you for spotting it.
Simon
From johan@jeuring.net Mon Jun 18 12:17:11 2001
From: johan@jeuring.net (Johan Jeuring)
Date: Mon, 18 Jun 2001 13:17:11 +0200
Subject: Working Conference on Generic Programming: first call for
papers
Message-ID: <20010618111707.85D844518@mail.cs.uu.nl>
WCGP '02
IFIP TC2 Working Conference on
GENERIC PROGRAMMING
http://www.generic-programming.nl/wcgp/cfp.html
Organised in conjunction with MPC'02
July 8 - July 13, 2002
Dagstuhl, Germany
CALL FOR PAPERS
Generic programming is about making programs more
adaptable by making them more general. Generic
programs often embody non-traditional kinds of
polymorphism; ordinary programs are obtained from
them by suitably instantiating their parameters.
In contrast with normal programs, the parameters
of a generic programs are often quite rich in
structure. For example they may be other programs,
types or type constructors, class hierarchies, or
even programming paradigms.
Generic programming techniques have always been of
interest, both to practitioners and to theoreticians,
but only recently have generic programming
techniques become a specific focus of research in
the functional and object-oriented programming
language communities. This working conference will
bring together leading researchers in generic
programming from around the world, and feature
papers capturing the state of the art in this
important emerging area.
We welcome contributions on all aspects, theoretical
as well as practical, of generic programming,
aspect-oriented programming, polytypic programming,
adaptive object-oriented programming, generic
components, and so on.
SUBMISSION
Full papers should be submitted in Postscript or pdf
format by e-mail to reach Jeremy.Gibbons@comlab.ox.ac.uk
by February 16, 2002. The details of the submission
procedure can be found at
http://www.generic-programming.nl/wcgp/submit.html
Although there is no page limit, submissions should
strive for brevity and clarity.
IMPORTANT DATES
Submission February 16, 2002
Notification April 12, 2002
Final version due May 24, 2002
PROGRAMME COMMITTEE
Matt Austern
Eerke Boiten
Ulrich Eisenecker
Jeremy Gibbons (co-chair)
Ralf Hinze
Johan Jeuring (co-chair)
Gary Leavens
Karl Lieberherr
Lambert Meertens
Eugenio Moggi
Bernhard Moeller
Oege de Moor
David Musser
Martin Odersky
Ross Paterson
Simon Peyton Jones
Colin Runciman
Doaitse Swierstra
Stephanie Weirich
LOCAL ORGANISATION
Jeremy Gibbons
Johan Jeuring
Bernhard Moeller
CORRESPONDENCE
Jeremy Gibbons (Jeremy.Gibbons@comlab.ox.ac.uk)
Johan Jeuring (johan@jeuring.net)
From kh@dcs.st-and.ac.uk Mon Jun 18 15:30:19 2001
From: kh@dcs.st-and.ac.uk (Kevin Hammond)
Date: Mon, 18 Jun 2001 15:30:19 +0100
Subject: 3 Lectureships at St Andrews
Message-ID:
St Andrews University has three lectureships available in Computer Science.
We are
looking for good researchers, with an emphasis on practical skills:
functional programmers
would obviously be very good from my perspective! The deadline is the 22nd
of June, but
a late application may be acceptable if there is a good reason. Further
details are available at.
http://www.dcs.st-and.ac.uk/jobs/#lec
or send me email if you'd like to discuss it. The salary is on the
standard UK Lecturer scale:
currently UK pounds 18,731 to 30,967
Best Wishes,
Kevin
From kh@dcs.st-and.ac.uk Mon Jun 18 15:37:38 2001
From: kh@dcs.st-and.ac.uk (Kevin Hammond)
Date: Mon, 18 Jun 2001 15:37:38 +0100
Subject: Ray Tracing
In-Reply-To: <002401c0f4d2$400bd280$66a1fea9@heron>
Message-ID:
At 10:02 am -0300 14/6/01, Heron wrote:
> Hello Haskell &=A0GHC=A0people, =A0 =A0=A0=A0=A0=A0 I need the source =
code of a Ray
>Tracing written in Haskell.=A0This=A0code was used=A0for parallelization u=
sing
>Caliban and Eden. Can you help me on how or where I can obtain it ? =A0
>Heron de Carvalho, Msc.
Yes, we can let you have the sources (there are two different versions, one
with spheres
originally written in Id, the other is the one derived from Caliban).
Hans-Wolfgang Loidl is
probably the best contact, failing which I will look through my own archives=
=2E
Best Wishes,
Kevin
From v-julsew@microsoft.com Mon Jun 18 15:46:42 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Mon, 18 Jun 2001 07:46:42 -0700
Subject: GHC version 5.00.2 is available
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60302A9E9@red-msg-06.redmond.corp.microsoft.com>
The (Interactive) Glasgow Haskell Compiler -- version 5.00.2
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 5.00.2. The source distribution is
freely available via the World-Wide Web and through anon. FTP, under a
BSD-style license. See below for download details. Pre-built
packages for Linux, FreeBSD, and Solaris(sparc) are also available.
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.
GHC is a state-of-the-art programming suite for Haskell. Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, C++, whatever).
A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page at
http://www.haskell.org/
GHC's Web page lives at
http://www.haskell.org/ghc/
What's new in 5.00.2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Fixed a few more bugs which turned out to be showstoppers for various
people. Symptoms of the fixed bugs are:
* Panics in the bytecode (interactive) linker (two different bugs).
* Compiled code dies with a segfault (two different bugs).
* Interpreted code crashes or acts weird.
* A panic in the CPR analyser.
* An infinite loop in the strictness analyser.
* Nested comments are not properly handled during module chasing.
* :module command doesn't accept underscores in module names.
* -L doesn't work on the ghci command line.
* Posix.executeFile mistakenly propagates SIGVTALRM to children.
* Exceptions during an interactive session cause the UI to forget
some important state information.
* (a new feature) Packages can now loaded at the ghci prompt.
Do ":s -package ".
What's new in 5.00.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This is a bug-fix release. Most reported bugs in 5.00 have been
fixed, including a substantial number of show-stopping bugs. The
system should be much more usable for more people. Upgrading to
5.00.1 is recommended. To all those who tried out 5.00 and reported
bugs, we thank you for your feedback and patience.
At the moment there is no Win32 build of 5.00 or 5.00.1 available. We
decided to push Win32 support to the 5.02 release, so as not to delay
5.00.1 any further.
What's new in 5.00
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.00 has been majorly revamped since the previous stable version,
4.08.2.
This should be a stable release. Major changes since 4.08.2 are:
- An interactive system, similar in style to Hugs. You can
interactively
load and unload modules, run expressions, ask the types of things.
Module dependencies are tracked and chased automatically.
Combinations of compiled and interpreted modules may be used.
All the GHC libraries are available in interactive mode, as are
most of the Glasgow extensions to Haskell 98. Compilation in
interactive mode (to bytecode) is about three times faster than
compiling to object code.
- Batch compilation of multiple modules at once, with automatic
dependency chasing. For large programs this can halve compilation
times, and removes the need for Makefiles.
- Enhanced package (library) management system. Packages may be
installed and removed from an installation using the ghc-pkg tool.
- Initial Unicode support - the Char type is now 31 bits.
- Sparc native code generator, giving much faster compilation on
sparcs.
(Native code generation for x86s has been available for a while).
- Improved heap profiling - you can restrict heap profiles
by type, closure description, cost centre, and module.
- Support for the latest Foreign Function Interface (FFI)
proposals. Marcin Kowalczyk's hsc2hs tool is included.
- Language extensions: parallel list comprehensions and functional
dependencies.
- The usual huge collection of bug fixes. Most reported bugs have
been fixed.
For full details see the release notes:
http://www.haskell.org/ghc/docs/5.00/set/release-5-00.html
How to get it
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The easy way is to go to the WWW page, which should be
self-explanatory:
http://www.haskell.org/ghc/
We supply binary builds in .rpm/.deb form for all you Linux junkies
out there, and in InstallShield form for Windows folks. Everybody
else gets a .tar.gz which can be installed where you want.
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release.
On-line GHC-related resources
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
Relevant URLs on the World-Wide Web:
GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html
System requirements
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To compile programs with GHC, you need a machine with 32+MB memory, GNU
C
and perl. This release is known to work on the following platforms:
* i386-unknown-{linux,freebsd,mingw32}
* sparc-sun-solaris2
Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:
* hppa1.1-hp-hpux{9,10}
* i386-unknown-solaris2
* alpha-dec-osf{2,3}
* mips-sgi-irix{5,6}
* {rs6000,powerpc}-ibm-aix
The builder's guide included in distribution gives a complete
run-down of what ports work; an on-line version can be found at
http://www.haskell.org/ghc/docs/5.00/building/building-guide.html
Mailing lists
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see
http://www.haskell.org/mailman/listinfo/
Please send bug reports about GHC to glasgow-haskell-bugs@haskell.org;
GHC users hang out on glasgow-haskell-users@haskell.org. Bleeding
edge CVS users party on cvs-ghc@haskell.org.
From jcab@roningames.com Mon Jun 18 21:16:01 2001
From: jcab@roningames.com (Juan Carlos Arevalo Baeza)
Date: Mon, 18 Jun 2001 13:16:01 -0700
Subject: GHC version 5.00.2 is available
In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60302A9E9@red-msg-06.redmon
d.corp.microsoft.com>
Message-ID: <4.3.2.7.2.20010618131134.02aa3f08@207.33.235.243>
At 07:46 AM 6/18/2001 -0700, Julian Seward (Intl Vendor) wrote:
>The (Interactive) Glasgow Haskell Compiler -- version 5.00.2
>
>[...]
>
>Pre-built
>packages for Linux, FreeBSD, and Solaris(sparc) are also available.
>
>[...]
>
> What's new in 5.00.1
>======================
>
>[...]
>
>At the moment there is no Win32 build of 5.00 or 5.00.1 available. We
>decided to push Win32 support to the 5.02 release, so as not to delay
>5.00.1 any further.
So, what's up? I've been completely unable to build it (the previous
version) on my own... It says it requires Happy, and no matter what I do
(Happy build just fine), it doesn't see it.
No hurry, but still, I'd like to play with this new version.
Salutaciones,
JCAB
---------------------------------------------------------------------
Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com
Senior Technology Engineer | mailto:jcab@roningames.com
Ronin Entertainment | ICQ: 10913692
(my opinions are only mine)
JCAB's Rumblings is so off-line O:-(
From Nicole.Gabler@web.de Tue Jun 19 09:23:30 2001
From: Nicole.Gabler@web.de (Nicole Gabler)
Date: Tue, 19 Jun 2001 10:23:30 +0200
Subject: library Directory.hs
Message-ID: <200106190823.f5J8NUj22145@mailgate4.cinetic.de>
Hi all,
I have a problem: I need the library Directory.hs. But there is no directory.hs in {Hugs}/lib/ !! All standard libraries are there expect of this one. I downloaded Hugs from http://www.haskell.org/hugs/. Is there any alternative?? Or did I understand something wrong?? I hope you can help me!
Best regards,
Nicole
______________________________________________________________________________
Sie surfen im Internet statt im Meer? Selbst schuld!
Auf zum Strand: http://lastminute.de/?PP=1-0-100-105-1
From wlux@uni-muenster.de Tue Jun 19 11:30:59 2001
From: wlux@uni-muenster.de (Wolfgang Lux)
Date: Tue, 19 Jun 2001 12:30:59 +0200
Subject: Haskell report typo (bad law for readsPrec)
In-Reply-To: "Your message of Mon, 18 Jun 2001 02:28:19 PDT."
<37DA476A2BC9F64C95379BF66BA26902D730B5@red-msg-09.redmond.corp.microsoft.com>
References: <37DA476A2BC9F64C95379BF66BA26902D730B5@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <20010619103101.BFA8F255AB@www.haskell.org>
Sorry, it hit the wrong button so the following didn't go to the list.
> "Simon Peyton-Jones" wrote
>
> >
> > | Another simple alternative is to weaken the the equation by
> > | replacing the variable r by the empty string: [Alternative B:]
> > |
> > | ...
> > | should be the case that
> > |
> > | fst (head (readsPrec d (showsPrec d x ""))) == x
> >
> > Yes, I like this alternative too. I'll implement it.
>
> Why not require
>
> readsPrec d (showPrec d x "") == [(x,"")]
>
> in this case? At least it should be
>
> head (readsPrec d x "") == (x,"")
>
> Regards
> Wolfgang
>
--
Wolfgang Lux Phone: +49-251-83-38263
Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259
Universitaet Muenster Email: wlux@uni-muenster.de
From wolfgang@jeltsch.net Tue Jun 19 13:48:52 2001
From: wolfgang@jeltsch.net (Wolfgang Jeltsch)
Date: Tue, 19 Jun 2001 14:48:52 +0200
Subject: library Directory.hs
In-Reply-To: <200106190823.f5J8NUj22145@mailgate4.cinetic.de>
References: <200106190823.f5J8NUj22145@mailgate4.cinetic.de>
Message-ID: <01061914485203.00617@home>
Hello,
according to
http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/libs.html
Hugs does not contain all standard libraries. Especially the Directory module
is missing.
Wolfgang
On Tuesday, 19. June 2001 10:23, you wrote:
> Hi all,
>
> I have a problem: I need the library Directory.hs. But there is no
> directory.hs in {Hugs}/lib/ !! All standard libraries are there expect of
> this one. I downloaded Hugs from http://www.haskell.org/hugs/. Is there any
> alternative?? Or did I understand something wrong?? I hope you can help me!
>
> Best regards,
>
> Nicole
From Nicole.Gabler@web.de Tue Jun 19 15:01:51 2001
From: Nicole.Gabler@web.de (Nicole Gabler)
Date: Tue, 19 Jun 2001 16:01:51 +0200
Subject: library Directory.hs
References: <200106190823.f5J8NUj22145@mailgate4.cinetic.de> <01061914485203.00617@home>
Message-ID: <004d01c0f8c8$6431d930$e4a79cc2@icsag.de>
> Hello,
> according to
> http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/libs.html
> Hugs does not contain all standard libraries. Especially the Directory
module
> is missing.
>
> Wolfgang
O.k. thank you Wolfgang!!
Then I will tell you my problem exactly. Perhaps anybody can help me:
My haskell programm is in the root directory. I want to parse from several
files in different directories. How can I do this??
Thank you
Nicole
From qrczak@knm.org.pl Tue Jun 19 18:06:39 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 19 Jun 2001 17:06:39 GMT
Subject: library Directory.hs
References: <9gnnde$3ts$1@qrnik.zagroda>
Message-ID:
Tue, 19 Jun 2001 10:23:30 +0200, Nicole Gabler pisze:
> I have a problem: I need the library Directory.hs. But
> there is no directory.hs in {Hugs}/lib/ !! All standard
> libraries are there expect of this one.
Not exactly: Time and CPUTime are also missing.
> Is there any alternative??
You can use another Haskell implementation:
ghc - A big and rich compiler. May be hard to install because of
dependencies on various tools. Provides many language extensions
and libraries.
nhc98 - Smaller than ghc but larger than Hugs. Provides a little
more than Haskell 98. Compiles faster than ghc but programs execute
more slowly.
hbc - No longer maintained. Didn't reach Haskell 98. Compiles fast
and programs run quite fast.
A note about sources of these compilers: nhc98 is written in nice and
clean standard Haskell (but I haven't looked deeply); ghc is written
in itself and sometimes can be hard to understand; hbc is written in
LazyML and almost nobody except its author understands it. Hugs is
an interpreter written in C and I'm not sure how clearly it is written.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From jans@numeric-quest.com Tue Jun 19 14:35:32 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Tue, 19 Jun 2001 09:35:32 -0400 (EDT)
Subject: library Directory.hs
In-Reply-To: <004d01c0f8c8$6431d930$e4a79cc2@icsag.de>
Message-ID:
On Tue, 19 Jun 2001, Nicole Gabler wrote:
> O.k. thank you Wolfgang!!
> Then I will tell you my problem exactly. Perhaps anybody can help me:
> My haskell programm is in the root directory. I want to parse from several
> files in different directories. How can I do this??
That depends what you want to do. If you know the names
and locations of files, you can easily access them
by specifying full FilePaths. And this is definitely
supported by Hugs. With some gymnastic you can even
get directory listings - if you are willing to use Hugs
as a string server.
Jan
From awfurtado@uol.com.br Tue Jun 19 23:52:49 2001
From: awfurtado@uol.com.br (Andre W B Furtado)
Date: Tue, 19 Jun 2001 19:52:49 -0300
Subject: hbc
References: <9gnnde$3ts$1@qrnik.zagroda>
Message-ID: <003901c0f912$91eb0500$38dff9c8@windows9>
Why hbc did not succeeded? It is still possible to make it reach Haskell 98?
Or why doesn't ghc uses some of its techniques to compile/run programs
faster?
Andre W B Furtado
From patrikj@cs.chalmers.se Wed Jun 20 09:06:24 2001
From: patrikj@cs.chalmers.se (Patrik Jansson)
Date: Wed, 20 Jun 2001 10:06:24 +0200 (MET DST)
Subject: hbc
In-Reply-To: <003901c0f912$91eb0500$38dff9c8@windows9>
Message-ID:
On Tue, 19 Jun 2001, Andre W B Furtado wrote:
> It is still possible to make hbc reach Haskell 98?
In short: Hbc is not quite dead yet, and there is a H98 version.
In detail:
[Note: I'm no expert in compiler writing, nor do I support hbc. I just
happen to work at Chalmers in the office between Lennart Augustsson's
(main architect and implementor of hbc, now in industry) and Thomas
Hallgren's (still actively using and sometimes hacking hbc).
]
The latest unofficial release is a Haskell 98 version of hbc, from 1999.
Below are some links.
There has been no official release for the last few years and the support
level is pretty low, but the compiler exists and can be used.
Unfortunately the web-pages and the documentation has not been updated the
last few years!
One notable feature in hbc still missing in ghc is Unicode support (hbc
has supported Unicode from early on). I hope ghc will follow up the recent
change to Unicode-sized Chars with some library support soon.
Many years ago a big benefit of hbc was its interactive variant hbi, only
very recently implemented by ghc, but hbi is even less supported than hbc
and I have only tried it once or twice. [I'd be very happy to hear someone
more involved in developing hbc and hbi come forward and disprove this
claim by providing a new release.]
When it comes to speed I am pretty sure ghc produces faster code (it used
to be different, but that is a while ago) and I think hbc compiles faster
nowadays "only" because it does less work in producing good code.
/Patrik Jansson
Versions of hbc98:
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/
Binary distributions of the latest unofficial release: 0.9999.5b
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-libcv6.tar.gz
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-redhat-6.tar.gz
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-netbsdELF.tar.gz
Source snapshot:
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/snapshot/1999-09-10/
From john@repetae.net Wed Jun 20 10:35:54 2001
From: john@repetae.net (John Meacham)
Date: Wed, 20 Jun 2001 02:35:54 -0700
Subject: hbc
In-Reply-To: ; from patrikj@cs.chalmers.se on Wed, Jun 20, 2001 at 10:06:24AM +0200
References: <003901c0f912$91eb0500$38dff9c8@windows9>
Message-ID: <20010620023554.J710@mark.ugcs.caltech.edu>
you forget one other essential quality of hbc.
As far as I know it is the only compiler that even has a chance of
compiling Fudgets, and hence programs dependent on them such as
the very cool (IMHO) Alfa proof editor
(http://www.cs.chalmers.se/~hallgren/Alfa/)
and its assosiated improvments to Fudgets. If there is any effort to
port these tools to a modern haskell system then I cheer you on.
John
On Wed, Jun 20, 2001 at 10:06:24AM +0200, Patrik Jansson wrote:
> On Tue, 19 Jun 2001, Andre W B Furtado wrote:
> > It is still possible to make hbc reach Haskell 98?
>
> In short: Hbc is not quite dead yet, and there is a H98 version.
>
> In detail:
>
> [Note: I'm no expert in compiler writing, nor do I support hbc. I just
> happen to work at Chalmers in the office between Lennart Augustsson's
> (main architect and implementor of hbc, now in industry) and Thomas
> Hallgren's (still actively using and sometimes hacking hbc).
> ]
>
> The latest unofficial release is a Haskell 98 version of hbc, from 1999.
> Below are some links.
>
> There has been no official release for the last few years and the support
> level is pretty low, but the compiler exists and can be used.
> Unfortunately the web-pages and the documentation has not been updated the
> last few years!
>
> One notable feature in hbc still missing in ghc is Unicode support (hbc
> has supported Unicode from early on). I hope ghc will follow up the recent
> change to Unicode-sized Chars with some library support soon.
>
> Many years ago a big benefit of hbc was its interactive variant hbi, only
> very recently implemented by ghc, but hbi is even less supported than hbc
> and I have only tried it once or twice. [I'd be very happy to hear someone
> more involved in developing hbc and hbi come forward and disprove this
> claim by providing a new release.]
>
> When it comes to speed I am pretty sure ghc produces faster code (it used
> to be different, but that is a while ago) and I think hbc compiles faster
> nowadays "only" because it does less work in producing good code.
>
> /Patrik Jansson
>
> Versions of hbc98:
>
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/
>
> Binary distributions of the latest unofficial release: 0.9999.5b
>
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-libcv6.tar.gz
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-redhat-6.tar.gz
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-netbsdELF.tar.gz
>
> Source snapshot:
>
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/snapshot/1999-09-10/
>
>
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@repetae.net
--------------------------------------------------------------
From aaron.roth@lexys.com Wed Jun 20 19:58:47 2001
From: aaron.roth@lexys.com (Aaron Roth)
Date: Wed, 20 Jun 2001 14:58:47 -0400
Subject: Haskell GUI's
Message-ID:
I'm sure this topic has been discussed ad nauseum. I've only been
subscribing since January, so forgive me if I reintroduce it. Is there any
place where various approaches for a Haskell GUI are being actively
discussed? I've seen fragments here and there, namely pages on FranTk,
Fudgets, GTK+Haskell, and a request to port the Clean I/O library. I've also
read that there is no consensus view on how to do GUI's in Haskell, but is
there an active debate somewhere? Or a few other papers? Thanks.
Aaron
From steph@cs.uchicago.edu Wed Jun 20 19:59:59 2001
From: steph@cs.uchicago.edu (Stephen Bailey)
Date: Wed, 20 Jun 2001 14:59:59 -0400
Subject: hbc
In-Reply-To: Message from "Andre W B Furtado"
of "Tue, 19 Jun 2001 19:52:49 -0300." <003901c0f912$91eb0500$38dff9c8@windows9>
References: <9gnnde$3ts$1@qrnik.zagroda> <003901c0f912$91eb0500$38dff9c8@windows9>
Message-ID: <20010620190006.5B6DC94006@sandmail.sandburst.com>
> Why hbc did not succeeded?
I heard rumors that the author went off to some cushy industrial job,
or is spending all his time writing NetBSD drivers, or something like
that :^)
Steph
From nikhil@acm.org Thu Jun 21 01:52:20 2001
From: nikhil@acm.org (Rishiyur S. Nikhil)
Date: Wed, 20 Jun 2001 20:52:20 -0400
Subject: hbc
References: <9gnnde$3ts$1@qrnik.zagroda> <003901c0f912$91eb0500$38dff9c8@windows9> <20010620190006.5B6DC94006@sandmail.sandburst.com>
Message-ID: <3B314544.B2FDA770@mediaone.net>
Stephen Bailey wrote:
>
> > Why hbc did not succeeded?
>
> I heard rumors that the author went off to some cushy industrial job,
> or is spending all his time writing NetBSD drivers, or something like
> that :^)
>
> Steph
I heard that he had become a recluse and was chasing eclipses
somewhere in South Africa!
Nikhil
From chak@cse.unsw.edu.au Thu Jun 21 02:15:16 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 21 Jun 2001 11:15:16 +1000
Subject: Haskell GUI's
In-Reply-To:
References:
Message-ID: <20010621111516X.chak@cse.unsw.edu.au>
"Aaron Roth" wrote,
> I'm sure this topic has been discussed ad nauseum. I've only been
> subscribing since January, so forgive me if I reintroduce it. Is there any
> place where various approaches for a Haskell GUI are being actively
> discussed? I've seen fragments here and there, namely pages on FranTk,
> Fudgets, GTK+Haskell, and a request to port the Clean I/O library. I've also
> read that there is no consensus view on how to do GUI's in Haskell, but is
> there an active debate somewhere? Or a few other papers?
There is a mailing list for Gtk+Haskell:
http://haskell.org/mailman/listinfo/gtkhs
The list is mainly used for annoucements and questions
regarding Gtk+HS, but I would welcome any discussion
relating to the GTK+ binding. In particular, it is
certainly the right place to discuss the iHaskell high-level
API, which is being defined on top of Gtk+HS:
http://www.cse.unsw.edu.au/~chak/haskell/gtk/#iHaskell
Cheers,
Manuel
From chak@cse.unsw.edu.au Thu Jun 21 03:01:45 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 21 Jun 2001 12:01:45 +1000
Subject: GHC version 5.00.2 is available
In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60302A9E9@red-msg-06.redmond.corp.microsoft.com>
References: <68B95AA1648D1840AB0083CC63E57AD60302A9E9@red-msg-06.redmond.corp.microsoft.com>
Message-ID: <20010621120145S.chak@cse.unsw.edu.au>
"Julian Seward (Intl Vendor)" wrote,
> The (Interactive) Glasgow Haskell Compiler -- version 5.00.2
> ==============================================================
>
> We are pleased to announce a new patchlevel release of the Glasgow
> Haskell Compiler (GHC), version 5.00.2.
For your installation pleasure, RPM packages built on RedHat
are now available. Binary packages built for RedHat 7.x are at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.00.2-1.i386.rpm
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.00.2-1.i386.rpm
and those for RedHat 6.2 are at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-5.00.2-1.i386.rpm
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-prof-5.00.2-1.i386.rpm
The ghc-prof-* packages contain optional libraries for
profiling. The packages for 6.2 are courtesy of Tom Moertel.
The source rpm used to built the above binaries is at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.00.2-1.src.rpm
If you build from the source rpm using an older version of
GHC, note that you have to build the system twice if you
like to use the interactive environment. The second build
should use the compiler generated in the first.
Manuel
From v-julsew@microsoft.com Thu Jun 21 09:50:23 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Thu, 21 Jun 2001 01:50:23 -0700
Subject: hbc
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F233D@red-msg-06.redmond.corp.microsoft.com>
| > I heard rumors that the author went off to some cushy industrial
job,=20
| > or is spending all his time writing NetBSD drivers, or something
like=20
| > that :^)
|=20
| I heard that he had become a recluse and was chasing eclipses=20
| somewhere in South Africa!
I heard rumours that the author had nearly completed writing a
whole new Haskell compiler, in Haskell, which (presumably)=20
allowed him to move on from the by-now byzantine complexity
of hbc. It is further rumoured that this new compiler could
boot itself.
J
From v-julsew@microsoft.com Thu Jun 21 09:55:38 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Thu, 21 Jun 2001 01:55:38 -0700
Subject: RPMs for: GHC version 5.00.2 is available
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F233E@red-msg-06.redmond.corp.microsoft.com>
Thanks once again to Tom and Manuel for building RH6.2 and
RH7.x RPMs of ghc-5.00.2. I'll shortly put these RPMs at
the usual place, the download pages at http://www.haskell.org/ghc,
so you can get them from there too.
Note also that a build for Solaris 2.7 (sparc) is also now
available.
J
| -----Original Message-----
| From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au]=20
| Sent: Thursday, June 21, 2001 3:02 AM
| To: Julian Seward (Intl Vendor)
| Cc: glasgow-haskell-users@haskell.org; haskell@haskell.org
| Subject: Re: GHC version 5.00.2 is available
|=20
|=20
| "Julian Seward (Intl Vendor)" wrote,
|=20
| > The (Interactive) Glasgow Haskell Compiler -- version 5.00.2
| > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| >=20
| > We are pleased to announce a new patchlevel release of the Glasgow=20
| > Haskell Compiler (GHC), version 5.00.2.
|=20
| For your installation pleasure, RPM packages built on RedHat=20
| are now available. Binary packages built for RedHat 7.x are at
|=20
=20
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.00.2-1.i38
6.rpm
=20
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.00.2-
1.i386.rpm
and those for RedHat 6.2 are at
=20
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-5.00.2
-1.i386.rpm
=20
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-prof-5
.00.2-1.i386.rpm
The ghc-prof-* packages contain optional libraries for profiling. The
packages for 6.2 are courtesy of Tom Moertel.
The source rpm used to built the above binaries is at
=20
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.00.2-1.src.
rpm
If you build from the source rpm using an older version of
GHC, note that you have to build the system twice if you
like to use the interactive environment. The second build should use
the compiler generated in the first.
Manuel
From Sven.Panne@informatik.uni-muenchen.de Thu Jun 21 18:34:51 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Thu, 21 Jun 2001 19:34:51 +0200
Subject: hbc
References:
Message-ID: <3B32303B.9C8E4796@informatik.uni-muenchen.de>
Patrik Jansson wrote:
> [...]
> One notable feature in hbc still missing in ghc is Unicode support (hbc
> has supported Unicode from early on). I hope ghc will follow up the recent
> change to Unicode-sized Chars with some library support soon. [...]
*ahem* Just to get rumours correct: Starting from 5.00, GHC *has* Unicode
support (Char is even 31bits now), and there is some library support, too,
but Marcin should better comment on the latter...
Cheers,
S.
From jcohn@estrategypartners.com Sat Jun 23 03:28:37 2001
From: jcohn@estrategypartners.com (Jeff Cohn)
Date: Fri, 22 Jun 2001 19:28:37 -0700
Subject: User Generated Database of Internet Social Communities
Message-ID:
This is a multi-part message in MIME format.
------=_NextPart_000_0119_01C0FB51.890C95C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
We have launched a new research database and would appreciate the
contribution of you and your students.
http://ecultures.homestead.com/ecultures.html
A User Generated Database of Internet Social Communities
eCultures is a research tool established to address growing need to discover
the Internet's vast network of virtual communities around the world. Unlike
today's commercialized and non-collaborative search engines, eCultures has
taken a new approach to collaborative research by allowing users to
immediately share and search under one common database. All submissions are
subject to a review.
eCultures is a web property of eStrategy Partners, LLC
Comments are appreciated!
Regards,
Jeff Cohn
President & Founder
eStrategy Partners, LLC
Office: 310-546-7539
jcohn@estrategypartners.com
www.estrategypartners.com
"Solutions for eBusiness"
------=_NextPart_000_0119_01C0FB51.890C95C0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
We have launched a new research =
database and=20
would appreciate the contribution of you and your=20
students.
http://ecultures.h=
omestead.com/ecultures.html
A User Generated =
Database of=20
Internet Social Communities
eCultures is a research tool=20
established to address growing=20
need to discover the Internet's vast network of virtual communities =
around the=20
world. Unlike today's =
commercialized and=20
non-collaborative search engines, eCultures has taken a new approach to collaborative =
research by=20
allowing users to immediately share=20
and search under one common database. All submissions are =
subject=20
to a review.
eCultures=20
is a web property of =
eStrategy Partners, =
LLC
Comments are=20
appreciated!
Regards,
Jeff=20
Cohn
President & Founder
eStrategy Partners, =
LLC
Office: =20
310-546-7539
jcohn@estrategypartners.com
www.estrategypartners.com
"Solutions for =
eBusiness"=20
------=_NextPart_000_0119_01C0FB51.890C95C0--
From doaitse@cs.uu.nl Sat Jun 23 09:31:57 2001
From: doaitse@cs.uu.nl (S. Doaitse Swierstra)
Date: Sat, 23 Jun 2001 10:31:57 +0200
Subject: new version of parser combinators
Message-ID:
We have been working hard on new versions of the Parser Combinators
and AG system, with the following improvements:
even better error repairs
much faster and simpler basic parsing machine
permutation (of different types) and list combinators
extensive reporting about repairs made and what was expected
the possibility to manipulate your own state during parsing
and result construction, using classed based (like monads) interfaces
As an example of the permutation combinators we parse a permutation
of three elements:
1) a list of 'a's
2) a 'b'
3) an optional 'c'
which is described by:
permtest :: Parser Char (String, Char, Char)
permtest = permute $ (,,) ~$~ pList (pSym 'a') ~*~ pSym 'b' ~*~ pOptSym 'c'
pOptSym :: Char -> Parser Char Char
pOptSym x = pSym x <|> pSucceed '_'
which we try on several inputs resulting in:
t permtest "acb"
Result:
("a",'b','c')
t permtest "cdaa"
Errors:
Symbol 'd' before 'a' was deleted, because 'b' or ('a')* was expected.
Symbol 'b' was inserted at end of file, because 'a' or 'b' was expected.
Result:
("aa",'b','c')
t permtest "abd"
Errors:
Symbol 'd' at end of file was deleted, because 'c' or eof was expected.
Result:
("a",'b','_')
t permtest ""
Errors:
Symbol 'b' was inserted at end of file, because 'c' or 'b' or ('a')*
was expected.
Result:
("",'b','_')
The manual is still of an earlier version and will be adapted soon.
As an example of the combinators we provide a parser for bibtex
files, that returns the repairs made to the erroneous entries (as
far as we understand the bibtex format).
I hope this is useful to you,
Doaitse Swierstra
From iyermanjula@hotmail.com Mon Jun 25 07:02:40 2001
From: iyermanjula@hotmail.com (Manjula Iyer)
Date: Mon, 25 Jun 2001 01:02:40 -0500
Subject: (no subject)
Message-ID:
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C0FD12.8862F840
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
------=_NextPart_000_0007_01C0FD12.8862F840
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
------=_NextPart_000_0007_01C0FD12.8862F840--
From stanley_goof@yahoo.fr Mon Jun 25 10:25:26 2001
From: stanley_goof@yahoo.fr (=?iso-8859-1?q?stanley=20goof?=)
Date: Mon, 25 Jun 2001 11:25:26 +0200 (CEST)
Subject: adventure game
Message-ID: <20010625092526.36421.qmail@web14810.mail.yahoo.com>
Hi everybody,
I am planning to write a text-adventure game in
haskell.
This is the type of game in which you can execute many
commands like 'take'(to take an object), 'goto' to
move from a room to another room, 'look'(to see the
objects in a room), 'open'(to open a drawer), ...
I'm currently studying haskell, so i'm a beginner. If
you know any hints or any sources which can help
writing this game, write me.
Thank you very much
___________________________________________________________
Do You Yahoo!? -- Pour faire vos courses sur le Net,
Yahoo! Shopping : http://fr.shopping.yahoo.com
From Nicole.Gabler@web.de Wed Jun 27 08:47:00 2001
From: Nicole.Gabler@web.de (Nicole Gabler)
Date: Wed, 27 Jun 2001 09:47:00 +0200
Subject: library Directory.hs
References: <68B95AA1648D1840AB0083CC63E57AD60F233A@red-msg-06.redmond.corp.microsoft.com>
Message-ID: <005801c0fedd$59ba1a10$e4a79cc2@icsag.de>
Hello All,
thank you for all your answers. I solved the problem without using
Directory.hs, but now I have a new problem and now I need Directory.hs. I
only have the name of a directory and I have to search for any files in this
directory! Unfortunately, the business concern, where I'm doing an
industrial practical, don't use Unix but Windows NT. So, what can I do??
Thanks,
Nicole
From lennart@mail.augustsson.net Wed Jun 27 09:28:55 2001
From: lennart@mail.augustsson.net (Lennart Augustsson)
Date: Wed, 27 Jun 2001 10:28:55 +0200
Subject: hbc
References: <9gnnde$3ts$1@qrnik.zagroda> <003901c0f912$91eb0500$38dff9c8@windows9> <20010620190006.5B6DC94006@sandmail.sandburst.com> <3B314544.B2FDA770@mediaone.net>
Message-ID: <3B399947.2B4592C4@mail.augustsson.net>
"Rishiyur S. Nikhil" wrote:
> Stephen Bailey wrote:
> >
> > > Why hbc did not succeeded?
> >
> > I heard rumors that the author went off to some cushy industrial job,
> > or is spending all his time writing NetBSD drivers, or something like
> > that :^)
> >
> > Steph
>
> I heard that he had become a recluse and was chasing eclipses
> somewhere in South Africa!
I heard that he got trampled by a crazy rhino in Africa, but I'm not sure
if that rumour can be trusted.
-- Lennart
From sof@galconn.com Wed Jun 27 18:49:57 2001
From: sof@galconn.com (Sigbjorn Finne)
Date: Wed, 27 Jun 2001 10:49:57 -0700
Subject: library Directory.hs
Message-ID: <03dc01c0ff31$946e9790$6332a8c0@sofbox>
Nicole Gabler Nicole.Gabler@web.de writes:
>
> thank you for all your answers. I solved the problem without
> using Directory.hs, but now I have a new problem and now
> I need Directory.hs. I only have the name of a directory and I
> have to search for any files in this directory! Unfortunately, the
> business concern, where I'm doing an industrial practical, don't
> use Unix but Windows NT. So, what can I do??
Hi,
I'd suggest either waiting for the next release of Hugs98, or grab
a copy of the Hugs98 sources from the CVS repository
(http://cvs.haskell.org/ & compile it up. It has a complete set
of Haskell98 modules, including Directory.
If neither of these options are practical, let me know & I'll send
you a copy of the files you need.
hth
--sigbjorn
From coldblue@freemail.com.au Fri Jun 1 00:14:20 2001
From: coldblue@freemail.com.au (Shirley Widyaningsih)
Date: Thu, 31 May 2001 19:14:20 -0400 (EDT)
Subject: Information
Message-ID: <20010531231420.CCAE1255AB@www.haskell.org>
This is a multipart message in MIME format.
------------APMIME1
Content-type: text/plain
Dear Sir/Mdm,
I would like to ask some information about Haskell. For the information, I'm a student that currently studying at Bina Nusantara University, Jakarta, Indonesia and taking computer science as my subject. In Indonesia, we've never learned about Haskell. It's not populer in Indonesia, many people don't know about it. I know it from my friend that studying in Sydney, Australia. I would to install/download this program, could you give me some info where i can get this software ? If i have to but the software, what is the software name ? Is it haskell too??
Thank you.
Sincerely,
Shirley
---------------------------------------------
WANT A NEW JOB? THEN LET THE JOB FIND YOU
Visit www.ecruit.com.au and register your
profile. Then the headhunters can find you.
---------------------------------------------
Get your own free email account at
http://www.freemail.com.au/ now part of the
Webuser.com.au independent portal. Visit at…
http://www.webuser.com.au
---------------------------------------------
------------APMIME1--
From dscarlett@optushome.com.au Fri Jun 1 00:43:28 2001
From: dscarlett@optushome.com.au (David Scarlett)
Date: Fri, 1 Jun 2001 09:43:28 +1000
Subject: Information
References: <20010531231420.CCAE1255AB@www.haskell.org>
Message-ID: <00a001c0ea2b$7ddf1880$0100a8c0@CO3003288A>
Hugs is the standard Haskell interpreter.......
http://www.haskell.org/hugs/
See here for more info on Haskell.....
http://www.haskell.org/
From iscp9157@nus.edu.sg Fri Jun 1 23:25:24 2001
From: iscp9157@nus.edu.sg (Saswat Anand)
Date: Fri, 1 Jun 2001 15:25:24 -0700
Subject: fromInteger
Message-ID: <003101c0eae9$c248bbc0$733d8489@saswat>
This is a multi-part message in MIME format.
------=_NextPart_000_002E_01C0EAAF.1478A080
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I can't understand how the arithmatic operators like (+),(-) are =
defined and fromInteger works in that context.
Type Fun a =3D Int -> a
fun :: Fun Int
fun =3D (+1)
instance (Num a) =3D> Num (Fun a) where
.........
(fun + 2) 10 and (2 + fun) 10 works fine. But how does it know it has to =
use fromInteger?
But If I want these,
(Just 2 + fun) 10 and (fun + Just 2) 10
to work, then is there a way to tell which conversion function to use?
Thanks,
Saswat
------=_NextPart_000_002E_01C0EAAF.1478A080
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I can't understand how =
the arithmatic=20
operators like (+),(-) are defined and fromInteger works in that=20
context.
Type Fun a =3D Int -> a
fun :: Fun Int
fun =3D =
(+1)
instance (Num a) =3D> Num (Fun a)=20
where
.........
(fun + 2) 10 and (2 + fun) 10 works =
fine. But how=20
does it know it has to use fromInteger?
But If I want these,
(Just 2 =
+ fun) 10=20
and (fun + Just 2) 10
to work, then is there a way to tell which =
conversion=20
function to use?
Thanks,
Saswat
------=_NextPart_000_002E_01C0EAAF.1478A080--
From coldblue@freemail.com.au Fri Jun 1 09:10:20 2001
From: coldblue@freemail.com.au (Shirley Widyaningsih)
Date: Fri, 1 Jun 2001 04:10:20 -0400 (EDT)
Subject: Problem
Message-ID: <20010601081020.62E1E255AF@www.haskell.org>
This is a multipart message in MIME format.
------------APMIME1
Content-type: text/plain
Dear Sir/Mdm,
I've got some problem here, after i install the hugs98, i want to open file "Fact.hs", but there's an error.
It's written "ERROR Fact.hs - Unable to open file "Fact.hs" .
So what should i do???
Thank you.
Sincerely,
Shirley
---------------------------------------------
WANT A NEW JOB? THEN LET THE JOB FIND YOU
Visit www.ecruit.com.au and register your
profile. Then the headhunters can find you.
---------------------------------------------
Get your own free email account at
http://www.freemail.com.au/ now part of the
Webuser.com.au independent portal. Visit at…
http://www.webuser.com.au
---------------------------------------------
------------APMIME1--
From ross@soi.city.ac.uk Fri Jun 1 11:04:34 2001
From: ross@soi.city.ac.uk (Ross Paterson)
Date: Fri, 1 Jun 2001 11:04:34 +0100
Subject: unfoldr in Library Report
Message-ID: <20010601110434.A6870@soi.city.ac.uk>
While looking through the List module, I came across
The unfoldr function undoes a foldr operation. Note that, in general,
only invertible functions can be unfolded.
[followed by an equation about undoing foldr]
This is quite inadequate: unfoldr is very useful with non-invertible
functions. I suggest something like:
The unfoldr function is a `dual' to foldr: while foldr reduces a list
to a summary value, unfoldr builds a list from a seed value, e.g.,
iterate f == unfoldr (\x -> Just (x, f x))
In some cases unfoldr can undo a foldr operation:
[followed by the existing equation]
From coldblue@freemail.com.au Fri Jun 1 11:08:19 2001
From: coldblue@freemail.com.au (Shirley Widyaningsih)
Date: Fri, 1 Jun 2001 06:08:19 -0400 (EDT)
Subject: Problem
Message-ID: <20010601100819.C02D0255CC@www.haskell.org>
This is a multipart message in MIME format.
------------APMIME1
Content-type: text/plain
At 01 Jun 2001 11:18:00 +0200,
Bruno Barbier (barbier@comte.univ-fcomte.fr) wrote:
>
> When hugs is not able to find a file, it says this.
> In the interpreter, type ':?' for help, then you can change the
> current
> path or update the paths where hugs looks for files.
>
>
>
Can you teach me how to change the current path or updates the paths?
when i go to interpreter-> option, this below are appear.
Current settings: +fewuiA -stgl.qQkR -h250000 -p"%s> " -r$$ -c40
Search path : -P{Hugs}\lib;{Hugs}\lib\hugs;{Hugs}\lib\exts;{Hugs} \lib\win32
Editor setting : -EC:\WINDOWS\notepad.exe
Preprocessor : -F
For the information, my hugs directory is in C:\Program Files\HUGS98
Thank You
Sincerely,
Shirley
---------------------------------------------
WANT A NEW JOB? THEN LET THE JOB FIND YOU
Visit www.ecruit.com.au and register your
profile. Then the headhunters can find you.
---------------------------------------------
Get your own free email account at
http://www.freemail.com.au/ now part of the
Webuser.com.au independent portal. Visit at…
http://www.webuser.com.au
---------------------------------------------
------------APMIME1--
From barbier@comte.univ-fcomte.fr Fri Jun 1 11:37:50 2001
From: barbier@comte.univ-fcomte.fr (Bruno Barbier)
Date: 01 Jun 2001 12:37:50 +0200
Subject: Problem
In-Reply-To: Shirley Widyaningsih's message of "Fri, 1 Jun 2001 12:16:05 +0200 (MET DST)"
References: <200106011016.MAA24026@comte.univ-fcomte.fr>
Message-ID:
For hugs related questions, you should write at
hugs-users@haskell.org
See also
http://haskell.org/mailman/listinfo/
for a list of haskell related mailing lists.
For your problem,
(works fine with linux, but I guess it's the same for Windows)
I do
:s
to get the search paths and I get
| Search path : -P{Hugs}/lib:{Hugs}/lib/hugs:{Hugs}/lib/exts
then I type,
:s -P{Hugs}/lib:{Hugs}/lib/hugs:{Hugs}/lib/exts:mypath1:mypath2
to add the paths 'mypath1' and 'mypath2' into the search paths;
i.e. absolute paths separated by ':' (for Windows, you should probably use ';')
Shirley Widyaningsih writes:
> Content-type: text/plain
>
>
>
> At 01 Jun 2001 11:18:00 +0200,
> Bruno Barbier (barbier@comte.univ-fcomte.fr) wrote:
> >
> > When hugs is not able to find a file, it says this.
> > In the interpreter, type ':?' for help, then you can change the
> > current
> > path or update the paths where hugs looks for files.
> >
> >
> >
>
> Can you teach me how to change the current path or updates the paths?
> when i go to interpreter-> option, this below are appear.
> Current settings: +fewuiA -stgl.qQkR -h250000 -p"%s> " -r$$ -c40
> Search path : -P{Hugs}\lib;{Hugs}\lib\hugs;{Hugs}\lib\exts;{Hugs} \lib\win32
> Editor setting : -EC:\WINDOWS\notepad.exe
> Preprocessor : -F
>
> For the information, my hugs directory is in C:\Program Files\HUGS98
> Thank You
>
>
> Sincerely,
>
>
> Shirley
>
> ---------------------------------------------
> WANT A NEW JOB? THEN LET THE JOB FIND YOU
>
> Visit www.ecruit.com.au and register your
> profile. Then the headhunters can find you.
>
> ---------------------------------------------
> Get your own free email account at
> http://www.freemail.com.au/ now part of the
> Webuser.com.au independent portal. Visit at…
> http://www.webuser.com.au
> ---------------------------------------------
--
Bruno Barbier
Laboratoire d'Informatique de Besancon, Universite de Franche-Comte, France
Phone/Fax : (33) 381.662.087 / (33) 381.666.450
Mailto : barbier@lifc.univ-fcomte.fr
From Dominic.J.Steinitz@BritishAirways.com Fri Jun 1 16:27:48 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 01 Jun 2001 15:27:48 Z
Subject: Socket Behaviour
Message-ID: <"003753B17B474001*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Apologies if you have received this request for help already.
Can anyone tell me why the following code doesn't work as expected? Both the server and client hang.
[dom@lhrtba8fd85 simptest]$ server 20000 &
[1] 2694
[dom@lhrtba8fd85 simptest]$ client lhrtba8fd85 20000
client: interrupted
[1]+ Broken pipe server 20000
[dom@lhrtba8fd85 simptest]$ more log.txt
Starting logging
Hello world
[dom@lhrtba8fd85 simptest]$
So it looks like the hPutStrLn to the server's socket never completes. What's stopping it? On the client side, "Hello world" gets sent but the hGetLine never completes. I guess because the server for some reason can't send.
Dominic.
module Main(main) where
import System
import IO
import Socket
main :: IO ()
main = do prog <- getProgName
args <- getArgs
if (length args /= 2)
then do putStrLn ("Use: " ++ prog ++ " ")
exitWith (ExitFailure (-1))
else return ()
let host = args !! 0
port = read (args !! 1) :: Int in
client host (PortNumber (mkPortNumber port))
client :: Hostname -> PortID -> IO ()
client host port =
do sh <- connectTo host port
hPutStr sh "Hello world"
hFlush sh
x <- hGetLine sh
putStrLn x
module Main (main) where
import System
import IO
import Socket
main :: IO ()
main = do prog <- getProgName
args <- getArgs
if (length args /= 1)
then do putStrLn ("Use: " ++ prog ++ " ")
exitWith (ExitFailure (-1))
else return ()
let port = read (args !! 0) :: Int in
server (PortNumber (mkPortNumber port))
-- The server function creates a socket to listen on the port and
-- loops to log messages.
server :: PortID -> IO ()
server port =
do ofh <- openFile "log.txt" WriteMode
hPutStrLn ofh "Starting logging"
hFlush ofh
socket <- listenOn port
(sh,host,portid) <- accept socket
let loop = do b <- getBuffer sh 16
case b of
Full msg ->
do hPutStrLn ofh msg
hFlush ofh
loop
Partial msg ->
do hPutStrLn ofh msg
hFlush ofh
hPutStrLn sh "Finishing Logging"
hFlush sh
hPutStrLn ofh "Finishing logging"
hClose ofh
in loop
data Buffer = Full String | Partial String
getBuffer :: Handle -> Int -> IO Buffer
getBuffer h n =
if (n <= 0)
then return (Full "")
else do x <- try (hGetChar h)
case x of
Right c ->
do xs <- getBuffer h (n-1)
case xs of
Full cs -> return (Full (c:cs))
Partial cs -> return (Partial (c:cs))
Left e -> if isEOFError e
then return (Partial "")
else ioError e
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From qrczak@knm.org.pl Fri Jun 1 19:36:01 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 1 Jun 2001 18:36:01 GMT
Subject: Haskell 98 Report
References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> <20010601041923.A10308@hg.cs.mu.oz.au> <9f7cla$81t$1@qrnik.zagroda>
Message-ID:
31 May 2001 16:10:43 -0600, Alastair David Reid pisze:
> and
>
> if foo has type
>
> foo :: (Ord a) => ty
>
> then fooBy has type
>
> fooBy :: (a -> a -> Bool) -> ty
It's (a -> a -> Ordering) -> ty, with the default value being
compare.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From qrczak@knm.org.pl Fri Jun 1 19:34:46 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 1 Jun 2001 18:34:46 GMT
Subject: fromInteger
References: <9f7jgp$94q$1@qrnik.zagroda>
Message-ID:
Fri, 1 Jun 2001 15:25:24 -0700, Saswat Anand pisze:
> I can't understand how the arithmatic operators like (+),(-) are =
> defined and fromInteger works in that context.
They are all in class Num. fromInteger is automatically
inserted before all integer literals, e.g. '42' is equivalent to
'fromInteger (42::Integer)' and has type 'Num a => a', i.e. the
context can provide any numeric type and 42 will have that type
by using the appropriate fromInteger.
> Type Fun a = Int -> a
>
> fun:: Fun Int
> fun = (+1)
>
> instance (Num a) => Num (Fun a) where
> .........
>
> (fun + 2) 10 and (2 + fun) 10 works fine. But how does it know it
> has to use fromInteger?
(+):: Num a => a -> a -> a
>From this type it follows that both arguments of '+' must have the
same type (and that this type must be Num).
The first argument of '+' in 'fun + 2', i.e. 'fun', has a fully
determined type: 'Fun Int'. It follows that the second argument of
'+', i.e. '2', must be 'Fun Int' too.
It's an integral literal, so it can have any Num type. Unifying
'Num a => a' with 'Fun Int' succeeds and gives an answer what 'a'
is here: it's 'Fun Int', and it's ok because it's Num.
> But If I want these,
> (Just 2 + fun) 10 and (fun + Just 2) 10
> to work, then is there a way to tell which conversion function
> to use?
No: 'Just 2' has type 'Num a => Maybe a', 'fun' has type 'Fun Int',
i.e. 'Int -> Int'. In no way 'Maybe something' can be the same type as
'arg -> result'.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From s350366@student.uq.edu.au Sat Jun 2 14:03:29 2001
From: s350366@student.uq.edu.au (Sean Seefried)
Date: Sat, 02 Jun 2001 23:03:29 +1000
Subject: A problem with the typing system.
Message-ID: <3B18E421.16040DB7@student.uq.edu.au>
Dear Haskell users,
I am playing around with a variation of the Church numerals and it is
giving me grief.
Usually the definitions for Church numerals appear as follows.
zero = \s z -> z
succ x = \s z -> s (x s z)
But what I would like to do is define them this way.
zero = \s z ->z
succ x = \s z -> s x (x s z).
I don't think it's important that I explain why I want the extra
occurrence of x there.
Just typing this in hugs or ghci gives problems. In ghci the error
message is
Occurs check: cannot construct the infinite type:
t = (t -> t3 -> t2) -> t2 -> t1
Expected type: t
Inferred type: (t -> t3 -> t2) -> t2 -> t1
In the first argument of `x', namely `s'
In the second argument of `s', namely `(x s z)'
I know about rank-2 polymorphic types. (I don't really understand it
but I have used them). I attempted to create a type with the following
declaration.
data Church = Ch (forall a.(a -> a -> a) -> a -> a)
I declared an unCh
unCh (Ch a) = a
I then declared succ as
succ x = Ch(\s z -> s x (unCh x s z)
which gives the strange typing error:
Inferred type is less polymorphic than expected
Quantified type variable `a' is unified with `Church'
Signature type: forall a. (a -> a -> a) -> a -> a
Type to generalise: (Church -> Church -> Church)
-> Church -> Church
When checking an expression type signature
In the first argument of `Ch', namely `(\ s z -> s x (unCh x s z))'
in the definition of function `succ':
Ch (\ s z -> s x (unCh x s z))
Doesn't the "type to generalise" fit within the framework of forall
a.(a->a->a) ->a ->a. Why should it matter if something is
_less_ polymorphic than expected. This is something I do not
understand.
Now, if I modify the definition to
succ = \s z -> s x (unCh x s z)
I can at least load the file.
succ zero
gives me _no_ typing errors.
However
succ (succ zero)
gives me a typing error again. (And I know why)
Because the type of succ zero is "(Church -> Church -> Church) -> Church
-> Church" and not just simply "Church". (that is what the constructor
Ch is supposed to do but it complains of the typing being less
polymorphic than expected).
Is this sort of typing possible within Haskell. I realise that it is
sort of an infinite data type but in my opinion these sorts of things
should be able to be typed.
Thanks in advance.
Sean Seefried.
From ltaesch@europemail.com Sun Jun 3 00:05:12 2001
From: ltaesch@europemail.com (luc)
Date: Sat, 02 Jun 2001 23:05:12 +0000
Subject: proof in haskell ?
Message-ID: <3B197128.D390CE78@europemail.com>
chapter 12 of birds book mention mike spivey' theorem prover.
are there anything available in source code about proof in haskell ?
(btw , haskell is a great language ! one of the rare that try to
"improve lazyness " ! (chaperter 11)
thanks
Luc
From qrczak@knm.org.pl Sun Jun 3 12:13:26 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 3 Jun 2001 11:13:26 GMT
Subject: A problem with the typing system.
References: <9fapjj$tf6$1@qrnik.zagroda>
Message-ID:
Sat, 02 Jun 2001 23:03:29 +1000, Sean Seefried pisze:
> zero = \s z ->z
> succ x = \s z -> s x (x s z).
>
> I don't think it's important that I explain why I want the extra
> occurrence of x there.
I don't understand what the extra x means, so I can only explain what
errors mean. I don't know what do you want to archieve.
> Occurs check: cannot construct the infinite type:
> t = (t -> t3 -> t2) -> t2 -> t1
The type of 's' is requested to take as its first argument 'x',
which is a function which takes as its first argument 's' again.
So the type of 's' would have to appear as a proper part of itself.
> data Church = Ch (forall a.(a -> a -> a) -> a -> a)
I would expect
data Church = Ch (forall a. (a -> a) -> a)
but perhaps it has something to do with your extra 'x'...
> succ x = Ch(\s z -> s x (unCh x s z)
>
> which gives the strange typing error:
>
> Inferred type is less polymorphic than expected
> Quantified type variable `a' is unified with `Church'
The constructor Ch has type
(forall a. (a -> a -> a) -> a -> a) -> Church
and must be applied to a value which is polymorphic itself, i.e. which
could be assigned the type '(a -> a -> a) -> a -> a' for any 'a',
without knowing anything about the particular choice of 'a'. The type
allows a user of the resulting Church value to choose any type for
'a' and use this argument on this type - that's why it must work for
all of them. But
\s z -> s x (unCh x s z)
doesn't have sufficiently general type: 'x' has type Church (because
'unCh' is applied to 'x'), so 's' takes only Church as argument, so
what should happen if the user instantiates it with something other
than Church?
> Is this sort of typing possible within Haskell.
I don't know how it's supposed to behave with the extra 'x', so I
can't tell what type it could have.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From t-atolm@microsoft.com Mon Jun 4 10:31:44 2001
From: t-atolm@microsoft.com (Andrew Tolmach)
Date: Mon, 4 Jun 2001 02:31:44 -0700
Subject: GHC core representation
Message-ID: <8D7D23D65C1CEB44ABEE89F137A5D32815E71E@red-msg-09.redmond.corp.microsoft.com>
Dear Haskellers,
Many months after the topic was first raised, there is finally a draft
document describing a formal external syntax for GHC's "Core"
intermediate language. It is available from
http://www.cs.pdx.edu/~apt/ext-core.ps
Those who wish to experiment seriously with the format described
can download the latest "HEAD" experimental version of GHC.
Using the "-fext-core" option when compiling "foo.hs" will generate
a file "foo.core" (in additition to any other outputs specified).
The document currently gives only an informal semantics "Core;"
a much more formal semantics -- which I view as
a very important thing to have in practice -- is in progress=20
but not quite ready for public scrutiny.=20
As this is very much a draft (you'll see the holes!), feedback is
welcome,=20
but due to the GHC-internals nature of this topic, please direct your
comments
to glasgow-haskell-users@haskell.org or to me personally
at apt@cs.pdx.edu. I'll be out of email contact for the next
month, though, so don't expect replies until July!
- Andrew Tolmach
From ross@soi.city.ac.uk Mon Jun 4 11:07:42 2001
From: ross@soi.city.ac.uk (Ross Paterson)
Date: Mon, 4 Jun 2001 11:07:42 +0100
Subject: proof in haskell ?
In-Reply-To: <3B197128.D390CE78@europemail.com>
Message-ID: <20010604110742.A30820@soi.city.ac.uk>
On Sat, Jun 02, 2001 at 11:05:12PM +0000, luc wrote:
> chapter 12 of birds book mention mike spivey' theorem prover.
> are there anything available in source code about proof in haskell ?
The calculator in the book is available on the book's web page
http://web.comlab.ox.ac.uk/oucl/publications/books/functional/
I also have an improved version I can send on request (our web server
was incinerated last week).
From ger@tzi.de Tue Jun 5 17:32:22 2001
From: ger@tzi.de (George Russell)
Date: Tue, 05 Jun 2001 18:32:22 +0200
Subject: Advantages of Paper
Message-ID: <3B1D0996.2D1F0B03@tzi.de>
I don't want to seem incredibly Luddite, but there are some things the World Wide
Web is not good at, and one of them is permanence. Try for example finding out
about Glasgow Haskell from http://www.dcs.gla.ac.uk, which was I think the
standard URL a few years ago. In 2050 we may not even have a World Wide Web
(remember Gopher?), or if we do URLs as we have them may be as outdated as
those e-mail addresses I remember which included lots of percent signs telling
the network to send your message to Birmingham via Beachy Head. I find it
therefore of concern that many crucial Haskell documents, including the
standard and, for example, the various Glasgow Haskell manuals, are only
available online. I therefore suggest that they at least be printed out
in the form of technical reports, and made available in this form to
libraries, which are well-used to storing information long-term. Otherwise
the curious in 2050 will be able to locate manuals for FORTRAN II and
Simula (as I can do in 5 minutes in the local library), but getting Haskell
documentation will be about as easy as reading 5-track paper tape.
I don't think it matters if Haskell itself is obsolete in the year
2050, as it probably will be. But it will be a pity if most of the papers
written using it are hard to figure out because the documentation itself
is missing.
From reid@cs.utah.edu Tue Jun 5 18:14:03 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 05 Jun 2001 11:14:03 -0600
Subject: Why is there a space leak here?
In-Reply-To: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout>
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout>
Message-ID:
Executive summary: David's program has an incredibly subtle space leak
in it (or I'm being incredibly dumb). I encourage the honchos (and
would be honchos) to have a look. Users of other compilers might give
it a shot too.
David Bakin writes:
> Why is there a space leak in foo1 but not in foo2? (I.e., in Hugs
> Nov '99) foo1 eats cells (and eventually runs out) where foo2
> doesn't. That is, if I do (length (foo1 1000000)) I eventually run
> out of cells but (length (foo2 1000000)) runs fine (every GC returns
> basically the same amount of space). Something must be wrong in
> flatten but it follows the pattern of many functions in the prelude
> (which I'm trying to learn from). I have been puzzling over this
> for nearly a full day (getting this reduced version from my own code
> which wasn't working). In general, how can I either a) analyze code
> looking for a space leak or b) experiment (e.g., using Hugs) to find
> a space leak? Thanks! -- Dave
Interesting question. The functions certainly look as though either
both should leak or neither should leak. As for how to chase this
sort of problem, I'll try to describe everything I do in trying to
chase the problem down in the hope that this might be instructive.
1) Is there really a problem?
Using Feb 2001 Hugs, I run "hugs +g /tmp/leak.hs" and type
length (foo1 1000000)
output is:
{{Gc:235464}}{{Gc:227548}}{{Gc:219900}}{{Gc:212509}}{{Gc:205364}}{{Gc:198465}}{{Gc:191793}}{{Gc:185343}}{{Gc:179119}}{{Gc:173090}}{{Gc:167274}}{{Gc:161653}}{{Gc:156217}}{{Gc:150968}}{{Gc:145888}}{{Gc:140989}}{{Gc:136245}}{{Gc:131668}}{{Gc:127238}}{{Gc:122965}}{{Gc:118832}}{{Gc:114844}}{{Gc:110976}}{{Gc:107248}}{{Gc:103648}}{{Gc:100165}}{{Gc:96796}}{{Gc:93542}}{{Gc:90391}}{{Gc:87353}}{{Gc:84419}}{{Gc:81583}}{Interrupted!}
Yup, it leaks.
I then quit (just to be certain), restart and type:
length (foo2 1000000)
output is:
{{Gc:239721}}{{Gc:239718}}{{Gc:239722}}{{Gc:239725}}{{Gc:239713}}{{Gc:239717}}{{Gc:239717}}{{Gc:239722}}{{Gc:239725}}{{Gc:239713}}{{Gc:239717}}{{Gc:239717}}{{Gc:239722}}{{Gc:239725}}{Interrupted!}
Nope, it doesn't leak.
2) Could it be something to do with CAFs and the monmomorphism restriction?
Check the type:
Main> :t foo1
foo1 :: Num a => Int -> [a]
Main> :t foo2
foo2 :: Num a => Int -> [a]
Same type, almost certainly not.
(The fact that all definitions are of the form "foo m = ..." makes it
even less likely. The fact that I tried this at all shows that I'm
already grasping for straws.)
3) Could it be a bug in the garbage collector or code generator?
1) Try swapping the two definitions and see if it still leaks.
Yes, still leaks.
2) Try adding a third definition in the hope that it will perturb
code generation and heap allocation enough to make the problem show up.
(This definition is based on "double x = [x,x]")
Both foo1 (triple) and foo2 (double) leak, foo3 (single) still
doesn't leak.
3) Try a different compiler (ghc) and run with +RTS -Sstderr flags:
foo1: leaks (6Mb maximum residency)
foo2: leaks (5Mb maximum residency)
foo3: doesn't leak (1,112 bytes maximum residency)
4) Maybe there's something funny in your definition of flatten - write
my own.
f1 :: [[a]] -> [a]
f1 [] = []
f1 ([]:xss) = f1 xss
f1 ((x:xs):xss) = x : f1 (xs:xss)
Nope, foo1 still leaks and foo3 doesn't leak.
5) Cut and paste code for map and take from language definition into
this module in case Hugs (and GHC) are doing something funny.
(The straws are getting smaller and further away.)
No change.
(Actually, I wrote the definitions from memory - effect should be
the same.)
Well, I thought I understood lazy evaluation, garbage collectors, Hugs
and GHC but I'm at a complete loss for why one definition leaks and
the other doesn't. I would be really fascinated to learn what is
going on here.
I'm attaching my revised version of David's program and David's
original version.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
David's version:
----------------------------------------------------------------
-- This has a space leak, e.g., when reducing (length (foo1 1000000))
foo1 m
= take m v
where
v = 1 : flatten (map triple v)
triple x = [x,x,x]
-- This has no space leak, e.g., when reducing (length (foo2 1000000))
foo2 m
= take m v
where
v = 1 : flatten (map single v)
single x = [x]
-- flatten a list-of-lists
flatten :: [[a]] -> [a]
flatten [] = []
flatten ([]:xxs) = flatten xxs
flatten ((x':xs'):xxs) = x' : flatten' xs' xxs
flatten' [] xxs = flatten xxs
flatten' (x':xs') xxs = x': flatten' xs' xxs
----------------------------------------------------------------
The Haggoidal version:
----------------------------------------------------------------
module Main( main ) where
import Prelude hiding ( take, map )
take :: Int -> [a] -> [a]
take 0 xs = []
take m [] = []
take m (x:xs) | m > 0 = x : take (m-1) xs
map :: (a -> b) -> ([a] -> [b])
map f [] = []
map f (x:xs) = f x : map f xs
main :: IO ()
main = do
print (length (foo1 1000000))
-- This has a space leak, e.g., when reducing (length (foo1 1000000))
foo1 m
= take m v
where
v = 1 : f1 (map triple v)
triple x = [x,x,x]
-- This has no space leak, e.g., when reducing (length (foo2 1000000))
foo2 m
= take m v
where
v = 1 : flatten (map double v)
double x = [x,x]
-- This has no space leak, e.g., when reducing (length (foo3 1000000))
foo3 m
= take m v
where
v = 1 : f1 (map single v)
single x = [x]
-- This has no space leak, e.g., when reducing (length (foo3 1000000))
foo4 m
= take m v
where
v = 1 : f1 (map single v)
single x = [x,x,x]
-- flatten a list-of-lists
flatten :: [[a]] -> [a]
flatten [] = []
flatten ([]:xxs) = flatten xxs
flatten ((x':xs'):xxs) = x' : flatten' xs' xxs
flatten' :: [a] -> [[a]] -> [a]
flatten' [] xxs = flatten xxs
flatten' (x':xs') xxs = x': flatten' xs' xxs
f1 :: [[a]] -> [a]
f1 [] = []
f1 ([]:xss) = f1 xss
f1 ((x:xs):xss) = x : f1 (xs:xss)
----------------------------------------------------------------
From reid@cs.utah.edu Tue Jun 5 18:28:40 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 05 Jun 2001 11:28:40 -0600
Subject: Advantages of Paper
In-Reply-To: <3B1D0996.2D1F0B03@tzi.de>
References: <3B1D0996.2D1F0B03@tzi.de>
Message-ID:
> I find it therefore of concern that many crucial Haskell documents,
> including the standard and, for example, the various Glasgow Haskell
> manuals, are only available online.
My printed copy of the Haskell 98 report is numbered:
YaleU/DCS/RR-1106
Copies can no doubt be obtained from the Yale Haskell Group though I'm
afraid I don't know who you should write to or how much money to send.
It would be a good idea if haskell.org described how to get a copy but
I don't know who maintains those pages. As it is, you have to infer
the existence of a Yale tech report for the language from the fact
that the language report cites a tech report for the library :-)
[I'm less concerned about GHC documentation because it comes with the
compiler and it seems unlikely that you'd want one and not the other.]
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From peterson-john@cs.yale.edu Tue Jun 5 18:35:24 2001
From: peterson-john@cs.yale.edu (John Peterson)
Date: Tue, 5 Jun 2001 13:35:24 -0400
Subject: Advantages of Paper
In-Reply-To: (message from Alastair David
Reid on 05 Jun 2001 11:28:40 -0600)
References: <3B1D0996.2D1F0B03@tzi.de>
Message-ID: <200106051735.NAA06517@ragged.cs.yale.edu>
We're not really in a position to mail out bound copies of the Haskell
report. We generally distribute our tech reports in electronic form
and haven't even been asked for paper copies in years. I've got a few
bound Haskell reports that I give to visitors but we don't plan to
print any more. It would be nice if the report was published in book
form someday!
The original problem here is that there's no comprehensive archive of
Haskell related research papers. At one point we were maintaining a
set of useful papers at haskell.org by hand (Olaf did all the hard
work ...) but it's not really feasable to do any of the haskell.org
maintainence by hand anymore.
I've been slowly putting together software to automate haskell.org -
forms for adding new applications, libraries, documents, and anything
else that you could want. However, I'm not done and really need help
to get things finished. In general, haskell.org is open to anyone
that wants to work on these things and I would highly encourage anyone
with time available to pitch in! I think haskell.org is the right
place to give documents a permant home and will be glad to assist
anyone that wants to work on this with me.
John
From jans@numeric-quest.com Tue Jun 5 13:42:07 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Tue, 5 Jun 2001 08:42:07 -0400 (EDT)
Subject: Advantages of Paper
In-Reply-To: <3B1D0996.2D1F0B03@tzi.de>
Message-ID:
Judging from my logs, some libraries, such as University
of Chicago library, do their own indexing of WWW.
Jan
From ger@tzi.de Tue Jun 5 18:50:33 2001
From: ger@tzi.de (George Russell)
Date: Tue, 05 Jun 2001 19:50:33 +0200
Subject: Advantages of Paper
References: <3B1D0996.2D1F0B03@tzi.de>
Message-ID: <3B1D1BE9.A7F88F18@tzi.de>
Alastair David Reid wrote:
>
> > I find it therefore of concern that many crucial Haskell documents,
> > including the standard and, for example, the various Glasgow Haskell
> > manuals, are only available online.
>
> My printed copy of the Haskell 98 report is numbered:
>
> YaleU/DCS/RR-1106
[snip]
Er, are you sure? According to
ftp://ftp.cs.yale.edu/pub/TR/LISTING
TR1106 is "The Haskell 1.3 Language Version" and comes from 1996.
(Earlier versions of the Haskell Report also appear with separate
numbers in this listing).
http://citeseer.nj.nec.com
doesn't appear to know of any later print versions.
From jans@numeric-quest.com Tue Jun 5 14:38:48 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Tue, 5 Jun 2001 09:38:48 -0400 (EDT)
Subject: A pecular algebraic data structure
Message-ID:
I've been working with one pecular algebraic data structure,
named Register, which is described in currently upgraded
http://www.numeric-quest.com/haskell/QuantumComputer.html.
or in gzipped version of the same document
http://www.numeric-quest.com/haskell/QuantumComputer.html.gz.
Section 13 of that document outlines the background for
the topic of this message. But the section is just way too
long to quote it in here.
But to summarize it: data Register is pecular because
it is indexable but not observable in a standard way,
and because two different representations can describe the same
state. In theory there should be well defined transformation
from one representation to another. This seems to me as a good
subject for some research work.
Granted that there are many experts on functional data
structures out there (I do not want to pressure any
of you gurus, so I am not naming anyone :-)), could you please
look at the write-up and help me with the following questions?
+ Is the Register data structure strangely unique,
or does it fit somewhere into a hierarchy of known
functional data structures? I would be happy to learn
that the latter is the case, since I could then start
looking at it at a more formal, well known and tested way.
+ Is a non-uniqness of representation amenable to formal
treatment, such as deforestation?
Jan
From tom-list-haskell@moertel.com Tue Jun 5 20:05:52 2001
From: tom-list-haskell@moertel.com (Tom Moertel)
Date: Tue, 05 Jun 2001 15:05:52 -0400
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout>
Message-ID: <3B1D2D90.BA7F8BEC@moertel.com>
Alastair David Reid wrote:
>
> Executive summary: David's program has an incredibly subtle space leak
> in it (or I'm being incredibly dumb). I encourage the honchos (and
> would be honchos) to have a look. Users of other compilers might give
> it a shot too.
> David Bakin wrote:
>
> Why is there a space leak in foo1 but not in foo2?
The reason that foo1 "leaks" space is because the middle of v grows
faster than its head. So taking elements from v causes its in-memory
footprint to grow. To see why this is the case, evaluate foo1 by hand:
> -- This has a space leak, e.g., when reducing (length (foo1 1000000))
> foo1 m
> = take m v
> where
> v = 1 : flatten (map triple v)
> triple x = [x,x,x]
Focusing on just v for now, and letting f = flatten for notation
purposes, we have
(1) v = 1 : f (map triple v)
(2) = { unwrap v }
1 : f (map triple (1 : f (map triple v)))
(3) = { eval map }
1 : f (triple 1 : map triple (f (map triple v)))
(4) = { eval triple }
1 : f ([1,1,1] : map triple (f (map triple v)))
(5) = { eval f (= flatten = foldr (++) []) }
1 : 1 : 1 : 1 : f (map triple (f (map triple v))))
In order to expose elements 2-4 of v, we had to evaluate v to the extent
that the overall expression held in memory *grew*. Notice how in (1) we
had a single (f (map triple ...)) expression in the tail of v but in (5)
there are two such expressions, nested.
Continuing further, if we want to expose the 5th-7th elements of v, we
have to expand the expression yet even more. Noticing that the (f (map
triple v)) subexpression in (5) is identical to the tail of (1), we can
apply the same expansion that we derived in (1)-(5) to yield
(6) = { repeat (1)-(5) for f (map triple v) in (5) }
1 : 1 : 1 : 1 :
f (map triple (1 : 1 : 1 :
f (map triple (
f (map triple v)))))))
(7) = { eval map }
1 : 1 : 1 : 1 :
f (triple 1 : map triple (
f (map triple (
f (map triple v))))))))
(8) = { eval triple }
1 : 1 : 1 : 1 :
f ([1,1,1] : map triple (
f (map triple (
f (map triple v))))))))
(9) = { eval f }
1 : 1 : 1 : 1 : 1 : 1 : 1 :
f (map triple (
f (map triple (
f (map triple v)))))))))
Notice how in (9) we have three nested (f (map triple (...)))
expressions in the tail of v whereas in (5) we had only two and in (1)
we had but one?
Now you can see why foo1 has a space "leak": In order to take the Nth
element of v, v's definition must be expanded to the point where there
are 1+(N+1)/3 (f (map triple (...))) subexpressions in the tail of v
*that will never be reached*. In other words, v's "middle" grows faster
than its head, ensuring that take will never consume the tail. Taking
elements from the head only makes the middle grow larger. The more your
take, the larger it grows.
So the problem isn't Hugs but rather the definition of v, which grows
faster than it can be consumed.
Cheers,
Tom
From alex@shop.com Tue Jun 5 20:37:41 2001
From: alex@shop.com (S. Alexander Jacobson)
Date: Tue, 5 Jun 2001 15:37:41 -0400 (Eastern Daylight Time)
Subject: Why is there a space leak here?
In-Reply-To: <3B1D2D90.BA7F8BEC@moertel.com>
Message-ID:
This whole discussion seems strange...
Is laziness an operational or a semantic issue?
Why can't haskell implementations reduce some expressions to save space?
In particular, why can't haskell mark expressions that grow after
evaluation, and reduce them if too much space is being consumed.
For example w/ foldl:
foldl + 0 [1..10000]
foldl (+) ((+) 0 1) [2..10000]
foldl (+) ((+) ((+) 0 1) 2) [3..10000]
Can't the implementation notice that each iteration leads to a
larger closure and, if it is running out of space go ahead an just
evaluate (+) 0 1?
I realize that there is a risk of evaluating _|_ unnecessarily, but if you
are otherwise going to run out of memory, you might as well give it a
shot.
In practice, how often do you expect to see growing expressions that cover
a _|_ that are not actually an error in any case?
Hunting down memory leaks is already so obscure, that you might as well
take a shot at solving the problem automatically...
Alternatively, is there some magical way of warning about leaky
expressions at compile time? You don't have to ban them, but it would be
nice if the programmer were aware of which parts of the code are likely to
grow...
-Alex-
On Tue, 5 Jun 2001, Tom Moertel wrote:
> Alastair David Reid wrote:
> >
> > Executive summary: David's program has an incredibly subtle space leak
> > in it (or I'm being incredibly dumb). I encourage the honchos (and
> > would be honchos) to have a look. Users of other compilers might give
> > it a shot too.
>
> > David Bakin wrote:
> >
> > Why is there a space leak in foo1 but not in foo2?
>
> The reason that foo1 "leaks" space is because the middle of v grows
> faster than its head. So taking elements from v causes its in-memory
> footprint to grow. To see why this is the case, evaluate foo1 by hand:
>
> > -- This has a space leak, e.g., when reducing (length (foo1 1000000))
> > foo1 m
> > = take m v
> > where
> > v = 1 : flatten (map triple v)
> > triple x = [x,x,x]
>
> Focusing on just v for now, and letting f = flatten for notation
> purposes, we have
>
> (1) v = 1 : f (map triple v)
>
> (2) = { unwrap v }
> 1 : f (map triple (1 : f (map triple v)))
>
> (3) = { eval map }
> 1 : f (triple 1 : map triple (f (map triple v)))
>
> (4) = { eval triple }
> 1 : f ([1,1,1] : map triple (f (map triple v)))
>
> (5) = { eval f (= flatten = foldr (++) []) }
> 1 : 1 : 1 : 1 : f (map triple (f (map triple v))))
>
> In order to expose elements 2-4 of v, we had to evaluate v to the extent
> that the overall expression held in memory *grew*. Notice how in (1) we
> had a single (f (map triple ...)) expression in the tail of v but in (5)
> there are two such expressions, nested.
>
> Continuing further, if we want to expose the 5th-7th elements of v, we
> have to expand the expression yet even more. Noticing that the (f (map
> triple v)) subexpression in (5) is identical to the tail of (1), we can
> apply the same expansion that we derived in (1)-(5) to yield
>
> (6) = { repeat (1)-(5) for f (map triple v) in (5) }
> 1 : 1 : 1 : 1 :
> f (map triple (1 : 1 : 1 :
> f (map triple (
> f (map triple v)))))))
>
> (7) = { eval map }
> 1 : 1 : 1 : 1 :
> f (triple 1 : map triple (
> f (map triple (
> f (map triple v))))))))
>
> (8) = { eval triple }
> 1 : 1 : 1 : 1 :
> f ([1,1,1] : map triple (
> f (map triple (
> f (map triple v))))))))
>
> (9) = { eval f }
> 1 : 1 : 1 : 1 : 1 : 1 : 1 :
> f (map triple (
> f (map triple (
> f (map triple v)))))))))
>
> Notice how in (9) we have three nested (f (map triple (...)))
> expressions in the tail of v whereas in (5) we had only two and in (1)
> we had but one?
>
> Now you can see why foo1 has a space "leak": In order to take the Nth
> element of v, v's definition must be expanded to the point where there
> are 1+(N+1)/3 (f (map triple (...))) subexpressions in the tail of v
> *that will never be reached*. In other words, v's "middle" grows faster
> than its head, ensuring that take will never consume the tail. Taking
> elements from the head only makes the middle grow larger. The more your
> take, the larger it grows.
>
> So the problem isn't Hugs but rather the definition of v, which grows
> faster than it can be consumed.
>
> Cheers,
> Tom
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
From khaliff@astercity.net Tue Jun 5 20:50:34 2001
From: khaliff@astercity.net (Wojciech Moczydlowski, Jr)
Date: Tue, 5 Jun 2001 19:50:34 +0000 (UTC)
Subject: Why is there a space leak here?
In-Reply-To: <3B1D2D90.BA7F8BEC@moertel.com>
Message-ID:
On Tue, 5 Jun 2001, Tom Moertel wrote:
> The reason that foo1 "leaks" space is because the middle of v grows
> faster than its head. So taking elements from v causes its in-memory
> footprint to grow. To see why this is the case, evaluate foo1 by hand:
>
> So the problem isn't Hugs but rather the definition of v, which grows
> faster than it can be consumed.
> Tom
How come then that the very program compiled under nhc98 evaluates without
any problem, with memory usage below 1M during its execution?
Wojciech Moczydlowski, Jr
From tullsen@cs.yale.edu Tue Jun 5 22:03:24 2001
From: tullsen@cs.yale.edu (Mark Tullsen)
Date: Tue, 05 Jun 2001 17:03:24 -0400
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout>
Message-ID: <3B1D491C.EB097D54@cs.yale.edu>
Alastair David Reid wrote:
>
> Executive summary: David's program has an incredibly subtle space leak
> in it (or I'm being incredibly dumb). I encourage the honchos (and
> would be honchos) to have a look. Users of other compilers might give
> it a shot too.
>
> David Bakin writes:
>
> > Why is there a space leak in foo1 but not in foo2? (I.e., in Hugs
> > Nov '99) foo1 eats cells (and eventually runs out) where foo2
> > doesn't. That is, if I do (length (foo1 1000000)) I eventually run
> > out of cells but (length (foo2 1000000)) runs fine (every GC returns
> > basically the same amount of space). Something must be wrong in
> > flatten but it follows the pattern of many functions in the prelude
> > (which I'm trying to learn from). I have been puzzling over this
> > for nearly a full day (getting this reduced version from my own code
> > which wasn't working). In general, how can I either a) analyze code
> > looking for a space leak or b) experiment (e.g., using Hugs) to find
> > a space leak? Thanks! -- Dave
>
I certainly don't have tons of experience tracking down and fixing
space leaks. But I can show you how one could attack the problem
in a brute-force kind of way. Let's use the following definitions
(from Alastair) to make things simpler:
flatten :: [[a]] -> [a]
flatten [] = []
flatten ([]:xss) = flatten xss
flatten ((x:xs):xss) = x : flatten (xs:xss)
-- This has a space leak, e.g., when reducing (length (foo2 1000000))
foo2 m
= take m v
where
v = 1 : flatten (map double v)
double x = [x,x]
-- This has no space leak, e.g., when reducing (length (foo3 1000000))
foo3 m
= take m v
where
v = 1 : f1 (map single v)
single x = [x]
We just start evaluating the program by hand and observe what's happening.
I'm being a little informal in my hand evaluations (and there's probably
a number of mistakes) but I think I've done well enough to visualize the
space behavior of these programs.
Regarding my derivations:
* I'm using let's to simulate the sharing done by something like the STG
machine. If you're curious about why exactly evaluation is proceeding
as it is, you might want to look at some of the work on "call by need
calculi".
* I'm showing the evaluation steps using "p1 -> p2" to indicate that
p1 reduces to p2. Also, I "embed" evaluation steps into programs
as follows so as to save repetition (where C[] is any context):
C[ p1
-> p2
]
which is the same as
C[p1] -> C[p2]
Hopefully the indentation will disambiguate things.
So, let's simulate the evaluation of (length $ foo3 100):
length $ foo3 100
-> foldl' (\n _ -> n + 1) 0 $
foo3 100
-> take 100 v
-> let v = 1 : v2
v2 = flatten (map single v)
in take 100 (1:v2)
-> 1 : take 99 v2
-> foldl' (\n _ -> n + 1) 1 $
let v = 1 : v2
v2 = flatten (map single v)
-> flatten (map single (1:v2))
-> flatten ([1] : map single v2))
-> 1 : flatten ([] : map single v2))
in take 99 v2
->
let v = 1 : v2
v2 = 1 : v3
v3 = flatten ([] : map single v2))
in take 99 (1 : v3)
-> {GC}
let v2 = 1 : v3
v3 = flatten ([] : map single v2))
in take 99 (1 : v3)
-> 1 : take 98 v3
-> foldl' (\n _ -> n + 1) 2 $
let v2 = 1 : v3
v3 = flatten ([] : map single v2))
-> flatten (map single v2))
in take 98 v3
So, there is no space leak here because at this point we have a program
which is the same as a previous program (up to variable naming and integer
values). So the program isn't growing.
Note that for every foldl' reduction, there will be a GC (garbage collection)
step.
Now, let's simulate the evaluation of (length $ foo2 100):
length $ foo2 100
-> foldl' (\n _ -> n + 1) 0 $
foo2 100
-> take 100 v
-> let v = 1 : v2
v2 = flatten (map double v)
in take 100 (1:v2)
-> 1 : take 99 v2
-> foldl' (\n _ -> n + 1) 1 $
let v = 1 : v2
v2 = flatten (map double v)
-> flatten (map double (1:v2))
-> flatten ([1,1] : map double v2)
-> 1 : flatten ([1] : map double v2)
in take 99 v2
->
let v = 1 : v2
v2 = 1 : v3
v3 = flatten ([1] : map double v2)
in take 99 (1 : v3)
-> 1 : take 98 v3
-> {GC}
let v2 = 1 : v3
v3 = flatten ([1] : map double v2)
in take 99 (1 : v3)
-> 1 : take 98 v3
-> foldl' (\n _ -> n + 1) 2 $
let v2 = 1 : v3
v3 = flatten ([1] : map double v2)
-> 1 : flatten ([] : map double v2)
in take 98 v3
->
let v2 = 1 : v3
v3 = 1 : v4
v4 = flatten ([] : map double v2)
in take 98 (1:v4)
-> 1 : take 97 v4
-> foldl' (\n _ -> n + 1) 3 $
let v2 = 1 : v3
v3 = 1 : v4
v4 = flatten ([] : map double v2)
-> flatten (map double v2)
-> flatten (map double (1:v3))
-> flatten ([1,1] : map double v3)
-> 1 : flatten ([1] : map double v3)
in take 97 v4
->
let v2 = 1 : v3
v3 = 1 : v4
v4 = 1 : v5
v5 = flatten ([1] : map double v3)
in take 97 (1:v5)
-> {GC}
let v3 = 1 : v4
v4 = 1 : v5
v5 = flatten ([1] : map double v3)
in take 97 (1:v5)
-> 1 : take 96 v5
-> foldl' (\n _ -> n + 1) 4 $
let v3 = 1 : v4
v4 = 1 : v5
v5 = flatten ([1] : map double v3)
-> 1 : flatten ([] : map double v3)
in take 96 v5
->
let v3 = 1 : v4
v4 = 1 : v5
v5 = 1 : v6
v6 = flatten ([] : map double v3)
in take 96 (1:v6)
-> 1 : take 95 v6
-> foldl' (\n _ -> n + 1) 5 $
let v3 = 1 : v4
v4 = 1 : v5
v5 = 1 : v6
v6 = flatten ([] : map double v3)
in take 95 v6
I've done a few more reduction steps here. Note that for every two foldl'
reductions there is only one {GC} step! So, the program is growing.
Thus, we have a space leak.
- Mark
From tom-list-haskell@moertel.com Tue Jun 5 22:17:41 2001
From: tom-list-haskell@moertel.com (Tom Moertel)
Date: Tue, 05 Jun 2001 17:17:41 -0400
Subject: Why is there a space leak here?
References:
Message-ID: <3B1D4C75.D8AD6C91@moertel.com>
"Wojciech Moczydlowski, Jr" wrote:
>
> How come then that the very program compiled under nhc98 evaluates without
> any problem, with memory usage below 1M during its execution?
My claim was that v (as defined) grew faster than it could be consumed,
not that (length (foo1 n)) couldn't be evaluated in constant space.
Even so, your results suggest that nhc98 is doing something
interesting. Does the memory usage remain constant even if you take 10
or 100 times the number of elements? If so, perhaps nhc98 is smart
enough to know that
length (take n x) = n
for all infinite lists x. It might apply those smarts to optimize out
the expansion of v in foo1 when foo1's result is used as the argument of
length. Out of curiosity, what happens if you consume those elements
with foldl' (+) 0 rather than length?
Alternatively, if nhc98 were smart enough to prove that
foo1 n = replicate n 1
it could do away with v altogether, which would also explain the
interesting behavior. And if nhc does *that*, my hat's off to the nhc98
folks.
Or, if your constants are hard-coded, perhaps nhc98 is evaluating the
(length foo1 1000000) expression at compile time. What happens to
memory consumption if foo1's argument is supplied at run time?
Or maybe I'm mistaken about v. Wouldn't be the first time I've done
something boneheaded. ;-)
In any case, I am curious about what nhc98 is doing internally. Any
ideas?
Cheers,
Tom
From tullsen@cs.yale.edu Tue Jun 5 22:23:57 2001
From: tullsen@cs.yale.edu (Mark Tullsen)
Date: Tue, 05 Jun 2001 17:23:57 -0400
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> <3B1D2D90.BA7F8BEC@moertel.com>
Message-ID: <3B1D4DED.337CC06C@cs.yale.edu>
Tom,
I noticed this post after I had just posted my own response.
You have to realize that Alastair Reid is one of the truly
great Haskell programmers on planet earth. I'm serious.
So, when he says "incredibly subtle space leak" I wouldn't
expect the solution to be simple. As far as I can tell, your
argument would also apply to foo2, which doesn't have a space leak.
I'd be happy to be proven wrong, but I think this space leak
really /is/ subtle and in order to see the problem seems to
require some /tedious/ hand-reductions, taking into account both
the sharing and the strictness properties. See my recent posting
for a very brute-force "analysis".
- Mark
Tom Moertel wrote:
>
> Alastair David Reid wrote:
> >
> > Executive summary: David's program has an incredibly subtle space leak
> > in it (or I'm being incredibly dumb). I encourage the honchos (and
> > would be honchos) to have a look. Users of other compilers might give
> > it a shot too.
>
> > David Bakin wrote:
> >
> > Why is there a space leak in foo1 but not in foo2?
>
> The reason that foo1 "leaks" space is because the middle of v grows
> faster than its head. So taking elements from v causes its in-memory
> footprint to grow. To see why this is the case, evaluate foo1 by hand:
>
> > -- This has a space leak, e.g., when reducing (length (foo1 1000000))
> > foo1 m
> > = take m v
> > where
> > v = 1 : flatten (map triple v)
> > triple x = [x,x,x]
>
> Focusing on just v for now, and letting f = flatten for notation
> purposes, we have
>
> (1) v = 1 : f (map triple v)
>
> (2) = { unwrap v }
> 1 : f (map triple (1 : f (map triple v)))
>
> (3) = { eval map }
> 1 : f (triple 1 : map triple (f (map triple v)))
>
> (4) = { eval triple }
> 1 : f ([1,1,1] : map triple (f (map triple v)))
>
> (5) = { eval f (= flatten = foldr (++) []) }
> 1 : 1 : 1 : 1 : f (map triple (f (map triple v))))
>
> In order to expose elements 2-4 of v, we had to evaluate v to the extent
> that the overall expression held in memory *grew*. Notice how in (1) we
> had a single (f (map triple ...)) expression in the tail of v but in (5)
> there are two such expressions, nested.
>
> Continuing further, if we want to expose the 5th-7th elements of v, we
> have to expand the expression yet even more. Noticing that the (f (map
> triple v)) subexpression in (5) is identical to the tail of (1), we can
> apply the same expansion that we derived in (1)-(5) to yield
>
> (6) = { repeat (1)-(5) for f (map triple v) in (5) }
> 1 : 1 : 1 : 1 :
> f (map triple (1 : 1 : 1 :
> f (map triple (
> f (map triple v)))))))
>
> (7) = { eval map }
> 1 : 1 : 1 : 1 :
> f (triple 1 : map triple (
> f (map triple (
> f (map triple v))))))))
>
> (8) = { eval triple }
> 1 : 1 : 1 : 1 :
> f ([1,1,1] : map triple (
> f (map triple (
> f (map triple v))))))))
>
> (9) = { eval f }
> 1 : 1 : 1 : 1 : 1 : 1 : 1 :
> f (map triple (
> f (map triple (
> f (map triple v)))))))))
>
> Notice how in (9) we have three nested (f (map triple (...)))
> expressions in the tail of v whereas in (5) we had only two and in (1)
> we had but one?
>
> Now you can see why foo1 has a space "leak": In order to take the Nth
> element of v, v's definition must be expanded to the point where there
> are 1+(N+1)/3 (f (map triple (...))) subexpressions in the tail of v
> *that will never be reached*. In other words, v's "middle" grows faster
> than its head, ensuring that take will never consume the tail. Taking
> elements from the head only makes the middle grow larger. The more your
> take, the larger it grows.
>
> So the problem isn't Hugs but rather the definition of v, which grows
> faster than it can be consumed.
>
> Cheers,
> Tom
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From khaliff@astercity.net Tue Jun 5 22:06:50 2001
From: khaliff@astercity.net (Wojciech Moczydlowski, Jr)
Date: Tue, 5 Jun 2001 21:06:50 +0000 (UTC)
Subject: Why is there a space leak here?
In-Reply-To: <3B1D4C75.D8AD6C91@moertel.com>
Message-ID:
On Tue, 5 Jun 2001, Tom Moertel wrote:
> "Wojciech Moczydlowski, Jr" wrote:
> >
> Even so, your results suggest that nhc98 is doing something
> interesting. Does the memory usage remain constant even if you take 10
> or 100 times the number of elements? If so, perhaps nhc98 is smart
I was just writing that it stayed constant, when the executing program
ran out of heap :). Seems that my claim about nhc98 was false - I didn't
wait long enough to see the program stop. Sorry for mistaking you.
> Tom
Wojciech Moczydlowski, Jr
From Dominic.J.Steinitz@BritishAirways.com Tue Jun 5 22:40:28 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 05 Jun 2001 21:40:28 Z
Subject: Why is there a space leak here?
Message-ID: <"027723B1D51CC00F*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
I'd love it if someone could write a tutorial paper on space leaks. Even with the explanations that have been provided, I find it difficult to understand why expressions get evaluated in a particular order and why garbage collections happen at a given point.
Dominic.
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From reid@cs.utah.edu Tue Jun 5 22:45:42 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 05 Jun 2001 15:45:42 -0600
Subject: Why is there a space leak here?
In-Reply-To: <3B1D4DED.337CC06C@cs.yale.edu>
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout>
<3B1D2D90.BA7F8BEC@moertel.com>
<3B1D4DED.337CC06C@cs.yale.edu>
Message-ID:
Mark Tullsen writes:
> You have to realize that Alastair Reid is one of the truly great
> Haskell programmers on planet earth. I'm serious. So, when he says
> "incredibly subtle space leak" I wouldn't expect the solution to be
> simple. As far as I can tell, your argument would also apply to
> foo2, which doesn't have a space leak.
Yeah, well, in this case this allegedly "truly great Haskell
programmer" happened to be looking at the problem the wrong way. I
started out assuming it was a compiler or garbage collector bug and
didn't even think of trying to actually reason about the program using
the CBN calculus.
Blush!
--
Alastair Reid
ps Tell you what, I'll make up for it by making most of the fptools/hslib
libraries work in Hugs. If you have read-write access to the cvs
repository, all you have to do (as of 20 minutes ago) is:
cvs -d checkout hugs98
cvs -d checkout fptools/hslibs
cd hugs98/src/unix
./convert_hslibs ../../.. # path points to base of fptools tree
./configure --prefix=$HOME
cd ..
make install
where is whatever you normally use to get the CVS
repository. Something like this
:ext:@cvs.haskell.org:/home/cvs/root
If you only have read access, you'll need to wait until it gets updated
(sometime tonight) and then use
:pserver:anoncvs@cvs.haskell.org:/cvs
with the password "cvs".
From tom-list-haskell@moertel.com Tue Jun 5 23:08:44 2001
From: tom-list-haskell@moertel.com (Tom Moertel)
Date: Tue, 05 Jun 2001 18:08:44 -0400
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> <3B1D2D90.BA7F8BEC@moertel.com> <3B1D4DED.337CC06C@cs.yale.edu>
Message-ID: <3B1D586C.A49A480B@moertel.com>
Mark Tullsen wrote:
>
> You have to realize that Alastair Reid is one of the truly
> great Haskell programmers on planet earth. I'm serious.
> So, when he says "incredibly subtle space leak" I wouldn't
> expect the solution to be simple.
Whoops. Now don't I feel foolish.
> As far as I can tell, your argument would also apply to foo2,
> which doesn't have a space leak.
Hmmm... Let's see.
foo2 m
= take m v
where
v = 1 : flatten (map single v)
single x = [x]
v = 1 : flatten (map single v)
= 1 : flatten (map single (1 : flatten (map single v)))
= 1 : flatten (single 1 : map single (flatten (map single v)))
= 1 : flatten ([1] : map single (flatten (map single v)))
= 1 : 1 : flatten (map single (flatten (map single v)))
= Aaaarrggggh! You're right.
Now don't I feel double foolish. :P
Okay, then, what is the *right* way to reason about these things?
Cheers,
Tom
From tullsen@cs.yale.edu Tue Jun 5 23:18:01 2001
From: tullsen@cs.yale.edu (Mark Tullsen)
Date: Tue, 05 Jun 2001 18:18:01 -0400
Subject: Why is there a space leak here?
References: <"027723B1D51CC00F*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Message-ID: <3B1D5A99.74803A38@cs.yale.edu>
"Steinitz, Dominic J" wrote:
> I'd love it if someone could write a tutorial paper on space
> leaks.
I agree that would be very useful.
> Even with the explanations that have been provided, I find it
> difficult to understand why expressions get evaluated in a
> particular order and why garbage collections happen at a given
> point.
In my "traces" I did the garbage collections as soon as possible, basically
removing unused let bindings.
The ordering of evaluations is a bit more tricky ... I would
recommend becoming familiar with the various call-by-need calculi.
For me, it was more intuitive than trying to understand what's going
on at some lower level (such as the STG Machine) and then relate that
lower level to my program. With call-by-need calculi you can
understand what's going on at the source level. Here's a starting
point:
The Call-by-Need Lambda Calculus,
POPL 95, Ariola, Felleisen, Maraist, Odersky, & Wadler
@article{maraist-odersky-wadler:need-JFP98,
author = "John Maraist and Martin Odersky and Philip Wadler",
title = "The Call-by-Need Lambda Calculus",
journal = "Journal of Functional Programming",
volume = 8,
number = 3,
month = may,
year = 1998,
publisher = "Cambridge University Press",
}
- Mark
From claus.reinke@talk21.com Tue Jun 5 23:37:14 2001
From: claus.reinke@talk21.com (Claus Reinke)
Date: Tue, 5 Jun 2001 23:37:14 +0100
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> <3B1D2D90.BA7F8BEC@moertel.com>
Message-ID: <009a01c0ee10$127f6480$80f17ad5@vaio>
> Alastair David Reid wrote:
> > Executive summary: David's program has an incredibly subtle space leak
> > in it (or I'm being incredibly dumb). I encourage the honchos (and
> > would be honchos) to have a look. Users of other compilers might give
> > it a shot too.
I think there have been several good explanations already, or
is there anything wrong with them?
As Olaf pointed out, one might use GHood for the job:
http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/GHood/
An example on how to add observations in this case, and
how to interpret the results might be helpful to those who
haven't used GHood.
1. Code:
import Observe
foo1 m
= take m (observe "v-out" v)
where
v = 1 : concat (map triple (observe "v-in" v))
triple x = [x,x,x]
main = printO $ (foo1 100::[Int])
2. Interpretation:
Using Hugs to generate the observations, you should see the two
views of v evolving just as other mails in this thread have explained,
i.e., "v-out" grows at three times the rate of "v-in". Remembering
that these are two views of the same structure, the problem is that
generating "v-out" depends on "v-in", which is "v-out";-) which means
that the program execution should hold on to whatever "v-out"
delivers until observers of "v-in" are through with it. In simpler words:
"v-out to v-in: you ain't seen nothing yet!".
3. Variation:
Wojciech suggested that nhc's behaviour seems to differ slightly,
which prompted me to try whether this would be visible in GHood.
For explanation: Hood is portable, in that it works with most Haskell
implementations (special version make use of more features, when
available, and cater for renamed IOExtras..), but as it instruments
those Haskell implementations to do its work, its observations can
actually depend on what the implementation does.
As GHood shows you observations in more detail, you'll see even
more differences (such as: evaluation order of additions in nhc98
seems to depend on the type;-).
Trying the code above with nhc98-1.02 and the matching variant
of Observe.lhs, you'll see something odd: instead of two views of
v evolving in parallel, further copies of the "v-in"-view are created.
So, every three elements in "v-out", we need another element of
"v-in"(1), every three elements in "v-in"(1), we seem to need another
element of "v-in"(2), etc.
Perhaps Malcolm can explain what nhc98 does with this example?
Oh, and for all the honchos Alastairs referred to: I seem to
remember that the work on preserving cycles with lazy memo
functions also had some comments about avoiding unnecessary
growth of cyclic structures. Can anyone figure out how to apply
that to this example (or tell me that it is impossible)?
Hth,
Claus
PS: Getting new email in before sending this off, I see that
some explainers now refer to themselves as foolish, but
I'll send this off anyway, at the risk of adding myself to
that foolish Haskell programmers club:-)
From tullsen@cs.yale.edu Tue Jun 5 23:54:31 2001
From: tullsen@cs.yale.edu (Mark Tullsen)
Date: Tue, 05 Jun 2001 18:54:31 -0400
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> <3B1D2D90.BA7F8BEC@moertel.com> <3B1D4DED.337CC06C@cs.yale.edu> <3B1D586C.A49A480B@moertel.com>
Message-ID: <3B1D6327.DBB516C2@cs.yale.edu>
Tom Moertel wrote:
>
> Mark Tullsen wrote:
> >
> > You have to realize that Alastair Reid is one of the truly
> > great Haskell programmers on planet earth. I'm serious.
> > So, when he says "incredibly subtle space leak" I wouldn't
> > expect the solution to be simple.
>
> Whoops. Now don't I feel foolish.
>
> > As far as I can tell, your argument would also apply to foo2,
> > which doesn't have a space leak.
>
> Hmmm... Let's see.
>
> foo2 m
> = take m v
> where
> v = 1 : flatten (map single v)
> single x = [x]
>
> v = 1 : flatten (map single v)
> = 1 : flatten (map single (1 : flatten (map single v)))
> = 1 : flatten (single 1 : map single (flatten (map single v)))
> = 1 : flatten ([1] : map single (flatten (map single v)))
> = 1 : 1 : flatten (map single (flatten (map single v)))
> = Aaaarrggggh! You're right.
>
> Now don't I feel double foolish. :P
>
> Okay, then, what is the *right* way to reason about these things?
>
> Cheers,
> Tom
Tom,
I don't know if this approach is the *right* way but it's one
way. This approach is very brute force, and I'm sure there are experts
out there who can think and reason at a much higher level than
this. But the brute force approach is this:
Start evaluating your program symbolically
You can do this at the source level using a CBN (call-by-need)
calculus.
If the program (the program in CBN includes the "heap") starts
growing in size faster than expected then you have a space leak.
Simple, but a bit tedious. It would be great if we had a tool that
could output such a trace.
- Mark
From claus.reinke@talk21.com Wed Jun 6 10:51:32 2001
From: claus.reinke@talk21.com (Claus Reinke)
Date: Wed, 6 Jun 2001 10:51:32 +0100
Subject: Why is there a space leak here?
References: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> <3B1D2D90.BA7F8BEC@moertel.com> <3B1D4DED.337CC06C@cs.yale.edu> <3B1D586C.A49A480B@moertel.com>
Message-ID: <001501c0ee6e$456a9500$0b06073e@vaio>
From: "Tom Moertel"
> Okay, then, what is the *right* way to reason about these things?
(Non?-)strictly speaking, there is no *right* way to reason about
these things, as Haskell somehow seems to have neglected to acquire
a semantics (blush - even Java has one, kind of..). The reason, as far
as I can tell, is that everyone assumed that the core of Haskell is
sufficiently similar to "standard" calculi (some of which were developed
to make this so), so that those or "standard" works on
implementation implicitly define what everyone assumes to be Haskell's
semantics (I find it funny that the report, which equates "non-strict" and
"lazy", refers to potential loss of sharing in two places, without ever
bothering to explain how such sharing might come about in the first
place.. or am I missing anything?).
Perhaps one could say that Haskell was too lazy to acquire a
semantics before it was needed?-) But call-by-need lambda-calculus,
refered to in other replies, was developed in anticipation or
awareness of that need, I think, and is a good place to get started
without having to worry about implementation details.
> v = 1 : flatten (map single v)
> = 1 : flatten (map single (1 : flatten (map single v)))
> = 1 : flatten (single 1 : map single (flatten (map single v)))
> = 1 : flatten ([1] : map single (flatten (map single v)))
> = 1 : 1 : flatten (map single (flatten (map single v)))
> = Aaaarrggggh! You're right.
In essence, call-by-need is normal-order evaluation plus sharing of
parameters, so you can adapt your deduction (which follows
normal-order reduction, but ignores sharing) by taking care of
sharing (I'll use where for that here):
v = 1 : flatten (map single v)
->
v = 1 : tl_v
where tl_v = flatten (single 1 : map single tl_v) -- don't lose that sharing
->
v = 1 : tl_v
where tl_v = flatten ([1] : map single tl_v)
->
v = 1 : tl_v
where tl_v = 1 : flatten (map single tl_v) -- this looks familiar
..
->
v = 1 : tl_v
where tl_v = 1 : tl_tl_v -- there is now only one reference to this
tl_tl_v = 1 : flatten (map single tl_tl_v)
=
v = 1 : 1 : tl_tl_v
where tl_tl_v = 1:flatten (map single tl_tl_v)
..
I've tried to stay close to your own derivation, but otherwise this
should really correspond to Mark Tullsen's earlier posting. This
might already enable you to adapt your derivation for the version
with triple instead of single, but I would still suggest to have a
look at the CBN papers.
To complement my own earlier posting, GHood builds on Hood,
which doesn't observe sharing or garbage-collection, so if one of
these is important to the argument, observations have to be
interpreted with more care than usual.Still, it can be quite helpful
because it can give you some input about your program's behaviour
Hth,
Claus
From gustavss@cs.chalmers.se Wed Jun 6 11:52:30 2001
From: gustavss@cs.chalmers.se (=?ISO-8859-1?Q?J=F6rgen_Gustavsson?=)
Date: Wed, 6 Jun 2001 12:52:30 +0200 (MET DST)
Subject: Why is there a space leak here?
In-Reply-To: <3B1D586C.A49A480B@moertel.com>
Message-ID:
Tom Moertel wrote:
> Okay, then, what is the *right* way to reason about these things?
I will take the oppurtunity to advertise some recent work I have been
doing together with David Sands.
I think that the call-by-need lambda calculus is a very good starting
point for gaining intuition about call-by-need beacuse it gives a way to
reason about call-by-need computation at the term level. But the
call-by-need lambda calculus was not designed for reasoning about space -
there are terms which are considered equivalent which when you replace
one by the other in a whole program may change the asymptotic space
behaviour of the program. Therefore, we have been working on a theory of
space equivalence based on an operational semantics for a small subset of
Haskell. We have used the theory to reason about the to different
definitions of the function any that were discussed on the list some
months ago and I think it could be used in this case too. If you are
interested you can find a draft paper at www.cs.chalmers.se/~gustavss/.
We will submit the final version to ICFP in a few weeks so we would be
very grateful for any comments.
Regards,
Jörgen Gustavsson.
From iscp9157@nus.edu.sg Thu Jun 7 03:30:42 2001
From: iscp9157@nus.edu.sg (Saswat Anand)
Date: Wed, 6 Jun 2001 19:30:42 -0700
Subject: Functional Dependency
Message-ID: <001701c0eefa$815d8b80$bd3e8489@saswat>
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C0EEBF.2CC13E40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I am trying to define a commutative operator :
(%+) :: a -> b -> c
(%+) :: b -> a -> c
instead of defining a class and instantiating twice every time, I am =
trying to do the following:
class Commutative a b c where
(%+) :: a -> b -> c
class Operation a b c | a b -> c where
(%+%) :: a -> b -> c
instance (Operation a b c) =3D> Commutative a b c where
(%+) =3D (%+%)
instance (Operation b a c) =3D> Commutative a b c where
(%+) =3D flip (%+%)
--=20
instance Operation Int (Maybe Int) Int where
i %+% (Just s) =3D i + s
---
With hugs -98 +mo
((2::Int) %+ (Just (2::Int)))::Int gives 4
But (2::Int) %+ (Just (2::Int)) is of type Commutative Int (Maybe Int) =
a =3D> a. So is (Just (2::Int)) %+ (2::Int)
Is the dependency in Operation class not sufficient. Any work around?
Which flags to be set for Ghc to accept this code. I tried =
-fallow-overlapping-instances and
-fallow-undecidable-instances.
Thanks,
S
------=_NextPart_000_0007_01C0EEBF.2CC13E40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I am trying to define a =
commutative operator=20
:
(%+) :: a -> b -> c
(%+) :: b -> a ->=20
c
instead of defining a class and =
instantiating twice=20
every time, I am trying to do the following:
class Commutative a b c =
where
(%+) ::=20
a -> b -> c
class Operation a b c | a b -> c=20
where
(%+%) :: a -> b -> c
instance (Operation a b c) =3D> =
Commutative a b c=20
where
(%+) =3D (%+%)
instance (Operation b a c) =3D> =
Commutative a b c=20
where
(%+) =3D flip (%+%)
--
instance Operation Int (Maybe Int) Int=20
where
i %+% (Just s) =3D i + s
---
With hugs -98 +mo
((2::Int) %+ =
(Just=20
(2::Int)))::Int gives 4
But (2::Int) %+ (Just (2::Int)) is of =
type =20
Commutative Int (Maybe Int) a =3D> a. So is (Just (2::Int)) %+=20
(2::Int)
Is the dependency in Operation class =
not=20
sufficient. Any work around?
Which flags to be set for Ghc to accept =
this code.=20
I tried -fallow-overlapping-instances=20
and
-fallow-undecidable-instances.
Thanks,
S
------=_NextPart_000_0007_01C0EEBF.2CC13E40--
From cwitty@newtonlabs.com Wed Jun 6 19:30:34 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 06 Jun 2001 11:30:34 -0700
Subject: Why is there a space leak here?
In-Reply-To: "S. Alexander Jacobson"'s message of "Tue, 5 Jun 2001 15:37:41 -0400 (Eastern Daylight Time)"
References:
Message-ID:
"S. Alexander Jacobson" writes:
> For example w/ foldl:
>
> foldl + 0 [1..10000]
> foldl (+) ((+) 0 1) [2..10000]
> foldl (+) ((+) ((+) 0 1) 2) [3..10000]
>
> Can't the implementation notice that each iteration leads to a
> larger closure and, if it is running out of space go ahead an just
> evaluate (+) 0 1?
It's complicated. You can't (in general) know whether application of
a function will increase or decrease the space used. If you were
running out of space, would you just search the whole unevaluated
program graph for reductions which somehow seemed "likely" to reduce
the space used? Would you add such reduction nodes to some global
list at the time they were created?
> I realize that there is a risk of evaluating _|_ unnecessarily, but if you
> are otherwise going to run out of memory, you might as well give it a
> shot.
>
> In practice, how often do you expect to see growing expressions that cover
> a _|_ that are not actually an error in any case?
It's certainly possible.
One portable way to implement a memoizing function in Haskell (if the
domain of the function is countable) is to lazily build a data
structure that contains the results of the function on every possible
argument. Then you evaluate the portions of the data structure that
you need; the result on each argument is only evaluated once. This
probably would count as a "growing expression", and it's certainly
possible that the function on some arguments would be bottom.
> Hunting down memory leaks is already so obscure, that you might as well
> take a shot at solving the problem automatically...
>
> Alternatively, is there some magical way of warning about leaky
> expressions at compile time? You don't have to ban them, but it would be
> nice if the programmer were aware of which parts of the code are likely to
> grow...
In general, this problem is uncomputable. It might be possible to
come up with some useful approximation, but I bet that's a very
difficult research problem.
Carl Witty
From Malcolm.Wallace@cs.york.ac.uk Thu Jun 7 12:11:12 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 7 Jun 2001 12:11:12 +0100
Subject: Why is there a space leak here? (fwd)
In-Reply-To:
Message-ID:
Hi Claus,
I've had a look at this example in GHood, and you are right, nhc98
does seem to create several copies of v-in.
> import Observe
>
> foo1 m
> = take m (observe "v-out" v)
> where
> v = 1 : concat (map triple (observe "v-in" v))
> triple x = [x,x,x]
>
> main = printO $ (foo1 100::[Int])
> Perhaps Malcolm can explain what nhc98 does with this example?
At a guess, I think the answer lies in lambda-lifting.
nhc98 -c Leak.hs +CTS -lift -CTS
shows this code for `v' (reformatted a little to make it easier to read):
Main.Prelude.173.v = \ v223 v224 ->
Prelude.:
(Prelude._apply1 (Prelude.fromInteger v223) 1L)
(Prelude._apply1
(Prelude.concat)
(Prelude.map (Main.Prelude.174.triple)
(Observe.observe (Observe.Observable.Prelude.[] v224)
(LAMBDA225)
(Prelude._apply2
(Main.Prelude.173.v) v223 v224))))
v takes two arguments; v223 represents the numeric dictionary, and
v224 the Observer dictionary. The recursive reference to v is not
a cyclic pointer to a constant structure, but actually a function call.
I believe the real culprit is that nhc98 does not implement the
monomorphism restriction. IIRC, the DMR applies to every group
of simple pattern bindings at the same let-bound scope, not just
the top-level, so really we ought to default-away the dictionaries,
which would solve this particular space oddity.
Regards,
Malcolm
From giorgio@etabeta.disi.unige.it Thu Jun 7 16:09:58 2001
From: giorgio@etabeta.disi.unige.it (Giorgio Delzanno)
Date: Thu, 7 Jun 2001 17:09:58 +0200 (CEST)
Subject: CFP: ICLP ws SAVE 2001
Message-ID: <200106071509.RAA19748@etabeta.disi.unige.it>
===============================================================================
We apologize for multiple copies of this message
===============================================================================
ICLP 2001 workshop SAVE 2001
Specification, Analysis and Validation for Emerging Technologies
in Computational Logic
http://www.disi.unige.it/person/DelzannoG/save.html
Dec 1, 2001 , Coral Beach Hotel and Resort, Paphos, Cyprus
Submission Deadline: August 25, 2001
The huge increase in interconnectivity we have witnessed in the last decade has boosted the development of
systems which are often large-scale, distributed, time-critical, and possibly acting in an unreliable or malicious
environment. Furthermore, software and hardware components are often mobile, and have to interact with a
potentially arbitrary number of other entities.
These systems require solid formal techniques for their verification and analysis. In this respect, computational
logic plays an increasingly important role, both providing formal methods for proving system's correctness and
tools - e.g. using techniques like constraint programming and theorem proving - for verifying their properties.
In addition, computational logic is gaining importance as tool for the specification of (part) of these systems. For
instance, one can think at the specification, in a form of temporal logic, of a communication protocol. Such
specification offers the advantage that one can reason about it using formal methods, and at the same time it is
often easily executable by rewriting it into a logic-based programming language.
Extending and shifting slightly from the scope of the predecessors (on verification and logic languages) held in
the context of past editions of ICLP, the aim of this workshop is to bring together researchers interested in the
use of computational logicas a tool for the specification, analysis and validation of systems, with particular
emphasis on (but not restricted to) emerging technologies like World Wide Web and E-Commerce, (protocols
for) Smart Cards and Mobile Telephony, Wireless Technology, Hybrid Systems, Real-Time and Distributed
systems etc.
Topics
The topics of interest include but are not limited to:
Specification languages and rapid prototyping:
Logic programming and its extensions
First-order, constructive, modal and temporal logic
Constraints
Type theory
Analysis:
Abstract interpretation
Static analysis
Validation:
Simulation and testing
Deductive methods
Model checking
Theorem proving
The preferred issues include, but are not limited to:
Mobility: specification and verification of mobile code.
Security: access rights, information flow, and security protocols.
Interaction, coordination, negotiation, communication and exchange on the Web.
Open and infinite-state systems.
Real-time systems.
Important Dates:
Deadline for submissions: August 25, 2001.
Notification of acceptance/rejection: September 15, 2001.
Final papers due: October 5, 2001.
Authors should submit papers of at most 15 pages, in postscript format,
formatted for A4 paper, to Giorgio Delzanno (giorgio@disi.unige.it) by
31st July 2001. The proceedings will be published in electronic format.
A printed version will be distributed to all
participants of the workshop.
On the basis of the number and quality of the submissions, we could also consider the
possibility of inviting submissions for a special issue of an international journal
dedicated to the workshop.
Workshop Organizers/PC Chairs:
Giorgio Delzanno
Dipartimento di Informatica e Scienze dell'Informazione
Universita' di Genova
giorgio@disi.unige.it
Sandro Etalle
Department of Computer Science
University of Twente and CWI
etalle@cs.utwente.nl
Maurizio Gabbrielli
Dipartimento di Matematica ed Informatica
Universita' di Udine
gabbri@dimi.uniud.it
Program Committee:
Radhia Cousot, CNRS & École Polytechnique, France
Giorgio Delzanno, University of Genova, Italy
Sandro Etalle, University of Twente and CWI, The Netherlands
Maurizio Gabbrielli, University of Udine, Italy
Thierry Massart, University of Brussels, Belgium
Frank Pfenning, Carnegie Mellon University, USA
Andreas Podelski, Max Planck Institute, Germany
Sriram Rajamani, Microsoft Research, USA
Jean-Francois Raskin, University of Brussels, Belgium
From alex@shop.com Fri Jun 8 15:41:48 2001
From: alex@shop.com (S. Alexander Jacobson)
Date: Fri, 8 Jun 2001 10:41:48 -0400 (Eastern Daylight Time)
Subject: Why is there a space leak here?
In-Reply-To:
Message-ID:
On 6 Jun 2001, Carl R. Witty wrote:
> "S. Alexander Jacobson" writes:
>
> > For example w/ foldl:
> >
> > foldl + 0 [1..10000]
> > foldl (+) ((+) 0 1) [2..10000]
> > foldl (+) ((+) ((+) 0 1) 2) [3..10000]
> >
> > Can't the implementation notice that each iteration leads to a
> > larger closure and, if it is running out of space go ahead an just
> > evaluate (+) 0 1?
>
> It's complicated. You can't (in general) know whether application of
> a function will increase or decrease the space used. If you were
> running out of space, would you just search the whole unevaluated
> program graph for reductions which somehow seemed "likely" to reduce
> the space used? Would you add such reduction nodes to some global
> list at the time they were created?
I'm not clear why you can't in general notice that you are using
more space after function application than before. I it hard to see why a
program couldn't do the analysis I just did on foldl.
You could accumulate statistics on funtions that increase/decrease space
used at runtime and evaluate those that do reduce space used...
> > I realize that there is a risk of evaluating _|_ unnecessarily, but if you
> > are otherwise going to run out of memory, you might as well give it a
> > shot.
> >
> > In practice, how often do you expect to see growing expressions that cover
> > a _|_ that are not actually an error in any case?
>
> It's certainly possible.
You are trading off the likelihood that an exploding expression contains a
bottom against the liklihood that the programmer would prefer the
exploding expression not to explode. Much of this type of work can be
done as test-time warnings....
> One portable way to implement a memoizing function in Haskell (if the
> domain of the function is countable) is to lazily build a data
> structure that contains the results of the function on every possible
> argument. Then you evaluate the portions of the data structure that
> you need; the result on each argument is only evaluated once. This
> probably would count as a "growing expression", and it's certainly
> possible that the function on some arguments would be bottom.
I don't think I understood this. Can you clarify?
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
From jcab@roningames.com Sun Jun 10 03:39:42 2001
From: jcab@roningames.com (Juan Carlos Arevalo Baeza)
Date: Sat, 09 Jun 2001 19:39:42 -0700
Subject: Why is there a space leak here?
In-Reply-To:
References:
Message-ID: <4.3.2.7.2.20010609192951.03907a70@207.33.235.243>
At 10:41 AM 6/8/2001 -0400, S. Alexander Jacobson wrote:
> > One portable way to implement a memoizing function in Haskell (if the
> > domain of the function is countable) is to lazily build a data
> > structure that contains the results of the function on every possible
> > argument. Then you evaluate the portions of the data structure that
> > you need; the result on each argument is only evaluated once. This
> > probably would count as a "growing expression", and it's certainly
> > possible that the function on some arguments would be bottom.
>
>I don't think I understood this. Can you clarify?
I believe I know what he's talking about. The example I've read about
this technique is random-number generators. Because typical generators will
need a state (the seed), they can be awkward to use in functional
languages. Instead, you can just generate an infinite list of the random
numbers, and extract them from that list lazily.
Specifically, what he's talking about is the fact that a function like
"Natural -> a" corresponds to a list where all the possible results for
each number are stored in the corresponding position in the list. If you
generate that list lazily, and then access it, each element will only be
computed once (the compiler/interpreter takes care of this in a very
natural way). But if you do this, the program will (or can) grow as more
elements get computed.
Am I making sense?
Salutaciones,
JCAB
---------------------------------------------------------------------
Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com
Senior Technology programmer | mailto:jcab@roningames.com
Ronin Entertainment | ICQ: 10913692
(my opinions are only mine)
JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html
From ashley@semantic.org Sun Jun 10 06:55:48 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Sat, 9 Jun 2001 22:55:48 -0700
Subject: Monomorphism Restriction
Message-ID: <200106100555.WAA05519@mail4.halcyon.com>
Is there a point to the "monomorphism restriction" in GHC and Hugs? In
practice, all it seems to mean is "occasionally require unnecessary
explicit type signatures".
--
Ashley Yakeley, Seattle WA
From bjpop@cs.mu.OZ.AU Mon Jun 11 05:34:23 2001
From: bjpop@cs.mu.OZ.AU (Bernard James POPE)
Date: Mon, 11 Jun 2001 14:34:23 +1000 (EST)
Subject: Monomorphism Restriction
Message-ID: <200106110434.OAA06216@mulga.cs.mu.OZ.AU>
Ashley Yakeley, Seattle WA, writes:
> Is there a point to the "monomorphism restriction" in GHC and Hugs? In
> practice, all it seems to mean is "occasionally require unnecessary
> explicit type signatures".
I think the point is made clearly enough in section 4.5.5 of the Haskell 98
language report, you can find it at www.haskell.org. Whether you are
satisified with this explanation is another matter.
Regards Bernie.
From kahl@heraklit.informatik.unibw-muenchen.de Mon Jun 11 10:22:38 2001
From: kahl@heraklit.informatik.unibw-muenchen.de (kahl@heraklit.informatik.unibw-muenchen.de)
Date: 11 Jun 2001 09:22:38 -0000
Subject: Haskell 98 Report
In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com>
(simonpj@microsoft.com)
References: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <20010611092238.11279.qmail@demokrit.informatik.unibw-muenchen.de>
Simon Peyton-Jones wrote:
> I've finished what I hope is the final version of the Haskell 98
> Language and Library Reports
> http://research.microsoft.com/~simonpj/haskell98-revised
haskell98-library-html/index.html still contains the following line:
The Haskell Library Report 1.4
By my count, it should be ``1.6'' ;-)
Cheers,
Wolfram
From radhia@lix.polytechnique.fr Sat Jun 9 19:38:00 2001
From: radhia@lix.polytechnique.fr (radhia@lix.polytechnique.fr)
Date: Sat, 9 Jun 2001 20:38:00 +0200 (CEST)
Subject: SAS'01: Early registration 15th June
Message-ID: <200106091838.UAA11019@albatros.polytechnique.fr>
___________________________________________________________________________
[We apologize for any inconvience caused by multiple copies]
SAS'01
Eigth International Static Analysis Symposium
La Sorbonne, Paris, 16-18 July, 2001
http://www.ens.fr/sas01/
Registration information is available on the SAS'01 website.
Early registration ends soon (15th June).
___________________________________________________________________________
From claire@CoLi.Uni-SB.DE Mon Jun 11 09:46:06 2001
From: claire@CoLi.Uni-SB.DE (Claire Gardent)
Date: Mon, 11 Jun 2001 10:46:06 +0200 (MET DST)
Subject: CFP ESSLLI02 (Trento, Italy)
Message-ID:
[An HTML version of the Call for Proposals is available via the
FoLLI page .
Usual apologies apply if you receive multiple copies of this message.]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Fourteenth European Summer School in Logic, Language and Information
ESSLLI-2002
August 4-17, 2002, Trento, Italy
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
CALL FOR COURSE and WORKSHOP PROPOSALS
--------------------------------------
The main focus of the European Summer Schools in Logic, Language and
Information is on the interface between linguistics, logic and
computation. Foundational, introductory and advanced courses together
with workshops cover a wide variety of topics within the three areas
of interest: Language and Computation, Language and Logic, and Logic
and Computation.
Previous summer schools have been highly successful, attracting up to
500 students from Europe and elsewhere. The school has developed into
an important meeting place and forum for discussion for students and
researchers interested in the interdisciplinary study of Logic,
Language and Information. ESSLLI-2002 is organised under the auspices
of the European Association for Logic, Language and Information
(FoLLI).
The ESSLLI-2002 Programme Committee invites proposals for foundational,
introductory, and advanced courses, and for workshops for the 14th annual
Summer School on a wide range of topics in the following fields:
LANGUAGE & COMPUTATION LANGUAGE & LOGIC LOGIC & COMPUTATION
In addition to courses and workshops there will be a Student Session. A Call
for Papers for the Student Session will be distributed separately.
PROPOSAL SUBMISSION: Proposals should be submitted through a web form located
at
All proposals should be submitted no later than July 22, 2001.
Authors of proposals will be notified of the committee's decision no
later than September 17, 2001. Proposers should follow the guidelines
below while preparing their submissions; proposals that deviate can
not be considered.
GUIDELINES FOR SUBMISSION: Anyone interested in lecturing or organising a
workshop during ESSLLI-2002, please read the following information carefully.
ALL COURSES: Courses are taught by 1 or max. 2 lecturers. They typically
consist of five sessions (a one-week course) or ten sessions (a two-week
course). Each session lasts 90 minutes.
Timetable for Course Proposal Submission:
Jul 22, 2001: Proposal Submission Deadline
Sep 17, 2001: Notification
Nov 15, 2001: Deadline for receipt of title, abstract, lecturer(s)
information, course description and prerequisites
Jun 1, 2002: Deadline for receipt of camera-ready course material
FOUNDATIONAL COURSES: These are really elementary courses not assuming any
background knowledge. They are intended for people to get acquainted with the
problems and techniques of areas new to them. Ideally, they should allow
researchers from other fields to acquire the key competences of neighbouring
disciplines, thus encouraging the development of a truly interdisciplinary
research community. Foundational courses may presuppose some experience with
scientific methods in general, so as to be able to concentrate on the issues
that are germane to the area of the course.
INTRODUCTORY COURSES: Introductory courses are central to the
activities of the Summer School. They are intended to equip students
and young researchers with a good understanding of a field's basic
methods and techniques. Introductory courses in, for instance,
Language and Computation, can build on some knowledge of the component
fields; e.g., an introductory course in computational linguistics
should address an audience which is familiar with the basics of
linguistics and computation.
Proposals for introductory courses should indicate the level of
the course as compared to standard texts in the area.
ADVANCED COURSES: Advanced courses should be pitched at an audience of
advanced Masters or PhD students. Proposals for advanced courses
should specify the prerequisites in some detail.
WORKSHOPS: The aim of the workshops is to provide a forum for advanced
Ph.D. students and other researchers to present and discuss their
work. A workshop has a theme. At most one organiser is paid. The
organisers should be specialists in the theme of the workshop and give
a general introduction in the first session. They are also
responsible for the programme of the workshop, i.e., for finding
speakers.
Each workshop organiser will be responsible for producing a Call for
Papers for the workshop by November 15, 2001. The call must make it
clear that the workshop is open to all members of the LLI community.
It should also note that all workshop contributors must register for
the Summer School.
A workshop consists of five sessions (a one-week workshop) or ten
sessions (a two-week workshop). Sessions are normally 90 minutes.
Timetable for Workshop Proposal Submissions
Jul 22, 2001: Proposal Submission Deadline
Sep 15, 2001: Notification
Nov 15, 2001: Deadline for receipt of Call for Papers
Dec 1, 2001: Send out Call for Papers
Mar 15, 2002: Deadline for Papers (suggested)
May 1, 2002: Notification of Workshop Contributors (suggested)
May 15, 2002: Deadline for Provisional Workshop Programme
Jun 1, 2002: Deadline for receipt of camera-ready copy of Workshop
notes
Jun 1, 2002: Deadline for Final Workshop Programme
FORMAT FOR PROPOSALS:
The web-based form for submitting course and workshop proposals is accessible
at . You will be required
to submit the following information:
* Name (name(s) of proposed lecturer(s)/organiser)
* Address (contact addresses of proposed lecturer(s)/organiser;
where possible, please include phone and fax numbers)
* Title (title of proposed course/workshop)
* Type (is this a workshop, a foundational course, an introductory
course, or an advanced course?)
* Section (does your proposal fit in Language & Computation,
Language & Logic or Logic & Computation? name only one)
* Description (describe the proposed contents in at most 150 words)
* External funding (will you be able to find external funding to
help fund your travel and accommodation expenses? if so, how?)
* Further particulars (any further information that is required by
the above guidelines should be included here)
FINANCIAL ASPECTS: Prospective lecturers and workshop organisers
should be aware that all teaching and organising at the summer schools
is done on a voluntary basis in order to keep the participants fees as
low as possible. Lecturers and organisers are not paid for their
contribution, but are reimbursed for travel and accommodation. Please
note the following: In case a course is to be taught by two lecturers,
a lump sum is paid to cover travel and accommodation expenses. The
splitting of the sum is up to the lecturers. However, please note
that the organisers highly appreciate it if, whenever possible,
lecturers and workshop organisers find alternative funding to cover
travel and accommodation expenses.
Workshop speakers are required to register for the Summer School;
however, workshop speakers will be able to register at a reduced rate
to be determined by the Organising Committee.
Finally, it should be stressed that while proposals from all over the
world are welcomed, the Summer School can in general guarantee only to
reimburse travel costs for travel from destinations within Europe to
Trento. Exceptions will be made depending on the financial situation.
PROGRAM COMMITTEE:
Claire Gardent (chair)
Attn: ESSLLI-2002
LORIA
BP 239 Campus Scientifique
54506 Vandoeuvre-les-Nancy (France)
Tel: +33-3-83-59-2039
Fax: +33-3-83-27-5652
Email: claire.gardent@loria.fr
Local co-chair:
Paolo Bouquet (bouquet@cs.unitn.it)
Language & Computation:
Hinrich Schuetze (me@hinrichschuetze.com)
Gerry Altmann (g.altmann@psych.york.ac.uk)
Language & Logic:
Fabio Pianesi (pianesi@irst.itc.it)
Steve Pulman (stephen.pulman@somerville.ox.ac.uk)
Logic & Computation:
Simon Parsons (S.D.Parsons@csc.liv.ac.uk )
Frank Wolter (wolter@jaist.ac.jp)
ORGANISING COMMITTEE:
Luciano Serafini (chair)
Email: serafini@itc.it
FURTHER INFORMATION: To obtain further information, visit the web site
for ESSLLI-2002 .
For this year's summer school, please see the web site for ESSLLI-2001
.
http://www.loria.fr/~gardent
From cwitty@newtonlabs.com Mon Jun 11 23:58:14 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 11 Jun 2001 15:58:14 -0700
Subject: Why is there a space leak here?
In-Reply-To: "S. Alexander Jacobson"'s message of "Fri, 8 Jun 2001 10:41:48 -0400 (Eastern Daylight Time)"
References:
Message-ID:
"S. Alexander Jacobson" writes:
> On 6 Jun 2001, Carl R. Witty wrote:
>
> > "S. Alexander Jacobson" writes:
> >
> > > For example w/ foldl:
> > >
> > > foldl + 0 [1..10000]
> > > foldl (+) ((+) 0 1) [2..10000]
> > > foldl (+) ((+) ((+) 0 1) 2) [3..10000]
> > >
> > > Can't the implementation notice that each iteration leads to a
> > > larger closure and, if it is running out of space go ahead an just
> > > evaluate (+) 0 1?
> >
> > It's complicated. You can't (in general) know whether application of
> > a function will increase or decrease the space used. If you were
> > running out of space, would you just search the whole unevaluated
> > program graph for reductions which somehow seemed "likely" to reduce
> > the space used? Would you add such reduction nodes to some global
> > list at the time they were created?
>
> I'm not clear why you can't in general notice that you are using
> more space after function application than before. I it hard to see why a
> program couldn't do the analysis I just did on foldl.
I wasn't worried about foldl; you assumed that (+) 0 1 got smaller if
you carried out the application. Even for (+) on Integer, this is not
guaranteed (for large integers, if something else happens to be
holding on to the summands, evaluating the addition can increase total
space usage).
> You could accumulate statistics on funtions that increase/decrease space
> used at runtime and evaluate those that do reduce space used...
Right, that's the sort of thing I meant about "likely" above. But how
do you find such function applications in the global program graph, if
you seem to be running low on space? (And you also need to realize
that some functions might usually have "small" outputs, and sometimes
have "large" outputs.)
> > One portable way to implement a memoizing function in Haskell (if the
> > domain of the function is countable) is to lazily build a data
> > structure that contains the results of the function on every possible
> > argument. Then you evaluate the portions of the data structure that
> > you need; the result on each argument is only evaluated once. This
> > probably would count as a "growing expression", and it's certainly
> > possible that the function on some arguments would be bottom.
>
> I don't think I understood this. Can you clarify?
Let me know if JCAB's response wasn't enough here.
Carl Witty
From heron_carvalho@bol.com.br Thu Jun 14 14:02:18 2001
From: heron_carvalho@bol.com.br (Heron)
Date: Thu, 14 Jun 2001 10:02:18 -0300
Subject: Ray Tracing
Message-ID: <002401c0f4d2$400bd280$66a1fea9@heron>
This is a multi-part message in MIME format.
------=_NextPart_000_0021_01C0F4B9.18E100E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Haskell & GHC people,
I need the source code of a Ray Tracing written in Haskell. This =
code was used for parallelization using Caliban and Eden. Can you help =
me on how or where I can obtain it ?
Heron de Carvalho, Msc.
------=_NextPart_000_0021_01C0F4B9.18E100E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Haskell=20
& GHC people,
I need =
the source=20
code of a Ray Tracing written in Haskell. This code was =
used for=20
parallelization using Caliban and Eden. Can you help me on how or where =
I can=20
obtain it ?
Heron de Carvalho, =
Msc.
------=_NextPart_000_0021_01C0F4B9.18E100E0--
From simonpj@microsoft.com Fri Jun 15 17:21:39 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 15 Jun 2001 09:21:39 -0700
Subject: Eq instance for (a,b,c,d,e) and upwards
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D730AA@red-msg-09.redmond.corp.microsoft.com>
Folks
It seems that people are happy with the draft Haskell report (I'm=20
glad to say). There seem to be two outstanding issues:
* Tuples. I've decided to specify that tuples up to size 15 exist,
along with all their Eq, Ord, etc instances up to that size.
* The Prelude types of=20
deleteBy
deleteFirstsBy
intersectBy
Although these could be given more general types, it's an
unforced change, and Fergus points out that the more general
types could change error messages for the worse. I'm going to=20
let sleeping dogs lie and make no change here. [Recall that
no-change is the *strong* default.]
The final version of everything is at
http://research.microsoft.com/~simonpj/haskell98-revised
I'm ready to call it a day, but of course I may have made some=20
stupid error. Take a look please and let me know.
I have not yet made PDF; there are issues I don't understand
about how to get PDF to look right. Help sought!
Simon
From patrikj@cs.chalmers.se Mon Jun 18 09:48:04 2001
From: patrikj@cs.chalmers.se (Patrik Jansson)
Date: Mon, 18 Jun 2001 10:48:04 +0200 (MET DST)
Subject: Haskell report typo (bad law for readsPrec)
In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D730AA@red-msg-09.redmond.corp.microsoft.com>
Message-ID:
In short: change the eq. for readsPrec in appendix D.4
In detail:
From "The Haskell 98 Report: Derived Instances: D.4"
...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty. It
should be the case that
fst (head (readsPrec d (showsPrec d x r))) == x
That is, readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...
Note that the equation stated is not true unless the string r starts with
some token-ending combination.
Counter-examples:
> testreadshow :: (Show a, Read a) => a -> String -> a
> testreadshow x r = fst (head (readsPrec 0 (showsPrec 0 x r)))
A simple one that just fails: the problem is that "Nothingx" can't be
parsed.
> bad1 :: Maybe Int
> bad1 = testreadshow Nothing "x"
> test1 = bad1 == Nothing
Using this we can make the law really false by inventing a datatype
where one constructor is a prefix of another constructor:
> data T = Bad | Badger deriving (Show, Read, Eq)
> bad2 = testreadshow Bad "ger"
> test2 = bad2 == Bad
Actually there is a predefined type with lots of constructors (Int)
where many values are prefixes of others:
> bad3 :: Int
> bad3 = testreadshow 1 "2"
> test3 = bad3 == 1
> main = do print (bad3, test3)
> print (bad2, test2)
> print (bad1, test1)
OK, so the falsity of the claim is proved - what could we write instead?
The sentence explaining the equation is correct:
... readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
Thus a simple way out is to remove the equation and the preceding
sentence leaving the paragraph as:
[Alternative A:]
...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty.
Function readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...
Another simple alternative is to weaken the the equation by replacing
the variable r by the empty string:
[Alternative B:]
...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty. It
should be the case that
fst (head (readsPrec d (showsPrec d x ""))) == x
That is, readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...
[Alternative C:]
A third alternative would be to keep the equation unchanged but to add
the requirement that the string variable r should start with a "token
ending sequence of characters". But what does "token" mean? As an
explanation it might be OK, but the report should be pretty formal and
self-contained so I think this is might be undesirable.
A more complicated alternative would be to state (in words or in
equations) a more detailed correctness requirement, but I think that
would lead too far. The Haskell Show and Read classes are not detailed
enough to capture this - we would need a standardized level of
tokenizing (lexing) and this is clearly out of the scope for any
report changes at this stage.
My vote is for [Alternative B] - weaken the equation, but keep it as a
help to understand the interplay between showsPrec and readsPrec.
/Patrik Jansson
From denicola@dsi.unifi.it Fri Jun 15 08:37:38 2001
From: denicola@dsi.unifi.it (Rocco De Nicola)
Date: Fri, 15 Jun 2001 09:37:38 +0200
Subject: PLI 2001 in Firenze
Message-ID:
CALL FOR PARTICIPATION AND EARLY REGISTRATION
PLI 2001
Principles, Logics, and Implementations
of high-level programming languages
Firenze, ITALY September 2 - 8, 2001
http://music.dsi.unifi.it/pli01/
The colloquium on Principles, Logics, and Implementations of high-
level programming languages is a collection of events aimed at the
advancement of high-level programming languages.
PLI 2001 includes the following conferences and workshops:
ACM Sponsored Conferences:
ICFP (September 3-5)
Int. Conf. on Functional Programming
General chair: Benjamin Pierce (Univ. Pennsylvania)
Program chair: Xavier Leroy (INRIA Rocquencourt)
Invited speakers: To be announced
PPDP (September 5-7)
Int. Conf. on Principles and Practice of Declarative Programming
Conference chair: Rocco De Nicola (Univ. Firenze)
Program chair: Harald S=F8ndergaard (Univ. Melbourne)
Invited speakers: J. Esparza, A. Gordon, and D.A. Schmidt.
ACM Sponsored Workshops:
=B7 BABEL (Multi-language Infrastructure and Interoperability)
=B7 HASKELL
=B7 QAPL (Quantitative Aspects of Programming Languages)
=B7 RULE (Rule-Based Programming)
=B7 SAIG (Semantics, Applications, and Implementation of Program
Generation)
=B7 SCHEME (Scheme and Functional Programming)
=B7 VCL (Verification and Computational Logic)
Co-located Workshops:
=B7 ERLANG
=B7 FICS (Fixed Points in Computer Science)
A detailed presentation of PLI2001, including schedule of events,
travel and tourist information, is available at the WEB page
http://music.dsi.unifi.it/pli01/.
Registration and accommodation information and forms are available at
http://music.dsi.unifi.it/pli01/registration/
Early registration rates apply until July 25.
=46or informations about hotels please contact (mentioning PLI 2001)
Giubbi Jet di Volo Viaggi
Piazza San Jacopino, 34/r - 50144 Firenze
Telephone: +39 055 3249074 - +39 055 350577
Fax: +39 055 366807
E-mail: incoming@voloviaggi.com
=46or all other informations mail to pli-org@gdn.dsi.unifi.it
-------------------------------------------------------------------
=46irenze is packed in September; do book accommodation as soon as possible.
-------------------------------------------------------------------
--
<><><><><><><><><><><><><><><><><><><><><><><><><><>
Prof. Rocco De Nicola
Dip. Sistemi e Informatica Univ. di Firenze
Via C. Lombroso 6/17 I-50134 FIRENZE (ITALY)
tel. +39 055 4796733 fax +39 055 4796730
Web Page: http://www.dsi.unifi.it/~denicola/
<><><><><><><><><><><><><><><><><><><><><><><><><><>
From simonpj@microsoft.com Mon Jun 18 10:28:19 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 18 Jun 2001 02:28:19 -0700
Subject: Haskell report typo (bad law for readsPrec)
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D730B5@red-msg-09.redmond.corp.microsoft.com>
| Another simple alternative is to weaken the the equation by=20
| replacing the variable r by the empty string: [Alternative B:]
|=20
| ...
| should be the case that
|=20
| fst (head (readsPrec d (showsPrec d x ""))) =3D=3D x
Yes, I like this alternative too. I'll implement it.
Thank you for spotting it.
Simon
From johan@jeuring.net Mon Jun 18 12:17:11 2001
From: johan@jeuring.net (Johan Jeuring)
Date: Mon, 18 Jun 2001 13:17:11 +0200
Subject: Working Conference on Generic Programming: first call for
papers
Message-ID: <20010618111707.85D844518@mail.cs.uu.nl>
WCGP '02
IFIP TC2 Working Conference on
GENERIC PROGRAMMING
http://www.generic-programming.nl/wcgp/cfp.html
Organised in conjunction with MPC'02
July 8 - July 13, 2002
Dagstuhl, Germany
CALL FOR PAPERS
Generic programming is about making programs more
adaptable by making them more general. Generic
programs often embody non-traditional kinds of
polymorphism; ordinary programs are obtained from
them by suitably instantiating their parameters.
In contrast with normal programs, the parameters
of a generic programs are often quite rich in
structure. For example they may be other programs,
types or type constructors, class hierarchies, or
even programming paradigms.
Generic programming techniques have always been of
interest, both to practitioners and to theoreticians,
but only recently have generic programming
techniques become a specific focus of research in
the functional and object-oriented programming
language communities. This working conference will
bring together leading researchers in generic
programming from around the world, and feature
papers capturing the state of the art in this
important emerging area.
We welcome contributions on all aspects, theoretical
as well as practical, of generic programming,
aspect-oriented programming, polytypic programming,
adaptive object-oriented programming, generic
components, and so on.
SUBMISSION
Full papers should be submitted in Postscript or pdf
format by e-mail to reach Jeremy.Gibbons@comlab.ox.ac.uk
by February 16, 2002. The details of the submission
procedure can be found at
http://www.generic-programming.nl/wcgp/submit.html
Although there is no page limit, submissions should
strive for brevity and clarity.
IMPORTANT DATES
Submission February 16, 2002
Notification April 12, 2002
Final version due May 24, 2002
PROGRAMME COMMITTEE
Matt Austern
Eerke Boiten
Ulrich Eisenecker
Jeremy Gibbons (co-chair)
Ralf Hinze
Johan Jeuring (co-chair)
Gary Leavens
Karl Lieberherr
Lambert Meertens
Eugenio Moggi
Bernhard Moeller
Oege de Moor
David Musser
Martin Odersky
Ross Paterson
Simon Peyton Jones
Colin Runciman
Doaitse Swierstra
Stephanie Weirich
LOCAL ORGANISATION
Jeremy Gibbons
Johan Jeuring
Bernhard Moeller
CORRESPONDENCE
Jeremy Gibbons (Jeremy.Gibbons@comlab.ox.ac.uk)
Johan Jeuring (johan@jeuring.net)
From kh@dcs.st-and.ac.uk Mon Jun 18 15:30:19 2001
From: kh@dcs.st-and.ac.uk (Kevin Hammond)
Date: Mon, 18 Jun 2001 15:30:19 +0100
Subject: 3 Lectureships at St Andrews
Message-ID:
St Andrews University has three lectureships available in Computer Science.
We are
looking for good researchers, with an emphasis on practical skills:
functional programmers
would obviously be very good from my perspective! The deadline is the 22nd
of June, but
a late application may be acceptable if there is a good reason. Further
details are available at.
http://www.dcs.st-and.ac.uk/jobs/#lec
or send me email if you'd like to discuss it. The salary is on the
standard UK Lecturer scale:
currently UK pounds 18,731 to 30,967
Best Wishes,
Kevin
From kh@dcs.st-and.ac.uk Mon Jun 18 15:37:38 2001
From: kh@dcs.st-and.ac.uk (Kevin Hammond)
Date: Mon, 18 Jun 2001 15:37:38 +0100
Subject: Ray Tracing
In-Reply-To: <002401c0f4d2$400bd280$66a1fea9@heron>
Message-ID:
At 10:02 am -0300 14/6/01, Heron wrote:
> Hello Haskell &=A0GHC=A0people, =A0 =A0=A0=A0=A0=A0 I need the source =
code of a Ray
>Tracing written in Haskell.=A0This=A0code was used=A0for parallelization u=
sing
>Caliban and Eden. Can you help me on how or where I can obtain it ? =A0
>Heron de Carvalho, Msc.
Yes, we can let you have the sources (there are two different versions, one
with spheres
originally written in Id, the other is the one derived from Caliban).
Hans-Wolfgang Loidl is
probably the best contact, failing which I will look through my own archives=
=2E
Best Wishes,
Kevin
From v-julsew@microsoft.com Mon Jun 18 15:46:42 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Mon, 18 Jun 2001 07:46:42 -0700
Subject: GHC version 5.00.2 is available
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60302A9E9@red-msg-06.redmond.corp.microsoft.com>
The (Interactive) Glasgow Haskell Compiler -- version 5.00.2
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 5.00.2. The source distribution is
freely available via the World-Wide Web and through anon. FTP, under a
BSD-style license. See below for download details. Pre-built
packages for Linux, FreeBSD, and Solaris(sparc) are also available.
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.
GHC is a state-of-the-art programming suite for Haskell. Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, C++, whatever).
A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page at
http://www.haskell.org/
GHC's Web page lives at
http://www.haskell.org/ghc/
What's new in 5.00.2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Fixed a few more bugs which turned out to be showstoppers for various
people. Symptoms of the fixed bugs are:
* Panics in the bytecode (interactive) linker (two different bugs).
* Compiled code dies with a segfault (two different bugs).
* Interpreted code crashes or acts weird.
* A panic in the CPR analyser.
* An infinite loop in the strictness analyser.
* Nested comments are not properly handled during module chasing.
* :module command doesn't accept underscores in module names.
* -L doesn't work on the ghci command line.
* Posix.executeFile mistakenly propagates SIGVTALRM to children.
* Exceptions during an interactive session cause the UI to forget
some important state information.
* (a new feature) Packages can now loaded at the ghci prompt.
Do ":s -package ".
What's new in 5.00.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This is a bug-fix release. Most reported bugs in 5.00 have been
fixed, including a substantial number of show-stopping bugs. The
system should be much more usable for more people. Upgrading to
5.00.1 is recommended. To all those who tried out 5.00 and reported
bugs, we thank you for your feedback and patience.
At the moment there is no Win32 build of 5.00 or 5.00.1 available. We
decided to push Win32 support to the 5.02 release, so as not to delay
5.00.1 any further.
What's new in 5.00
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.00 has been majorly revamped since the previous stable version,
4.08.2.
This should be a stable release. Major changes since 4.08.2 are:
- An interactive system, similar in style to Hugs. You can
interactively
load and unload modules, run expressions, ask the types of things.
Module dependencies are tracked and chased automatically.
Combinations of compiled and interpreted modules may be used.
All the GHC libraries are available in interactive mode, as are
most of the Glasgow extensions to Haskell 98. Compilation in
interactive mode (to bytecode) is about three times faster than
compiling to object code.
- Batch compilation of multiple modules at once, with automatic
dependency chasing. For large programs this can halve compilation
times, and removes the need for Makefiles.
- Enhanced package (library) management system. Packages may be
installed and removed from an installation using the ghc-pkg tool.
- Initial Unicode support - the Char type is now 31 bits.
- Sparc native code generator, giving much faster compilation on
sparcs.
(Native code generation for x86s has been available for a while).
- Improved heap profiling - you can restrict heap profiles
by type, closure description, cost centre, and module.
- Support for the latest Foreign Function Interface (FFI)
proposals. Marcin Kowalczyk's hsc2hs tool is included.
- Language extensions: parallel list comprehensions and functional
dependencies.
- The usual huge collection of bug fixes. Most reported bugs have
been fixed.
For full details see the release notes:
http://www.haskell.org/ghc/docs/5.00/set/release-5-00.html
How to get it
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The easy way is to go to the WWW page, which should be
self-explanatory:
http://www.haskell.org/ghc/
We supply binary builds in .rpm/.deb form for all you Linux junkies
out there, and in InstallShield form for Windows folks. Everybody
else gets a .tar.gz which can be installed where you want.
Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release.
On-line GHC-related resources
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
Relevant URLs on the World-Wide Web:
GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html
System requirements
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To compile programs with GHC, you need a machine with 32+MB memory, GNU
C
and perl. This release is known to work on the following platforms:
* i386-unknown-{linux,freebsd,mingw32}
* sparc-sun-solaris2
Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:
* hppa1.1-hp-hpux{9,10}
* i386-unknown-solaris2
* alpha-dec-osf{2,3}
* mips-sgi-irix{5,6}
* {rs6000,powerpc}-ibm-aix
The builder's guide included in distribution gives a complete
run-down of what ports work; an on-line version can be found at
http://www.haskell.org/ghc/docs/5.00/building/building-guide.html
Mailing lists
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see
http://www.haskell.org/mailman/listinfo/
Please send bug reports about GHC to glasgow-haskell-bugs@haskell.org;
GHC users hang out on glasgow-haskell-users@haskell.org. Bleeding
edge CVS users party on cvs-ghc@haskell.org.
From jcab@roningames.com Mon Jun 18 21:16:01 2001
From: jcab@roningames.com (Juan Carlos Arevalo Baeza)
Date: Mon, 18 Jun 2001 13:16:01 -0700
Subject: GHC version 5.00.2 is available
In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60302A9E9@red-msg-06.redmon
d.corp.microsoft.com>
Message-ID: <4.3.2.7.2.20010618131134.02aa3f08@207.33.235.243>
At 07:46 AM 6/18/2001 -0700, Julian Seward (Intl Vendor) wrote:
>The (Interactive) Glasgow Haskell Compiler -- version 5.00.2
>
>[...]
>
>Pre-built
>packages for Linux, FreeBSD, and Solaris(sparc) are also available.
>
>[...]
>
> What's new in 5.00.1
>======================
>
>[...]
>
>At the moment there is no Win32 build of 5.00 or 5.00.1 available. We
>decided to push Win32 support to the 5.02 release, so as not to delay
>5.00.1 any further.
So, what's up? I've been completely unable to build it (the previous
version) on my own... It says it requires Happy, and no matter what I do
(Happy build just fine), it doesn't see it.
No hurry, but still, I'd like to play with this new version.
Salutaciones,
JCAB
---------------------------------------------------------------------
Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com
Senior Technology Engineer | mailto:jcab@roningames.com
Ronin Entertainment | ICQ: 10913692
(my opinions are only mine)
JCAB's Rumblings is so off-line O:-(
From Nicole.Gabler@web.de Tue Jun 19 09:23:30 2001
From: Nicole.Gabler@web.de (Nicole Gabler)
Date: Tue, 19 Jun 2001 10:23:30 +0200
Subject: library Directory.hs
Message-ID: <200106190823.f5J8NUj22145@mailgate4.cinetic.de>
Hi all,
I have a problem: I need the library Directory.hs. But there is no directory.hs in {Hugs}/lib/ !! All standard libraries are there expect of this one. I downloaded Hugs from http://www.haskell.org/hugs/. Is there any alternative?? Or did I understand something wrong?? I hope you can help me!
Best regards,
Nicole
______________________________________________________________________________
Sie surfen im Internet statt im Meer? Selbst schuld!
Auf zum Strand: http://lastminute.de/?PP=1-0-100-105-1
From wlux@uni-muenster.de Tue Jun 19 11:30:59 2001
From: wlux@uni-muenster.de (Wolfgang Lux)
Date: Tue, 19 Jun 2001 12:30:59 +0200
Subject: Haskell report typo (bad law for readsPrec)
In-Reply-To: "Your message of Mon, 18 Jun 2001 02:28:19 PDT."
<37DA476A2BC9F64C95379BF66BA26902D730B5@red-msg-09.redmond.corp.microsoft.com>
References: <37DA476A2BC9F64C95379BF66BA26902D730B5@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <20010619103101.BFA8F255AB@www.haskell.org>
Sorry, it hit the wrong button so the following didn't go to the list.
> "Simon Peyton-Jones" wrote
>
> >
> > | Another simple alternative is to weaken the the equation by
> > | replacing the variable r by the empty string: [Alternative B:]
> > |
> > | ...
> > | should be the case that
> > |
> > | fst (head (readsPrec d (showsPrec d x ""))) == x
> >
> > Yes, I like this alternative too. I'll implement it.
>
> Why not require
>
> readsPrec d (showPrec d x "") == [(x,"")]
>
> in this case? At least it should be
>
> head (readsPrec d x "") == (x,"")
>
> Regards
> Wolfgang
>
--
Wolfgang Lux Phone: +49-251-83-38263
Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259
Universitaet Muenster Email: wlux@uni-muenster.de
From wolfgang@jeltsch.net Tue Jun 19 13:48:52 2001
From: wolfgang@jeltsch.net (Wolfgang Jeltsch)
Date: Tue, 19 Jun 2001 14:48:52 +0200
Subject: library Directory.hs
In-Reply-To: <200106190823.f5J8NUj22145@mailgate4.cinetic.de>
References: <200106190823.f5J8NUj22145@mailgate4.cinetic.de>
Message-ID: <01061914485203.00617@home>
Hello,
according to
http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/libs.html
Hugs does not contain all standard libraries. Especially the Directory module
is missing.
Wolfgang
On Tuesday, 19. June 2001 10:23, you wrote:
> Hi all,
>
> I have a problem: I need the library Directory.hs. But there is no
> directory.hs in {Hugs}/lib/ !! All standard libraries are there expect of
> this one. I downloaded Hugs from http://www.haskell.org/hugs/. Is there any
> alternative?? Or did I understand something wrong?? I hope you can help me!
>
> Best regards,
>
> Nicole
From Nicole.Gabler@web.de Tue Jun 19 15:01:51 2001
From: Nicole.Gabler@web.de (Nicole Gabler)
Date: Tue, 19 Jun 2001 16:01:51 +0200
Subject: library Directory.hs
References: <200106190823.f5J8NUj22145@mailgate4.cinetic.de> <01061914485203.00617@home>
Message-ID: <004d01c0f8c8$6431d930$e4a79cc2@icsag.de>
> Hello,
> according to
> http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/libs.html
> Hugs does not contain all standard libraries. Especially the Directory
module
> is missing.
>
> Wolfgang
O.k. thank you Wolfgang!!
Then I will tell you my problem exactly. Perhaps anybody can help me:
My haskell programm is in the root directory. I want to parse from several
files in different directories. How can I do this??
Thank you
Nicole
From qrczak@knm.org.pl Tue Jun 19 18:06:39 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 19 Jun 2001 17:06:39 GMT
Subject: library Directory.hs
References: <9gnnde$3ts$1@qrnik.zagroda>
Message-ID:
Tue, 19 Jun 2001 10:23:30 +0200, Nicole Gabler pisze:
> I have a problem: I need the library Directory.hs. But
> there is no directory.hs in {Hugs}/lib/ !! All standard
> libraries are there expect of this one.
Not exactly: Time and CPUTime are also missing.
> Is there any alternative??
You can use another Haskell implementation:
ghc - A big and rich compiler. May be hard to install because of
dependencies on various tools. Provides many language extensions
and libraries.
nhc98 - Smaller than ghc but larger than Hugs. Provides a little
more than Haskell 98. Compiles faster than ghc but programs execute
more slowly.
hbc - No longer maintained. Didn't reach Haskell 98. Compiles fast
and programs run quite fast.
A note about sources of these compilers: nhc98 is written in nice and
clean standard Haskell (but I haven't looked deeply); ghc is written
in itself and sometimes can be hard to understand; hbc is written in
LazyML and almost nobody except its author understands it. Hugs is
an interpreter written in C and I'm not sure how clearly it is written.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From jans@numeric-quest.com Tue Jun 19 14:35:32 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Tue, 19 Jun 2001 09:35:32 -0400 (EDT)
Subject: library Directory.hs
In-Reply-To: <004d01c0f8c8$6431d930$e4a79cc2@icsag.de>
Message-ID:
On Tue, 19 Jun 2001, Nicole Gabler wrote:
> O.k. thank you Wolfgang!!
> Then I will tell you my problem exactly. Perhaps anybody can help me:
> My haskell programm is in the root directory. I want to parse from several
> files in different directories. How can I do this??
That depends what you want to do. If you know the names
and locations of files, you can easily access them
by specifying full FilePaths. And this is definitely
supported by Hugs. With some gymnastic you can even
get directory listings - if you are willing to use Hugs
as a string server.
Jan
From awfurtado@uol.com.br Tue Jun 19 23:52:49 2001
From: awfurtado@uol.com.br (Andre W B Furtado)
Date: Tue, 19 Jun 2001 19:52:49 -0300
Subject: hbc
References: <9gnnde$3ts$1@qrnik.zagroda>
Message-ID: <003901c0f912$91eb0500$38dff9c8@windows9>
Why hbc did not succeeded? It is still possible to make it reach Haskell 98?
Or why doesn't ghc uses some of its techniques to compile/run programs
faster?
Andre W B Furtado
From patrikj@cs.chalmers.se Wed Jun 20 09:06:24 2001
From: patrikj@cs.chalmers.se (Patrik Jansson)
Date: Wed, 20 Jun 2001 10:06:24 +0200 (MET DST)
Subject: hbc
In-Reply-To: <003901c0f912$91eb0500$38dff9c8@windows9>
Message-ID:
On Tue, 19 Jun 2001, Andre W B Furtado wrote:
> It is still possible to make hbc reach Haskell 98?
In short: Hbc is not quite dead yet, and there is a H98 version.
In detail:
[Note: I'm no expert in compiler writing, nor do I support hbc. I just
happen to work at Chalmers in the office between Lennart Augustsson's
(main architect and implementor of hbc, now in industry) and Thomas
Hallgren's (still actively using and sometimes hacking hbc).
]
The latest unofficial release is a Haskell 98 version of hbc, from 1999.
Below are some links.
There has been no official release for the last few years and the support
level is pretty low, but the compiler exists and can be used.
Unfortunately the web-pages and the documentation has not been updated the
last few years!
One notable feature in hbc still missing in ghc is Unicode support (hbc
has supported Unicode from early on). I hope ghc will follow up the recent
change to Unicode-sized Chars with some library support soon.
Many years ago a big benefit of hbc was its interactive variant hbi, only
very recently implemented by ghc, but hbi is even less supported than hbc
and I have only tried it once or twice. [I'd be very happy to hear someone
more involved in developing hbc and hbi come forward and disprove this
claim by providing a new release.]
When it comes to speed I am pretty sure ghc produces faster code (it used
to be different, but that is a while ago) and I think hbc compiles faster
nowadays "only" because it does less work in producing good code.
/Patrik Jansson
Versions of hbc98:
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/
Binary distributions of the latest unofficial release: 0.9999.5b
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-libcv6.tar.gz
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-redhat-6.tar.gz
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-netbsdELF.tar.gz
Source snapshot:
http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/snapshot/1999-09-10/
From john@repetae.net Wed Jun 20 10:35:54 2001
From: john@repetae.net (John Meacham)
Date: Wed, 20 Jun 2001 02:35:54 -0700
Subject: hbc
In-Reply-To: ; from patrikj@cs.chalmers.se on Wed, Jun 20, 2001 at 10:06:24AM +0200
References: <003901c0f912$91eb0500$38dff9c8@windows9>
Message-ID: <20010620023554.J710@mark.ugcs.caltech.edu>
you forget one other essential quality of hbc.
As far as I know it is the only compiler that even has a chance of
compiling Fudgets, and hence programs dependent on them such as
the very cool (IMHO) Alfa proof editor
(http://www.cs.chalmers.se/~hallgren/Alfa/)
and its assosiated improvments to Fudgets. If there is any effort to
port these tools to a modern haskell system then I cheer you on.
John
On Wed, Jun 20, 2001 at 10:06:24AM +0200, Patrik Jansson wrote:
> On Tue, 19 Jun 2001, Andre W B Furtado wrote:
> > It is still possible to make hbc reach Haskell 98?
>
> In short: Hbc is not quite dead yet, and there is a H98 version.
>
> In detail:
>
> [Note: I'm no expert in compiler writing, nor do I support hbc. I just
> happen to work at Chalmers in the office between Lennart Augustsson's
> (main architect and implementor of hbc, now in industry) and Thomas
> Hallgren's (still actively using and sometimes hacking hbc).
> ]
>
> The latest unofficial release is a Haskell 98 version of hbc, from 1999.
> Below are some links.
>
> There has been no official release for the last few years and the support
> level is pretty low, but the compiler exists and can be used.
> Unfortunately the web-pages and the documentation has not been updated the
> last few years!
>
> One notable feature in hbc still missing in ghc is Unicode support (hbc
> has supported Unicode from early on). I hope ghc will follow up the recent
> change to Unicode-sized Chars with some library support soon.
>
> Many years ago a big benefit of hbc was its interactive variant hbi, only
> very recently implemented by ghc, but hbi is even less supported than hbc
> and I have only tried it once or twice. [I'd be very happy to hear someone
> more involved in developing hbc and hbi come forward and disprove this
> claim by providing a new release.]
>
> When it comes to speed I am pretty sure ghc produces faster code (it used
> to be different, but that is a while ago) and I think hbc compiles faster
> nowadays "only" because it does less work in producing good code.
>
> /Patrik Jansson
>
> Versions of hbc98:
>
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/
>
> Binary distributions of the latest unofficial release: 0.9999.5b
>
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-libcv6.tar.gz
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-linux-redhat-6.tar.gz
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/hbc-0.9999.5b.bin-i386-netbsdELF.tar.gz
>
> Source snapshot:
>
> http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haskell/snapshot/1999-09-10/
>
>
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@repetae.net
--------------------------------------------------------------
From aaron.roth@lexys.com Wed Jun 20 19:58:47 2001
From: aaron.roth@lexys.com (Aaron Roth)
Date: Wed, 20 Jun 2001 14:58:47 -0400
Subject: Haskell GUI's
Message-ID:
I'm sure this topic has been discussed ad nauseum. I've only been
subscribing since January, so forgive me if I reintroduce it. Is there any
place where various approaches for a Haskell GUI are being actively
discussed? I've seen fragments here and there, namely pages on FranTk,
Fudgets, GTK+Haskell, and a request to port the Clean I/O library. I've also
read that there is no consensus view on how to do GUI's in Haskell, but is
there an active debate somewhere? Or a few other papers? Thanks.
Aaron
From steph@cs.uchicago.edu Wed Jun 20 19:59:59 2001
From: steph@cs.uchicago.edu (Stephen Bailey)
Date: Wed, 20 Jun 2001 14:59:59 -0400
Subject: hbc
In-Reply-To: Message from "Andre W B Furtado"
of "Tue, 19 Jun 2001 19:52:49 -0300." <003901c0f912$91eb0500$38dff9c8@windows9>
References: <9gnnde$3ts$1@qrnik.zagroda> <003901c0f912$91eb0500$38dff9c8@windows9>
Message-ID: <20010620190006.5B6DC94006@sandmail.sandburst.com>
> Why hbc did not succeeded?
I heard rumors that the author went off to some cushy industrial job,
or is spending all his time writing NetBSD drivers, or something like
that :^)
Steph
From nikhil@acm.org Thu Jun 21 01:52:20 2001
From: nikhil@acm.org (Rishiyur S. Nikhil)
Date: Wed, 20 Jun 2001 20:52:20 -0400
Subject: hbc
References: <9gnnde$3ts$1@qrnik.zagroda> <003901c0f912$91eb0500$38dff9c8@windows9> <20010620190006.5B6DC94006@sandmail.sandburst.com>
Message-ID: <3B314544.B2FDA770@mediaone.net>
Stephen Bailey wrote:
>
> > Why hbc did not succeeded?
>
> I heard rumors that the author went off to some cushy industrial job,
> or is spending all his time writing NetBSD drivers, or something like
> that :^)
>
> Steph
I heard that he had become a recluse and was chasing eclipses
somewhere in South Africa!
Nikhil
From chak@cse.unsw.edu.au Thu Jun 21 02:15:16 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 21 Jun 2001 11:15:16 +1000
Subject: Haskell GUI's
In-Reply-To:
References: