From gmh@Cs.Nott.AC.UK Tue Jan 2 10:52:36 2001
Date: Tue, 02 Jan 2001 10:52:36 +0000
From: Graham Hutton gmh@Cs.Nott.AC.UK
Subject: JFP Special Issue on Haskell
Dear all,
Please note that the deadline for submission to the JFP Special Issue
on Haskell is in one months time --- 1st February 2001.
Graham Hutton
----------------------------------------------------------------------
CALL FOR PAPERS
Journal of Functional Programming
Special Issue on Haskell
Since its inception in 1987, Haskell has provided a focal point for
research in lazy functional programming. During this time the
language has continually evolved, as a result of both theoretical
advances and practical experience. Haskell has proved to be a
powerful tool for many kinds of programming tasks, and applications in
industry are beginning to emerge. The recent definition of Haskell 98
provides a long-awaited stable version of the language, but there are
many exciting possibilities for future versions of Haskell.
The fourth Haskell Workshop was held as part of the PLI 2000
colloquium on Principles, Logics, and Implementations of high-level
programming languages in Montreal, 17th September 2000. Previous
Haskell Workshops have been held in Paris (1999), Amsterdam (1997) and
La Jolla (1995). Following on from these workshops, a special issue
of the Journal of Functional Programming will be devoted to Haskell.
Possible topics include, but are not limited to:
Critiques of Haskell 98;
New proposals for Haskell;
Applications or case studies;
Programming techniques;
Reasoning about programs;
Semantic issues;
Pedagogical issues;
Implementation.
Contributors to any of the Haskell workshops are invited to submit
full papers to the special issue on Haskell, but submission is open to
everyone. Submissions should be sent to the guest editor (address
below), with a copy to Nasreen Ahmad (nasreen@dcs.gla.ac.uk).
Submitted articles should be sent in postscript format, preferably
gzipped and uuencoded. In addition, please send, as plain text, title,
abstract, and contact information. The submission deadline is 1st
February 2001. For other submission details, please consult an issue
of JFP or see the Journal's web pages.
Guest Editor:
Graham Hutton
School of Computer Science and IT
The University of Nottingham
Nottingham NG8 1BB
United Kingdom
gmh@cs.nott.ac.uk
Useful Links:
2000 Haskell Workshop www.cs.nott.ac.uk/~gmh/hw00.html
JFP Special Issue on Haskell www.cs.nott.ac.uk/~gmh/jfp.html
JFP Home Page www.dcs.gla.ac.uk/jfp
----------------------------------------------------------------------
From paul.hudak@yale.edu Tue Jan 2 14:14:33 2001
Date: Tue, 02 Jan 2001 09:14:33 -0500
From: Paul Hudak paul.hudak@yale.edu
Subject: Learning Haskell and FP
> Unforunately, the "Gentle Introduction To Haskell" that
> haskell.org links to is not a very useful introduction.
John and I should probably rename this document, since it really isn't a
very gentle intro at all. We should probably also downplay it's
prominance on the haskell website. It was written rather quickly many
years ago, at a time when there was not a single textbook on Haskell.
So it's probably outlived it's purpose, although I do believe that some
people still find it useful.
-Paul
From ger@tzi.de Tue Jan 2 14:27:20 2001
Date: Tue, 02 Jan 2001 15:27:20 +0100
From: George Russell ger@tzi.de
Subject: Learning Haskell and FP
Paul Hudak wrote:
>
> > Unforunately, the "Gentle Introduction To Haskell" that
> > haskell.org links to is not a very useful introduction.
>
> John and I should probably rename this document, since it really isn't a
> very gentle intro at all. We should probably also downplay it's
> prominance on the haskell website. It was written rather quickly many
> years ago, at a time when there was not a single textbook on Haskell.
> So it's probably outlived it's purpose, although I do believe that some
> people still find it useful.
I think Paul is being unduly modest. I found it very useful when I first learnt
Haskell. But I did already know ML, so maybe the "Gentle Introduction" would be
harder going for someone who didn't know anything about functional programming.
Nevertheless I think it might be a mistake to downplay it unless there's a better
publicly-available introduction with which you can replace it.
The introduction states quite clearly that
> Our goal is to provide a gentle introduction to Haskell for someone
> who has experience with at least one other language, preferably a
> functional language (even if only an "almost-functional" language
> such as ML or Scheme).
and then goes on to recommend a couple of texts giving more detailed
introductions to functional programming. I don't think one can ask for more.
From simonpj@microsoft.com Tue Jan 2 15:39:42 2001
Date: Tue, 2 Jan 2001 07:39:42 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: List.partition a bit too eager
It's a bug in the defn of 'partition' in the Haskell 98 report.
I have (still) failed to publish this as an errata, let alone revise
the report itself, so the buggy defn stands at present, I'm afraid.
I really plan to get to the revision in early '01.
Simon
| -----Original Message-----
| From: George Russell [mailto:ger@tzi.de]
| Sent: 22 December 2000 15:57
| To: haskell@haskell.org
| Subject: List.partition a bit too eager
|
|
| I think the following program
|
| import List
| main = putStr . show . fst . (partition id) . cycle $ [True,False]
|
| should display [True,True,True,...]. But instead, for both
| GHC and Hugs,
| you get a stack overflow. Is this a bug, or could someone
| explain it to me?
|
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|
From jans@numeric-quest.com Tue Jan 2 10:52:57 2001
Date: Tue, 2 Jan 2001 05:52:57 -0500 (EST)
From: Jan Skibinski jans@numeric-quest.com
Subject: Learning Haskell and FP
On Tue, 2 Jan 2001, George Russell wrote:
> Paul Hudak wrote:
> >
> > > Unforunately, the "Gentle Introduction To Haskell" that
> > > haskell.org links to is not a very useful introduction.
> >
> > John and I should probably rename this document, since it really isn't a
> > very gentle intro at all. We should probably also downplay it's
> > prominance on the haskell website. It was written rather quickly many
> > years ago, at a time when there was not a single textbook on Haskell.
> > So it's probably outlived it's purpose, although I do believe that some
> > people still find it useful.
> [cut]
> Nevertheless I think it might be a mistake to downplay it unless
> there's a better publicly-available introduction with which you can
> replace it.
Very valid observation.
John, Paul:
Wouldn't be worthwhile and possible to gradually upgrade
it within some sort of a supervised documentation project at
Yale, as part of your regular teaching curriculum?
Jan
From ger@tzi.de Tue Jan 2 15:59:18 2001
Date: Tue, 02 Jan 2001 16:59:18 +0100
From: George Russell ger@tzi.de
Subject: List.partition a bit too eager
Simon Peyton-Jones wrote:
>
> It's a bug in the defn of 'partition' in the Haskell 98 report.
> I have (still) failed to publish this as an errata, let alone revise
> the report itself, so the buggy defn stands at present, I'm afraid.
>
> I really plan to get to the revision in early '01.
One thing I would like to see changed is that every function should also
appear with a short description in English, as for the SML basis library.
This would be a huge improvement for those of us whose mother-tongue is
English and not Haskell, and would also mean that in cases such as these
the implementors would have more liberty to choose the best interpretation
consistent with the spirit of the standard.
(Irrelevant comment: I believe something similar happens with European
Union treaties, which are in a variety of versions in different languages
from Irish Gaelic to Swedish, all of which are deemed to have equal weight.
Translation errors are not unknown, and have to be sorted out by the
European Court of Justice.)
From patrick@watson.org Wed Jan 3 00:43:00 2001
Date: Tue, 2 Jan 2001 19:43:00 -0500 (EST)
From: Patrick M Doane patrick@watson.org
Subject: Learning Haskell and FP
On Tue, 2 Jan 2001, Paul Hudak wrote:
> > Unforunately, the "Gentle Introduction To Haskell" that
> > haskell.org links to is not a very useful introduction.
>
> John and I should probably rename this document, since it really isn't a
> very gentle intro at all. We should probably also downplay it's
> prominance on the haskell website. It was written rather quickly many
> years ago, at a time when there was not a single textbook on Haskell.
> So it's probably outlived it's purpose, although I do believe that some
> people still find it useful.
>
As another point of reference, I decided it was time to learn Haskell
recently and this guide is what I started with. I'm familiar with Standard
ML and O'Caml, and found the guide to be very easy to read and was a good
starting point. I had enough information that I could read other Haskell
source and understand what it was trying to do even if I didn't feel
comfortable about all the details for writing programs.
However, a related issue that has been causing a lot of difficulty is
system installation. I'm primarily interested in building stand-alone
executables where speed is an important factor, so ghc seemed the best
system to work with. I've been unable to get this to work at all on a
Windows system. It seems configured to use dynamic libraries but doesn't
come with any in the package. I tried building from source, but it
requires Happy to build (and that too needed the .dlls).
On the Unix side, the installation was much smoother. I installed from
source using the FreeBSD port system and everything came together without
a hitch (it was a rather lengthy compile process though!).
There is a definite lack of "Getting Started" material in the ghc
distribution.
Documentation on libraries is also rather distributed. Sometimes I need to
look in the GHC manual about a library that is included with the
distribution, other times I need to look in the Haskell standard library
report. And if that fails, look in the Haskell standard language report
for information on what is included in the Prelude. Collecting this
information together would be a big benefit.
I've installed Hugs on the Windows side recently, and it seemed to boot up
okay. I haven't tried looking into its documentation to see if things are
any different.
Overall, I'm very pleased with the lannguage design and am excited about
its future.
Patrick
From kh0ndor@aeiou.pt Wed Jan 3 03:01:53 2001
Date: Wed, 3 Jan 2001 03:01:53 GMT
From: kh0ndor@aeiou.pt kh0ndor@aeiou.pt
Subject: (no subject)
somebody can tell me where I can find some ideas that help me in the
construction of a minesweeper programmed in haskell
I thank any type of help because I am a little confused
__________________________________________________________
Mensagem enviada pelo Xekmail: webmail grátis do AEIOU
http://xekmail.aeiou.pt
From ketil@ii.uib.no Wed Jan 3 07:28:22 2001
Date: 03 Jan 2001 08:28:22 +0100
From: Ketil Malde ketil@ii.uib.no
Subject: Learning Haskell and FP
George Russell <ger@tzi.de> writes:
> I think Paul is being unduly modest. I found it very useful when I first learnt
> Haskell. But I did already know ML, so maybe the "Gentle Introduction" would be
> harder going for someone who didn't know anything about functional programming.
Mind if I "me too" a bit? I had just read the SICP, and I too found
that the Gentle Introduction served well as an introduction to the
Haskell syntax. I think it'd be fine if the title were a bit less
ambitious - it isn't really aimed at the novice, I think.
It's been a while since I read it tho'
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From syring@email.com Wed Jan 3 07:53:21 2001
Date: Wed, 3 Jan 2001 08:53:21 +0100
From: Karl M. Syring syring@email.com
Subject: Learning Haskell and FP
> -----Original Message-----
> From: haskell-admin@haskell.org [mailto:haskell-admin@haskell.org]On
> Behalf Of Ketil Malde
> Sent: Wednesday, January 03, 2001 8:28 AM
> To: George Russell
> Cc: paul.hudak@yale.edu; i r thomas; haskell@haskell.org
> Subject: Re: Learning Haskell and FP
>
>
> George Russell <ger@tzi.de> writes:
>
> > I think Paul is being unduly modest. I found it very useful
> when I first learnt
> > Haskell. But I did already know ML, so maybe the "Gentle
> Introduction" would be
> > harder going for someone who didn't know anything about
> functional programming.
>
> Mind if I "me too" a bit? I had just read the SICP, and I too found
> that the Gentle Introduction served well as an introduction to the
> Haskell syntax. I think it'd be fine if the title were a bit less
> ambitious - it isn't really aimed at the novice, I think.
>
> It's been a while since I read it tho'
If you start out with zero knowledge in functional programming, as I do, the
GITH is really not very helpful. I have found the Clean tutorial
(cleanBookI.pdf) a good place to get my feet wet. Now, I gently try to move
on.
Regards
Karl M. Syring
PS: are the members of the list expecting to get replies by private mail?
From shlomif@vipe.technion.ac.il Wed Jan 3 08:11:51 2001
Date: Wed, 3 Jan 2001 10:11:51 +0200 (IST)
From: Shlomi Fish shlomif@vipe.technion.ac.il
Subject: (no subject)
On Wed, 3 Jan 2001 kh0ndor@aeiou.pt wrote:
> somebody can tell me where I can find some ideas that help me in the=20
> construction of a minesweeper programmed in haskell
> I thank any type of help because I am a little confused=20
>
Check out the Haskell Gtk bindings.
Regards,
=09Shlomi Fish
=20
> __________________________________________________________
> Mensagem enviada pelo Xekmail: webmail gr=E1tis do AEIOU
> http://xekmail.aeiou.pt
>=20
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>=20
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il=20
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of=20
converting any statement that follows it into a true one.
From ketil@ii.uib.no Wed Jan 3 08:25:23 2001
Date: 03 Jan 2001 09:25:23 +0100
From: Ketil Malde ketil@ii.uib.no
Subject: Learning Haskell and FP
"Karl M. Syring" <syring@web.de> writes:
>> Mind if I "me too" a bit? I had just read the SICP, and I too found
>> that the Gentle Introduction served well as an introduction to the
>> Haskell syntax.
> If you start out with zero knowledge in functional programming, as I do, the
> GITH is really not very helpful.
Exactly. It's "gentle" if you know functional programming, but
probably not otherwise.
> PS: are the members of the list expecting to get replies by private mail?
Expecting? I'd have no qualms about replying to people privately, but
then perhaps I am the obnoxious kind of person. :-) Negative feedback
is scarce (although this thread might favorably diverge to -cafe?
Followup-To: set).
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From simonpj@microsoft.com Wed Jan 3 09:02:00 2001
Date: Wed, 3 Jan 2001 01:02:00 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Learning Haskell and FP
| PS: are the members of the list expecting to get replies by
| private mail?
The thing to do is to switch the thread to
haskell-cafe@haskell.org
haskell@haskell-org is meant for openers; longer threads should
move to haskell-cafe. That way people can control how inundated they
get.
You can "move" by simply adding "-cafe" into the address when you reply.
Simon
From sk@mathematik.uni-ulm.de Wed Jan 3 09:14:45 2001
Date: Wed, 3 Jan 2001 10:14:45 +0100
From: Stefan Karrmann sk@mathematik.uni-ulm.de
Subject: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
A syntax to choose the active instances may be useful, too.
E.g.:
use EccenticOrd, SetCollection in exp
then in exp the instances EccenticOrd, SetCollection are known (or preferred).
This is similiar to the open syntax in Cayenne.
--
Stefan Karrmann
From simonpj@microsoft.com Wed Jan 3 09:28:41 2001
Date: Wed, 3 Jan 2001 01:28:41 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Learning Haskell and FP
| There is a definite lack of "Getting Started" material in the ghc
| distribution.
I'm sure that's right. Trouble is, we're the last people qualified
to write one!
Here's a suggestion: would someone like to write such a guide,
from the point of view of a beginner, leaving blanks that we can fill in,
when you come across a task or issue you don't know the answer
to? That is, you provide the skeleton, and we fill in the blanks.
Simon
From syring@email.com Wed Jan 3 09:59:41 2001
Date: Wed, 3 Jan 2001 10:59:41 +0100
From: Karl M. Syring syring@email.com
Subject: Learning Haskell and FP
> -----Original Message-----
> From: Simon Peyton-Jones [mailto:simonpj@microsoft.com]
> Sent: Wednesday, January 03, 2001 10:02 AM
> To: syring@email.com; haskell@haskell.org
> Subject: RE: Learning Haskell and FP
>
>
> | PS: are the members of the list expecting to get replies by
> | private mail?
>
> The thing to do is to switch the thread to
>
> haskell-cafe@haskell.org
>
> haskell@haskell-org is meant for openers; longer threads should
> move to haskell-cafe. That way people can control how inundated they
> get.
>
> You can "move" by simply adding "-cafe" into the address when you reply.
I was somewhat irritated about the inclusion of the individual reply
adresses. Most mailing list software seems to remove the email adresses of
the senders. On the other hand, there are people that use the private mail
for archiving purposes, iff the content seems to be potentially important
while forwarding the letters send to the list to bit nirvana.
Regards
Karl M. Syring
From atze@cs.uu.nl Wed Jan 3 10:05:49 2001
Date: Wed, 3 Jan 2001 11:05:49 +0100
From: Atze Dijkstra atze@cs.uu.nl
Subject: GHC/Happy on MacOS X/Darwin
On http://www.cs.uu.nl/~atze/Programming/index.html a version of ghc (4.08.1) and happy (still 1.8) for MacOS X/Darwin can be downloaded. However, a few remarks do apply: this version of ghc is not a completely ported version but built with generic settings and meant as a bootstrapping compiler. It also is distributed as binaries for a specific location (/usr/local/{ghc,happy}) in the UNIX directory structure. The main reasons for distributing it in this unfinished form are:
- The MacOS X cc (c compiler) has some (blocking) bugs (for example, problems with asm statements) which hinder progress.
- I consider 'unfinished' availability now of greater importance than 'perfect' availability later, so people can play with it.
- The compiler seems to run ok, that is, after minimal testing (compiling ghc libraries and a local AG + parsercombinator system).
--
- Atze -
Atze Dijkstra, Dept. of Computer Science, Utrecht University /|\
Tel.: +31-30-2534093/1454 | WWW : http://www.cs.uu.nl/~atze / | \
Fax : +31-30-2513971 | Email: atze@cs.uu.nl /--| \
atze.dijkstra@hetnet.nl / |___|
From israelt@optushome.com.au Wed Jan 3 13:36:25 2001
Date: Wed, 03 Jan 2001 23:36:25 +1000
From: i r thomas israelt@optushome.com.au
Subject: Writing a beginners guide to Haskell
>Here's a suggestion: would someone like to write such a guide,
>from the point of view of a beginner, leaving blanks that we can fill in,
>when you come across a task or issue you don't know the answer
>to? That is, you provide the skeleton, and we fill in the blanks.
Well, I am definitely a beginner and am prepared to take this on
I have had some exposure to Ada, C , C++, Prolog etc but definitely no=
previous FP experience before.
For some time now, I had been planning to write an introduction to Haskell=
for my son
He is a bright 14 year old who is familiar with Delphi and VB but has like=
me
has not done any functional programming before . If it is simple enough
for him, it should work as a true "Beginners guide to Haskell".
I propose that I write it section by section, and either post to the=
mailing list for corrections and feedback.
If there are objections , I will send it to those willing to correct it (=
hopefully these will include Paul Hudak and Simon Peyton Jones ) . If my=
ability to continue this falters or if I encounter a section that is too=
hard for me, ( at the moment, monads seem a likely candidate ! ) I'll pass=
the enterprise along to anyone else who is willing to take it on !
From shlomif@vipe.technion.ac.il Wed Jan 3 12:44:16 2001
Date: Wed, 3 Jan 2001 14:44:16 +0200 (IST)
From: Shlomi Fish shlomif@vipe.technion.ac.il
Subject: Learning Haskell and FP
On Tue, 2 Jan 2001, Paul Hudak wrote:
> > Unforunately, the "Gentle Introduction To Haskell" that
> > haskell.org links to is not a very useful introduction.
>
> John and I should probably rename this document, since it really isn't a
> very gentle intro at all. We should probably also downplay it's
> prominance on the haskell website. It was written rather quickly many
> years ago, at a time when there was not a single textbook on Haskell.
> So it's probably outlived it's purpose, although I do believe that some
> people still find it useful.
>
I learned Haskell from it. Later, people corrected my style and I learned
some more. Of course, I did not do any serious Haskell programming yet,
except for my infamous primes finding algorithms.
Regards,
Shlomi Fish
> -Paul
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From paul.hudak@yale.edu Wed Jan 3 14:51:10 2001
Date: Wed, 03 Jan 2001 09:51:10 -0500
From: Paul Hudak paul.hudak@yale.edu
Subject: Learning Haskell and FP
Thanks to everyone for their comments regarding "GITH". I conclude
that:
-- it is useful to people who have previously programmed in Scheme
or some other functional language
-- it is a difficult read for those not familiar with FP concepts,
and certainly not appropriate for novice programmers
-- given the dearth of free documentation on Haskell, it serves a
useful purpose
-- the title is misleading
Also thanks to George Russell for reminding me that the intro states
clearly that:
> Our goal is to provide a gentle introduction to Haskell for someone
> who has experience with at least one other language, preferably a
> functional language (even if only an "almost-functional" language
> such as ML or Scheme).
So I suppose the main thing that John and I should think about is
changing the title. Something like "An Introduction to Haskell for
People Who Have Previously Programmed in Scheme or Some Other Functional
Language" might be good! :-) Of course changing the title might confuse
people to whom the document was recommended. It may be that a
clarifying remark on haskell.org is warranted.
Anyway, thanks again for the comments.
Best to All for the New Year,
-Paul
From peterson-john@cs.yale.edu Wed Jan 3 15:02:01 2001
Date: Wed, 3 Jan 2001 10:02:01 -0500
From: John Peterson peterson-john@cs.yale.edu
Subject: Learning Haskell and FP
One more thing: I'm happy to incorporate any tutorial material into
haskell.org. If you have material that would be appropriate please
let me know and I'll add it to the site. I know there are some very
good slides from Haskell courses that could be put into haskell.org.
The document sources to the Gentle Intro are also available. We've
already had some very generous help with it and Paul and I will be
happy to support anyone that would like to improve it further.
Finally, another thing that would be really nice in the way of
tutorials is one from the perspective of an experienced C++ / Java
programmer. Even a relatively short work that maps between the O-O
terminology and the Haskell world would be quite useful.
John
From ger@tzi.de Wed Jan 3 15:07:15 2001
Date: Wed, 03 Jan 2001 16:07:15 +0100
From: George Russell ger@tzi.de
Subject: Learning Haskell and FP
Paul Hudak wrote:
[snip]
> So I suppose the main thing that John and I should think about is
> changing the title. Something like "An Introduction to Haskell for
> People Who Have Previously Programmed in Scheme or Some Other Functional
> Language" might be good! :-)
"A Gentle Introduction to Haskell for Functional Programmers" might be better.
Then hopefully people who have been directed to "A Gentle Introduction" will
not be confused.
From zawrotny@gecko.sb.fsu.edu Wed Jan 3 16:26:53 2001
Date: Wed, 03 Jan 2001 11:26:53 -0500
From: Michael Zawrotny zawrotny@gecko.sb.fsu.edu
Subject: Learning Haskell and FP
Paul Hudak <paul.hudak@yale.edu> wrote:
> Thanks to everyone for their comments regarding "GITH". I conclude
> that:
>
> -- it is useful to people who have previously programmed in Scheme
> or some other functional language
> -- it is a difficult read for those not familiar with FP concepts,
> and certainly not appropriate for novice programmers
> -- given the dearth of free documentation on Haskell, it serves a
> useful purpose
> -- the title is misleading
>
> Also thanks to George Russell for reminding me that the intro states
> clearly that:
>
> > Our goal is to provide a gentle introduction to Haskell for someone
> > who has experience with at least one other language, preferably a
> > functional language (even if only an "almost-functional" language
> > such as ML or Scheme).
GITH was a bit much for me. However, I have a slightly different
take on the reason why. My original background (undergrad
and PhD) is in biochemistry. Most of my programming, etc. is
self-taught, although I got through about third year's worth of
course work for an undergrad CS degree while I was at my previous
job. In the course of teaching myself various things, I dabbled
in both scheme and common lisp and more recently in SML and OCaml
(and obviously Haskell as well).
The reason that I found GITH difficult wasn't that the concept
of programming with functions/functional style was new to
me. What got me was that the concepts and notations were much
more "mathematical" than "programmatic". In my explorations
of various languages, my experience with introductions to
scheme/CL has mostly been that they tend to show how to do
things that are familiar to imperative programmers, plus all
of the things that you can do with functions as first class
values. With intros to SML, OCaml and Haskell, there is a
much greater emphasis on types, type systems, and provable
program correctness. The main difference being the emphasis
on doing familiar things in a better way followed by some new
things (scheme/lisp intros) versus throwing you into what may
be completely uncharted territory (formal type systems, monads,
functors) in SML/OCaml/Haskell intros.
There also seems to be the tendency to assume that the meaning of
a type signature like
map :: (a->b) -> [a] -> [b]
is inherently obvious. To someone unfamiliar with HM type
systems and whose last course in mathematics was more than a
decade ago, it might as well be greek.
The thing that I would most like to see would entitled "A
Practical Guide to Haskell" or something of that nature. After
working through some of the online tutorials and a fair portion
of "Craft of Functional Programming", I thought, "Ok, I do most
of these excercises, and am comfortable. Let's try that utility
program I've been thinking about for the last couple weeks."
What I ran into was scenarios like the ones listed below (some of
which have since been solved):
1. How the #$!? do I read some data from a file. Good, I've
got the data, now I can work on it. Nope, now I have an "IO
thingie" whatever that is, but all of the standard functions want
a regular "thingie" now what?
2. I need to do some XML processing. Go to haskell.org, find
links to HaXML and install it. Try to use it... Nope, no
documentation that is understandable to me. Ok, look at the
source to the one demo program that does something close to
what I want. Nope, it was written in the "It's functional and
therefore self-documenting" style. (Note, this is not intended
to be a shot at the implementors of HaXML. It is clear from
the description of the library and the functions of the included
programs that the library is complete and well thought out. I
am also sure that someone already fluent in Haskell who is used
to looking at type signatures to deduce the purpose of a function
can do sophisticated things with it. My only criticism was that
it wasn't approachable to someone who is starting to feel somewhat
comfortable with Haskell and wants to "do" something useful with it,
as opposed to exercises from a book or tutorial.)
3. I gave up on Haskell for that particular utility and wrote it
OCaml.
One is tempted to come to the conclusion that Haskell is not
suited for "normal" programmers writing "normal" programs. I
don't necessarily think that is true, but it is difficult for
someone who is used to imperative/OO style programming and has
dabbled in impure functional languages.
To be fair, I had almost the same reaction to SML/OCaml when I
first encountered them. Working on Haskell and reading "Craft"
made it much easier to go back and look at them again. It's
probably that in the spectrum of imperative ----> functional
languages, scheme/CL are farther to the left than SML/OCaml,
which is still left of Haskell. In the case of someone like me
coming from C, C++, perl, python, etc., the extreme right is
inherently much less familiar territory than the middle ground.
The tendency of the written materials to get more mathematical as
one moves to the right also exacerbates the problem.
That was my reaction when I read GITH and some of the other
introductory material around. A lot of this probably is
more relevant to the people who are thinking of writing
a lower-level intro than it is to the next edition of
The-Document-Formerly-Known-As-GITH.
My plea is for people include introductory material for people
who know how to program in general and want to do mundane tasks
in Haskell as opposed to C, Python, or whatever other language.
Mike
--
Michael Zawrotny
411 Molecular Biophysics Building
Florida State University | email: zawrotny@sb.fsu.edu
Tallahassee, FL 32306-4380 | phone: (850) 644-0069
From mpj@cse.ogi.edu Wed Jan 3 17:05:07 2001
Date: Wed, 3 Jan 2001 09:05:07 -0800
From: Mark P Jones mpj@cse.ogi.edu
Subject: Problem with functional dependencies
| I think you can simplify the example. Given
|=20
| class HasFoo a b | a -> b where
| foo :: a -> b
| instance HasFoo Int Bool where ...
|=20
| Is this legal?
| f :: HasFoo Int b =3D> Int -> b
| f x =3D foo x
The theoretical foundation for functional dependencies goes back to
the work I did on "Simplifying and Improving Qualified Types".
(Interested parties can find a 1994 report on this on my web pages;
email me if you need a pointer.)
According to that theory, the type above is a "principal satisfiable
type" for f, as is the more accurate Int -> Bool: under the
satisfiability ordering described in the report, these two types
are (satisfiably) equivalent. There is, therefore, no technical
reason why the function f could not be treated as having the
polymorphic type shown above.
On the other hand, from a practical perspective, one can argue that
the polymorphic type is misleading, obfuscating, and cumbersome:
Misleading because f doesn't really have a polymorphic type as the
declaration pretends; Obfuscating because it forces a reader to
study instance declarations that are not included in the type;
and Cumbersome because it includes an unnecessary (HasFoo Int b)
constraint that could be eliminated to produce a shorter, simpler
type.
So it comes down to a language design *decision* for which functional
dependencies, by themselves, do not force a particular choice.
- The current Hugs implementation does not allow the polymorphic
type; the intention in that implementation was to infer more
accurate, less complex types. The idea here is to make programs
easier for programmers to read, write, and understand.
- Marcin indicates that he would prefer the more relaxed approach
that allows polymorphic types; he is writing a preprocessor that
generates type signatures, and his task is easier if he doesn't
have to worry about the "improvement" of class constraints.
The idea here is to make programs easier for generators to read,
write and manipulate.
Clearly, some compromise is needed because neither approach is right
for all purposes. If we look to other aspects of the language for
inspiration, then the best way to deal with this is (probably):
(i) to infer simpler types whenever possible, but
(ii) to allow more polymorphic types when they are requested by
means of an explicit type signature.
(Incidentally, in the interests of consistency, such a system should
also programmers to use types like Num Int =3D> Int -> Bool.)
All the best,
Mark
From fjh@cs.mu.oz.au Wed Jan 3 17:37:55 2001
Date: Thu, 4 Jan 2001 04:37:55 +1100
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: Problem with functional dependencies
On 03-Jan-2001, Mark P Jones <mpj@cse.ogi.edu> wrote:
> ... the best way to deal with this is (probably):
> (i) to infer simpler types whenever possible, but
> (ii) to allow more polymorphic types when they are requested by
> means of an explicit type signature.
I agree.
> (Incidentally, in the interests of consistency, such a system should
> also programmers to use types like Num Int => Int -> Bool.)
Mercury uses the approach you've suggested above for constraints like
these. That is, you can declare types like that, and the Mercury
type checker will accept them, but it won't try to infer such types.
This feature could be a bit more useful in Mercury than in Haskell,
since in Mercury instance declarations can be private to a particular
module.
(Unfortunately, though, the Mercury runtime system's RTTI
representation of instances is not able to handle such constraints, so
for such examples, the current implementation of the compiler reports
"sorry, not implemented: constraints may only constrain type variables".)
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From haberg@matematik.su.se Wed Jan 3 18:01:38 2001
Date: Wed, 3 Jan 2001 19:01:38 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: GHC/Happy on MacOS X/Darwin
[Replies please cc me or the hugs-bugs list, as I currently is not on the
Haskell list.]
At 11:05 +0100 1-01-03, Atze Dijkstra wrote:
>On http://www.cs.uu.nl/~atze/Programming/index.html a version of ghc
>(4.08.1) and happy (still 1.8) for MacOS X/Darwin can be downloaded.
>However, a few remarks do apply: this version of ghc is not a completely
>ported version but built with generic settings and meant as a
>bootstrapping compiler. It also is distributed as binaries for a specific
>location (/usr/local/{ghc,happy}) in the UNIX directory structure. The
>main reasons for distributing it in this unfinished form are:
>- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>problems with asm statements) which hinder progress.
Isn't this related to the "munging" that GHC makes use of on other platforms?
>- I consider 'unfinished' availability now of greater importance than
>'perfect' availability later, so people can play with it.
>- The compiler seems to run ok, that is, after minimal testing (compiling
>ghc libraries and a local AG + parsercombinator system).
Otherwise it sounds great: As no-one before has been able to port anything
of GHC to MacOS (as far as I know), any kind of progress is important. (I
do not have access to MacOS X right now, so unfortunatley I cannot try out
your port.)
Hans Aberg
From qrczak@knm.org.pl Wed Jan 3 18:40:30 2001
Date: 3 Jan 2001 18:40:30 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Problem with functional dependencies
I don't fully understand fundeps. Would the following transform
legal programs (without overlapping instances) into legal programs?
I hope yes.
Let's imagine a class with a set of instances and uses, without
fundeps.
- Add some additional type variables to the class header.
- Add a fundep: all old type variables -> all new type variables.
- For each instance, in places corresponding to new type variables
write arbitrary types.
- For each constraint based on this class, in places corresponding
to new type variables write unique type variables.
In particular, should the following be legal:
class C a b c | a -> b c
instance C [a] b b
f:: C [a] b c => a
f = undefined
ghc panics and Hugs rejects it.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From atze@cs.uu.nl Wed Jan 3 19:48:59 2001
Date: Wed, 3 Jan 2001 20:48:59 +0100
From: Atze Dijkstra atze@cs.uu.nl
Subject: GHC/Happy on MacOS X/Darwin
At 19:01 +0100 03/01/2001, Hans Aberg wrote:
> >- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>>problems with asm statements) which hinder progress.
>
>Isn't this related to the "munging" that GHC makes use of on other platforms?
Apple's cc (actually gcc) does not accept 'asm' statements the way the manual describes it (it fails to parse them). asm statements are used to map GHC runtime pseudo registers to actual powerpc machine registers. The assembly source postprocessing does not work either (it is turned off) but is not related to this problem (to my knowledge).
--
- Atze -
Atze Dijkstra, Dept. of Computer Science, Utrecht University /|\
Tel.: +31-30-2534093/1454 | WWW : http://www.cs.uu.nl/~atze / | \
Fax : +31-30-2513971 | Email: atze@cs.uu.nl /--| \
atze.dijkstra@hetnet.nl / |___|
From haberg@matematik.su.se Wed Jan 3 20:03:56 2001
Date: Wed, 3 Jan 2001 21:03:56 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: GHC/Happy on MacOS X/Darwin
At 20:48 +0100 1-01-03, Atze Dijkstra wrote:
>At 19:01 +0100 03/01/2001, Hans Aberg wrote:
>> >- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>>>problems with asm statements) which hinder progress.
>>
>>Isn't this related to the "munging" that GHC makes use of on other platforms?
>
>Apple's cc (actually gcc) does not accept 'asm' statements the way the
>manual describes it (it fails to parse them). asm statements are used to
>map GHC runtime pseudo registers to actual powerpc machine registers. The
>assembly source postprocessing does not work either (it is turned off) but
>is not related to this problem (to my knowledge).
I think that it was Will Partain that described the problem as though one
had to do some assembly local to the CPU in order to get put the munging
through (perhaps I misunderstood it). -- So even if Apple's gcc accepted
asm, there would some (hard) work to do, in figuring out how the PPC (G3 &
G4) assmebly worked.
Hans Aberg
From russell@brainlink.com Thu Jan 4 04:11:38 2001
Date: Wed, 03 Jan 2001 23:11:38 -0500
From: Benjamin L. Russell russell@brainlink.com
Subject: Learning Haskell and FP
On Wed, 03 Jan 2001 11:26:53 -0500
Michael Zawrotny <zawrotny@gecko.sb.fsu.edu> wrote:
>
> [snip]
>
> The reason that I found GITH difficult wasn't that the
> concept
> of programming with functions/functional style was new to
> me. What got me was that the concepts and notations were
> much
> more "mathematical" than "programmatic". In my
> explorations
> of various languages, my experience with introductions to
> scheme/CL has mostly been that they tend to show how to
> do
> things that are familiar to imperative programmers, plus
> all
> of the things that you can do with functions as first
> class
> values. With intros to SML, OCaml and Haskell, there is
> a
> much greater emphasis on types, type systems, and
> provable
> program correctness.
>
> [snip]
>
> The thing that I would most like to see would entitled "A
> Practical Guide to Haskell" or something of that nature.
>
> [snip]
>
> One is tempted to come to the conclusion that Haskell is
> not
> suited for "normal" programmers writing "normal"
> programs.
How would you define a "'normal' programmer writing 'normal' programs?" What exactly is a "'normal' program?"
(Perhaps another way of phrasing the issue is as the "declarative" vs. "procedural" distinction, since the issue seems to be that of "what is" (types) vs. "how to" (imperative expression; i.e., procedures).)
While I agree that "A Practical Guide to Haskell" would indeed be a suitable alternative for programmers from the procedural school of expression, I would caution that such an introduction would probably not be suitable for all.
If I may give my own case as an example, I studied both C and Scheme (in addition to auditing a course in Haskell) in college, and favored Scheme over C precisely because of my Scheme course's emphasis on provable program correctness. This is largely a matter of background and taste: my course background was relatively focused on the design and analysis of algorithms, with provable program correctness being a related topic.
Perhaps, ideally, two separate tutorials (or perhaps a single tutorial with two sections based on different viewpoints?) may be needed? The difficulty is that the conceptual distance between the declarative and procedural schools of thought seems too great to be bridged by a single viewpoint. It seems that any introduction favoring either one would risk alienating the other.
Personally, I would really prefer "A Gentle Elementary Introduction to Haskell: Elements of the Haskell School of Expression with Practical Examples," but some would no doubt choose "Haskell in a Nutshell: How to Write Practical Programs in Haskell."
--Ben
--
Benjamin L. Russell
russell@brainlink.com
benjamin.russell.es.94@aya.yale.edu
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
From wli@holomorphy.com Thu Jan 4 07:18:49 2001
Date: Wed, 3 Jan 2001 23:18:49 -0800
From: William Lee Irwin III wli@holomorphy.com
Subject: Learning Haskell and FP
On Wed, Jan 03, 2001 at 01:28:41AM -0800, Simon Peyton-Jones wrote:
> Here's a suggestion: would someone like to write such a guide,
> from the point of view of a beginner, leaving blanks that we can fill in,
> when you come across a task or issue you don't know the answer
> to? That is, you provide the skeleton, and we fill in the blanks.
If someone should be bold enough to start writing such a guide, I would
be more than happy than to try to contribute to it and also set it up as
a Debian package.
Cheers,
Bill
--
"AIX is Unix from the universe where Spock had a beard."
-- Unknown
From d95lars@dtek.chalmers.se Thu Jan 4 08:45:19 2001
Date: Thu, 4 Jan 2001 09:45:19 +0100 (MET)
From: Lars Lundgren d95lars@dtek.chalmers.se
Subject: Learning Haskell and FP
On Wed, 3 Jan 2001, Michael Zawrotny wrote:
> 1. How the #$!? do I read some data from a file. Good, I've
> got the data, now I can work on it. Nope, now I have an "IO
> thingie" whatever that is, but all of the standard functions want
> a regular "thingie" now what?
>
I do not know if you actually wanted an answer to this, but I'm sick of
hearing this FAQ everywhere when the answer is so simple. There are
exactly two ways to do this (one of them is actually syntactic sugar for
the other).
1. Use the do notation:
do regularThingie <- IOThingie
return (doWhateverYouWantWith regularThingie)
2. Use bind ( >>= ):
IOThingie >>=
\regularThingie -> return (doWhateverYouWantWith regularThingie)
Note: Both constructs produces IO thingies. This is the real beauty of it,
if you have a value that is dependent on the environment (i.e. a IO value)
you can use it as a regular value inside one of the above constructs, but
the result will always be an IO value (The result will depend on the
environment because it uses a value dependent of the environment). This is
no problem, just accept it.
Can everyone include an answer to this FAQ everywhere, phleaze!
/Lars L
From Keith.Wansbrough@cl.cam.ac.uk Thu Jan 4 10:42:08 2001
Date: Thu, 04 Jan 2001 10:42:08 +0000
From: Keith Wansbrough Keith.Wansbrough@cl.cam.ac.uk
Subject: Learning Haskell and FP
> I do not know if you actually wanted an answer to this, but I'm sick of
> hearing this FAQ everywhere when the answer is so simple. There are
> exactly two ways to do this (one of them is actually syntactic sugar for
> the other).
[..]
> Can everyone include an answer to this FAQ everywhere, phleaze!
>
> /Lars L
Thanks Lars... I've added it to the Wiki.
HINT TO EVERYONE: *Anyone* can add this kind of thing to the Wiki.
Just find the appropriate page and click the EditText link at the
bottom. To create a new page just name it (in BiCapitalised form), and
the name becomes a hyperlink. Click on the link, then EditText on the
new page and you're done.
The Haskell Wiki is at:
http://haskell.org/wiki/wiki
I *do not* maintain it, I just evangelise for it. :-)
--KW 8-)
From simonpj@microsoft.com Thu Jan 4 10:51:23 2001
Date: Thu, 4 Jan 2001 02:51:23 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Learning Haskell and FP
| > 1. How the #$!? do I read some data from a file. Good, I've
| > got the data, now I can work on it. Nope, now I have an "IO
| > thingie" whatever that is, but all of the standard functions want
| > a regular "thingie" now what?
Perhaps this would be a good moment to advertise the revised version of
Tackling the Tackling the Awkward Squad:
monadic input/output, concurrency, exceptions,
and foreign-language calls in Haskell
http://research.microsoft.com/~simonpj/#marktoberdorf
(Concerning the thread I'm responding to, it gives an introduction
to monadic input/output.)
I've revised and extended this tutorial quite a bit since I announced it
last year,
with a lot of help from people on the Haskell mailing list: thank you!
Further suggestions are most welcome.
Simon
Abstract
Functional programming may be beautiful, but to write real
applications we must grapple with awkward real-world issues:
input/output, robustness, concurrency, and interfacing to programs
written in other languages.
These lecture notes give an overview of the techniques that have
been
developed by the Haskell community to address these problems. I
introduce various proposed extensions to Haskell along the way, and
I
offer an operational semantics that explains what these extensions
mean.
From israelt@optushome.com.au Thu Jan 4 13:04:33 2001
Date: Thu, 04 Jan 2001 23:04:33 +1000
From: i r thomas israelt@optushome.com.au
Subject: Learning Haskell and FP
>Perhaps this would be a good moment to advertise the revised version of
> Tackling the Tackling the Awkward Squad:
> monadic input/output, concurrency, exceptions,
> and foreign-language calls in Haskell
> http://research.microsoft.com/~simonpj/#marktoberdorf
>(Concerning the thread I'm responding to, it gives an introduction
>to monadic input/output.)
Many thanks !
This is just what I need.
Will read it before bed tonight...
From dfields@interpage.net Thu Jan 4 14:59:28 2001
Date: Thu, 4 Jan 2001 09:59:28 -0500 (EST)
From: Doug Fields dfields@interpage.net
Subject: Learning Haskell and FP
> One more thing: I'm happy to incorporate any tutorial material into
> haskell.org. If you have material that would be appropriate please
> let me know and I'll add it to the site. I know there are some very
> good slides from Haskell courses that could be put into haskell.org.
For what it's worth,
I'm happy to contribute my solutions to the exercises in
"Haskell: Craft" for posting on haskell.org. However, I assume that
in at least one place, the book is used for coursework and would, hence,
such posting would be discouraged.
Hi Paul. Hi Benjamin.
Cheers,
Doug
From rrt1001@cam.ac.uk Thu Jan 4 15:03:17 2001
Date: Thu, 4 Jan 2001 15:03:17 +0000 (GMT)
From: Reuben Thomas rrt1001@cam.ac.uk
Subject: Happy InstallShield update
I just noticed that the Happy 1.9 InstallShield contained a dynamically
linked executable for Happy. This was a Bad Idea, so I've replaced it with a
statically linked executable. This should work for more people.
--
http://sc3d.org/rrt/ | maxim, n. wisdom for fools
From C.Reinke@ukc.ac.uk Thu Jan 4 18:34:26 2001
Date: Thu, 04 Jan 2001 18:34:26 +0000
From: C.Reinke C.Reinke@ukc.ac.uk
Subject: ANNOUNCE: GHood -- a Graphical Hood (pre-release)
Ever wanted to see what your Haskell program is doing?
Andy Gill's Hood library (http://www.haskell.org/hood/) represents
a big improvement over previous uses of trace & co. It doesn't affect
strictness properties, and instead of displaying debug information
in the nearly incomprehensible order in which it is generated, it
collects, post-processes and pretty-prints the information and displays
the results after program evaluation, in a more readable form.
However, as Andy already noted in the Hood documentation, there is
a lot of useful information to be gathered from the order in which
(parts of) data structures are observed. Now that Hood associates
individual observation events with the data structures to which they
belong, thus facilitating comprehension of observations, it would be
nice to find a way to visualise the observation order as well.
Andy's plan was to incorporate such a feature into a textual browser
add-on for Hood (in CVS, not released yet?). But for tasks for which
structural context and relationships between parts dominate over details,
my personal preference would be a graphical form of visualisation.
GHood is my current attempt to add a such a graphical viewer to Hood.
It hasn't yet reached its final form, but it is quite useful and usable
already. We have played with it locally, and I can't spent too much
time on this, but I would like to get some external feedback before
I finalise the development. Hence this pre-release.
Currently, GHood comes in two files: a drop-in replacement for the
Hugs98 variant of Hood (only minimal changes, same interface) and
a Java class file archive for the graphical viewer itself.
To find the two files, please visit my Haskell corner at:
http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/
Enjoy (and let me know what you think about it),
Claus
--
Claus Reinke, http://www.cs.ukc.ac.uk/people/staff/cr3/
Computing Lab, University of Kent at Canterbury
From mpj@cse.ogi.edu Thu Jan 4 21:01:56 2001
Date: Thu, 4 Jan 2001 13:01:56 -0800
From: Mark P Jones mpj@cse.ogi.edu
Subject: Problem with functional dependencies
Hi Marcin,
| In particular, should the following be legal:
|=20
| class C a b c | a -> b c
| instance C [a] b b
| f:: C [a] b c =3D> a
| f =3D undefined
|=20
| ghc panics and Hugs rejects it.
No, it is not legal. Even if you delete the definition of f, the code
is still not legal because the class and the instance declaration are
inconsistent.
The class declaration says that you want to define a three place =
relation
on types called C. We can think of the entries in this relation as rows
in a table with columns headed a, b, and c:
a | b | c
C =3D -----+-----+------
| |
Before we take a look at any instance declarations, this table is empty
(i.e., there are no rows). But the functional dependency a -> b c that
you have specified establishes a constraint that any data that gets =
added
to the table by subsequent instance declarations must satisfy. It says
that, if two rows have the same type in the a column, then they must =
also
have the same types in the b and c columns; "the values of b and c are
uniquely determined by the value of a."
So here are two plausible instance declarations that you could use:
instance C Int Int Char
instance C (Maybe t) t Int
Notice that the second declaration here is really an instance scheme;
the presence of a variable "t" means that it introduces a whole family
of instances, one for each possible instantiation of the variable "t".
With these two instance declarations in hand, our table looks something
like the following:
a | b | c
C =3D ------------------+-----------+------
Int | Int | Char
Maybe Int | Int | Int
Maybe Bool | Bool | Int
Maybe Char | Char | Int
Maybe [Int] | [Int] | Int
Maybe (Maybe Int) | Maybe Int | Int
... | ... | ...
Conceptually, of course, there are now infinitely many rows in the =
table,
so what you see here is just a small part of the relation. But notice =
that
the data in the table is entirely consistent with the functional =
dependency
a -> b c because no two rows have the same type in the a column.
Now consider the instance declaration that you have given:
instance C [t] s s
Again, this is an instance scheme, generating one row in the table
for each possible instantiation of variables "t" and "s". (To avoid
confusion with the names of the columns in C, I've chosen different
variable names from the ones you've used.) For example, based on
this instance declaration, we would expect to continue adding rows
to the table along the following lines:
a | b | c
C =3D ------------+-------+-------
[Int] | Int | Int t=3DInt, s=3DInt
[Int] | Bool | Bool t=3DInt, s=3DBool
[Bool] | Int | Int t=3DBool, s=3DInt
... | ... | ...
I hope now that the problem is becoming clear: this instance declaration
is not consistent with the dependency; in the first two lines above, for
example, we see two rows that violate the specification because they =
have
the same value of "a", but different values for "b" and "c".
In summary, the class declaration and its associated dependency are not
consistent with the instance declaration. If you really wanted the rows
described by the instance declaration to be part of the relation C, then
the dependency you have written is not valid. If you really did want =
the
restriction captured by the dependency, then the instance declaration is
not valid. Hugs can't tell which of these is the real source of the
problem, but it does report, correctly, that there is an inconsistency.
A little more generally, given the class declaration and the dependency
that you've specified, Hugs will not allow any instance declaration for
something of the form C t1 t2 t3 if there are variables in t2 or t3
that do not appear in t1. If this restriction were not enforced, then
it would again be possible for there to be multiple rows with the same
"a" value, but different "b" and "c" entries.
I noticed the same problem in one of the earlier examples that you sent
to the list:
| class Foo a b | a
| instance Foo Int [a]
| -- This is rejected by Hugs (with fundep a->b) but I would definitely
| -- accept it.
I hope that it is now clear why Hugs rejects this definition.
| I don't fully understand fundeps.
The specific point described above is actually discussed twice in my =
ESOP
paper, once informally, and once in a more general setting. I encourage
you to take a look at that paper for more details. If you're basing =
your
knowledge of fundeps on the (now quite outdated) note on my web page, or
on the section of the Hugs manual on which it was based, you may well =
have
some gaps to fill in. I'm not too happy with the ESOP paper either; I
couldn't include as much technical material there as I wanted because of
limited space. If you have read the ESOP paper and still have =
questions,
please let me know and I will do my best to answer them.
All the best,
Mark
From qrczak@knm.org.pl Thu Jan 4 22:33:50 2001
Date: 4 Jan 2001 22:33:50 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Problem with functional dependencies
Thu, 4 Jan 2001 13:01:56 -0800, Mark P Jones <mpj@cse.ogi.edu> pisze:
> I hope now that the problem is becoming clear: this instance
> declaration is not consistent with the dependency; in the first
> two lines above, for example, we see two rows that violate the
> specification because they have the same value of "a", but different
> values for "b" and "c".
I see. So fundeps are not capable of expressing what I hoped, and what
a related but simpler concept I talked about once can express. I wonder
if there are practical uses of fundeps which are not expressible by
this concept.
What I have in mind is the following. A subset of type variables
of a class is chosen. Only that subset is used to find an instance
for resolving constraints with this class. The instance chosen
determines the rest of types. Instances must make this possible,
i.e. be non-unifiable wrt. the active subset of type variables. Voila.
An extended variant: several such subsets instead of one. Probably
each subset should be considered independently, with their results
unified. Or something like that.
This provides an equivalent of types contained in classes in C++.
It does not matter if the passive types in an instance use additional
type variables. This is where fundeps fail.
Having types with type variables which are never instantiated nor
constrained should be equivalent to having ground types!
Why, oh why haven't a more friendly and less problematic concept been
used, instead of fundeps which forever can't be finished in ghc and
have some different semantics in Hugs?
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From russell@brainlink.com Fri Jan 5 00:04:10 2001
Date: Thu, 04 Jan 2001 19:04:10 -0500
From: Benjamin L. Russell russell@brainlink.com
Subject: Learning Haskell and FP
On Wed, 3 Jan 2001 22:55:17 -0800 (PST)
Fritz K Ruehr <fruehr@willamette.edu> wrote:
>
> [snip]
>
> An O'Reilly "nutshell" book is an even better suggestion
> than
> my "Design Patterns in Haskell" of a few days back, at
> least
> from the perspective of marketing and promotion.
>
> But it raises the issue of an appropriate animal mascot
> for
> the cover; I can only come up with the Uakari, an
> exotic-looking
> rainforest monkey, which sounds similar to "Curry".
>
> (look here for a picture:)
>
> <http://www.animalsoftherainforest.com/uakari.htm>
Lalit Pant ( lalitp@acm.org ) (alternatively, lalit_pant@yahoo.com ) wrote an article in the May 2000 issue of _Java Report_ entitled "Developing Intelligent Systems With Java and Prolog" that described a Prolog implementation of the A-star search algorithm. Lalit stated that Prolog was useful for algorithm prototyping.
Perhaps Lalit Pant and Simon Peyton Jones could collaborate together on an article, perhaps overseen by Paul Hudak, on prototyping search algorithms in Haskell, also for _The Java Report?_ If this article then had a high readership, maybe the article's success could then justify publication of an O'Reilly _Haskell in a Nutshell_ book?
--Ben
P. S. (Hi Doug Fields. I didn't know that you were reading this mailing list. I guess that I should also greet Professor Paul Hudak: Hello, Professor Hudak. Sorry about Collectively Speaking. How's jazz in general?)
Benjamin L. Russell
russell@brainlink.com
benjamin.russell.es.94@aya.yale.edu
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
From peterd@availant.com Fri Jan 5 20:13:49 2001
Date: Fri, 5 Jan 2001 15:13:49 -0500
From: Peter Douglass peterd@availant.com
Subject: Are anonymous type classes the right model at all? (replying
to Re: Are fundeps the right model at all?)
Julian Assange wrote (Dec 28, 2000):
> This is why all non S-exp like lanaguage are doomed to progressive
> syntactic cancer as the useful parts of operator name space and syntax
> space become progressively polluted and mutated by one fad after
> another.
Could you expand on this? I would think that all languages have identifies
that, through common usage become standardized, and that this meaning
becomes a de-facto part of the language. Do you feel that this has not
happened in Lisp/Scheme?
--PeterD
From proff@iq.org Sat Jan 6 00:29:59 2001
Date: 06 Jan 2001 11:29:59 +1100
From: Julian Assange proff@iq.org
Subject: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
Peter Douglass <peterd@availant.com> writes:
> Julian Assange wrote (Dec 28, 2000):
>
> > This is why all non S-exp like lanaguage are doomed to progressive
> > syntactic cancer as the useful parts of operator name space and syntax
> > space become progressively polluted and mutated by one fad after
> > another.
>
> Could you expand on this? I would think that all languages have identifies
> that, through common usage become standardized, and that this meaning
> becomes a de-facto part of the language. Do you feel that this has not
> happened in Lisp/Scheme?
The identifier space in lisp/scheme has wide tree depth and is
(essentially) lexically scoped. Infix operator identifiers in other
languages are the antithesis of this. It could be argued, both fairly
and unfairly, that the verbosity of S-exp bracketing leaves short
identifiers less desirable than they otherwise would be, however
tree-width arguments remain.
Polution of syntax space is a more difficult problem. As new syntactic
axioms are intruded, they should remain consistant with the existing
syntax elements. This poses ever increasing restraint on the evolution
of the language. New syntax elements appear less intuitive and more
arbitary in an attempt to fit in with the morass of ever increasing
restraints. If these restraints are not honnored, the language becomes
inconsistant. Eventually the language is guarenteed to become either
inconsistant or moribund as the number of interactions between
language elements overwhelms a language designers attempts understand
them.
The same is even more true of language semantics. The trouble lays in
finding initial axioms which can cleave large sections of future
concept space between them.
--
Julian Assange |If you want to build a ship, don't drum up people
|together to collect wood or assign them tasks and
proff@iq.org |work, but rather teach them to long for the endless
proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery
From kh0ndor@aeiou.pt Sun Jan 7 00:06:29 2001
Date: Sun, 7 Jan 2001 00:06:29 GMT
From: kh0ndor@aeiou.pt kh0ndor@aeiou.pt
Subject: (no subject)
which is the function in haskell that allows to generate us an amount
of aleatory numbers
I thank your help
__________________________________________________________
Mensagem enviada pelo Xekmail: webmail grátis do AEIOU
http://xekmail.aeiou.pt
From chak@cse.unsw.edu.au Sun Jan 7 09:13:45 2001
Date: Sun, 07 Jan 2001 20:13:45 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: (no subject)
kh0ndor@aeiou.pt wrote,
> which is the function in haskell that allows to generate us an amount
> of aleatory numbers
I guess, you want to generate random numbers. Check out
http://haskell.org/onlinelibrary/random.html
Cheers,
Manuel
From sebc@posse42.net Sun Jan 7 14:03:07 2001
Date: Sun, 7 Jan 2001 15:03:07 +0100
From: Sebastien Carlier sebc@posse42.net
Subject: Extending the do-notation
Sometimes I need to write code which looks like this:
> do x <- m1
> let y = unzip x
> ... -- never using x anymore
I thinks the following extension to do-notation would be useful:
> pat <- exp1 # exp2 ; exp3
would be rewritten as
> exp2 >>= ((\pat -> exp3) . exp1)
so that the above example could be rewritten more compactly:
> do y <- unzip # m1
I think the biggest problem with this extension is the choice
of a proper symbol.
Does this extension already exist ? (I only checked the Haskell 98
report).
From rje33@cam.ac.uk Sun Jan 7 14:41:48 2001
Date: Sun, 7 Jan 2001 14:41:48 +0000 (GMT)
From: Robert Ennals rje33@cam.ac.uk
Subject: Extending the do-notation
On Sun, 7 Jan 2001, Sebastien Carlier wrote:
>
> Sometimes I need to write code which looks like this:
> > do x <- m1
> > let y = unzip x
> > ... -- never using x anymore
>
> I thinks the following extension to do-notation would be useful:
> > pat <- exp1 # exp2 ; exp3
> would be rewritten as
> > exp2 >>= ((\pat -> exp3) . exp1)
>
> so that the above example could be rewritten more compactly:
> > do y <- unzip # m1
>
> I think the biggest problem with this extension is the choice
> of a proper symbol.
Why not just use a user defined operator. eg:
infixr #
(#) :: Monad m => (a -> b) -> m a -> m b
f # p = p >>= (return . f)
Alternatively, define it to be "fmap", and be a bit more general.
-Rob
From qrczak@knm.org.pl Sun Jan 7 14:14:05 2001
Date: 7 Jan 2001 14:14:05 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Extending the do-notation
Sun, 7 Jan 2001 15:03:07 +0100, Sebastien Carlier <sebc@posse42.net> pisze:
> Does this extension already exist ?
Yes.
import Monad
...
do y <- liftM unzip m1
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From sebc@posse42.net Sun Jan 7 15:34:53 2001
Date: Sun, 7 Jan 2001 16:34:53 +0100
From: Sebastien Carlier sebc@posse42.net
Subject: Extending the do-notation
> import Monad
> ...
> do y <- liftM unzip m1
Thanks.
I'm constantly amazed by the number of tricks one has
to know before he can write concise code using the
do-notation (among other things, I used to write
"x <- return $ m" instead of "let x = m").
Is there a paper demonstrating the most common
coding styles for do-notation ?
Another question concerning the do-notation: I noticed
that most parts of ghc do not use it. Is it because
the code was written before the notation was available,
because the do-notation is too weak to express these
parts, or for another fundamental reason ?
From R.Daniel@Europe.com Sun Jan 7 15:45:30 2001
Date: Sun, 07 Jan 2001 15:45:30 +0000
From: R.Daniel R.Daniel@Europe.com
Subject: Movement in a frictionless environment
--=====================_1052009==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi, could anyone tell me where to find some info about generating movement
on a frictionless environment?
I need to put a ball running in a window, given an initial speed and then
let it run along with the rules of phisics....can anyone give me a hint on
where to find info, or on how to do that?
I would be most greatefull.
Thankx
----->R.Daniel
ICQ 28959546
--=====================_1052009==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Hi, could anyone tell me where to find some info about generating
movement on a frictionless environment? <br>
I need to put a ball running in a window, given an initial speed and then
let it run along with the rules of phisics....can anyone give me a hint
on where to find info, or on how to do that?<br>
<br>
I would be most greatefull.<br>
<br>
Thankx<br>
<x-sigsep><p></x-sigsep>
----->R.Daniel <br>
<font color="#0000FF">ICQ
28959546</font></html>
--=====================_1052009==_.ALT--
From Sven.Panne@informatik.uni-muenchen.de Sun Jan 7 16:21:06 2001
Date: Sun, 07 Jan 2001 17:21:06 +0100
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: Extending the do-notation
Sebastien Carlier wrote:
> I'm constantly amazed by the number of tricks one has
> to know before he can write concise code using the
> do-notation [...]
In my experience it is not the do-notation itself, but the mixture
of monadic actions and higher-order functions. But after a while
you´ll really like it. :-)
> Another question concerning the do-notation: I noticed
> that most parts of ghc do not use it. Is it because
> the code was written before the notation was available,
> because the do-notation is too weak to express these
> parts, or for another fundamental reason ?
It's only because of historical reasons, nothing more.
Cheers,
Sven
From Sven.Panne@informatik.uni-muenchen.de Sun Jan 7 16:24:19 2001
Date: Sun, 07 Jan 2001 17:24:19 +0100
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: Movement in a frictionless environment
"R.Daniel" wrote:
> Hi, could anyone tell me where to find some info about generating
> movement on a frictionless environment? [...]
I'd recommend one of the game programming sites, they have tons of
useful stuff related to physics, too:
http://www.devgames.com/
http://www.gdmag.com/
http://www.gamasutra.com/
http://www.flipcode.com/
http://www.gamesdomain.co.uk/gamedev/gprog.html
http://www.3dgamedev.com/
Cheers,
Sven
From shlomif@vipe.technion.ac.il Sun Jan 7 18:00:51 2001
Date: Sun, 7 Jan 2001 20:00:51 +0200 (IST)
From: Shlomi Fish shlomif@vipe.technion.ac.il
Subject: A dictionary implementation in Hasekll
Does anybody knows of an implementation for an efficient dictionary (such
as a hash, an AVL tree, a B-Tree etc. ) in Haskell? Can an array do that?
I'd like something that can map any type to any other type based on a
comparison function, and perhaps a hashing function.
TIA,
Shlomi Fish
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From jenglish@flightlab.com Sun Jan 7 19:08:32 2001
Date: Sun, 07 Jan 2001 11:08:32 -0800
From: Joe English jenglish@flightlab.com
Subject: Extending the do-notation
Sebastien Carlier wrote:
> Sometimes I need to write code which looks like this:
> > do x <- m1
> > let y = unzip x
> > ... -- never using x anymore
>
> I thinks the following extension to do-notation would be useful:
> > pat <- exp1 # exp2 ; exp3
> would be rewritten as
> > exp2 >>= ((\pat -> exp3) . exp1)
>
> so that the above example could be rewritten more compactly:
> > do y <- unzip # m1
This can be done in Haskell without any changes to the
'do' notation at all: just define
| f # m = m >>= (return . f)
and add an appropriate fixity declaration for '#'.
--Joe English
jenglish@flightlab.com
From qrczak@knm.org.pl Sun Jan 7 21:25:58 2001
Date: 7 Jan 2001 21:25:58 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: A dictionary implementation in Hasekll
Sun, 7 Jan 2001 20:00:51 +0200 (IST), Shlomi Fish <shlomif@vipe.technion.ac.il> pisze:
> Does anybody knows of an implementation for an efficient dictionary
> (such as a hash, an AVL tree, a B-Tree etc. ) in Haskell?
ghc's library contains FiniteMap, implemented as a balanced binary tree
(not exactly AVL), over any comparable type as the key.
I haven't seen a hash table. It's harder to do in the functional
context. It would either have to be mutable, or provide bulk operations
on many elements at once to be efficient - or use a trick with hidden
mutations in place to obtain a modified value while substituting
a backward difference for the old value, to have the functional
interface and cheap access to newest versions.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From Tom.Pledger@peace.com Mon Jan 8 04:53:35 2001
Date: Mon, 8 Jan 2001 17:53:35 +1300
From: Tom Pledger Tom.Pledger@peace.com
Subject: Are fundeps the right model at all?
Marcin 'Qrczak' Kowalczyk writes:
> Could somebody show an example which requires fundeps and cannot be
> expressed using a simpler model explained below - a model that I
> can even understand? Is the model self-consistent at all?
>
[a model which uses key constraints instead of functional dependencies]
Hi.
Try this:
class C a b c | b -> c
instance C t () t
Hugs rejects it.
If we try to express C with keys instead of fundeps, the key must
contain both a and b, which is equivalent to this:
class C a b c | a b -> c
instance C t () t
Hugs accepts this, but only because the constraint has been weakened
to something which can be expressed with keys.
It's quite a contrived example, and I'm not sure how it relates to
your later statement:
> Having types with type variables which are never instantiated nor
> constrained should be equivalent to having ground types!
Do you have any examples of such a type variable in an instance decl?
I'm having trouble imagining it, because I keep running into
unnecessary class parameters and overlapping instances.
Regards,
Tom
From ahey@iee.org Mon Jan 8 04:57:17 2001
Date: Mon, 8 Jan 2001 04:57:17 +0000 (GMT)
From: Adrian Hey ahey@iee.org
Subject: First Class Modules? was Re: Are anonymous type classes the right model at all?
Hello,
All this talk about Haskell classes, ML modules and improved record types
reminds me of the rumours of a "First Class Modules" system for Haskell,
but the only documentation I found was a fairly brief document that looked
like an application for a research grant. So...
Could somebody explain what a first class module is?
How does it differ from a record?
What could I do with a first class module (if Haskell provided them)?
Thanks
--
Adrian Hey
From ger@tzi.de Mon Jan 8 10:55:49 2001
Date: Mon, 08 Jan 2001 11:55:49 +0100
From: George Russell ger@tzi.de
Subject: Extending the do-notation
Sebastien Carlier wrote:
>
> > import Monad
> > ...
> > do y <- liftM unzip m1
>
> Thanks.
>
> I'm constantly amazed by the number of tricks one has
> to know before he can write concise code using the
> do-notation (among other things, I used to write
> "x <- return $ m" instead of "let x = m").
[snip]
Why do you WANT to write concise code using the do-notation?
Has someone revived the Obfuscated Haskell Contest, or
do you find touch-typing difficult?
From ger@tzi.de Mon Jan 8 14:58:06 2001
Date: Mon, 08 Jan 2001 15:58:06 +0100
From: George Russell ger@tzi.de
Subject: Yet more on functional dependencies
I am finding functional dependencies confusing. (I suspect I am not alone.)
Should the following code work?
class HasConverter a b | a -> b where
convert :: a -> b
instance (HasConverter a b,Show b) => Show a where
show value = show (convert value)
From qrczak@knm.org.pl Mon Jan 8 17:21:52 2001
Date: 8 Jan 2001 17:21:52 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Are fundeps the right model at all?
Mon, 8 Jan 2001 17:53:35 +1300, Tom Pledger <Tom.Pledger@peace.com> pisze:
> > Having types with type variables which are never instantiated nor
> > constrained should be equivalent to having ground types!
>
> Do you have any examples of such a type variable in an instance decl?
Not quite. When the type variable is never instantiated, like in ST
(ghc's and hbc's state threads), I don't see fundeps.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From Tom.Pledger@peace.com Mon Jan 8 20:15:10 2001
Date: Tue, 9 Jan 2001 09:15:10 +1300
From: Tom Pledger Tom.Pledger@peace.com
Subject: Yet more on functional dependencies
George Russell writes:
> I am finding functional dependencies confusing. (I suspect I am not alone.)
> Should the following code work?
>
> class HasConverter a b | a -> b where
> convert :: a -> b
>
> instance (HasConverter a b,Show b) => Show a where
> show value = show (convert value)
Yes.
Let's assume that multi-parameter classes and overlapping instances
are enabled.
Without the functional dependency, the instance decl would be rejected
because the type variable b occurs in the context (HasConverter a b,
Show b) but not in the head (Show a). The compiler needs to generate
some code for `show value', but it's not allowed to make an arbitrary
substitution for b.
The functional dependency provides a way to determine b uniquely once
a is matched. So, the compiler can generate the code for `show value'
without being arbitrary.
Regards,
Tom
From Tom.Pledger@peace.com Mon Jan 8 21:30:52 2001
Date: Tue, 9 Jan 2001 10:30:52 +1300
From: Tom Pledger Tom.Pledger@peace.com
Subject: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
Marcin 'Qrczak' Kowalczyk writes:
[...]
> My new record scheme proposal does not provide such lightweight
> extensibility, but fields can be added and deleted in a controlled
> way if the right types and instances are made.
Johan Nordlander must be on holiday or something, so I'll deputise for
him. :-)
O'Haskell also has add-a-field subtyping. Here's the coloured point
example (from http://www.cs.chalmers.se/~nordland/ohaskell/survey.html):
struct Point =
x,y :: Float
struct CPoint < Point =
color :: Color
Regards,
Tom
From nellardo@concentric.net Tue Jan 9 00:13:21 2001
Date: Mon, 08 Jan 2001 19:13:21 -0500
From: Brook Conner nellardo@concentric.net
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Inspired by the recent discussions of what kinds of books would
encourage the spread of Haskell, I whipped up a draft table of contents
for "Haskell in a Nutshell."
You can find it in PDF form at
http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts
embedded - OReilly uses a couple of oddballs) and in ASCII text at
http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt.
While there are page numbers attached, you should simply ignore those
for the moment :-) Rather, I'd be interested in feedback on the
structure etc. Oh, and please don't just rip it off and write it
yourself :-)
Like "Java in a Nutshell", the first part is a firehose description of
the language. As Haskell is somewhat different from what most OReilly
readers are used to, I've included a bit more about different ways you
can run Haskell (which, incidentally, points out that it runs *everywhere*).
Also like "Java in a Nutshell", the last part is a reference to common
packages.
The middle part is a bit different - a short "cookbook" of
semi-practical programs addressing fairly common programming tasks -
some of the kinds of things you'd typically do with Perl or C++. I think
it needs more "recipes" of course, but I'd like to know if the general
idea is working.
Brook
ps - for the curious, I have in fact written a textbook before
(object-oriented programming for a first-semester course, from 1994...).
And I'm using O'Reilly's FrameMaker templates, so the draft is
"camera-ready" (hence the page numbers - the TOC is automatically
generated).
From chak@cse.unsw.edu.au Tue Jan 9 02:43:59 2001
Date: Tue, 09 Jan 2001 13:43:59 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Brook Conner <nellardo@concentric.net> wrote,
> You can find it in PDF form at
> http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts
> embedded - OReilly uses a couple of oddballs) and in ASCII text at
> http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt.
Makes sense to me. However, I would move IO further to the
front. For any "real life" programming, IO is essential
and, I think, it is bad for the image of Haskell to treat it
as something dirty that is relegated to end of every (at
least, many) introduction of Haskell.
I have just given an Introduction to Computing course using
Haskell and written a set of lecture notes, which introduce
a couple of concepts (including IO) differently than
commonly done. The whole stuff is at
http://www.cse.unsw.edu.au/~cs1011/lectures/index.html
Feel free to get inspiration from the material (except Weeks
8 - 10, which weren't given by me). You will find IO in
Week 5. Note that I haven't used the word monad a single
time. IMHO, monads are an advanced concept, IO is not.
It's like you can introduce recursion without discussing
stacks. If you understand stacks, you can gain a deeper
understanding of recursion, but if you hear about recursion
for the first time, the mention of stacks will only distract
the average student.
> The middle part is a bit different - a short "cookbook" of
> semi-practical programs addressing fairly common programming tasks -
> some of the kinds of things you'd typically do with Perl or C++. I think
> it needs more "recipes" of course, but I'd like to know if the general
> idea is working.
I think, that this is a good idea.
Cheers,
Manuel
From bhalchin@hotmail.com Tue Jan 9 03:15:34 2001
Date: Tue, 09 Jan 2001 03:15:34
From: Bill Halchin bhalchin@hotmail.com
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Yes! I agree with Manuel about the IO. It looks bad being towards
the end.
Regards,
Bill Halchin
>From: "Manuel M. T. Chakravarty" <chak@cse.unsw.edu.au>
>Reply-To: chak@cse.unsw.edu.au
>To: nellardo@concentric.net
>CC: haskell@haskell.org
>Subject: Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
>Date: Tue, 09 Jan 2001 13:43:59 +1100
>
>Brook Conner <nellardo@concentric.net> wrote,
>
> > You can find it in PDF form at
> > http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts
> > embedded - OReilly uses a couple of oddballs) and in ASCII text at
> > http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt.
>
>Makes sense to me. However, I would move IO further to the
>front. For any "real life" programming, IO is essential
>and, I think, it is bad for the image of Haskell to treat it
>as something dirty that is relegated to end of every (at
>least, many) introduction of Haskell.
>
>I have just given an Introduction to Computing course using
>Haskell and written a set of lecture notes, which introduce
>a couple of concepts (including IO) differently than
>commonly done. The whole stuff is at
>
> http://www.cse.unsw.edu.au/~cs1011/lectures/index.html
>
>Feel free to get inspiration from the material (except Weeks
>8 - 10, which weren't given by me). You will find IO in
>Week 5. Note that I haven't used the word monad a single
>time. IMHO, monads are an advanced concept, IO is not.
>It's like you can introduce recursion without discussing
>stacks. If you understand stacks, you can gain a deeper
>understanding of recursion, but if you hear about recursion
>for the first time, the mention of stacks will only distract
>the average student.
>
> > The middle part is a bit different - a short "cookbook" of
> > semi-practical programs addressing fairly common programming tasks -
> > some of the kinds of things you'd typically do with Perl or C++. I think
> > it needs more "recipes" of course, but I'd like to know if the general
> > idea is working.
>
>I think, that this is a good idea.
>
>Cheers,
>Manuel
>
>_______________________________________________
>Haskell mailing list
>Haskell@haskell.org
>http://www.haskell.org/mailman/listinfo/haskell
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
From ketil@ii.uib.no Tue Jan 9 06:39:47 2001
Date: 09 Jan 2001 07:39:47 +0100
From: Ketil Malde ketil@ii.uib.no
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Brook Conner <nellardo@concentric.net> writes:
> Inspired by the recent discussions of what kinds of books would encourage the
> spread of Haskell, I whipped up a draft table of contents for "Haskell in a
> Nutshell."
Let's see. It all depends on what you put into the chapters, of
course, but you seem to jump directly from simple concepts into
Haskell for web servers. Wouldn't it be better to push this further
out, until at least some of the syntax has been explored?
>From the headlines, one might get the impression that type
declarations are only important when the compiler can't figure it out
itself - I'm sure the actual text will give a different view, no?
The cookbook looks great, and it's certainly something I'd buy the
book for. I can, of course, think of many kinds of example programs
I'd like to see - how about a GUI oriented program, for instance?
Perhaps you could finish it off with a "real" application, say a GUIed
JPEG viewer, where you sort of string it all (the JPEG codec, a C
library interface for something or other, and GUI stuff, etc.)
together into a whole?
On the whole, I think it looks good. Best of luck!
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From joe@isun.informatik.uni-leipzig.de Tue Jan 9 08:00:27 2001
Date: Tue, 9 Jan 2001 09:00:27 +0100 (MET)
From: Johannes Waldmann joe@isun.informatik.uni-leipzig.de
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
> However, I would move IO further to the front.
> For any "real life" programming, IO is essential...
I am currently teaching a Functional Programming lecture (notes in German:
http://www.informatik.uni-leipzig.de/~joe/edu/ws00/praxis/skript/)
and I also used this approach: use the do-notation intuitively
(for text IO and graphics, using SOE book),
and explain monads later (with parser combinators and interpreters).
This could be driven to the extreme: not only hide the word "monad",
but also "functional". The title would be "Imperative programming in Haskell"
(as S. Peyton Jones says in Tackling the Awkward Squad:
"Haskell is the world's finest imperative programming language").
The students would start writing do-notated programs in the IO monad,
starting with putStrLn "Hello World";
and gradually the emphasis is shifted from sequencing (the "semicolon")
to "what can we do on the righthand side of let x = ... ",
thus introducing functional programming.
Not sure if this is really a good idea, though...
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From joe@isun.informatik.uni-leipzig.de Tue Jan 9 08:46:31 2001
Date: Tue, 9 Jan 2001 09:46:31 +0100 (MET)
From: Johannes Waldmann joe@isun.informatik.uni-leipzig.de
Subject: Defaults in datatype definitions
Below are some suggestions for extensions to Haskell records.
These are just naive ideas.
Of course the extensions should integrate nicely
w.r.t. the existing syntax, type system, and module system.
Perhaps you can point me to opinions and research
on what has already been done, or to why it should not, or can not.
1) I would like to write down default values for record components
data Foo = Foo { x :: Bar; y :: Baz; x = some_expression }
We can do this for methods in type classes, so why not here.
2) With classes, we can do even more: in the default method,
we can access other methods.
This suggests that the above example should in fact read
data Foo = Foo { x :: Bar; y :: Baz; x = \ self -> some_expression }
where `self' might occur in some_expression. that is,
the default value of `me.x ' gets computed by applying a function to `me'.
3) I want to be able, in modules that use the type,
to add more components (with defaults) to the type:
This would avoid lengthy recomputations (at the cost of additional space).
Imagine the difference between
data Tree a = Node { key :: a, children :: [ Tree a ] }
size t = 1 + sum (map size (children t))
and
data Tree a = Node { key :: a, children :: [ Tree a ]
, size :: Integer
, size = \ self -> 1 + sum (map size (children self)) }
when you have one large tree and frequently need sizes of subtrees.
(by the way, what type does `size' have now -
do we write `Integer' or `Tree a -> Integer'?)
yes, I can do this manually, replacing `Node' by a smart constructor
that computes and stores the size. What I don't like about this
is that I have to know in advance (i. e. at the moment I define the type)
what functions I want to be "cached" this way.
Imagine `size' as some more complicated function,
only defined many modules later.
Of course I see that this would be difficult to implement
w.r.t. separate compilation. But I would be happy with a compiler
that ignores the "cache" specs during single-module compilations,
but honors them when doing a full rebuild of a set of modules.
I imagine that inter-module inlining behaves similar.
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From chak@cse.unsw.edu.au Tue Jan 9 09:41:05 2001
Date: Tue, 09 Jan 2001 20:41:05 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Johannes Waldmann <joe@isun.informatik.uni-leipzig.de> wrote,
> > However, I would move IO further to the front.
> > For any "real life" programming, IO is essential...
>
> I am currently teaching a Functional Programming lecture (notes in German:
> http://www.informatik.uni-leipzig.de/~joe/edu/ws00/praxis/skript/)
> and I also used this approach: use the do-notation intuitively
> (for text IO and graphics, using SOE book),
> and explain monads later (with parser combinators and interpreters).
>
> This could be driven to the extreme: not only hide the word "monad",
> but also "functional". The title would be "Imperative programming in Haskell"
> (as S. Peyton Jones says in Tackling the Awkward Squad:
> "Haskell is the world's finest imperative programming language").
>
> The students would start writing do-notated programs in the IO monad,
> starting with putStrLn "Hello World";
> and gradually the emphasis is shifted from sequencing (the "semicolon")
> to "what can we do on the righthand side of let x = ... ",
> thus introducing functional programming.
Starting with
putStrLn "Hello World"
is a good idea and this would exactly be my approach when
teaching students who already know some programming language
(in the course I did last term, it was their first
programming experience; therefore, I waited until Week 5).
However, I don't think it is necessary (or desirable) to
hide "functional". With "monad" it is a different story, as
it is a complicated sounding word, which is not easily
explained (to non-mathematicians). And it is not necessary;
we are not starting on fixed point and domain theory either
when explaining recursive functions.
Actually, I did run a moderately detailed survey at the end
about what the students found interesting/boring and
difficult/easy etc (and with a good sample size, too: close
to 500 students filled in the survey). I am planing to
summarise the results and post them here sometime.
Cheers,
Manuel
From nellardo@concentric.net Tue Jan 9 16:55:11 2001
Date: Tue, 09 Jan 2001 11:55:11 -0500
From: Brook Conner nellardo@concentric.net
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Ketil Malde wrote:
> Let's see. It all depends on what you put into the chapters, of
> course, but you seem to jump directly from simple concepts into
> Haskell for web servers. Wouldn't it be better to push this further
> out, until at least some of the syntax has been explored?
The second chapter is meant to be a brief overview of some of the ways
you can execute Haskell code. For a programmer familiar with some of the
more common languages (C++, Java, Perl is the kind I'm expecting),
showing them right off the bat that Haskell *can* be used in web servers
seemed like a good idea. It met two goals:
a) this list's objective in spreading the good word about how useful
Haskell is :-)
b) the objective of "Nutshell" books to let experienced people transfer
their existing skills as quickly as possible.
> >From the headlines, one might get the impression that type
> declarations are only important when the compiler can't figure it out
> itself - I'm sure the actual text will give a different view, no?
Of course - I have something of an informal writing tone when I'm
writing for education, and some of the headlines reflect that (I mean,
really, "hash"? :-) ) But part of what I was trying to do was to get
some key concepts across to two different audiences of programmers:
a) the Perl programmers, who have types but generally don't ever write
them down. These people will like type inferencing - it will seem more
natural to them.
b) the C++ and Java programmers. They'll be just fine declaring types -
showing them how to get strong typing without necessarily declaring the
types explicitly will seem nifty cool to them (it did to me, ten years
ago :-) )
I'm not about to get into any of the old arguments about static vs
dynamic typing or that stuff - been there, done that. Haskell is a
strongly typed language, and that will be apparent in the text.
> The cookbook looks great, and it's certainly something I'd buy the
Do you think the cookbook would be better as its own book?
> I can, of course, think of many kinds of example programs
> I'd like to see - how about a GUI oriented program, for instance?
Actually, last night after sending the announcement, I added exactly
that :-)
Years and years ago, Paul Haeberli of SGI implemented this cute little
hack of having a brush attached to the cursor with a spring - real
simple - moving the mouse changed the velocity vector of the brush, with
settable strength and inertia and such. It made it insanely easy to
produce a swooping, calligraphic stroke. Haeberli did it in C to OpenGL
- using Fran, it would be perhaps a one-liner.
Scott Snibbe, then of Brown University, did another cute hack that
showed up at SIGGRAPH later under the name "MotionPhone". He set up a
loop of screen buffers that ran at a constant frame rate. As you drew,
your mouse left behind moving streaks. Faster motion, longer streaks.
This would be another one-liner with Fran (Scott originally did it in C
to Pixrect, Sun's ancient direct screen access API).
I figured those kinds of examples showed off the power of Haskell.
> Perhaps you could finish it off with a "real" application, say a GUIed
> JPEG viewer, where you sort of string it all (the JPEG codec, a C
> library interface for something or other, and GUI stuff, etc.)
> together into a whole?
This morning I've been thinking about data visualization from an SQL DB....
> On the whole, I think it looks good. Best of luck!
Thanks!
Brook
From qrczak@knm.org.pl Tue Jan 9 18:52:11 2001
Date: 9 Jan 2001 18:52:11 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Are fundeps the right model at all?
Mon, 8 Jan 2001 17:53:35 +1300, Tom Pledger <Tom.Pledger@peace.com> pisze:
> > Having types with type variables which are never instantiated nor
> > constrained should be equivalent to having ground types!
>
> Do you have any examples of such a type variable in an instance decl?
Now I have a practical example where fundeps don't work and keys
would work - but the type variable is later instantiated.
Let's take Parsec from ghc's libraries which includes the following
(this is cut down):
data TokenParser = TokenParser {
identifier :: Parser String,
reserved :: String -> Parser (),
operator :: Parser String,
reservedOp :: String -> Parser (),
parens :: forall a. Parser a -> Parser a}
makeTokenParser:: LanguageDef -> TokenParser
I would like to express this "first-class module" in my records
proposal, to make it extensible (there can be different types similar
to TokenParser with similar fields and used polymorphically together
with TokenParser).
Each record field in my proposal induces a class:
class Has_field r a | r -> a where
get_field :: r -> a
The fundep, or something which allows to find the instance from the
type of the record only, is required to make this practical. A type
which includes Has_field r a in its context, and includes r but not a
in its body, is legal.
For non-polymorphic fields it works great. But parens cause trouble:
instance Has_parens TokenParser (Parser a -> Parser a)
This instance is illegal because of the fundep. What it should mean is:
instance Has_parens TokenParser (forall a. Parser a -> Parser a)
but this is not possible either.
With keys instead of fundeps it works! The first instance is OK.
The record type is specified to be a key in all Has_field classes,
meaning that the record type alone is sufficient to determine which
instance of a field getter to use.
It is not always sufficient to determine the exact type of the field,
but this is not needed. For example here many types are good because
the instance is polymorphic wrt. a type variable used in the field's
type.
I want keys instead of fundeps! :-)
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From qrczak@knm.org.pl Tue Jan 9 18:37:03 2001
Date: 9 Jan 2001 18:37:03 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Defaults in datatype definitions
Tue, 9 Jan 2001 09:46:31 +0100 (MET), Johannes Waldmann <joe@isun.informatik.uni-leipzig.de> pisze:
> 1) I would like to write down default values for record components
My proposal for remaking records ina more flexible way includes this.
> 2) With classes, we can do even more: in the default method,
> we can access other methods.
And this too.
> 3) I want to be able, in modules that use the type,
> to add more components (with defaults) to the type:
>
> This would avoid lengthy recomputations (at the cost of additional space).
> Imagine the difference between
>
> data Tree a = Node { key :: a, children :: [ Tree a ] }
> size t = 1 + sum (map size (children t))
>
> and
>
> data Tree a = Node { key :: a, children :: [ Tree a ]
> , size :: Integer
> , size = \ self -> 1 + sum (map size (children self)) }
>
> when you have one large tree and frequently need sizes of subtrees.
And this too, but it's a bit tricky because a field changes the
type covariantly.
data Tree a = record
key :: a
children :: [Tree a]
children = []
-- A function working on a tree must be prepared for extensions.
-- The following function does not actually refer to the above type,
-- but can be used on Tree Int.
isInTree:: (Eq a, tree.key :: a, tree.children :: [tree])
=> a -> tree -> Bool
isInTree a tree = a == tree.key || any (isInTree a) tree.children
-- Trees extended by size cache. The type below does not refer to
-- the type Tree because the type of children has changed. Otherwise
-- it could include Tree as a field and delegate key and children to
-- this field instead of defining them itself. Well, it could do it,
-- but it would have to store children as SizedTrees somewhere too.
-- I don't know yet if it can be solved more elegantly.
data SizedTree a = record
key :: a
children :: [SizedTree a]
size :: Int
children = []
size = 1 + sum (map (.size) children)
-- Creation of a tree is the same for both kinds. A different kind of
-- context is needed to create a record than to extract its fields.
-- This context includes the context used in isInTree (except Eq a)
-- in its superclasses.
flatTree:: (tree.record {key :: a; children :: [tree]})
=> a -> [a] -> tree
flatTree root leaves = record
key = root
children = [record key = leaf | leaf <- leaves]
I haven't written a complete description of the proposal yet, but
will do it in two weeks. I posted basic info here some time ago.
Some details changed since then.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From msk@post.tepkom.ru Tue Jan 9 21:10:46 2001
Date: Wed, 10 Jan 2001 00:10:46 +0300 (MSK)
From: Anton Moscal msk@post.tepkom.ru
Subject: Just for fun
Hello!
This is well-known definition of the existential quantification through
universal:
(E x.P(x)) <=> A y.(A x.P (x) => y) => y
I try to translate in to Haskell. The following program can be compiled
by "ghc -fglasgow-exts ..." and works correctly:
----------------------------------------
import Char
type E a = forall t . (forall x . a x -> t) -> t
newtype Pair a b = MkPair (b, (b -> a))
newtype App a = MkApp (E (Pair a))
mk_app :: (a -> b) -> a -> App b
mk_app f v = MkApp (\g -> g (MkPair (v, f)))
app_s = mk_app Char.ord '1'
app_id = mk_app (\x->x) 239
eval :: App a -> a
eval (MkApp g) = g (\(MkPair (x, f)) -> f x)
main = print (map eval [mk_app (\x->x) 239, mk_app Char.ord '1'])
---------------------------------------
Regards,
Anton Moscal
From Tom.Pledger@peace.com Tue Jan 9 22:40:17 2001
Date: Wed, 10 Jan 2001 11:40:17 +1300
From: Tom Pledger Tom.Pledger@peace.com
Subject: Just for fun
Anton Moscal writes:
> Hello!
>
> This is well-known definition of the existential quantification
> through universal:
>
> (E x.P(x)) <=> A y.(A x.P (x) => y) => y
>
> I try to translate in to Haskell. The following program can be
> compiled by "ghc -fglasgow-exts ..." and works correctly:
>
[...]
> main = print (map eval [mk_app (\x->x) 239, mk_app Char.ord '1'])
import Char(ord)
main = print (tail [error "I'm too lazy to be explicitly existential.",
(\x->x) 239,
ord '1'])
{- Regards, Tom :-}
From qrczak@knm.org.pl Tue Jan 9 23:10:40 2001
Date: 9 Jan 2001 23:10:40 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Haskell 98 (Library) Report: contradiction about fail :: String -> IO a
The Haskell 98 Report says that fail in instance Monad IO invokes error.
The Library Report says that fail in instance Monad IO raises a user error.
I would let it raise a user error, to be able to use fail in exception
monads where strings suffice as the error type.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From ketil@ii.uib.no Wed Jan 10 07:36:03 2001
Date: 10 Jan 2001 08:36:03 +0100
From: Ketil Malde ketil@ii.uib.no
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Brook Conner <nellardo@concentric.net> writes:
> Do you think the cookbook would be better as its own book?
Perhaps it could? I think it's a natural component in a "nutshell"
book, but it seems clear that there's tons of example programs that
would be immensely useful as well-documented howtos.
[Cool graphics hacks]
> I figured those kinds of examples showed off the power of Haskell.
Sounds good to me.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From msk@post.tepkom.ru Wed Jan 10 09:58:36 2001
Date: Wed, 10 Jan 2001 12:58:36 +0300 (MSK)
From: Anton Moscal msk@post.tepkom.ru
Subject: About fundeps
Hello!
When I apply hugs to the following program:
import Char (ord) class Conv a b | a -> b where conv:: a -> b
instance Conv Char Int where conv = ord
instance (Conv a b, Conv b c) => Conv a c where conv = conv . conv
Hugs reports:
ERROR "fdep.hs" (line 4): Instances are not consistent with dependencies
*** This instance : Conv a b
*** Conflicts with : Conv Char Int
*** For class : Conv a b
*** Under dependency : a -> b
But why?
Regards,
Anton Moscal
From lennart@mail.augustsson.net Wed Jan 10 10:03:26 2001
Date: Wed, 10 Jan 2001 05:03:26 -0500
From: Lennart Augustsson lennart@mail.augustsson.net
Subject: About fundeps
Anton Moscal wrote:
> Hello!
>
> When I apply hugs to the following program:
>
> import Char (ord) class Conv a b | a -> b where conv:: a -> b
> instance Conv Char Int where conv = ord
> instance (Conv a b, Conv b c) => Conv a c where conv = conv . conv
>
> Hugs reports:
>
> ERROR "fdep.hs" (line 4): Instances are not consistent with dependencies
> *** This instance : Conv a b
> *** Conflicts with : Conv Char Int
> *** For class : Conv a b
> *** Under dependency : a -> b
>
> But why?
Because they aren't.
Assume you have
> instance Char Int
and also
> instance Int Float
According to your second instance declaration you now also have
> instance Char Float
But the functional dependency states that the first parameter uniquely
determines the second and now there are two conflicting instances
for Char.
-- Lennart
From kris@CoLi.Uni-SB.DE Mon Jan 8 08:13:04 2001
Date: Mon, 8 Jan 2001 09:13:04 +0100 (MET)
From: Kristina Striegnitz kris@CoLi.Uni-SB.DE
Subject: 2nd CfP: ESSLLI 01 Student Session
!!! Concerns all students in Logic, Linguistics and Computer Science !!!=20
!!! Please circulate and post among students !!!
We apologize, if you receive this message more than once.
ESSLLI 2001 STUDENT SESSION
SECOND CALL FOR PAPERS
August 13-24 2001, Helsinki, Finland
Deadline: February 18, 2001
http://www.coli.uni-sb.de/~kris/esslli
We are pleased to announce the Student Session of the 13th European
Summer School in Logic, Language and Information (ESSLLI 2001)
organized by the University of Helsinki under the auspices of the
European Association for Logic, Language and Information
(FoLLI). ESSLLI 2001 will be held at the University of Helsinki in
August 2001. We invite submission of papers for presentation at the
ESSLLI 2001 Student Session and for appearance in the proceedings.
PURPOSE:
This sixth ESSLLI Student Session will provide, like the other
editions, an opportunity for ESSLLI participants who are students to
present their own work in progress and get feedback from senior
researchers and fellow-students. The ESSLLI Student Session
encourages submissions from students at any level, from undergraduates
(before completion of the Master Thesis) as well as postgraduates
(before completion of the PhD degree). Papers co-authored by
non-students will not be accepted. Papers may be accepted for full
presentation (30 minutes including 10 minutes of discussion) or for a
poster presentation. The accepted papers will be published in the
ESSLLI 2001 Student Session proceedings, which will be made available
during the summer school.
KLUWER BEST PAPER AWARD:=20
As in previous years, the best paper will be selected by the program
committee and will be offered a prize by Kluwer Academic Publishers
consisting in 1000 Dfl worth of books.
REQUIREMENTS:=20
The Student Session papers should describe original, unpublished work,
completed or in progress that demonstrates insight, creativity, and
promise. No previously published papers should be submitted. All
topics within the six ESSLLI subject areas (Logic, Language,
Computation, Logic & Language, Logic & Computation, Language &
Computation) are of interest.
FORMAT OF SUBMISSION:
Student authors should submit an anonymous extended abstract headed by
the paper title, not to exceed 5 pages in length exclusive of
references and send a separate identification page (see below). Note
that the length of the full papers will not be allowed to exceed 10
pages. Since reviewing will be blind, the body of the abstract should
omit author names and addresses. Furthermore, self-references that
reveal the author's identity (e.g., "We previously showed (Smith,
1991)... ") should be avoided. It is possible to use instead
references like "Smith (1991) previously showed...". For any
submission, a plain ASCII text version of the identification page
should be sent separately, using the following format:
Title: title of the submission=20
First author: firstname lastname
Address: address of the first author=20
=2E.....=20
Last author: firstname lastname=20
Address: address of the last author=20
Short summary: abstract (5 lines)=20
Subject area (one of): Logic | Language | Computation | Logic and
Language | Logic and Computation | Language and Computation
If necessary, the program committee may reassign papers to a more
appropriate subject area. The submission of the extended abstract
should be in one of the following formats: PostScript, PDF, RTF, or
plain text. But note that, in case of acceptance, the final version of
the paper has to be submitted in LaTeX format. Please, use A4 size
pages, 11pt or 12pt fonts, and standard margins. Submissions outside
the specified length and formatting requirements may be subject to
rejection without review.
The extended abstract and separate identification page must be sent by
e-mail to:
kris@coli.uni-sb.de by FEBRUARY 18, 2001
ESSLLI 2001 INFORMATION:=20
In order to present a paper at ESSLLI 2001 Student Session, at least
one student author of each accepted paper has to register as a
participant at ESSLLI 2001. The authors of accepted papers will be
eligible for reduced registration fees. For all information concerning
ESSLLI 2001, please consult the ESSLLI 2001 web site at
http://www.helsinki.fi/esslli.=20
IMPORTANT DATES:
Deadline for submission of abstracts: February 18, 2001.
Authors Notifications: April 17, 2001.
Final version due: May 18, 2001.=20
ESSLLI-2001 Student Session: August 13-24, 2001.=20
PROGRAM COMMITTEE:
Raffaella Bernardi, University of Utrecht (Logic & Language)
Patrick Blackburn, Loria Nancy (Logic & Language)
Gilles Dowek, INRIA (Computation)
Ruth Kempson, King`s College London (Language)
Carsten Lutz, University of Aachen (Logic & Computation)
Ani Nenkova, Columbia University (Logic)
Ilkka Niemel=E4, Helsinki University of Technology (Logic & Computation)
Malvina Nissim, University of Pavia (Language)
Susanne Salmon-Alt, Loria, Nancy (Language & Computation)
Jan Schwinghammer, University of the Saarland (Computation)
Kristina Striegnitz, University of the Saarland (Chair)
Yde Venema, University of Amsterdam (Logic)
Shuly Wintner, University of Haifa (Language & Computation)
For any question concerning the ESSLLI 2001 Student Session, please,
do not hesitate to contact me:=20
Kristina Striegnitz
Computational Linguistics, University of the Saarland, Germany
phone: +49 - 681 - 302 4503 email: kris@coli.uni-sb.de
From russell@brainlink.com Wed Jan 10 15:48:29 2001
Date: Wed, 10 Jan 2001 10:48:29 -0500
From: Benjamin L. Russell russell@brainlink.com
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
On Tue, 9 Jan 2001 09:00:27 +0100 (MET)
Johannes Waldmann <joe@isun.informatik.uni-leipzig.de> wrote:
>
> [snip]
>
> This could be driven to the extreme: not only hide the
> word "monad",
> but also "functional". The title would be "Imperative
> programming in Haskell"
> (as S. Peyton Jones says in Tackling the Awkward Squad:
> "Haskell is the world's finest imperative programming
> language").
Couldn't this choice potentially backfire, though? For example, many people choose Java over C because they prefer OO to straight imperative programming, which they see at The Old Way.
If I went to a bookstore and saw one book entitled, "Imperative Programming in Haskell," and another entitled, "OO Programming in Java," I wouldn't buy the Haskell book, especially if had already had a bad experience with imperative programming in C.
How about, "The Post-OO Age: Haskell: Back to the Future in Imperative Programming"?
--Ben
--
Benjamin L. Russell
russell@brainlink.com
benjamin.russell.es.94@aya.yale.edu
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
From Krprtn@aol.com Wed Jan 10 19:52:08 2001
Date: Wed, 10 Jan 2001 14:52:08 EST
From: Krprtn@aol.com Krprtn@aol.com
Subject: Hugs
--part1_50.fdb0f92.278e1768_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
I've currently installed Hugs on my PC, could you tell me how I can configure
Hugs to use an editor. The editor I have got installed on my computer is
winedt.
--part1_50.fdb0f92.278e1768_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
<HTML><FONT FACE=arial,helvetica><FONT SIZE=2>I've currently installed Hugs on my PC, could you tell me how I can configure <BR>Hugs to use an editor. The editor I have got installed on my computer is <BR>winedt. </FONT></HTML>
--part1_50.fdb0f92.278e1768_boundary--
From trinder@cee.hw.ac.uk Thu Jan 11 13:58:11 2001
Date: Thu, 11 Jan 2001 13:58:11 +0000 (GMT Standard Time)
From: Phil Trinder trinder@cee.hw.ac.uk
Subject: Haskell PhD Scholarship
Folks,
Are you planning to do a PhD and interested in parallel or distributed versions
of Haskell? There's a PhD scholarship available at Heriot-Watt University,
Edinburgh, Scotland. To win the scholarship you'll need to have, or get, a
first-class degree and have excellent references.
The group at Heriot-Watt have implemented and used parallel versions of Haskell
and ML, and a distributed Haskell. We're part of a vibrant functional
programming community in the central belt of Scotland. More information on who
we are and what we do is available at
http://www.cee.hw.ac.uk/~trinder/projects.html
http://www.cee.hw.ac.uk/~trinder/
http://www.cee.hw.ac.uk/~dsg/
If you're interested in applying for the scholarship please contact me.
Phil
--------------------------------------------------
Phil Trinder
Department of Computing and Electrical Engineering
Heriot Watt University
Riccarton
Edinburgh, EH14 4AS
E-mail: trinder@cee.hw.ac.uk
Teleph: +44 (0)131 451 3435
Depart: +44 (0)131 451 3328
Fasmly: +44 (0)131 451 3327
Intrnt: http://www.cee.hw.ac.uk/~trinder
From Krprtn@aol.com Thu Jan 11 18:33:27 2001
Date: Thu, 11 Jan 2001 13:33:27 EST
From: Krprtn@aol.com Krprtn@aol.com
Subject: Hugs
--part1_fe.d460b4.278f5677_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
I tried sending this message to the hugs email address but it kept being sent
back!
I have installed Hugs on my PC, could you please tell me how I can configure
Hugs to use winedt (editor). I have alreadly tried using the hugs user manual
(section 4). Also is it a problem if I use the latest version of winedt with
hugs 98. thankyou
--part1_fe.d460b4.278f5677_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
<HTML><FONT FACE=arial,helvetica><FONT SIZE=2>I tried sending this message to the hugs email address but it kept being sent <BR>back!
<BR>I have installed Hugs on my PC, could you please tell me how I can configure <BR>Hugs to use winedt (editor). I have alreadly tried using the hugs user manual <BR>(section 4). Also is it a problem if I use the latest version of winedt with <BR>hugs 98. thankyou</FONT></HTML>
--part1_fe.d460b4.278f5677_boundary--
From Dominic.J.Steinitz@BritishAirways.com Fri Jan 12 08:41:37 2001
Date: 12 Jan 2001 08:41:37 Z
From: Steinitz, Dominic J Dominic.J.Steinitz@BritishAirways.com
Subject: Hash Functions
I was thinking of using MD5 or SHA-1 for an application. Is there a Haskell library that contains these or other hash algorithms that have a very low probability of giving clashes?
Dominic.
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From simonpj@microsoft.com Fri Jan 12 09:31:22 2001
Date: Fri, 12 Jan 2001 01:31:22 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Haskell 98 (Library) Report: contradiction about fail :: Stri
ng -> IO a
Marcin writes:
| The Haskell 98 Report says that fail in instance Monad IO invokes error.
| The Library Report says that fail in instance Monad IO raises a user
error.
|
| I would let it raise a user error, to be able to use fail in exception
| monads where strings suffice as the error type.
He's right. The instance declaration in the Prelude (p101) should say
instance Monad IO where
...
fail s = ioError (userError s)
This was always intended (see Library report p55, 11.1).
Other clarifications should be
* Index the reference to userError in Sec 7.3 of the Report
and give a type signature for userError
* In that same section, specify that fail s = ioError (userError s)
I'll do these as part of the (long-postponed) H98 report revision.
Any objections? I don't think this is controversial. Implementors take
note,
though.
Simon
From Dominic.J.Steinitz@BritishAirways.com Mon Jan 15 09:08:13 2001
Date: 15 Jan 2001 09:08:13 Z
From: Steinitz, Dominic J Dominic.J.Steinitz@BritishAirways.com
Subject: Too Strict?
Can someone help? The program below works fine with small files but when I try to use it on the one I need to (about 3 million lines of data) it produces no output. The hard disk is hammered - I assume this is the run time system paging. My suspicion is that the program is trying to read in the whole file before processing it. Is this correct? If so, how do I make the program lazy so that it processes a line at time?
By the way, the MD5 function which I use and is included as part of HSLIBS has the type String -> IO String. The MD5 algorithm really is a function and should have type String -> String. Do people agree and if so how do I get it changed?
Dominic.
-- Compile with ghc -o test test.hs -static -package util
-- under Windows.
module Main(main) where
import IO(openFile,
hPutStr,
IOMode(ReadMode,WriteMode,AppendMode))
import MD5
import Char
-- showHex and showHex' convert the hashed values to
-- human-readable hexadecimal strings.
showHex :: Integer -> String
showHex =
map hexDigit .
map (fromInteger . (\x -> mod x 16)) .
takeWhile (/=0) .
iterate (\x -> div x 16) .
toInteger
hexDigit x
| (0 <= x) && (x <= 9) = chr(ord '0' + x)
| (10 <= x) && (x <=16) = chr(ord 'a' + (x-10))
| otherwise = error "Outside hexadecimal range"
powersOf256 = 1 : map (*256) powersOf256
showHex' x =
showHex $
sum (zipWith (*)
(map ((\x -> (mod x 16)*16 + (div x 16)) .
toInteger .
ord) x)
powersOf256)
-- The type Anon and function anonymize hide the anonymisation
-- process. In this case, it's a hash function
-- digest :: String -> IO String which implements MD5.
type Anon a = IO a
class Anonymizable a where
anonymize :: a -> Anon a
-- MyString avoids overlapping instances of Strings
-- with the [Char]
data MyString = MyString String
deriving Show
instance Anonymizable MyString where
anonymize (MyString x)
= do s <- digest x
return ((MyString . showHex') s)
instance Anonymizable a => Anonymizable [a] where
anonymize xs = mapM anonymize xs
filename = "ldif1.txt"
fileout = "ldif.out"
readAndWriteAttrVals =
do h <- openFile fileout WriteMode
s <- readFile filename
a <- anonymize((map MyString) (lines s))
hPutStr h (unlines (map (\(MyString x) -> x) a))
main = readAndWriteAttrVals
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From matt@CadMOS.COM Fri Jan 12 22:10:07 2001
Date: Fri, 12 Jan 2001 14:10:07 -0800
From: Matthew Liberty matt@CadMOS.COM
Subject: gui building in haskell
This is a multi-part message in MIME format.
--------------863106FFDA2059FB84119F6B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Greetings,
I've been looking at http://www.haskell.org/libraries/#guis and trying
to figure out which package is "best" for building a gui. Can anyone
give a comparison of the strengths/weaknesses of these packages (or any
others)?
thanks
-Matt
--------------863106FFDA2059FB84119F6B
Content-Type: text/x-vcard; charset=us-ascii;
name="matt.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Matthew Liberty
Content-Disposition: attachment;
filename="matt.vcf"
begin:vcard
n:Liberty;Matthew
tel;fax:408-795-1210
tel;work:408-795-1212 x514
x-mozilla-html:FALSE
url:http://www.cadmos.com
version:2.1
email;internet:matt@CadMOS.com
title:Software Architect
adr;quoted-printable:;;111 North Market Street=0D=0ASuite 440;San Jose;CA;95113-1117;USA
x-mozilla-cpt:;0
fn:Matthew Liberty
end:vcard
--------------863106FFDA2059FB84119F6B--
From mpj@cse.ogi.edu Mon Jan 15 10:01:27 2001
Date: Mon, 15 Jan 2001 02:01:27 -0800
From: Mark P Jones mpj@cse.ogi.edu
Subject: Yet more on functional dependencies
| I am finding functional dependencies confusing. (I suspect I am=20
| not alone.) Should the following code work?
|=20
| class HasConverter a b | a -> b where
| convert :: a -> b
|=20
| instance (HasConverter a b,Show b) =3D> Show a where
| show value =3D show (convert value)
It's a separate issue. There's no reason why a system using
functional dependencies *should* support this. But it is an
attractive and useful extension that such a system would
probably *want* to include. (i.e., it's a desirable feature,
not a requirement.)
I typed your example into Hugs on my machine and it seemed to
accept the syntax (which suggests that the implementation is
intended to allow this kind of thing). But then it choked on
the definition with a curious error message that I suspect is
an indication of a bug in Hugs' treatment of functional
dependencies. And, for that reason, I'm crossposting this
message to hugs-bugs. [Let me take the opportunity to remind
good readers of these lists that it is now more than a year
since I retired from the joys of maintaining Hugs, so I'm not
planning to try and track down the source of this bug myself!]
Of course, it could be that my version of Hugs is out of date!
All the best,
Mark
From mpj@cse.ogi.edu Mon Jan 15 10:01:18 2001
Date: Mon, 15 Jan 2001 02:01:18 -0800
From: Mark P Jones mpj@cse.ogi.edu
Subject: Are fundeps the right model at all?
| Now I have a practical example where fundeps don't work and keys
| would work - but the type variable is later instantiated.
| ...
| Each record field in my proposal induces a class:
| class Has_field r a | r -> a where
| get_field :: r -> a
|=20
| The fundep, or something which allows to find the instance from the
| type of the record only, is required to make this practical. A type
| which includes Has_field r a in its context, and includes r but not a
| in its body, is legal.
|=20
| For non-polymorphic fields it works great. But parens cause trouble:
| instance Has_parens TokenParser (Parser a -> Parser a)
| This instance is illegal because of the fundep. What it should mean =
is:
| instance Has_parens TokenParser (forall a. Parser a -> Parser a)
| but this is not possible either.
Let's explore the design space a little more carefully. There's a wide
spectrum of options, and it's not yet entirely clear which one Marcin is
referring to by "keys". Perhaps it will be one of the entries on the
following list:
0) "Standard multiple parameter classes": A class constraint Has_parens =
r a
does not imply any connection between the different parameters, and a
type like Has_parens r a =3D> r is ambiguous. This kind of class has =
its
uses, but also tends to lead to ambiguity problems. It doesn't =
address
Marcin's needs.
1) "A weaker notion of ambiguity" (title of Section 5.8.3 in my =
dissertation,
which is where I think the following idea originated): We can modify =
the
definition of ambiguity for certain kinds of class constraint by =
considering
(for example) only certain subsets of parameters. In this setting, a =
type
P =3D> t is ambiguous if and only if there is a variable in AV(P) =
that is not
in t. The AV function returns the set of potentially ambiguous =
variables in
the predicates P. It is defined so that AV(Eq t) =3D TV(t), but also =
can
accommodate things like AV(Has_field r a) =3D TV(r). A semantic =
justification
for the definition of AV(...) is needed in cases where only some =
parameters
are used; this is straightforward in the case of Has_field-like =
classes.
Note that, in this setting, the only thing that changes is the =
definition
of an ambiguous type.
A similar weakening of the notion of ambiguity is permitted by each =
of the
following points in the design space.
2) "Partial dependencies": At this point in the spectrum, we allow the =
values
of one or more class parameters to specify something about the shape =
of the
values of the other parameters, without uniquely determining them. =
This is
perhaps closest to what Marcin is asking for in the text included =
above.
For his example, a partial dependency might ensure that the type t in =
any
constraint of the form Has_parens TokenParser t is of the form
Parser a -> Parser a for *some* a, which may be chosen in different =
ways
at each use. My old work on improvement provides a theoretical =
foundation
for this. And, in fact, an unimplemented proposal for supporting =
this kind
of extension is included in the source code for Hugs (subst.c), =
predating
functional dependencies by several years. With the syntax used =
there, the
improvement would be specified as follows:
instance Has_parens TokenParser (Parser a -> Parser a)
improves Has_parens TokenParser b where ...
The idea here is to use improvement at the level of individual =
instances,
whereas functional dependencies use improvement at the level of whole
classes. Given a declaration instance P =3D> p where ... we expect =
the
instance to be used for any constraint that matches p. If an =
improves
clause is specified, possibly with multiple predicates, as in:
instance P =3D> p improves p1, ..., pn where ...
then we expect p to be a substitution instance of each of p1, ..., =
pn,
and we expect the instance to apply to any constraint that matches =
one
(or more) of p1, ..., pn, with an appropriate improving substitution
applied to bring it into line with p.
3) "Underspecified/Inferred Functional Dependencies": Here, we insist =
that
the values of certain parameters in a constraint are *uniquely* =
determined
by the values of other parameters ... but we allow the values of the
determined types to be inferred rather than declared explicitly. For
example, one might write:
instance C Int b where ...
and then leave type inference to figure out that the value for b in =
this
particular instance must actually be Bool (say). I don't know =
whether
anyone has seriously explored this point in the design space, in =
particular
to determine conditions under which we can be sure that missing =
parameters
can be inferred, or to come up with a good, clean syntax. The whole =
idea
may seem a bit odd, but it is in line with proposals circulating a =
couple
of weeks ago by folks who want to allow declared types like
forall b. C Int b =3D> b -> Bool
in situations where they knew that the only possible instantiation =
for b was
some fixed type like Int (say).
4) "Functional Dependencies": As described in my ESOP 00 paper (the =
Hugs
manual, and the HTML note on my web page, don't tell the whole =
story).
This allows a programmer to indicate that, like (3), some of the
parameters in a constraint will be *uniquely* determined by other
parameters. Unlike (3), the assumption in the ESOP paper, and in
current implementations, is that these uniquely determined types will
be mentioned explicitly in each instance declaration. With =
functional
dependencies, inferred constraint sets can be improved in ways that =
are
(a) important in practice, and (b) not possible in any of the options
mentioned previously. For example, given class Collects c e | c -> =
e,
we can simplify (Collects c e, Collects c f) =3D> e -> f -> c -> c =
to
(Collects c e) =3D> e -> e -> c -> c.
[Aside: Marcin's specific problem with Has_parens could be dealt with =
in
this framework also, but that would probably require the introduction =
of
a newtype like:
newtype PP =3D forall a. PP (Parser a -> Parser a)
instance Has_parens TokenParser PP where ...
This, of course, would require extra games with the PP constructor =
(and
an appropriately defined inverse) in expressions, which would =
probably
be too messy and awkward in practice; a record system designed to =
support
polymorphic fields from the outset would be a better solution here.]
5) And so on. There are other alternatives ...
| I want keys instead of fundeps! :-)
I've found it hard to assess or make sense of your descriptions of keys =
in
previous postings; at different times it has seemed as though keys could =
be
any of options 1, 2, 3, 4, or 5 in the above. But I hope that my =
analysis
of the design space above is helping us to reach a better shared =
understanding
of exactly what you are proposing. In terms of what I've written above, =
my
current guess at interpreting your proposal goes something like this:
- You want to allow each class declaration to be annotated with zero or =
more
subsets of the parameters, each of which you refer to as a "key" for =
the
class.
- When a user writes an instance declaration:
instance P =3D> C t1 ... tn where ...
you treat it, in the notation of (2) above, as if they'd written:
instance P =3D> C t1 ... tn=20
improves C t11 ... t1n, ..., C tm1 ... tmn where ...
Here, m is the number of keys, and: tij =3D ti, if parameter i is =
in key j
=3D ai, otherwise
where a1, ..., an are distinct new variables.
If this is correct, then it seems to me that:
- Keys will provide a more concise, but less expressive notation than =
(2).
The notation of (2) is considerably more expressive because it isn't
limited to the form used in the translation above, and because it can
be used on an instance by instance basis rather than a specification =
that
applies uniformly to all instances of a class. It's hard to know what =
the
tradeoffs will be in practice, but I'm inclined to believe that keys =
are
too limited, and the more general mechanism will not be too cumbersome =
in
many practical cases.
- Keys will not give you the full functionality of functional =
dependencies,
and that missing functionality is important in some cases.
All the best,
Mark
PS. If we're going to continue this discussion any further, let's take =
it
over into the haskell-cafe ...
From Tom.Pledger@peace.com Mon Jan 15 00:05:58 2001
Date: Mon, 15 Jan 2001 13:05:58 +1300
From: Tom Pledger Tom.Pledger@peace.com
Subject: Are fundeps the right model at all?
Marcin 'Qrczak' Kowalczyk writes:
> Mon, 8 Jan 2001 17:53:35 +1300, Tom Pledger <Tom.Pledger@peace.com> pisze:
>
> > > Having types with type variables which are never instantiated nor
> > > constrained should be equivalent to having ground types!
> >
> > Do you have any examples of such a type variable in an instance decl?
>
> Now I have a practical example where fundeps don't work and keys
> would work - but the type variable is later instantiated.
>
> Let's take Parsec from ghc's libraries which includes the following
> (this is cut down):
>
> data TokenParser = TokenParser {
> identifier :: Parser String,
> reserved :: String -> Parser (),
> operator :: Parser String,
> reservedOp :: String -> Parser (),
> parens :: forall a. Parser a -> Parser a}
>
> makeTokenParser:: LanguageDef -> TokenParser
>
> I would like to express this "first-class module" in my records
> proposal, to make it extensible (there can be different types similar
> to TokenParser with similar fields and used polymorphically together
> with TokenParser).
>
> Each record field in my proposal induces a class:
> class Has_field r a | r -> a where
> get_field :: r -> a
>
> The fundep, or something which allows to find the instance from the
> type of the record only, is required to make this practical. A type
> which includes Has_field r a in its context, and includes r but not a
> in its body, is legal.
>
> For non-polymorphic fields it works great. But parens cause trouble:
> instance Has_parens TokenParser (Parser a -> Parser a)
> This instance is illegal because of the fundep. What it should mean is:
> instance Has_parens TokenParser (forall a. Parser a -> Parser a)
> but this is not possible either.
[...]
Hallo again.
The second instance decl expresses the situation better, because it's
faithful to the rank-2 polymorphism in TokenParser, i.e. the
requirement that the TokenParser constructor's 5th argument have a
type at *least* as general as forall a. Parser a -> Parser a. The first instance decl
Should we be able to put a local forall in an instance decl?
I suspect that we shouldn't in general, because it would cause leaks
in the rank-2 polymorphism restrictions. For example:
module MA where
class C a where f :: () -> a -> ()
module MB where
import MA
f' :: C a => a -> ()
f' = f ()
module MC where
import MA
instance C (forall a. a -> a) where f z g = if g True then g () else z
If any other module imports both MB and MC, the partial application of
f in MB will break the "maximal function application subexpressions
must include arguments for all rank-2 polymorphic parameters"
restriction. (I don't actually know the purpose of this restriction
and its friends, but I'm sure there's a good reason for them.)
Trex avoids the question of field types in contexts, by using a Lacks
context which only mentions the row type and the label. Is the
combination of Trex and newtype worth another look? This sort of
thing:
newtype T1 a = T1 {unT1 :: Rec (foo :: a)}
newtype T2 a = T2 {unT2 :: Rec (foo :: a, bar :: a)}
Regards,
Tom
From ess_lli@cc.helsinki.fi Fri Jan 12 15:41:34 2001
Date: Fri, 12 Jan 2001 17:41:34 +0200 (EET)
From: Ahti Pietarinen ess_lli@cc.helsinki.fi
Subject: FORMAL GRAMMAR/MATHEMATICS OF LANGUAGE'01
[apologies if you receive this more than once]
FGMOL'01 FGMOL'01 FGMOL'01 FGMOL'01 FGMOL'01 FGMOL'01 FGMOL'01 FGMOL'01
FORMAL GRAMMAR/MATHEMATICS OF LANGUAGE CONFERENCE
August 10--12, 2001
Helsinki, Finland
FIRST CALL FOR PAPERS
We are pleased to announce the joint meeting of two conferences:
the sixth conferene on Formal Grammar and the seventh on the
Mathematics of Language. The joint meeting will be held just prior
to the European Summer School in Logic, Language, and Information.
AIMS and SCOPE
especially with regard to the application of formal methods to natural
language analysis.
Themes of interest include, but are not limited to,
* formal and computational syntax, semantics, pragmatics, and phonology;
* model-theoretic and proof-theoretic methods in linguistics;
* constraint-based and resource-sensitive approaches to grammar;
* foundational, methodological and architectural issues in grammar.
* mathematical properties of linguistic frameworks
* theories and models of natural language processing and generation
* parsing theory
* statistical and quantitative models of language
INVITED SPEAKERS will be announced with the circulation
of the second call for papers in early February
SUBMISSION DETAILS
We invite E-MAIL submissions of abstracts for 30-minute papers (including
questions, comments, and discussion).
A submission should consist of two parts:
- an information sheet (in ascii), containing the name of the author(s),
affiliation(s), e-mail and postal address(es) and a title;
- an abstract, consisting of a description of not more than 5 pages
(including figures and references). Abstracts may be either in plain
ASCII or in (unix-compatible encoded) postscript, PDF, or DVI.
Abstracts can be sent to
fgmol@cs.indiana.edu
ABSTRACT SUBMISSION DEADLINE
April 1, 2001
NOTIFICATION OF ACCEPTANCE
May 15, 2001
PROCEEDINGS
A full version of each accepted paper will be included in the conference
proceedings, to be distributed at the conference. Full papers are due
June 30, 2001.
PROGRAMME COMMITTEE
Anne Abeill'e (Paris)
Patrick Blackburn (INRIA)
Gosse Bouma (Groningen)
Mary Dalrymple (Xerox Parc)
Nissim Francez (Haifa)
Thilo Goetz (IBM)
David Johnson (IBM)
Mark Johnson (Brown)
Aravind Joshi (UPenn)
Gerhard J"ager (Utrecht)
Ruth Kempson (London)
Alain Lecomte (LORIA)
Uwe Moennich (T"ubingen)
Glyn Morrill (U.P. Catalunya)
Michael Moortgat (Utrecht)
Owen Rambow (Cogentex)
James Rogers (Earlham)
Giorgio Satta (Padova)
Mark Steedman (Edinburgh)
FURTHER INFORMATION
Web site for ESSLLI XIII: http://www.helsinki.fi/esslli/
Web site for FGMOL'01 :http://www.cis.upenn.edu/~ircs/mol/mol7.html
The organizers:
Geert-Jan Kruijff gj@cogsci.ed.ac.uk
Larry Moss lsm@cs.indiana.edu
Dick Oehrle oehrle@linc.cis.upenn.edu
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%[LaTeX2E Source File]%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{article}
\usepackage{tabularx}
\setlength{\textwidth}{7in}
\setlength{\oddsidemargin}{-.5in}
\setlength{\topmargin}{-36pt}
\pagestyle{empty}
\begin{document}
\begin{center}
{\em Please Post}\\[.1cm]
{\large{\bf Formal Grammar / Mathematics of Language Conference ---
FGMOL'01\\
CALL FOR PAPERS}}\\
{August 10--12, 2001}\qquad Helsinki\\
\end{center}
\begin{center}
\begin{tabular}{@{}p{.27\textwidth}|p{.70\textwidth}@{}}
%\small\ixpt\setlength{\baselineskip}{9pt}
\footnotesize
\begin{flushleft}
{\bf Programme Committee}
\end{flushleft}
\begin{tabular}{l@{}}
Anne Abeill\'{e} (Paris) \\
Patrick Blackburn (INRIA) \\
Gosse Bouma (Groningen) \\
Mary Dalrymple (Xerox Parc) \\
Nissim Francez (Haifa)\\
Thilo Goetz (IBM)\\
David Johnson (IBM) \\
Mark Johnson (Brown)\\
Aravind Joshi (UPenn)\\
Gerhard J\"{a}ger (Utrecht)\\
Ruth Kempson (London)\\
Alain Lecomte (LORIA)\\
Uwe M\"{o}nnich (T\"{u}bingen)\\
Glyn Morrill (U.P. Catalunya) \\
Michael Moortgat (Utrecht) \\
Owen Rambow (Cogentex)\\
James Rogers (Earlham) \\
Giorgio Satta (Padova) \\
Mark Steedman (Edinburgh)\\
[12pt]
{\bf Organizing Committee}\\
Geert-Jan Kruijff (Prague)\\
Larry Moss (Indiana)\\
Richard Oehrle (Ashford)
\end{tabular}
\medskip
{\bf Important Dates}
\smallskip
\begin{tabular}{l@{}}
Abstracts Due: March 31, 2001\\
Notification: May 15, 2001\\
Final Versions: June 30, 2001\\
Conference: August 10-12, 2001\\
\end{tabular}
\medskip
{\bf Addresses:\quad}
\smallskip
\begin{tabular}{l@{}}
ESSLLI XIII: \\
\texttt{http://www.helsinki.fi/esslli}\\
FGMOL'01:\\
\texttt{http://www.cis.upenn.edu/\ldots}\\
$\quad$ \texttt{\ldots $^{\sim}$ircs/mol/mol7.html}
\end{tabular}
&
\setlength{\parskip}{2pt}
We are pleased to announce the joint meeting of two conferences:
the sixth conferene on Formal Grammar and the seventh on the
Mathematics of Language. The joint meeting will be held just prior
to the European Summer School in Logic, Language, and Information.
\medskip
{\it Aims And Scope} FGMOL'01 provides a forum for the presentation of new
and
original research on formal grammar and mathematical aspects of language,
especially with regard to the application of formal methods to natural
language
analysis. Themes of interest include, but are not limited to,
\begin{itemize}
\setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}
\item formal and computational syntax, semantics, pragmatics, and
phonology;
\item model-theoretic and proof-theoretic methods in linguistics;
\item constraint-based and resource-sensitive approaches to grammar;
\item foundational, methodological and architectural issues in grammar.
\item mathematical properties of linguistic frameworks
\item theories and models of natural language processing and generation
\item parsing theory
\item statistical and quantitative models of language
\end{itemize}
\noindent We welcome papers from
a wide variety of frameworks.
\medskip
{\it Invited Speakers} will be announced with the circulation
of the second call for papers in early February.
\medskip
{\it Submission Details} We invite E-MAIL submissions of abstracts
for 30-minute papers (including questions, comments, and discussion).
A submission should consist of two parts:
\begin{itemize}
\setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}
\item an information sheet (in ascii), containing the name of the
author(s),
affiliation(s), e-mail and postal address(es) and a title;
\item an abstract, consisting of a description of not more than 5 pages
(including figures and references). Abstracts may be either in plain
ASCII or in (unix-compatible encoded) postscript, PDF, or DVI.
\end{itemize}
\noindent Abstracts can be sent to {\tt fgmol@cs.indiana.edu} (Larry
Moss).
\medskip
{\it Abstract Submission Deadline} March 31, 2001
{\it Notification of Acceptance} May 15, 2001
{\it Proceedings} A full version of each accepted paper will be
included in the conference proceedings, to be distributed at the
conference. Full papers are due June 30, 2001.
\end{tabular}
\end{center}
\end{document}
From jans@numeric-quest.com Fri Jan 12 08:41:45 2001
Date: Fri, 12 Jan 2001 03:41:45 -0500 (EST)
From: Jan Skibinski jans@numeric-quest.com
Subject: Hash Functions
On 12 Jan 2001, Steinitz, Dominic J wrote:
> I was thinking of using MD5 or SHA-1 for an application.
> Is there a Haskell library that contains these or other hash algorithms
> that have a very low probability of giving clashes?
>
> Dominic.
http://www.numeric-quest.com/haskell/bridge/index.html
contains interface to MD5 code in C via Greencard. There
is a support for one function only (the only
function I really needed for a certain CGI application)
digest :: String -> String.
It uses 'unsafePerformIO' but you could redesign it
changing its signature to
digest :: String -> String IO
or extend it to supply other functions you need.
Jan
From wli@holomorphy.com Mon Jan 15 00:05:47 2001
Date: Sun, 14 Jan 2001 16:05:47 -0800
From: William Lee Irwin III wli@holomorphy.com
Subject: bootstrapping GHC
I've recently acquired access to SPARC and PPC Linux boxen. GHC 4.04 is
presently bootstrapping on the SPARC, and I was wondering if there were
PPC hc files floating about anywhere, or documentation on how to
generate them.
Thanks,
Bill
From C.Reinke@ukc.ac.uk Mon Jan 15 14:56:46 2001
Date: Mon, 15 Jan 2001 14:56:46 +0000
From: C.Reinke C.Reinke@ukc.ac.uk
Subject: Too Strict?
> Can someone help? The program below works fine with small files but when I
> try to use it on the one I need to (about 3 million lines of data) it
> produces no output. The hard disk is hammered - I assume this is the run time
> system paging. My suspicion is that the program is trying to read in the
> whole file before processing it. Is this correct? If so, how do I make the
> program lazy so that it processes a line at time?
I was about to apply GHood to your program to see whether such a tool could
help to find the problem, so I started to cut down your code. However,
in the simplified version of the program, one can see what is going on
without any graphical tool.. (nevertheless, observation of the simplified
code with GHood confirms your suspicion immediately, and it points out
the spine of the list as the problem, too, so the tool is useful!-) (*)
In effect, your anonymize comes down to a "mapM" over a list of actions
applied to input lines, and all of the resulting IO-actions are placed
before the single "hPutStr". So, even if the results of the individual
actions in the list may not be needed until later, the whole spine of
the list of lines has to be traversed before "hPutStr" can be executed,
meaning that all input is read before any output is produced (and thus
before any computation results are requested, blowing up memory usage).
For the problem at hand, you could simply output each line as it is
processed instead of just returning it into a list for later use (see
variant _1 below). If you would want to keep both the modular program
structure and the explicit line-by-line IO-style, you would need to
interleave the input and output commands somehow (perhaps similar to
variant _2 below?).
Hth,
Claus
(*) Please note that our web-server is being upgraded today..
(web-pages and GHood download will not be available until
tomorrow, hence no URL here :-(
PS The simplified code (+ variations) with observations:
module Main(main) where
import Observe
import IO(openFile,
hPutStr,
IOMode(ReadMode,WriteMode,AppendMode))
filename = "ldif1.txt"
fileout = "ldif.out"
readAndWriteAttrVals =
do h <- openFile fileout WriteMode
s <- readFile filename
let action l = return (':':l)
a <- mapM action (observe "input" (lines s))
hPutStr h (unlines (observe "output" a))
main = runO readAndWriteAttrVals
readAndWriteAttrVals_1 =
do h <- openFile fileout WriteMode
s <- readFile filename
let action_and_output l = hPutStr h (':':l)
mapM_ (observe "output" action_and_output) (observe "input" (lines s))
main_1 = runO readAndWriteAttrVals_1
readAndWriteAttrVals_2 =
do h <- openFile fileout WriteMode
s <- readFile filename
let { action l = return (':':l)
; as = map action (observe "input" (lines s))
; os = repeat (hPutStr h)
}
mapM id (observe "output" (zipWith (>>=) as os))
main_2 = runO readAndWriteAttrVals_2
From jeff@galconn.com Mon Jan 15 16:36:52 2001
Date: Mon, 15 Jan 2001 08:36:52 -0800
From: Jeffrey R. Lewis jeff@galconn.com
Subject: Yet more on functional dependencies
Mark P Jones wrote:
> | I am finding functional dependencies confusing. (I suspect I am
> | not alone.) Should the following code work?
> |
> | class HasConverter a b | a -> b where
> | convert :: a -> b
> |
> | instance (HasConverter a b,Show b) => Show a where
> | show value = show (convert value)
>
> It's a separate issue. There's no reason why a system using
> functional dependencies *should* support this. But it is an
> attractive and useful extension that such a system would
> probably *want* to include. (i.e., it's a desirable feature,
> not a requirement.)
>
> I typed your example into Hugs on my machine and it seemed to
> accept the syntax (which suggests that the implementation is
> intended to allow this kind of thing). But then it choked on
> the definition with a curious error message that I suspect is
> an indication of a bug in Hugs' treatment of functional
> dependencies. And, for that reason, I'm crossposting this
> message to hugs-bugs. [Let me take the opportunity to remind
> good readers of these lists that it is now more than a year
> since I retired from the joys of maintaining Hugs, so I'm not
> planning to try and track down the source of this bug myself!]
> Of course, it could be that my version of Hugs is out of date!
Could you share the error message please. Boy, even old maintainers don't know how to submit a bug report... ;-)
Actually, I suspect whatever the problem was has been fixed, because (with -98 +o), it compiles fine. (I'm using the bleeding edge, out-of-the-repository version.)
--Jeff
From qrczak@knm.org.pl Sat Jan 13 13:09:25 2001
Date: 13 Jan 2001 13:09:25 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
What should be the preferred way of marking correspondence to source
positions after some preprocessing?
Here is what is currently supported:
| {-# LINE 100 "Foo.hs #-} | # 100 "Foo.hs"
------------------------+------------------------------+----------------
Released ghc, no -cpp | understand | error
Released ghc, with -cpp | understand | understand
Developed ghc | understand | understand
hbc | understand (ignore filename) | understand (warning)
Hugs | ignore | error
Released nhc98 | error | understand
Developed nhc98 | ignore | understand
I would choose LINE pragma. In this case nhc98 should be taught
about it.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From shlomif@vipe.technion.ac.il Mon Jan 15 17:07:29 2001
Date: Mon, 15 Jan 2001 19:07:29 +0200 (IST)
From: Shlomi Fish shlomif@vipe.technion.ac.il
Subject: A Regular Expression Library for Haskell
Does such a thing exists? Is it part of Happy?
Regards,
Shlomi Fish
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From simonmar@microsoft.com Mon Jan 15 17:03:29 2001
Date: Mon, 15 Jan 2001 09:03:29 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
> What should be the preferred way of marking correspondence to source
> positions after some preprocessing?
>
> Here is what is currently supported:
>
> | {-# LINE 100 "Foo.hs #-} | #
> 100 "Foo.hs"
> ------------------------+------------------------------+------
> ----------
> Released ghc, no -cpp | understand | error
> Released ghc, with -cpp | understand | understand
> Developed ghc | understand | understand
> hbc | understand (ignore filename) |
> understand (warning)
> Hugs | ignore | error
> Released nhc98 | error | understand
> Developed nhc98 | ignore | understand
>
> I would choose LINE pragma. In this case nhc98 should be taught
> about it.
CPP generates the '# 100 "Foo.hs"' form, which is why GHC understands
them. We used to convert these into LINE pragmas automatically before
feeding to the compiler, but this required an extra script and
preprocessing step (hscpp), so we don't do that anymore.
The preferred way should presumably be LINE pragmas.
Cheers,
Simon
From icsm2001@dsi.unifi.it Sat Jan 13 10:33:40 2001
Date: Sat, 13 Jan 2001 11:33:40 +0100 (MET)
From: icsm2001 (NESI) icsm2001@dsi.unifi.it
Subject: IEEE Conference Software Maint. Italy,Florence, ICSM2001
Dear Colleague
I would like to invite you to propose papers, experiences, tutorials, tool
expositions, dissertations at the
IEEE International Conference on Software Maintenance, 2001,
and workshops: SCAM, WESS, WSE and TABOO, etc., November 2001, Florence, Italy.
ICSM is the major international conference in the field of software and
systems maintenance, evolution, management, software metrics and quality, etc.
Outstanding Keynotes such as:
>->->Prof. David Lorge Parnas, Prof. Dieter Rombach, Prof. Ivar Jacobson<-<-<-
Awards, workshops, panels, and other exciting activities have been planned.
Please note in the following the new deadline that has been moved to satisfy the
several requests recevied, next deadline >->->->-29 January 2001<-<-<-<-<-<-
Please forward this remind to anybody who you think may be interested.
Apologies if you have already seen this.
If you would like to be removed from our list please send an email to
icsm2001@dsi.unifi.it with REMOVE in the subject.
ICSM2001
Paolo Nesi
(General Chair)
_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=
>->->CALL---FOR---PAPERs<-<-<
IEEE International Conference on Software Maintenance 2001
FLORENCE, ITALY, 6-10 November 2001
http://www.dsi.unifi.it/icsm2001
Theme: Systems and Software Evolution in the era of the Internet
IMPORTANT DATES, DEADLINES
Research Paper submission 29 January 2001
Dissertation submission 29 January 2001
Industrial Application submission 12 March 2001
Tools request and submission 12 March 2001
Tutorial submission 12 February 2001
_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=
From wli@holomorphy.com Mon Jan 15 19:46:17 2001
Date: Mon, 15 Jan 2001 11:46:17 -0800
From: William Lee Irwin III wli@holomorphy.com
Subject: bootstrapping GHC
On Sun, Jan 14, 2001 at 04:05:47PM -0800, William Lee Irwin III wrote:
> I've recently acquired access to SPARC and PPC Linux boxen. GHC 4.04 is
> presently bootstrapping on the SPARC, and I was wondering if there were
> PPC hc files floating about anywhere, or documentation on how to
> generate them.
I found the mailing list discussion on generating the hc boot files and
unregisterized code after a tip from Michael Weber and will eventually
get around to trying to bootstrap on Linux/PPC.
On the other hand, I'm running into a bit of trouble on the SPARC. It's
actually an UltraSPARC (sparc64). My assumption was that ordinary SPARC
code should just run on it. What's actually happen is illegal instructions
everywhere. The one that seems to stop me dead cold every time is here:
00000000009c4cfc <PrelMain_mainIO_info>:
9c4cfc: 00 9c 4c f8 bn 10d80dc <_end+0x69bff4>
9c4d00: 00 00 00 00 unimp 0
9c4d04: 00 11 00 01 unimp 0x110001
and this is in hsc, which is as far into the bootstrap as I got.
This disassembly looks wrong to me. Perhaps asm mangling is needed; I
had -fno-asm-mangling set because the assembler was barfing on prologue
nonsense. I'll be looking into that, as I'm not very familiar with the
real guts of the compiler, or, for that matter, modern SPARC's.
Any pointers will be appreciated.
Thanks,
Bill
--
<Jon_I> 'the Baire category theorem has no connection with category theory'
<Wo^tW> nonsense. *everything* is connected to category theory.
--
From ashley@semantic.org Tue Jan 16 02:11:09 2001
Date: Mon, 15 Jan 2001 18:11:09 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: O'Haskell OOP Polymorphic Functions
How do you do OOP-style polymorphic functions in O'Haskell? My first
attempt looked something like this:
struct Base
struct Derived < Base =
value :: Int
theValue :: Base -> Maybe Int
theValue x = Just (x.value) -- problem line
theValue _ = Nothing
In the problem line, x is considered to be of type Base, so x.value gives
an error. I tried replacing it with
theValue (x :: Derived) = Just (x.value)
...but that doesn't work either.
--
Ashley Yakeley, Seattle WA
From nordland@cse.ogi.edu Tue Jan 16 08:03:31 2001
Date: Tue, 16 Jan 2001 00:03:31 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: O'Haskell OOP Polymorphic Functions
Ashley Yakeley wrote:
>
> How do you do OOP-style polymorphic functions in O'Haskell? My first
> attempt looked something like this:
>
> struct Base
>
> struct Derived < Base =
> value :: Int
>
> theValue :: Base -> Maybe Int
> theValue x = Just (x.value) -- problem line
> theValue _ = Nothing
>
> In the problem line, x is considered to be of type Base, so x.value
> gives an error.
I'm not sure what OOP-style you're referring to. This is like trying
to access the "color" field of an ordinary, uncolored "point". How
would you program your function in Java?
> I tried replacing it with
>
> theValue (x :: Derived) = Just (x.value)
>
> ...but that doesn't work either.
But that's just because O'Haskell doesn't support type annotated
variables in patterns (yet). Change the type signature of your function
to
theValue :: Derived -> Maybe Int
instead, and it should typecheck (it still wouldn't make much sense, though).
However, as a general remark, I'd like to point out that record terms in
O'Haskell don't carry their type with them at run-time. Like in C++,
the type of a record term is a purely static notion that only exists at
compile time. Hence it's not possible to define a function that returns
a value that depends on the dynamic type of its argument (a big win when
one wants to enforce information hiding).
The solution is instead to use an ordinary datatype for values that one
would like to scrutinize at run-time by pattern-matching (the FP way),
or to internalize the function in question into the record type itself
(the OOP way).
-- Johan
From ashley@semantic.org Tue Jan 16 08:54:17 2001
Date: Tue, 16 Jan 2001 00:54:17 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: O'Haskell OOP Polymorphic Functions
At 2001-01-16 00:03, Johan Nordlander wrote:
>Ashley Yakeley wrote:
>>
>> How do you do OOP-style polymorphic functions in O'Haskell? My first
>> attempt looked something like this:
>>
>> struct Base
>>
>> struct Derived < Base =
>> value :: Int
>>
>> theValue :: Base -> Maybe Int
>> theValue x = Just (x.value) -- problem line
>> theValue _ = Nothing
>>
>> In the problem line, x is considered to be of type Base, so x.value
>> gives an error.
>
>I'm not sure what OOP-style you're referring to. This is like trying
>to access the "color" field of an ordinary, uncolored "point".
Right, but returning 'Nothing' for uncolored points and (Just) the color
for colored points.
> How would you program your function in Java?
Library code:
public class Base
{
}
public class Derived
extends Base
{
public int value;
public Derived(int v)
{
value = v;
}
}
Application code:
public static MaybeInt theValue(Base x)
{
if (x instanceof Derived)
return new MaybeInt(((Derived) x).value);
else return MaybeInt.NOTHING;
}
>> I tried replacing it with
>>
>> theValue (x :: Derived) = Just (x.value)
>>
>> ...but that doesn't work either.
>
>But that's just because O'Haskell doesn't support type annotated
>variables in patterns (yet). Change the type signature of your function
>to
>
> theValue :: Derived -> Maybe Int
>
>instead, and it should typecheck (it still wouldn't make much sense, though).
I want a function of type 'Base -> Maybe Int' that returns the value of a
Derived and Nothing for any other Base.
Is it possible to construct such a function?
>However, as a general remark, I'd like to point out that record terms in
>O'Haskell don't carry their type with them at run-time. Like in C++,
>the type of a record term is a purely static notion that only exists at
>compile time. Hence it's not possible to define a function that returns
>a value that depends on the dynamic type of its argument (a big win when
>one wants to enforce information hiding).
>
>The solution is instead to use an ordinary datatype for values that one
>would like to scrutinize at run-time by pattern-matching (the FP way),
This requires knowing the entire type structure before defining any such
functions.
>or to internalize the function in question into the record type itself
>(the OOP way).
This requires knowing all such functions before defining the type
structure. It also makes multiple dispatch difficult. I'm not sure this
can even be done by adding a dynamic-type field, since you still need to
cast to the Derived type to get the value.
--
Ashley Yakeley, Seattle WA
From Dominic.J.Steinitz@BritishAirways.com Tue Jan 16 10:27:32 2001
Date: 16 Jan 2001 10:27:32 Z
From: Steinitz, Dominic J Dominic.J.Steinitz@BritishAirways.com
Subject: Too Strict?
Claus,
Thanks for this. I think I can see what the problem was: mapM has to process the whole input before making a value available for hPutStr. Also I can see how to fix the problem.
What I can't see at the moment is how to keep what I was doing modular. I had a module Anonymize, the implementation of which I wanted to change without the user of it having to change their code. The initial implementation was a state monad which generated a new string every time it needed one but if it was a string it had already anonymized then it looked it up in the state. I initially used a list but with 100,000+ strings it took a long time. The next implementation used FiniteMap which improved things considerably. I only had to make three changes in Anonymize and none in Main. Using MD5 is quicker still but isn't so good from the program maintenance point of view.
Dominic.
C.Reinke@ukc.ac.uk on 15/01/2001 15:02:00
To: Dominic Steinitz
cc: haskell
glasgow-haskell-users
bcc:
Subject: Re: Too Strict?
> Can someone help? The program below works fine with small files but when I
> try to use it on the one I need to (about 3 million lines of data) it
> produces no output. The hard disk is hammered - I assume this is the run time
> system paging. My suspicion is that the program is trying to read in the
> whole file before processing it. Is this correct? If so, how do I make the
> program lazy so that it processes a line at time?
I was about to apply GHood to your program to see whether such a tool could
help to find the problem, so I started to cut down your code. However,
in the simplified version of the program, one can see what is going on
without any graphical tool.. (nevertheless, observation of the simplified
code with GHood confirms your suspicion immediately, and it points out
the spine of the list as the problem, too, so the tool is useful!-) (*)
In effect, your anonymize comes down to a "mapM" over a list of actions
applied to input lines, and all of the resulting IO-actions are placed
before the single "hPutStr". So, even if the results of the individual
actions in the list may not be needed until later, the whole spine of
the list of lines has to be traversed before "hPutStr" can be executed,
meaning that all input is read before any output is produced (and thus
before any computation results are requested, blowing up memory usage).
For the problem at hand, you could simply output each line as it is
processed instead of just returning it into a list for later use (see
variant _1 below). If you would want to keep both the modular program
structure and the explicit line-by-line IO-style, you would need to
interleave the input and output commands somehow (perhaps similar to
variant _2 below?).
Hth,
Claus
(*) Please note that our web-server is being upgraded today..
(web-pages and GHood download will not be available until
tomorrow, hence no URL here :-(
PS The simplified code (+ variations) with observations:
module Main(main) where
import Observe
import IO(openFile,
hPutStr,
IOMode(ReadMode,WriteMode,AppendMode))
filename = "ldif1.txt"
fileout = "ldif.out"
readAndWriteAttrVals =
do h <- openFile fileout WriteMode
s <- readFile filename
let action l = return (':':l)
a <- mapM action (observe "input" (lines s))
hPutStr h (unlines (observe "output" a))
main = runO readAndWriteAttrVals
readAndWriteAttrVals_1 =
do h <- openFile fileout WriteMode
s <- readFile filename
let action_and_output l = hPutStr h (':':l)
mapM_ (observe "output" action_and_output) (observe "input" (lines s))
main_1 = runO readAndWriteAttrVals_1
readAndWriteAttrVals_2 =
do h <- openFile fileout WriteMode
s <- readFile filename
let { action l = return (':':l)
; as = map action (observe "input" (lines s))
; os = repeat (hPutStr h)
}
mapM id (observe "output" (zipWith (>>=) as os))
main_2 = runO readAndWriteAttrVals_2
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From magnus@cse.ogi.edu Tue Jan 16 18:23:06 2001
Date: Tue, 16 Jan 2001 10:23:06 -0800
From: Magnus Carlsson magnus@cse.ogi.edu
Subject: O'Haskell OOP Polymorphic Functions
You can use overloading for the definition of theValue instead:
class TheValue a where theValue :: a -> Maybe Int
instance TheValue Base where theValue _ = Nothing
instance TheValue Derived where theValue x = Just (x.value)
/M
Ashley Yakeley writes:
> How do you do OOP-style polymorphic functions in O'Haskell? My first
> attempt looked something like this:
>
> struct Base
>
> struct Derived < Base =
> value :: Int
>
> theValue :: Base -> Maybe Int
> theValue x = Just (x.value) -- problem line
> theValue _ = Nothing
>
> In the problem line, x is considered to be of type Base, so x.value gives
> an error. I tried replacing it with
>
> theValue (x :: Derived) = Just (x.value)
>
> ...but that doesn't work either.
>
> --
> Ashley Yakeley, Seattle WA
From nordland@cse.ogi.edu Tue Jan 16 18:38:30 2001
Date: Tue, 16 Jan 2001 10:38:30 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: O'Haskell OOP Polymorphic Functions
Magnus Carlsson wrote:
>
> You can use overloading for the definition of theValue instead:
>
> class TheValue a where theValue :: a -> Maybe Int
>
> instance TheValue Base where theValue _ = Nothing
> instance TheValue Derived where theValue x = Just (x.value)
>
... or rather, you will be able to use overloading when the new version of
O'Hugs is released in a few days :-)
-- Johan
From Malcolm.Wallace@cs.york.ac.uk Tue Jan 16 19:47:31 2001
Date: Tue, 16 Jan 2001 19:47:31 +0000
From: Malcolm Wallace Malcolm.Wallace@cs.york.ac.uk
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
> Here is what is currently supported:
> {-# LINE 100 "Foo.hs #-} | # 100 "Foo.hs"
I recently discovered that some of the GHC toolset actually
generates and recognises
{-# LINE 100 "Foo.hs -}
which is somewhere in between a comment and a pragma. Has
this been fixed yet?
> I would choose LINE pragma. In this case nhc98 should be taught
> about it.
The 1.00 release of nhc98 (incorrectly) rejects almost all pragmas.
The 1.01 (CVS) version correctly accepts (but ignores) almost all
pragmas. In time, it will learn to use the information from a small
number of pragmas. When that happens, LINE can certainly be one
of them.
Regards,
Malcolm
From C.Reinke@ukc.ac.uk Tue Jan 16 19:59:03 2001
Date: Tue, 16 Jan 2001 19:59:03 +0000
From: C.Reinke C.Reinke@ukc.ac.uk
Subject: ANNOUNCE: GHood (updated pre-release)
Ever wanted to see what your Haskell program is doing?-)
-----------------------------------------------------------------
GHood (pre-release, 11 January 2001)
"Graphical Hood" -- a Java-based graphical observation event viewer, as
a back-end for Andy Gill's Hood (Haskell Object Observation Debugger).
Currently, GHood comes in two files: a drop-in replacement for the
Hugs98 variant of Hood (only minimal changes, same interface) and a
Java class file archive for the graphical viewer itself.
To find the two files, please visit my Haskell corner at:
http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/#GHood
-----------------------------------------------------------------
The GHood pre-release has been updated. The main change (apart from
single-stepping through the observation event stream, which you might
have been missing in the previous version):
GHood can now be used as an applet (requires Java 2/Swing-capable
browser or a suitable Java plug-in).
This means that GHood animations can now be used to enrich webpages.
If you ever wanted to discuss the behaviour of Haskell programs on your
webpages, you can now add applets to those pages that visualise and
animate the issues you describe. If you never dared to write about
program behaviour for lack of illustrations, you might now consider
adding such discussions to your webpages. Potential uses:
- educators: as part of your functional programming course webpages,
- programmers: as part of the description of a clever functional algorithm,
or to document problems in a misbehaving functional program
- GHood implementors (me;-): show examples of GHood animations online.
I would be interested to learn about example problems from practice for
which GHood has been found helpful. Please let me know, too, if you
create websites that use GHood as an applet.
Enjoy,
Claus
--
Claus Reinke, http://www.cs.ukc.ac.uk/people/staff/cr3/
Computing Lab, University of Kent at Canterbury
From ashley@semantic.org Tue Jan 16 21:06:54 2001
Date: Tue, 16 Jan 2001 13:06:54 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: O'Haskell OOP Polymorphic Functions
At 2001-01-16 10:23, Magnus Carlsson wrote:
>You can use overloading for the definition of theValue instead:
>
> class TheValue a where theValue :: a -> Maybe Int
>
> instance TheValue Base where theValue _ = Nothing
> instance TheValue Derived where theValue x = Just (x.value)
Doesn't this imply that run-time type information is kept with the
structs?
Consider:
d :: Derived
d = struct
value = 3
b :: Base
b = d
idb :: Base -> Base
idb x = x
f1 = theValue d
f2 = theValue b
f3 = theValue (idb d)
f4 = theValue (idb b)
What are the values of f1, f2, f3 & f4?
--
Ashley Yakeley, Seattle WA
From qrczak@knm.org.pl Tue Jan 16 21:09:07 2001
Date: 16 Jan 2001 21:09:07 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
Tue, 16 Jan 2001 19:47:31 +0000, Malcolm Wallace <Malcolm.Wallace@cs.york.ac.uk> pisze:
> I recently discovered that some of the GHC toolset actually
> generates and recognises
> {-# LINE 100 "Foo.hs -}
> which is somewhere in between a comment and a pragma. Has
> this been fixed yet?
I've heard about it... Oops, it appears that since the CVS version
of ghc no longer translates cpp-style markers into LINE pragmas in
a separate pass, but interprets them itself in the compiler proper,
ghc -E does not perform that pass and now outputs cpp-style markers,
which do get into happy's templates. So it's indeed "fixed": to
cpp-style markers :-(
It can be properly fixed either by postprocessing the templates
during building of happy, or implementing that pass separately again
for explicit invocation of ghc -E. Since ghc -E does not seem to be
a widely used and very standard feature, perhaps it's enough to do
the former.
Moreover, there was one place internal to ghc which output
{-# LINE 1 "File" -}
and I will commit a fix in a minute.
> The 1.00 release of nhc98 (incorrectly) rejects almost all pragmas.
> The 1.01 (CVS) version correctly accepts (but ignores) almost all
> pragmas. In time, it will learn to use the information from a small
> number of pragmas. When that happens, LINE can certainly be one
> of them.
ghc recognizes {-# together with the pragma's keyword during lexical
analysis, emits e.g. '{-# SPECIALIZE' as a single token, and treats
unrecognized pragmas as comments. nhc98 passes all pragmas to the
parser.
The difference is that ghc ignores pragmas with unknown keywords
placed in unusual places (e.g. in the middle of an expression),
where nhc98 flags them as errors.
Of course LINE can appear anywhere without respect to layout so must
be dealt with during the lexical analysis.
Haskell 98 does not say anything about case sensitivity of pragmas'
keywords but uses lowercase and mixedCase examples. ghc ignores the
case. hbc understands both all-uppercase and all-lowercase forms but
no mixing. I've seen only uppercase in practice. Perhaps something
should be said about it more explicitly. Perhaps official support
for uppercase only is enough (the rest of Haskell is case sensitive).
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From magnus@cse.ogi.edu Tue Jan 16 21:18:02 2001
Date: Tue, 16 Jan 2001 13:18:02 -0800
From: Magnus Carlsson magnus@cse.ogi.edu
Subject: O'Haskell OOP Polymorphic Functions
Ashley Yakeley writes:
> At 2001-01-16 10:23, Magnus Carlsson wrote:
>
> >You can use overloading for the definition of theValue instead:
> >
> > class TheValue a where theValue :: a -> Maybe Int
> >
> > instance TheValue Base where theValue _ = Nothing
> > instance TheValue Derived where theValue x = Just (x.value)
>
> Doesn't this imply that run-time type information is kept with the
> structs?
The overloading is resolved statically, so no run-time type
information is needed.
>
> Consider:
>
> d :: Derived
> d = struct
> value = 3
>
> b :: Base
> b = d
>
> idb :: Base -> Base
> idb x = x
>
> f1 = theValue d
> f2 = theValue b
> f3 = theValue (idb d)
> f4 = theValue (idb b)
>
> What are the values of f1, f2, f3 & f4?
f1 = Just 3
f2 = f3 = f4 = Nothing
> --
> Ashley Yakeley, Seattle WA
/M
From ashley@semantic.org Tue Jan 16 21:27:05 2001
Date: Tue, 16 Jan 2001 13:27:05 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: O'Haskell OOP Polymorphic Functions
At 2001-01-16 13:18, Magnus Carlsson wrote:
>f1 = Just 3
>f2 = f3 = f4 = Nothing
So I've declared b = d, but 'theValue b' and 'theValue d' are different
because theValue is looking at the static type of its argument?
What's to stop 'instance TheValue Base' applying in 'theValue d'?
--
Ashley Yakeley, Seattle WA
From john@foo.net Tue Jan 16 22:04:22 2001
Date: Tue, 16 Jan 2001 14:04:22 -0800
From: John Meacham john@foo.net
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
With all this talk of preprocessor generated information and whatnot, I
am reminded of a paper I read not too long ago but can't seem to find
anymore about a dedicated pre-processor for haskell based on the C
preprocessor but made to deal with haskell constructs a bit more sanely.
I was wondering whatever happened to that Idea as I find myself in need
of a preprocessor every now and again... I imagine a small pure Haskell 98
implementation of the preprocessor would be very useful because then it
can be included directly with programs that require it and compiled
first as part of the make process until compilers have it integrated...
any thoughts? anyone have a link to the original paper I am talking
about?
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@foo.net
--------------------------------------------------------------
From nordland@cse.ogi.edu Tue Jan 16 22:41:52 2001
Date: Tue, 16 Jan 2001 14:41:52 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: O'Haskell OOP Polymorphic Functions
Ashley Yakeley wrote:
>
> At 2001-01-16 14:04, Tom Pledger wrote:
>
> >The subtyping (struct Derived < Base ...) makes the two instances
> >overlap, with 'instance TheValue Derived' being strictly more specific
> >than 'instance TheValue Base'. If the system preferred the less
> >specific one, the more specific one would never be used.
> >
> >This is quite similar to the way overlapping instances are handled
> >when they occur via substitutions for type variables (e.g. 'instance C
> >[Char]' is strictly more specific than 'instance C [a]') in
> >implementations which support than language extension.
>
> Subtyping-overlapping is quite different from type-substitution
> overlapping.
>
> Consider:
>
> struct B
>
> struct D1 < Base =
> a1 :: Int
>
> struct D2 < Base =
> a2 :: Int
>
> class TheValue a where theValue :: a -> Int
> instance TheValue B where theValue _ = 0
> instance TheValue D1 where theValue _ = 1
> instance TheValue D2 where theValue _ = 2
>
> struct M < D1,D2
>
> m = struct
> a1 = 0
> a2 = 0
>
> f = theValue m
>
> What's the value of f?
This program is rejected on the grounds that it lacks an instance
delaration for TheValue M. Declare one and you will be fine.
Or (when the upcoming release becomes available) remove the instance
decl for either D1 or D2 and the remaining one will be chosen.
-- Johan
From chak@cse.unsw.edu.au Tue Jan 16 23:04:30 2001
Date: Tue, 16 Jan 2001 23:04:30 GMT
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
Simon Marlow <simonmar@microsoft.com> wrote,
> The preferred way should presumably be LINE pragmas.
Indeed. Or do you want to tell me that you are going to
break one of my favourite programs?
<EndangeredProgram>
import Char
instance Eq (a -> b) where
_ ==_ = False
instance Show (a -> b) where
show = const "<function>"
instance Num b => Num (a -> b) where
fromInteger = const . fromInteger
(+) = undefined
(*) = undefined
signum = undefined
abs = undefined
(#) :: Int -> Int -> String
(x # y) = chr x : chr y : "!"
main = putStrLn $ 78
# 111 "Foo.hs"
</EndangeredProgram>
Cheers,
Manuel
From chak@cse.unsw.edu.au Wed Jan 17 00:01:33 2001
Date: Wed, 17 Jan 2001 00:01:33 GMT
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: A Regular Expression Library for Haskell
> Does such a thing exists?
Yes. See the lexer library in
http://www.cse.unsw.edu.au/~chak/haskell/ctk/
You can use it without most of the other stuff and it is
fast, too.
Cheers,
Manuel
From sebc@posse42.net Wed Jan 17 08:53:26 2001
Date: Wed, 17 Jan 2001 09:53:26 +0100
From: Sebastien Carlier sebc@posse42.net
Subject: An Haskell compilation server
How about turning ghc into a compilation server ?
It would run as a daemon waiting for network
connections, retrieve source files (through the
same network socket, or nfs, or cvs, ...), compile
them locally, and send back the result.
This would prevent having to reload the compiler
for each file - as the executable is quite large, this
may already speed up compilation a bit.
It could also cache .hi files, which would remove
the need to parse them.
It would also enable distributed compilation, on a
properly configured site. That would be easy to do
with hmake.
There are many details to think about (should the
parsing be made locally by the driver, or remotely...).
How does it sound ?
--
Sebastien Carlier
EPITA, Posse42
From john@foo.net Wed Jan 17 09:28:00 2001
Date: Wed, 17 Jan 2001 01:28:00 -0800
From: John Meacham john@foo.net
Subject: An Haskell compilation server
the benefits may not be as great as you suppose, modern operating
systems keep a buffer cache which contains all recently used data in
memory including executables, if your machine is not memory limited
(such that the OS would have to throw away your ghc pages to make room
for something else) then probably most of ghc's pages will already be
resident in RAM for subsequent runs. if you wish to distribute the make
over several machines that can be done easily by using 'ssh' or 'rsh' to
start jobs on remote machines and share the results via nfs or smb or
some other remote filesystem. there are also certain versions of make
such as 'pmake' which specialize in distributing building across
clusters of machines... modifying 'hmake' to distribute the builds
automagically might be an interesting and useful project though.
John
On Wed, Jan 17, 2001 at 09:53:26AM +0100, Sebastien Carlier wrote:
> How about turning ghc into a compilation server ?
> It would run as a daemon waiting for network
> connections, retrieve source files (through the
> same network socket, or nfs, or cvs, ...), compile
> them locally, and send back the result.
> This would prevent having to reload the compiler
> for each file - as the executable is quite large, this
> may already speed up compilation a bit.
> It could also cache .hi files, which would remove
> the need to parse them.
> It would also enable distributed compilation, on a
> properly configured site. That would be easy to do
> with hmake.
> There are many details to think about (should the
> parsing be made locally by the driver, or remotely...).
> How does it sound ?
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@foo.net
--------------------------------------------------------------
From sebc@posse42.net Wed Jan 17 09:48:20 2001
Date: Wed, 17 Jan 2001 10:48:20 +0100
From: Sebastien Carlier sebc@posse42.net
Subject: An Haskell compilation server
John Meacham wrote:
> the benefits may not be as great as you suppose, modern operating
> systems keep a buffer cache which contains all recently used data in
> memory including executables, if your machine is not memory limited
> (such that the OS would have to throw away your ghc pages to make room
> for something else) then probably most of ghc's pages will already be
> resident in RAM for subsequent runs.
Even if the executable file is cached, there is still dynamic linking
to be done. Are pages of the executable memory mapped, or does the
binary file format get in the way and force the code segment to be
copied ? (this is architecture dependent, it would be interesting to
find out for the most common ones)
Even if the loading time is only slightly shorter, I think more
interesting speed-ups can be achieved by removing any work which
is duplicated by the compiler at each run. This probably includes
parsing .hi files. Where does the compiler spend most of its time ?
> if you wish to distribute the make over several machines that can be
> done easily by using 'ssh' or 'rsh' to start jobs on remote machines
> and share the results via nfs or smb or some other remote filesystem.
This would be very difficult without analysing the dependencies
between modules, I think the compilation has to be globally coordinated.
Also, you probably want to use only compilers for the sate architecture,
although you might have compilation servers for several. They should
register themselves to a central coordination server, which could also
balance the workload between servers.
I do not think this would be efficiently done with shell scripts.
> there are also certain versions of make such as 'pmake' which
> specialize in distributing building across clusters of machines...
> modifying 'hmake' to distribute the builds automagically might be
> an interesting and useful project though.
This would indeed be nice for universities and large sites.
And rebuilding ghc would be a breeze :)
> --
> --------------------------------------------------------------
> John Meacham http://www.ugcs.caltech.edu/~john/
> California Institute of Technology, Alum. john@foo.net
> --------------------------------------------------------------
From mh@informatik.uni-kiel.de Wed Jan 17 09:50:37 2001
Date: Wed, 17 Jan 2001 10:50:37 +0100 (MET)
From: Michael Hanus mh@informatik.uni-kiel.de
Subject: An Haskell compilation server
Sebastien Carlier wrote:
> How about turning ghc into a compilation server ?
> It would run as a daemon waiting for network
> connections, retrieve source files (through the
> same network socket, or nfs, or cvs, ...), compile
> them locally, and send back the result.
> This would prevent having to reload the compiler
> for each file - as the executable is quite large, this
> may already speed up compilation a bit.
> It could also cache .hi files, which would remove
> the need to parse them.
> It would also enable distributed compilation, on a
> properly configured site. That would be easy to do
> with hmake.
> There are many details to think about (should the
> parsing be made locally by the driver, or remotely...).
> How does it sound ?
This is a good idea. We have done this for our Curry implementation
(http://www.informatik.uni-kiel.de/~pakcs)
(Curry is an extension of Haskell to deal with logic and concurrent
programming features) and made very good experiences with it,
in particular, there was a considerably speed-up when recompiling
larger applications.
Michael
From simonmar@microsoft.com Wed Jan 17 09:49:25 2001
Date: Wed, 17 Jan 2001 01:49:25 -0800
From: Simon Marlow simonmar@microsoft.com
Subject: An Haskell compilation server
> How about turning ghc into a compilation server ?
> It would run as a daemon waiting for network
> connections, retrieve source files (through the
> same network socket, or nfs, or cvs, ...), compile
> them locally, and send back the result.
> This would prevent having to reload the compiler
> for each file - as the executable is quite large, this
> may already speed up compilation a bit.
> It could also cache .hi files, which would remove
> the need to parse them.
> It would also enable distributed compilation, on a
> properly configured site. That would be easy to do
> with hmake.
> There are many details to think about (should the
> parsing be made locally by the driver, or remotely...).
> How does it sound ?
Funny you should say that. The next version of GHC (5.00 - to be
released soon) will have hmake-like functionality enabling it to compile
multiple modules without exiting, caching .hi files between
compilations. This speeds up compilations by as much as a factor of 2
for large programs.
Cheers,
Simon
From qrczak@knm.org.pl Wed Jan 17 13:06:36 2001
Date: 17 Jan 2001 13:06:36 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: An Haskell compilation server
Wed, 17 Jan 2001 01:49:25 -0800, Simon Marlow <simonmar@microsoft.com> pisze:
> Funny you should say that. The next version of GHC (5.00 - to be
> released soon) will have hmake-like functionality enabling it to
> compile multiple modules without exiting,
How to specify .c files to be linked in?
Or to not bother with linking so I will link manually.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From till@Informatik.Uni-Bremen.DE Wed Jan 17 14:13:37 2001
Date: Wed, 17 Jan 2001 15:13:37 +0100
From: Till Mossakowski till@Informatik.Uni-Bremen.DE
Subject: Research assistant positions in Bremen
The following two research assistant positions
are available at the University of Bremen, Germany.
The Bremen Institute of Safe Systems in the Center for Computing
Technologies at the University of Bremen hosts the research projects
"Multi-logic systems as a basis for heterogeneous specification
and development" (MULTIPLE)
and
"Algebraic specification + functional programming =
environment for formal software development" (HasCASL)
funded by the Deutsche Forschungsgemeinschaft (DFG).
Within the framework of each of these projects, one position in the
working group of Prof. Dr. Krieg-Brückner is to be immediately
filled for at least two years (additional option for another two
years),
subject to availability of funds:
Research Assistant
Verg. Gr. IIa BAT (full time)
In addition to successful university studies in computer science,
experience and skills in functional programming (e.g. Haskell, ML)
are expected. Familiarity with at least one of formal specification
methods (like CoFI/CASL), theorem proving or category theory is
desirable.
Applicants with a PhD are welcome. However, there will also be the
oppurtunity to prepare a PhD thesis in connection with the research
project.
In case of essentially equal qualification in the subject and personal
suitability, severely handicapped applicants will be preferred. The
University of Bremen intends to increase the share of women in
scientific activities and does therefore strongly encourage women to
apply for these positions.
More detailed information about the projects can be found under
http://www.tzi.de/cofi/projects/multiple.html
http://www.tzi.de/cofi/projects/hascasl.html
Please address your application with the usual documents and the
reference number A164/00 (MULTIPLE) resp. A165/00 (HasCASL)
before 01.02.2001 to:
UNIVERSITÄT BREMEN
Prof. Dr. B. Krieg-Brückner
Fachbereich 3
Postfach 33 04 40
28334 Bremen
e-Mail: cofi@tzi.de
--
Till Mossakowski Phone: +49-421-218-4683, monday:
+49-4252-1859
Dept. of Computer Science Fax: +49-421-218-3054
University of Bremen EMail: till@tzi.de
P.O.Box 330440, D-28334 Bremen WWW: http://www.tzi.de/~till
From koen@cs.chalmers.se Wed Jan 17 15:32:29 2001
Date: Wed, 17 Jan 2001 16:32:29 +0100 (MET)
From: Koen Claessen koen@cs.chalmers.se
Subject: fixity for (\\)
Hi all,
The Haskell report defines the fixity of (\\) to be:
infix 5 \\
I propose that it gets the following fixity:
infixl 5 \\
This means that one can write:
as \\ bs \\ cs \\ ds
Which means:
(((as \\ bs) \\ cs) \\ ds)
I think that one less often means the following:
as \\ (bs \\ (cs \\ ds))
/Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
From pamela@research.att.com Wed Jan 17 15:31:35 2001
Date: Wed, 17 Jan 2001 10:31:35 -0500 (EST)
From: Pamela Zave pamela@research.att.com
Subject: FME2001 Call for Participation
To learn about Formal Methods Europe 2001, to be held in Berlin 12-16 March,
please visit the symposium website at:
www.informatik.hu-berlin.de/top/fme2001
Registration and hotel reservation are available on the website. The deadline
for early registration is 9 February.
Please register now so we can look forward to seeing you in Berlin!
From jf15@hermes.cam.ac.uk Wed Jan 17 16:41:07 2001
Date: Wed, 17 Jan 2001 16:41:07 +0000 (GMT)
From: Jon Fairbairn jf15@hermes.cam.ac.uk
Subject: fixity for (\\)
On Wed, 17 Jan 2001, Koen Claessen wrote:
> I propose that it gets the following fixity:
>=20
> infixl 5 \\
Unless the it's common usage outside of Haskell, I oppose!
Getting=20
List> [1,2,3]\\[2]\\[3]
ERROR: Ambiguous use of operator "(\\)" with "(\\)"
at compile time does no harm, but getting [1] instead of
[1,3] _at run time_ does do harm.
J=F3n
--=20
J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.uk
31 Chalmers Road jf@cl.cam.ac.uk
Cambridge CB1 3SZ +44 1223 570179 (pm only, please)
From igloo@earth.li Wed Jan 17 19:11:40 2001
Date: Wed, 17 Jan 2001 19:11:40 +0000
From: Ian Lynagh igloo@earth.li
Subject: MD5 in Haskell
I apologise if this is off topic for this list - I haven't been here long.
Someone recently mentioned that the MD5 function in GHC uses C code to do the
work so returns an IO String rather than a String. I have written an MD5
implementation in pure Haskell code (following the RFC - I don't know if a
better optimised version could be written although I may look into this).
I've put the code at http://c93.keble.ox.ac.uk/~ian/md5/
License is GPL.
Ian
From ashley@semantic.org Wed Jan 17 23:48:55 2001
Date: Wed, 17 Jan 2001 15:48:55 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: O'Haskell OOP Polymorphic Functions
OK, I've figured it out. In this O'Haskell statement,
> struct Derived < Base =
> value :: Int
...Derived is not, in fact, a subtype of Base. Derived and Base are
disjoint types, but an implicit map of type "Derived -> Base" has been
defined.
--
Ashley Yakeley, Seattle WA
From uk1o@rz.uni-karlsruhe.de Wed Jan 17 23:58:59 2001
Date: Thu, 18 Jan 2001 00:58:59 +0100
From: Hannah Schroeter uk1o@rz.uni-karlsruhe.de
Subject: Finding primes using a primes map with Haskell and Hugs98
Hello!
On Wed, Dec 20, 2000 at 04:02:23PM +0200, Shlomi Fish wrote:
> [...]
> primes :: Int -> [Int]
> primes how_much = sieve [2..how_much] where
> sieve (p:x) =
> p : (if p <= mybound
> then sieve (remove (p*p) x)
> else x) where
> remove what (a:as) | what > how_much = (a:as)
> | a < what = a:(remove what as)
> | a == what = (remove (what+step) as)
> | a > what = a:(remove (what+step) as)
> remove what [] = []
> step = (if (p == 2) then p else (2*p))
> sieve [] = []
> mybound = ceiling(sqrt(fromIntegral how_much))
> [...]
How about this: Yet another infinite list version, however
only sieving numbers to the square of the current maximum:
primes :: [Int]
primes = 2:fil' 4 primes [3..]
where
fil' cutoff fl@(f:fs) rl@(r:rs) =
if r < cutoff then r:fil' cutoff fl rs
else fil' (square (head fs)) fs [y|y<-rl, (y `mod` f) /= 0]
square x = x*x
Comparison:
my version (with a small main around it):
hannah@mamba:~/src/haskell $ time ./primes 1000000 >/tmp/p1
real 0m31.928s
user 0m31.690s
sys 0m0.317s
your version (with adapted small main around it):
hannah@mamba:~/src/haskell $ time ./primes2 1000000 >/tmp/p2
real 0m42.993s
user 0m42.023s
sys 0m0.236s
(measurements with ghc 4.08, -O2 -O2-for-C, Pentium I 200 MHz 64 MB RAM)
The outputs (primes list + number of found primes) are the same.
In contrast, take the simple two-liner
primes :: [Int]
primes = p' [2..] where p' (p:ps) = p:p' [y|y<-ps, (y `mod` p) /= 0]
with the same small main:
hannah@mamba:~/src/haskell $ time ./primes0 100000 >/tmp/p0
real 2m17.460s
user 2m15.773s
sys 0m1.170s
(mine with 100000 limit)
hannah@mamba:~/src/haskell $ time ./primes 100000 >/tmp/p1
real 0m1.666s
user 0m1.607s
sys 0m0.048s
(yours with 100000 limit)
hannah@mamba:~/src/haskell $ time ./primes2 100000 >/tmp/p2
real 0m1.903s
user 0m1.827s
sys 0m0.064s
Kind regards,
Hannah.
From kuchen@uni-muenster.de Thu Jan 18 10:59:59 2001
Date: Thu, 18 Jan 2001 11:59:59 +0100
From: Herbert Kuchen kuchen@uni-muenster.de
Subject: FLOPS 2001 - Call for Participation
*********************************************************************
* CALL FOR PARTICIPATION *
* *
* FLOPS 2001 *
* Fifth International Symposium on Functional and Logic Programming *
* *
* Waseda University, Tokyo, Japan *
* March 7-9, 2001 *
* *
* http://www.ueda.info.waseda.ac.jp/flops2001/ *
*********************************************************************
The symposium is a forum for research on all issues concerning
functional programming and logic programming. In particular, it aims
to stimulate the cross-fertilization as well as integration of the two
paradigms. This is the fifth in the series of FLOPS symposia held
every 1.5 years in Japan.
The symposium program will consist of 3 invited talks and 21 technical
research talks. The proceedings will be published by Springer-Verlag
in the Lecture Notes in Computer Science series.
Invited Talks
=============
Gopalan Nadathur (Univ. of Minnesota, USA)
"The Metalanguage lambda-Prolog and Its Implementation"
George C. Necula (Univ. of California, Berkeley, USA)
"A Scalable Architecture for Proof-Carrying Code"
Taisuke Sato (Tokyo Institute of Technology, Japan)
"Parameterized Logic Programs where Computing Meets Learning"
Important Dates
===============
Early Registration Deadline: January 30, 2001
Symposium: March 7-9, 2001
Venue
=====
The symposium will be held at the International Conference Center of
Waseda University, which is located in central Tokyo and can be
accessed easily. For details, please visit the FLOPS2001 Web page
http://www.ueda.info.waseda.ac.jp/flops2001/ .
Registration and Hotel Information
==================================
Details of registration and hotel booking information are available
on the FLOPS2001 Web page. Registration fees are as follows:
Before Jan. 30 After Jan. 31
Regular 22,000 yen 32,000 yen
Student 12,000 yen 22,000 yen
The fees include participation, proceedings, banquet and
refreshments for one person. Additional banquet tickets are
available. The current exchange rate for Japanese yen is
US$1 = 116 yen and 1 Euro = 109 yen.
Detailed information on accommodations near the conference site,
ranging from luxuary to inexpensive, is available on the FLOPS Web
page.
Accepted Papers
===============
(A timetable will be available on the FLOPS2001 Web page shortly.)
Proving Syntactic Properties of Exceptions in an Ordered Logical
Framework
Jeff Polakow and Kwangkeun Yi
A Higher-Order Colon Translation
Olivier Danvy and Lasse R. Nielsen
Compiling Lazy Functional Programs Based on the Spineless Tagless
G-machine for the Java Virtual Machine
Kwanghoon Choi, Hyun-il Lim, and Taisook Han
A Higher-Order Logic Programming Language with Constraints
Javier Leach and Susana Nieva
Specifying and Debugging Security Protocols via Hereditary Harrop
Formulas and lambdaProlog - A Case-study
Giorgio Delzanno
An Effective Bottom-Up Semantics for First-Order Linear Logic Programs
Marco Bozzano, Giorgio Delzanno, and Maurizio Martelli
A Framework for Goal-Directed Bottom-Up Evaluation
of Functional Logic Programs
Jesus M. Almendros-Jimenez and Antonio Becerra-Teron
Theoretical Foundations for the Declarative Debugging of
Lazy Functional Logic Programs
Rafael Caballero, Francisco J. Lopez-Fraguas, and
Mario Rodriguez-Artalejo
Adding Linear Constrains over Real Numbers to Curry
Wolfgang Lux
A Complete Selection Function for Lazy Conditional Narrowing
Taro Suzuki and Aart Middeldorp
An Abstract Machine Based System for a Lazy Narrowing Calculus
Teresa Hortala-Gonzalez and Eva Ullan
Incremental Learning of Functional Logic Programs
Cesar Ferri-Ramirez, Jose Hernandez-Orallo,
and Maria Jose Ramirez-Quintana
A General Type Inference Framework for Hindley/Milner Style Systems
Martin Sulzmann
Monadic Encapsulation with Stack of Regions
Koji Kagawa
Well-Typed Logic Programs Are not Wrong
Pierre Deransart and Jan-Georg Smaus
A Framework for Analysis of Typed Logic Programs
Vitaly Lagoon and Peter J. Stuckey
Abstract Compilation for Sharing Analysis
Gianluca Amato and Fausto Spoto
A Practical Partial Evaluator for a Multi-Paradigm Declarative
Language
Elvira Albert, Michael Hanus, and German Vidal
A Simple Take on Typed Abstract Syntax in ML-like Languages
Olivier Danvy and Morten Rhiger
A Simply Typed Context Calculus with First-Class Environments
Masahiko Sato, Takafumi Sakurai, and Yukiyoshi Kameyama
Refining the Barendregt Cube using Parameters
Fairouz Kamareddine, Twan Laan, and Rob Nederpelt
Symposium Organization
======================
Program Co-Chairs:
Herbert Kuchen Univ. of Muenster, Germany
Kazunori Ueda Waseda Univ., Tokyo, Japan
Program Committee:
Sergio Antoy Portland State Univ., USA
Gopal Gupta New Mexico State Univ., USA
Michael Hanus Univ. of Kiel, Germany
Fergus Henderson Univ. of Melbourne, Australia
Zhenjiang Hu Univ. of Tokyo, Japan
Herbert Kuchen Univ. of Muenster, Germany
Giorgio Levi Univ. of Pisa, Italy
Michael Maher Griffith Univ., Brisbane, Australia
Dale Miller Pennsylvania State Univ., USA
I.V. Ramakrishnan State Univ. of New York at Stony Brook, USA
Olivier Ridoux IRISA, France
Mario Rodriguez-Artalejo Complutense Univ., Madrid, Spain
Colin Runciman Univ. of York, UK
Akihiko Takano Hitachi Ltd., Japan
Peter Thiemann Freiburg Univ., Germany
Yoshihito Toyama Tohoku Univ., Japan
Kazunori Ueda Waseda Univ., Tokyo, Japan
Local Arrangements Chair:
Zhenjiang Hu Univ. of Tokyo, Japan
Sponsors
========
FLOPS2001 is sponsored by Japan Society of Software Science and
Technology (JSSST), Special Interest Group on Principles of
Programming, and held in cooperation with Association for Logic
Programming (ALP).
From harald@cs.mu.OZ.AU Thu Jan 18 00:45:36 2001
Date: Thu, 18 Jan 2001 11:45:36 +1100
From: Harald Sondergaard harald@cs.mu.OZ.AU
Subject: PPDP 2001: Call for Papers (second call)
(Apologies if you receive multiple copies of this announcement.)
Third International Conference on
PRINCIPLES AND PRACTICE OF DECLARATIVE PROGRAMMING
Firenze, Italy, 5-7 September 2001
CALL FOR PAPERS
PPDP 2001 aims to stimulate research on the use of declarative methods
in programming and on the design, implementation and application of
programming languages that support such methods. Topics of interest
include any aspect related to understanding, integrating and extending
programming paradigms such as those for functional, logic, constraint
and object-oriented programming; concurrent extensions and mobile
computing; type theory; support for modularity; use of logical methods
in the design of program development tools; program analysis and
verification; abstract interpretation; development of implementation
methods; application of the relevant paradigms and associated methods
in industry and education. This list is not exhaustive: submissions
describing new and interesting ideas relating broadly to declarative
programming are encouraged. The technical program of the conference
will combine presentations of the accepted papers with invited talks
and advanced tutorials.
PPDP 2001 is part of a federation of colloquia known as Principles,
Logics and Implementations of high-level programming languages
(PLI 2001) which includes the ACM SIGPLAN International Conference on
Functional Programming (ICFP 2001) and a large number of workshops
devoted to aspects of programming languages.
The colloquia will run from 2 to 8 September, 2001. The venue for the
conference is Firenze (Florence), one of Europe's most attractive
cities, famous for its churches, galleries and museums.
More details can be found on the conference web site.
Web Sites and Email Contact:
PPDP 2001: http://music.dsi.unifi.it/pli01/ppdp
PLI 2001: http://music.dsi.unifi.it/pli01
mailto:ppdp01@cs.mu.oz.au
Important Dates:
Submission 15 March 2001
Notification 7 May 2001
Final Version 11 June 2001
Conference Chair:
Rocco De Nicola, Universita di Firenze
http://www.dsi.unifi.it/~denicola/
mailto:denicola@dsi.unifi.it
Program Chair:
Harald Sondergaard, The University of Melbourne
http://www.cs.mu.oz.au/~harald/
mailto:harald@cs.mu.oz.au
Program Committee:
Maria Alpuente, Univ. Politecnica de Valencia, ES
Yves Caseau, Bouygues, FR
Michael Codish, Ben-Gurion Univ. of the Negev, IL
Saumya Debray, Univ. of Arizona, US
Conal Elliott, Microsoft Research, US
Sandro Etalle, Univ. Maastricht, NL
Roberto Giacobazzi, Univ. di Verona, IT
Michael Leuschel, Univ. of Southampton, GB
John Lloyd, Australian National Univ., AU
Torben Mogensen, Kobenhavns Univ., DK
Alan Mycroft, Cambridge Univ., GB
Gopalan Nadathur, Univ. of Minnesota, US
Martin Odersky, Ecole Polyt. Fed. Lausanne, CH
Catuscia Palamidessi, Penn State Univ., US
Andreas Podelski, Max-Planck-Inst. Informatik, DE
Kostis Sagonas, Uppsala Univ., SE
Christian Schulte, Univ. des Saarlandes, DE
Michael Schwartzbach, Aarhus Univ., DK
Harald Sondergaard, Univ. of Melbourne, AU
Peter J. Stuckey, Univ. of Melbourne, AU
From slucas@dsic.upv.es Thu Jan 18 10:59:43 2001
Date: Thu, 18 Jan 2001 11:59:43 +0100
From: Salvador Lucas Alba slucas@dsic.upv.es
Subject: WRS'2001 - First call for papers
[Apologies for multiple copies of this announcement]
**************************************************************
*************** first call for papers and participation
****************
**************************************************************
International Workshop on Reduction Strategies in Rewriting and
Programming (WRS 2001)
http://www.logic.at/wrs01/
held in conjunction with RTA 2001
Utrecht, The Netherlands, May 26, 2001
--------------------------------------------------------------------------
BACKGROUND AND AIMS
Reduction strategies in rewriting and programming have attracted an
increasing attention within the last years. New types of reduction
strategies have been invented and investigated, and new results on
rewriting / computation under particular strategies have
been obtained. Research in this field ranges from primarily
theoretical
questions about reduction strategies to very practical application and
implementation issues. The need for a deeper understanding of
reduction
strategies in rewriting and programming, both in theory and practice,
is obvious, since they bridge the gap between unrestricted general
rewriting (computation) and (more deterministic) rewriting with
particular strategies (programming). Moreover, reduction strategies
provide a natural way to go from operational principles (e.g., graph
and term rewriting, narrowing, lambda-calculus) and semantics (e.g.,
normalization, computation of values, infinitary normalization,
head-normalization) to implementations of programming
languages.
Therefore any progress in this area is likely to be of interest not
only to the rewriting community, but also to neighbouring fields like
functional programming, functional-logic programming, and termination
proofs of algorithms.
The workshop wants to provide a forum for the presentation and
discussion of new ideas and results, recent developments, new research
directions, as well as of surveys on existing knowledge in this
area. Furthermore we aim at fostering interaction and exchange between
researchers and students actively working on such topics.
The workshop will be held in conjunction with RTA 2001 in Utrecht (The
Netherlands) on May 26, 2001. It will feature 2 invited talks, a panel
discussion, and contributed presentations selected from the
submissions, with ample time for discussion.
The workshop is (co-)organized by U Utrecht, TU Valencia and TU Wien.
TOPICS OF INTEREST
Topics of interest include, but are not restricted to,
- theoretical foundations for the definition and semantic description
of reduction strategies
- strategies in different frameworks (term rewriting, graph rewriting,
infinitary rewriting, lambda calculi, higher order rewriting,
conditional rewriting, rewriting with built-ins, narrowing,
constraint solving, etc.) and their application in (equational,
functional, functional-logic) programming (languages)
- properties of reduction strategies / computations under
strategies (e.g., completeness, computability, decidability,
complexity, optimality, (hyper-)normalization, cofinality,
fairness, perpetuality, context-freeness, neededness, lazyness,
eagerness, strictness)
- interrelations, combinations and applications of
reduction under different strategies (e.g., equivalence
conditions for fundamental properties like termination and
confluence, applications in modularity analysis, connections
between strategies of different frameworks, etc.)
- program analysis and other semantics-based optimization techniques
dealing with reduction strategies
- rewrite systems / tools / implementations with flexible /
programmable strategies as essential concept / ingredient
- specification of reduction strategies in (real) languages
- data structures and implementation techniques for reduction
strategies.
SUBMISSIONS
We solicit papers on all aspects of reduction strategies in
rewriting and programming. Submissions should describe unpublished
work, except for survey papers which are explicitly welcome,
too. Submissions should not exceed 10 pages (however, survey papers
may be longer) and be sent in postscript format to the PC co-chairs
(wrs01@logic.at) by March 1, 2001. Selection of papers by the PC
will be based on originality, significance, and correctness.
Accepted papers will be included in the workshop proceedings that will
be available at the workshop, and electronically on the web.
Depending on the number and quality of submissions, formal publication
of the proceedings is envisaged.
Researchers just interested in attending the workshop may send a
corresponding email to wrs01@logic.at by March 1, 2001, preferably
together with a brief position paper (up to two pages in postscript)
describing their interest and/or work in the area. However, we will
also consider late requests for attendance.
INVITED TALKS
Richard Kennaway (UEA Norwich, UK):
(to be confirmed)
Eelco Visser (U Utrecht, The Netherlands):
A Survey of Strategies in Program Transformation Systems
PANEL DISCUSSION on ``Hot Topics in Reduction Strategies'' with
Michael Hanus U Kiel (Germany)
Tetsuo Ida U Tsukuba (Japan)
Paul Klint (to be confirmed) CWI & U Amsterdam (The Netherlands)
PROGRAM COMMITTEE
Maria Alpuente TU Valencia (Spain)
Rachid Echahed IMAG Grenoble (France)
Bernhard Gramlich (co-chair) TU Wien (Austria)
Salvador Lucas (co-chair) TU Valencia (Spain)
Vincent van Oostrom U Utrecht (The Netherlands)
Rinus Plasmeijer KU Nijmegen (The Netherlands)
Manfred Schmidt-Schauss U Frankfurt a.M. (Germany)
Yoshihito Toyama U Tohoku (Japan)
LOCAL ORGANIZATION
Vincent van Oostrom U Utrecht (The Netherlands)
IMPORTANT DATES
Submission March 1, 2001
Notification March 31, 2001
Final version April 30, 2001
Workshop May 26, 2001
FURTHER INFORMATION
workshop website http://www.logic.at/wrs01/
workshop email address wrs01@logic.at
**************************************************************************
From iscp9157@nus.edu.sg Thu Jan 18 13:16:03 2001
Date: Thu, 18 Jan 2001 21:16:03 +0800
From: Saswat Anand iscp9157@nus.edu.sg
Subject: A simple problem
class C a where
fun :: a -> Integer
instance C Integer where
fun x = x+ 1
with these definitons:
fun 3 --gives error in Hugs
fun (3::Integer) -- OK
I am a building an embedded language, so don't want user to cast. Is there a
solution?
Thanks,
Saswat
From igloo@earth.li Thu Jan 18 15:52:08 2001
Date: Thu, 18 Jan 2001 15:52:08 +0000
From: Ian Lynagh igloo@earth.li
Subject: MD5 in Haskell
On Wed, Jan 17, 2001 at 07:11:40PM +0000, Ian Lynagh wrote:
>
> I've put the code at http://c93.keble.ox.ac.uk/~ian/md5/
>
> License is GPL.
0.1.1 now there which changes the license to GPL/BSD so it can be used
as a drop-in replacement for the GHC code.
Ian
From burton@sfu.ca Thu Jan 18 22:53:00 2001
Date: Thu, 18 Jan 2001 14:53:00 -0800
From: F. Warren Burton burton@sfu.ca
Subject: Student Cheating?
How many readers of this list got a copy of the following? Did
somebody reading this list assign this problem?
Warren
>X-Originating-IP: [194.83.240.16]
>From: "Rachael Maguire" <rachael_maguire@hotmail.com>
>To: burton@cs.sfu.ca
>Subject: haskell programming problem
>Date: Thu, 18 Jan 2001 21:21:25 -0000
>X-OriginalArrivalTime: 18 Jan 2001 21:21:25.0578 (UTC)
>FILETIME=[9D03AAA0:01C08194]
>
>I come across your e-mail address via the haskell.org website. I am
>having some difficulty with the language and am wondering if you can
>help due to your programming experience in Haskell. Could you write
>me a small program to count the number of words and characters from
>a string (the strings contents would be specified in the script
>containing the Haskell code for this mall program). Also the program
>must justify the string. Could you send me some code for a program
>of this kind as I do not know any people with experience of Haskell
>programming .
>
>Any help would be much appreciated.
>Thanks in advance Rachael.
>_________________________________________________________________________
>Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
From ashley@semantic.org Thu Jan 18 23:38:10 2001
Date: Thu, 18 Jan 2001 15:38:10 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: A simple problem
At 2001-01-18 05:16, Saswat Anand wrote:
>class C a where
> fun :: a -> Integer
>
>instance C Integer where
> fun x = x+ 1
>
>with these definitons:
>
>fun 3 --gives error in Hugs
>fun (3::Integer) -- OK
>
>I am a building an embedded language, so don't want user to cast. Is there a
>solution?
3 is not always an Integer. It's of type "(Num a) => a".
I couldn't find a way to say that every Num is a C.
--
Ashley Yakeley, Seattle WA
From ashley@semantic.org Fri Jan 19 00:08:07 2001
Date: Thu, 18 Jan 2001 16:08:07 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: A simple problem
At 2001-01-18 15:38, I wrote:
>3 is not always an Integer. It's of type "(Num a) => a".
Of course, it would be nice if 3 were an Integer, and Integer were a
subtype of Real. I haven't come across a language that does this, where
for instance 3.0 can be cast to Integer (because it is one) but 3.1
cannot be.
--
Ashley Yakeley, Seattle WA
From paul.hudak@yale.edu Fri Jan 19 13:30:37 2001
Date: Fri, 19 Jan 2001 08:30:37 -0500
From: Paul Hudak paul.hudak@yale.edu
Subject: Student Cheating?
> How many readers of this list got a copy of the following? Did
> somebody reading this list assign this problem?
I just got a copy of her message, similar to yours, but with a bunch of
code at the end that looks well written, so clearly it wasn't hers. But
she still couldn't get it to work, and asked, "Could you give me some
code to add to the end of the code below." :-) Pretty sad, despite the
smiley.
-Paul
From jans@numeric-quest.com Fri Jan 19 16:52:58 2001
Date: Fri, 19 Jan 2001 11:52:58 -0500 (EST)
From: Jan Skibinski jans@numeric-quest.com
Subject: Haskell Module Browser with code
Classes available from the description page at
http://www.numeric-quest.com/haskell/explorer/browser.html
Works in Squeak. Supports Hugs and NHC. Support for other
environments is planned. Hugs Module Browser is good only for
Linux/Unix users due to current lack of a support for pipes
and processes in Mac/Windows. NHC Module Browser should work
in any environment since it does not need to communicate with
external processes.
This is the interim release, far from being finished, not
optimized, with some glitches and unfinished design.
Jan
From igloo@earth.li Sat Jan 20 21:17:43 2001
Date: Sat, 20 Jan 2001 21:17:43 +0000
From: Ian Lynagh igloo@earth.li
Subject: Doing IO in foldr repeats lines?
Hi all
The following code:
> module Main (main) where
> import IO
> main :: IO()
> main = do _ <- foldl foo (return 14) ["qq\n", "ww\n", "ee\n"]
> putStr ""
> foo :: IO Int -> String -> IO Int
> foo io_l s = do l <- io_l
> () <- putStr s
> io_l
prints (with both GHC and hugs):
qq
ww
qq
ee
qq
ww
qq
and I really don't understand why. Is the code re-evaluated every time
foldl is expanded or something?
Thanks
Ian, confused
From p.turner@computer.org Sat Jan 20 22:08:48 2001
Date: Sat, 20 Jan 2001 17:08:48 -0500
From: Scott Turner p.turner@computer.org
Subject: Doing IO in foldr repeats lines?
At 21:17 2001-01-20 +0000, Ian Lynagh wrote:
> main = do _ <- foldl foo (return 14) ["qq\n", "ww\n", "ee\n"]
> putStr ""
>
> foo :: IO Int -> String -> IO Int
> foo io_l s = do l <- io_l
> () <- putStr s
> io_l
It repeats lines
>and I really don't understand why. Is the code re-evaluated every time
>foldl is expanded or something?
Since the result type of foo is IO Int, it is building an IO action, in
other words it is calculating a sequence of effects. The combined effects
are performed by main.
Repetition occurs due to the structure of foo. Notice that its action
consists of first performing io_l, then putting a string, and then
performing io_l _again_. If io_l prints the lines qq, ww, and qq, then the
result will involve two such triplets.
Try this. Remove either of the occurrences of io_l from the do block, and
you will see quite different results.
--
Scott Turner
p.turner@computer.org http://www.billygoat.org/pkturner
From igloo@earth.li Sat Jan 20 22:25:18 2001
Date: Sat, 20 Jan 2001 22:25:18 +0000
From: Ian Lynagh igloo@earth.li
Subject: Doing IO in foldr repeats lines?
On Sat, Jan 20, 2001 at 05:08:48PM -0500, Scott Turner wrote:
> At 21:17 2001-01-20 +0000, Ian Lynagh wrote:
> > main = do _ <- foldl foo (return 14) ["qq\n", "ww\n", "ee\n"]
> > putStr ""
> >
> > foo :: IO Int -> String -> IO Int
> > foo io_l s = do l <- io_l
> > () <- putStr s
> > io_l
>
> It repeats lines
> >and I really don't understand why. Is the code re-evaluated every time
> >foldl is expanded or something?
>
> Since the result type of foo is IO Int, it is building an IO action, in
> other words it is calculating a sequence of effects. The combined effects
> are performed by main.
Thanks, a private mail showing the evaluation highlighted my stupidity
wonderfully :-)
I now see what's going on and a return l instead of io_l as the last
line is what I wanted. The mixture of io_l and return bar also explains
why I was seeing really random looking output unlike the nice pattern
of the more minimal case :-)
Thanks
Ian
From simonpj@microsoft.com Sat Jan 20 13:09:58 2001
Date: Sat, 20 Jan 2001 05:09:58 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Combinator library gets software prize
You might enjoy this article, in Risk Magazine, a journal
of the financial engineering industry. Combinators in the real
world!
http://www.risk.net/riskawards2001/softwareproduct.htm
Simon
From guerby@acm.org Sun Jan 21 10:31:37 2001
Date: Sun, 21 Jan 2001 11:31:37 +0100
From: Laurent Guerby guerby@acm.org
Subject: Combinator library gets software prize
I don't know if Simon mentionned it but I found his & al. paper
proceedings of the fifth ACM SIGPLAN international conference on on
Functional programming, "Composing contracts: an adventure in
financial engineering (functional pearl) Pages 280-292" very
interesting:
http://www.acm.org/pubs/citations/proceedings/fp/351240/p280-jones/
--
Laurent Guerby <guerby@acm.org>
From davidbak@microsoft.com Sun Jan 21 18:57:19 2001
Date: Sun, 21 Jan 2001 10:57:19 -0800
From: David Bakin davidbak@microsoft.com
Subject: Combinator library gets software prize
This article is very good, and having read the conference paper earlier
in the year I finished it with only one question: What's a 'quant' ...
and is it good or bad to be one?
"Ten years ago, Jean-Marc Eber, then a quant at Soci=E9t=E9
G=E9n=E9rale, ..."
-- Dave
-----Original Message-----
From: Simon Peyton-Jones
Sent: Saturday, January 20, 2001 5:10 AM
To: haskell@haskell.org
Subject: Combinator library gets software prize
You might enjoy this article, in Risk Magazine, a journal
of the financial engineering industry. Combinators in the real
world!
http://www.risk.net/riskawards2001/softwareproduct.htm
<http://www.risk.net/riskawards2001/softwareproduct.htm>=20
Simon
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
<http://www.haskell.org/mailman/listinfo/haskell>=20
From ashley@semantic.org Sun Jan 21 22:55:43 2001
Date: Sun, 21 Jan 2001 14:55:43 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: Combinator library gets software prize
At 2001-01-21 10:57, David Bakin wrote:
>What's a 'quant' ...
>and is it good or bad to be one?
I think that depends on exactly how much of a quant you are.
--
Ashley Yakeley, Seattle WA
From jf15@hermes.cam.ac.uk Mon Jan 22 10:55:03 2001
Date: Mon, 22 Jan 2001 10:55:03 +0000 (GMT)
From: Jon Fairbairn jf15@hermes.cam.ac.uk
Subject: Combinator library gets software prize
On Sun, 21 Jan 2001, David Bakin wrote:
> This article is very good, and having read the conference paper earlier
> in the year I finished it with only one question: What's a 'quant' ...
> and is it good or bad to be one?
>=20
> "Ten years ago, Jean-Marc Eber, then a quant at Soci=E9t=E9
> G=E9n=E9rale, ..."
The OED has:
1. A pole for propelling a barge, esp. one with a cap at
the top and a prong at the bottom to
prevent it from sinking in mud. Also attrib., as quant-pole.
and
2. In a windmill:=20
1924 Trans. Newcomen Soc. III. 42 All the framing and
gearing of these mills are of wood, the only important parts
of iron being the wrought iron gudgeons upon which the
shafts revolve, and perhaps the `quants' or spindles which
drove the runner stones.
So perhaps he was tall, thin and fond of wearing a cap?
:-)
--=20
J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.uk
31 Chalmers Road jf@cl.cam.ac.uk
Cambridge CB1 3SZ +44 1223 570179 (pm only, please)
From john@launchbury.org Mon Jan 22 11:43:16 2001
Date: Mon, 22 Jan 2001 11:43:16 +0000
From: John Launchbury john@launchbury.org
Subject: fixity for (\\)
I agree with Koen: \\ is list subtraction and we're all used to subtraction being left associative.
John.
Jon Fairbairn wrote:
>
> On Wed, 17 Jan 2001, Koen Claessen wrote:
> > I propose that it gets the following fixity:
> >
> > infixl 5 \\
>
> Unless the it's common usage outside of Haskell, I oppose!
>
> Getting
>
> List> [1,2,3]\\[2]\\[3]
> ERROR: Ambiguous use of operator "(\\)" with "(\\)"
>
> at compile time does no harm, but getting [1] instead of
> [1,3] _at run time_ does do harm.
> Jón
> --
> Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
> 31 Chalmers Road jf@cl.cam.ac.uk
> Cambridge CB1 3SZ +44 1223 570179 (pm only, please)
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From C.Reinke@ukc.ac.uk Mon Jan 22 13:45:12 2001
Date: Mon, 22 Jan 2001 13:45:12 +0000
From: C.Reinke C.Reinke@ukc.ac.uk
Subject: Combinator library gets software prize
> > This article is very good, and having read the conference paper earlier
> > in the year I finished it with only one question: What's a 'quant' ...
> > and is it good or bad to be one?
> >
> > "Ten years ago, Jean-Marc Eber, then a quant at Société
> > Générale, ..."
>
> The OED has:
..
> So perhaps he was tall, thin and fond of wearing a cap?
>
> :-)
You might want to try
http://www.dictionary.com/cgi-bin/dict.pl?term=quant
An expert in the use of mathematics and related subjects,
particularly in investment management and stock trading.
...
http://www.investorwords.com/q1.htm#quant
One who performs quantitative analyses. Or more generally, a
securities analyst.
Am I the only one who finds the exclusive emphasis on combinator
languages slightly disappointing (in fact, the article seems to equate
functional language with domain-specific combinator languages, which is
more than a bit mistleading)?
This is a Haskell forum, not one on Backus' FP, so readers are well
aware of the advantages of functional abstraction. Domain-specific
languages, if embedded in Haskell, tend to inherit these advantages,
even if the language in question was designed as a pure combinator
language.
The consequence (and the intention, as far as one can gather from the
paper) of the limitation to combinators is that this language can and
will be used mainly in non-functional languages, not inheriting all
that much from a functional style of programming. The same will
probably hold for any communication standards based on it.
This appplication is undoubtely a success and a good step forward,
but there is more to functional languages.
The paper somewhat downplays the role of embedding the combinator-based
DSL in a full functional language while also mentioning that some
features gained for free in the Haskell prototype considerably
complicate implementations in other languages. I would be interested
to hear more about these aspects:
- Is the strictly combinator-based approach a pragmatic necessity
("one step at a time") or is there no need for more advanced
features (especially abstraction) in the application area?
- Has there been a comparison of the way the combinators of the
DSL are used in Haskell and in other implementations?
I would think that the use of abstraction to define more complex
instruments in terms of the basic combinators should play a rather
dominant role. On the other hand, I can imagine that users would
want to have each complex instrument explicitly named and studied,
instead of trusting large amounts of money to anonymous
abstractions created on-the-fly.
- What about interactive exploration of new instruments, e.g., in a
Hugs or OCaml session (as opposed to changing a C++ implementation,
or a stand-alone executable generated by an OCaml compiler, for
every experiment)?
Claus
From Keith.Wansbrough@cl.cam.ac.uk Mon Jan 22 16:42:32 2001
Date: Mon, 22 Jan 2001 16:42:32 +0000
From: Keith Wansbrough Keith.Wansbrough@cl.cam.ac.uk
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
> With all this talk of preprocessor generated information and whatnot, I
> am reminded of a paper I read not too long ago but can't seem to find
> anymore about a dedicated pre-processor for haskell based on the C
> preprocessor but made to deal with haskell constructs a bit more sanely.
This was me...
http://www.cl.cam.ac.uk/~kw217/research/papers.html#Wansbrough99:Macros
There wasn't sufficient interest, and no one has offered to implement
it. I think people are mostly happy using CPP, and the hassle of
writing a `decent' macro preprocessor isn't worth it. You may find
some of the ideas in the paper useful, though.
--KW 8-)
From EricShade@smsu.edu Mon Jan 22 17:19:42 2001
Date: Mon, 22 Jan 2001 11:19:42 -0600
From: Eric Shade EricShade@smsu.edu
Subject: Specifications of 'any', 'all', 'findIndices'
I have some questions about the specifications of 'any', 'all', and
'findIndices' in the Haskell 98 reports. The specifications of 'any'
and 'all' are
any p = or . map p
all p = and . map p
While this is correct, it seems to me that it generates a lot of
garbage because map will produce a list of Booleans until 'any' sees a
True or 'all' sees a False. 'elem' and 'notElem' inherit the problem
because they're defined in terms of 'any' and 'all'. I realize that
this is only a specification, but Hugs at least uses this as its
implementation. It seems clearer and more efficient to me to use the
following definitions:
any p [] = False
any p (x:xs) = p x || any p xs
all p [] = True
all p (x:xs) = p x && all p xs
leave 'elem' and 'notElem' as is, then define
and = notElem False
or = elem True
There is a similar problem with findIndices, whose specification is
findIndices p xs = [i | (x,i) <- zip xs [0..], p x]
While this is admittedly cool, it also seems to generate a lot of
garbage by producing pairs only to throw them away.
I'm not yet up to speed on the implementation of lazy functional
languages, so it may be that in all of these cases the compiler can
easily optimize away the garbage. If so, it would be nice to see some
documentation for non-wizards that explains what kinds of
optimizations one can reasonably expect (like tail-recursion
elimination in Scheme).
Even if the apparent inefficiencies melt away, I think that my
versions of 'any', 'all', 'and', and 'or' are clearer as specification
than the current ones.
--
Dr. Eric Shade, Associate Professor
Computer Science Department (CSAB Accredited)
Southwest Missouri State University
From uk1o@rz.uni-karlsruhe.de Mon Jan 22 21:29:50 2001
Date: Mon, 22 Jan 2001 22:29:50 +0100
From: Hannah Schroeter uk1o@rz.uni-karlsruhe.de
Subject: Specifications of 'any', 'all', 'findIndices'
Hello!
On Mon, Jan 22, 2001 at 11:19:42AM -0600, Eric Shade wrote:
> I have some questions about the specifications of 'any', 'all', and
> 'findIndices' in the Haskell 98 reports. The specifications of 'any'
> and 'all' are
> any p = or . map p
> all p = and . map p
> While this is correct, it seems to me that it generates a lot of
> garbage because map will produce a list of Booleans until 'any' sees a
> True or 'all' sees a False. 'elem' and 'notElem' inherit the problem
> because they're defined in terms of 'any' and 'all'. I realize that
> this is only a specification, but Hugs at least uses this as its
> implementation. It seems clearer and more efficient to me to use the
> following definitions:
> any p [] = False
> any p (x:xs) = p x || any p xs
> all p [] = True
> all p (x:xs) = p x && all p xs
> leave 'elem' and 'notElem' as is, then define
> and = notElem False
> or = elem True
> There is a similar problem with findIndices, whose specification is
> findIndices p xs = [i | (x,i) <- zip xs [0..], p x]
> While this is admittedly cool, it also seems to generate a lot of
> garbage by producing pairs only to throw them away.
> I'm not yet up to speed on the implementation of lazy functional
> languages, so it may be that in all of these cases the compiler can
> easily optimize away the garbage. If so, it would be nice to see some
> documentation for non-wizards that explains what kinds of
> optimizations one can reasonably expect (like tail-recursion
> elimination in Scheme).
Depends on the implementation. GHC might remove some of the garbage,
at least, see the GHC documentation ("good producers"/"good consumers"/
"cheap deforestation").
> Even if the apparent inefficiencies melt away, I think that my
> versions of 'any', 'all', 'and', and 'or' are clearer as specification
> than the current ones.
I don't think so. The specifications are quite concise.
Kind regards,
Hannah.
From timd@macquarie.com.au Mon Jan 22 22:05:02 2001
Date: Tue, 23 Jan 2001 09:05:02 +1100 (EST)
From: Timothy Docker timd@macquarie.com.au
Subject: Combinator library gets software prize
> Am I the only one who finds the exclusive emphasis on combinator
> languages slightly disappointing (in fact, the article seems to equate
> functional language with domain-specific combinator languages, which is
> more than a bit mistleading)?
What declarative approach(es) (other than combinators) are you
referring to here?
> The consequence (and the intention, as far as one can gather from the
> paper) of the limitation to combinators is that this language can and
> will be used mainly in non-functional languages, not inheriting all
> that much from a functional style of programming. The same will
> probably hold for any communication standards based on it.
Why is that? I'm new to the functional programming world, and haven't
reallystruck the concept of combinator libraries elsewhere. I assumed
they were largely a functional programming concept. Even though I can
see how they could be implemented in imperative languages, it doesn't
seem that they would be a nice fit.
> [Several interesting elided]
More generally, is there any more information or forums on declarative
approaches to financial engineering? I found this paper intriguing, as
it focuses on both my current academic interests, and my work!
Tim
From joe@isun.informatik.uni-leipzig.de Tue Jan 23 07:28:41 2001
Date: Tue, 23 Jan 2001 08:28:41 +0100 (MET)
From: Johannes Waldmann joe@isun.informatik.uni-leipzig.de
Subject: Specifications of 'any', 'all', 'findIndices'
I think a specification
> any p = or . map p
is much more concise than the implementation
> any p [] = False
> any p (x:xs) = p x || any p xs
another reason to prefer the higher-level variant
is that the compiler can apply fusion laws, as in
any p . map f = or . map p . map f = or . map (p . f)
(one could also do this starting from the second definition,
but then the compiler's first step would be to derive the
higher-level version from it, I guess)
so it's not at all clear that the above implementation
is indeed more efficient.
I'd rather write clear code, than worry about efficiency too early.
Who said this, "premature optimization is the root of all evil".
best regards
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From karczma@info.unicaen.fr Tue Jan 23 09:50:37 2001
Date: Tue, 23 Jan 2001 09:50:37 +0000
From: Jerzy Karczmarczuk karczma@info.unicaen.fr
Subject: Specifications of 'any', 'all', 'findIndices'
Hannah Schroeter wrote:
> Eric Shade wrote:
> > I have some questions about the specifications of 'any', 'all', and
> > 'findIndices'
...
> > any p = or . map p
> > all p = and . map p
> > ...It seems clearer and more efficient to me to use the
> > following definitions:
>
> > any p [] = False
> > any p (x:xs) = p x || any p xs
>
> > all p [] = True
> > all p (x:xs) = p x && all p xs
...
> > Even if the apparent inefficiencies melt away, I think that my
> > versions of 'any', 'all', 'and', and 'or' are clearer as
> > specification
> > than the current ones.
>
> I don't think so. The specifications are quite concise.
> Hannah.
Just a moment, please. Do we speak about "concise" or "clear"?
Johannes Waldman makes the same fusion, first saying that it
is concise, and terminating with a statement on clear programming.
Personally I am a convinced lazy programmer, I adore concise
and obfuscated style, and I used with some internal pleasure the
original definitions, until I started using Haskell for teaching.
(I do not teach Haskell, we *use* it on compilation stuff, some-
times on some graphics projects, and they have to learn it
"off-line".) THREE TIMES I've been asked about that. Somebody
quite clever remarked that any or all are *typical* cases for
fold rather than for map.
There is plenty of historical accidents in the standard prelude.
[I won't complain any more about the Num stuff...]
Johannes Waldmann last sentence:
> Who said this, "premature optimization is the root of all evil".
Who said that what Eric Shade proposes is an evil optimization,
while a curried "pearl": "any p = or . map p" is a nice shorthand,
plenty of vitamines, especially for beginners.
BTW., why not promote something like
any = (or .) . map
to make everybody happy?
Jerzy Karczmarczuk
Caen, France
PS. Johannes Waldman raises some doubts:
> so it's not at all clear that the above implementation
> is indeed more efficient.
Please, don't speculate. If you have something to say in this
context, perform some tests. I did it with Hugs. Eric Shade
implementation seems to be indeed more efficient, but very
slightly (on my test, I won't claim anything general).
From koen@cs.chalmers.se Tue Jan 23 11:30:12 2001
Date: Tue, 23 Jan 2001 12:30:12 +0100 (MET)
From: Koen Claessen koen@cs.chalmers.se
Subject: Specifications of 'any', 'all', 'findIndices'
Eric Shade wondered:
| I have some questions about the specifications of
| 'any', 'all', and 'findIndices' in the Haskell 98
| reports. [...] it seems to me that it generates a lot
| of garbage because map will produce a list of Booleans
| [...]
Several people have already commented on this. What I want
to add is the following.
The definitions in the Haskell report are a *specification*,
not an implementation. It probably depends on the compiler
which particular implementation runs faster.
Therefore, the Haskell report provides a clear (yes, this is
debatable) *possible* implementation, and the compiler
writer is free to implement this in whatever way (s)he
likes. As long as the implementation has the same functional
behavior as the specification in the report.
/Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
From lisper@it.kth.se Tue Jan 23 11:43:28 2001
Date: Tue, 23 Jan 2001 12:43:28 +0100 (MET)
From: Bjorn Lisper lisper@it.kth.se
Subject: Specifications of 'any', 'all', 'findIndices'
Koen:
>The definitions in the Haskell report are a *specification*,
>not an implementation. It probably depends on the compiler
>which particular implementation runs faster.
>Therefore, the Haskell report provides a clear (yes, this is
>debatable) *possible* implementation, and the compiler
>writer is free to implement this in whatever way (s)he
>likes. As long as the implementation has the same functional
>behavior as the specification in the report.
Hear, hear. What I in turn would like to add is that specifications like
any p = or . map p
are on a higher level of abstraction than definitions like
any p [] = False
any p (x:xs) = p x || any p xs
This makes it easier to find different implementations, which makes it
easier to adapt the implementation to fit different architectures. The first
specification is, for instance, directly data parallel which facilitates an
implementation on a parallel machine or in hardware.
Björn Lisper
From karczma@info.unicaen.fr Tue Jan 23 13:09:59 2001
Date: Tue, 23 Jan 2001 13:09:59 +0000
From: Jerzy Karczmarczuk karczma@info.unicaen.fr
Subject: Specifications of 'any', 'all', 'findIndices'
Koen Claessen wrote:
(about the definitions of any, all, etc.)
> The definitions in the Haskell report are a *specification*,
> not an implementation. It probably depends on the compiler
> which particular implementation runs faster.
>
> Therefore, the Haskell report provides a clear (yes, this is
> debatable) *possible* implementation, and the compiler
> writer is free to implement this in whatever way (s)he
> likes. As long as the implementation has the same functional
> behavior as the specification in the report.
I am sorry, but
any p = or . map p
is not an implementation-neutral specification, a
*functional* specification. This is a very concrete way
of doing things. As everybody knows, this is a folding process.
Of course, 'or' uses (normally, again, according to the Report
if I am not mistaken) 'foldr', and it is essentially trivial
to get rid of 'map', putting (||) and 'p' together in the
fold function, but:
1. Perhaps it is too optimistic to think that the compilers will
to that optimisation by themselves. Hugs uses literally this
"specification"
2. I maintain my opinion that from the pedagogical point of view
this definition is imperfect. I think that the specification
should say no more nor less what 'any', 'notElem' etc. functions
provide, and put (possibly) in the Report that possible
implementations are (...)
But the generation of this "garbage", the intermediate list of
booleans, whether real or virtual only, goes beyond the semantics
of 'all', etc.
As Koen said, several people already commented on that.
And, I am afraid that this will continue. I can promise
you that...
Bjorn Lisper adds:
> ... What I in turn would like to add is that specifications like
>
> any p = or . map p
>
> are on a higher level of abstraction than definitions like
>
> any p [] = False
> any p (x:xs) = p x || any p xs
>
> This makes it easier to find different implementations, which makes it
> easier to adapt the implementation to fit different architectures.
> The first specification is, for instance, directly data parallel
> which facilitates an implementation on a parallel machine or in hardware.
>
> Björn Lisper
Pardon?
map is data parallel. foldr not so obviously...
I am not sure about this higher level of abstraction. Unless, of course,
we want to use generalized, monadic maps, but then, also folds. And
we will produce, say, trees of boolean garbage instead of lists.
Jerzy Karczmarczuk
From lisper@it.kth.se Tue Jan 23 12:52:41 2001
Date: Tue, 23 Jan 2001 13:52:41 +0100 (MET)
From: Bjorn Lisper lisper@it.kth.se
Subject: Specifications of 'any', 'all', 'findIndices'
>Pardon?
>map is data parallel. foldr not so obviously...
Sorry, a slip on my behalf: foldr in general is not data parallel, but if
the function being folded with is associative then foldr can be implemented
by a parallel (balanced binary-tree) reduction in time O(log n), where n is
the length of the list.
A compiler needs the information that or is a fold over an associative
operation in order to employ such a parallel implementation.
Björn Lisper
From rossberg@ps.uni-sb.de Tue Jan 23 14:04:40 2001
Date: Tue, 23 Jan 2001 15:04:40 +0100
From: Andreas Rossberg rossberg@ps.uni-sb.de
Subject: Doing IO in foldr repeats lines?
Ian Lynagh wrote:
>
> > main :: IO()
> > main = do _ <- foldl foo (return 14) ["qq\n", "ww\n", "ee\n"]
> > putStr ""
>
> > foo :: IO Int -> String -> IO Int
> > foo io_l s = do l <- io_l
> > () <- putStr s
> > io_l
>
> prints (with both GHC and hugs):
>
> qq
> ww
> qq
> ee
> qq
> ww
> qq
>
> and I really don't understand why. Is the code re-evaluated every time
> foldl is expanded or something?
Nobody seems to have answered yet, so I try to explain it.
Look at your definition of foo: it actually duplicates its argument
action io_l. For the first application io_l is (return 14). Let's call
that io_l0. The resulting action is
io_l1 = do { l <- return 14; () <- putStr "qq"; return 14 }
which is passed at the next application. The result is
io_l2 = do { l <- do { l <- return 14; () <- putStr "qq"; return 14 }
; () <- putStr "ww"
; do { l <- return 14; () <- putStr "qq"; return 14 }
}
This can be reformulated as
io_l2'= do { l <- return 14
; () <- putStr "qq"
; l <- return 14
; () <- putStr "ww"
; l <- return 14
; () <- putStr "qq"
; return 14
}
And so on. Finally the complete action (io_l3) is executed by running
main and produces the output you observe.
Hope this helps,
- Andreas
--
Andreas Rossberg, rossberg@ps.uni-sb.de
:: be declarative. be functional. just be. ::
From mark.tullsen@yale.edu Tue Jan 23 18:11:33 2001
Date: Tue, 23 Jan 2001 13:11:33 -0500
From: Mark Tullsen mark.tullsen@yale.edu
Subject: Specifications of 'any', 'all', 'findIndices'
Johannes Waldmann wrote:
> ...
> I'd rather write clear code, than worry about efficiency too early.
> Who said this, "premature optimization is the root of all evil".
I've always attributed this to Donald Knuth:
Premature optimization is the root of all evil in programming.
Though I can't confirm it. I do find this similar statement
in his "Structured Programming with go to Statements"
(Computing Surveys 6 4, Dec 1974):
... premature emphasis on efficiency is a big mistake
which may well be the source of most programming complexity
and grief.
Note also one of Alan Perlis's epigrams:
Optimization hinders evolution.
(See http://www.cs.yale.edu/homes/perlis-alan/quotes.html)
- Mark Tullsen
From EricShade@smsu.edu Tue Jan 23 18:35:19 2001
Date: Tue, 23 Jan 2001 12:35:19 -0600
From: Eric Shade EricShade@smsu.edu
Subject: 'any' and 'all' compared with the rest of the Report
I didn't mean to get into a discussion about 'specification
vs. implementation' or 'clarity vs. conciseness', although those are
important distinctions. In my original post I didn't do a good job of
putting my objections in the proper context, so let me take one more
whack at it and then I'll leave it alone.
As a newcomer to Haskell, I read the entire Report, including all of
the purely functional code in the Prelude and Libraries (I glossed
over the monadic stuff initially). The code is not only clear as a
*specification*, but also seems perfectly suitable as a default
*implementation*. All the code seemed to have the time and space
requirements that one would expect.
Then I get to 'any' and 'all', whose specification requires linear
time and *linear* space when it should run in constant space. (By the
way, I checked and GHC does *not* use the Prelude definitions but
rather the obvious recursive ones, and most of its optimizations based
on "good consumers/producers" use meta-linguistic rewrite rules. So
without knowing the specific optimizations that a compiler provides, I
think it's safe to assume that the Prelude 'any' and 'all' *will*
require linear space.)
This is jarring; all the other code is clear *and* efficient, but
'any' and 'all' are not. I start to question whether I really
understand the language after all. (Do 'or' and 'map' work
differently than I thought? Did I misunderstand laziness? ...) After
all, why would the authors (who presumably know more about the
language than anyone on the planet) intentionally provide inefficient
code in *this* case when they provided efficient code for all the
*other* functions? This is why I don't think that the specifications
are good; they're OK in isolation but not in the context of the rest
of the Report. For me (and apparently for others), these
specifications didn't enhance my understanding; they led me to
question it.
I know that the Report clearly says that these are just
specifications, but that's one short paragraph. When I read 20 pages
of code that appears to be reasonably efficient as well, I assume that
that's by design and not accident. It would be one thing if the
Report were littered with functions whose specifications were
obviously not intended as implementations. But 'any', 'all', and
'findIndices' were the only inefficient ones I noticed out of the
entire Report.
And it's obvious that clarity is not the only goal in the
specifications. For example, why bother to write a messy O(log n)
version of x^n when the following is more clear *and* more concise?
x ^ n | n >= 0 = product (replicate n x)
_ ^ _ = error "Prelude.^: negative exponent"
Since the specifications of 'any' and 'all' are part of the Report,
they are part of the documentation for the language. They should be
judged by how well they help people understand the language. The
direct recursive versions, though slightly less concise, are equally
clear and will not cause any confusion. That's why I prefer them.
--
Dr. Eric Shade, Associate Professor
Computer Science Department (CSAB Accredited)
Southwest Missouri State University
From shlomif@vipe.technion.ac.il Tue Jan 23 18:56:49 2001
Date: Tue, 23 Jan 2001 20:56:49 +0200 (IST)
From: Shlomi Fish shlomif@vipe.technion.ac.il
Subject: Accpeting command-line arguments in GHC/Hugs
How can I read the command-line arguments passed to the program. For
instance, if I run my compiled program by typing "./foo hello -o
file.txt", I wish to access the list ["hello", "-o", "file.txt"] somehow.
TIA,
Shlomi Fish
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From herrmann@infosun.fmi.uni-passau.de Tue Jan 23 19:22:07 2001
Date: Tue, 23 Jan 2001 20:22:07 +0100 (MET)
From: Ch. A. Herrmann herrmann@infosun.fmi.uni-passau.de
Subject: 'any' and 'all' compared with the rest of the Report
Hi,
Eric> use meta-linguistic rewrite rules. So without knowing the
Eric> specific optimizations that a compiler provides, I think it's
Eric> safe to assume that the Prelude 'any' and 'all' *will* require
Eric> linear space.)
I don't hope so. If (||) and (&&) are implemented short circuiting,
and = foldr (&&) True
or = foldr (||) False
"foldr", if applied lazily, will stop producing the list as soon
as the outcome is available. (This will not be possible with
"foldl" which is to be preferred for reductions with a strict
operation.) Short circuiting means that (&&) or (||) will not
force evaluation of their second argument if not necessary and
it even should mean that they drop the space for their first argument
as soon as they force evaluation of their second.
(&&) x y = if x then y else False
(||) x y = if x then True else y
should forget everything about x as soon as the case
is determined.
Laziness of "map" in
any, all :: (a -> Bool) -> [a] -> Bool
any p = or . map p
all p = and . map p
will produce the list also only as far as it is required by
"or" resp. "and".
Thus, there should be no significant efficiency differences between
the explicitly recursive definition and the "foldr" definition.
However, there is a methodical difference. Consider a data type with
10 or 20 constructors (instead of 2). Do you like always to give a
definition for each case seperately?
Christoph
--
Christoph Herrmann
E-mail: herrmann@fmi.uni-passau.de
WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html
From senganb@ia.nsc.com Tue Jan 23 19:27:08 2001
Date: Tue, 23 Jan 2001 14:27:08 -0500
From: Sengan senganb@ia.nsc.com
Subject: Accpeting command-line arguments in GHC/Hugs
Shlomi Fish wrote:
>
> How can I read the command-line arguments passed to the program. For
> instance, if I run my compiled program by typing "./foo hello -o
> file.txt", I wish to access the list ["hello", "-o", "file.txt"] somehow.
> module Main (main) where
> import System
> main = getArgs >>= \args -> hugsMain args
> hugsMain :: [String] -> IO ()
> hugsMain = print
ghc Main.lhs
a.out foo bar --help
["foo","bar","--help"]
Sengan
From Sven.Panne@informatik.uni-muenchen.de Tue Jan 23 22:15:10 2001
Date: Tue, 23 Jan 2001 23:15:10 +0100
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: Accpeting command-line arguments in GHC/Hugs
Shlomi Fish wrote:
> How can I read the command-line arguments passed to the program. [...]
As already pointed out, System.getArgs is the basically the way to go.
If you want to use the list returned by it comfortably, see:
http://www.haskell.org/ghc/docs/latest/set/sec-util.html#SEC-GETOPT
Cheers,
Sven
From uk1o@rz.uni-karlsruhe.de Tue Jan 23 22:19:20 2001
Date: Tue, 23 Jan 2001 23:19:20 +0100
From: Hannah Schroeter uk1o@rz.uni-karlsruhe.de
Subject: Specifications of 'any', 'all', 'findIndices'
Hello!
On Tue, Jan 23, 2001 at 09:50:37AM +0000, Jerzy Karczmarczuk wrote:
> Hannah Schroeter wrote:
> > Eric Shade wrote:
> [...]
> > I don't think so. The specifications are quite concise.
> > Hannah.
> Just a moment, please. Do we speak about "concise" or "clear"?
I really probably spoke about "clear". However, I'm not a native
English speaker so I wasn't aware of the difference between those
two words until just now, when I looked them up.
In this case, I find
any p = or . map p
rather clear, and almost as concise as it can get (any = (or .) . map even
is shorter, thus perhaps more concise, but IMHO less clear for people
not so apt in a combinatorial style).
> [...]
> "off-line".) THREE TIMES I've been asked about that. Somebody
> quite clever remarked that any or all are *typical* cases for
> fold rather than for map.
You / they probably mean something like this:
any p = foldr (\ elem temp_res = p elem || temp_res) False
> [...]
> Please, don't speculate. If you have something to say in this
> context, perform some tests. I did it with Hugs. Eric Shade
> implementation seems to be indeed more efficient, but very
> slightly (on my test, I won't claim anything general).
Hugs is only a good test for --- hugs :-)
However, just tested with GHC and results were these:
hannah@c3po:/tmp $ cat x.hs
my_any p = or . map p
main =
print (my_any (== 0) [1..10000000])
hannah@c3po:/tmp $ time ./x
False
real 0m6.003s
user 0m5.917s
sys 0m0.024s
hannah@c3po:/tmp $ cat y.hs
my_any p [] = False
my_any p (x:xs) = p x || my_any p xs
main =
print (my_any (== 0) [1..10000000])
hannah@c3po:/tmp $ time ./y
False
real 0m4.403s
user 0m4.330s
sys 0m0.016s
GHC was 4.08.
Kind regards,
Hannah.
From EricShade@smsu.edu Tue Jan 23 22:38:57 2001
Date: Tue, 23 Jan 2001 16:38:57 -0600
From: Eric Shade EricShade@smsu.edu
Subject: Actual GHC memory usage for versions of 'any'
My questions about 'any' and 'all' really had more to do with pedagogy
than anything else, but now that I got GHC figured out, I ran some
tests using their profiler. I used version 4.08 on FreeBSD 4.2 and
did not enable optimization. I called the function 'atLeastOne'
instead of 'any' just to make sure I didn't confuse myself.
Prelude Version
---------------
GHC's default 'any' and 'or' differ from the Prelude specification, so
I wrote the equivalent versions by hand.
> default (Int)
> main = print (atLeastOne (> 1000000) [0..999999])
> atLeastOne :: (a -> Bool) -> [a] -> Bool
> atLeastOne p = foldr (||) False . map p
Here are the results:
Tue Jan 23 16:01 2001 Time and Allocation Profiling Report (Final)
foo +RTS -p -RTS
total time = 1.16 secs (58 ticks @ 20 ms)
total alloc = 88,001,188 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
atLeastOne Main 63.8 54.5
main Main 36.2 45.5
SYSTEM MAIN 17.2 0.1
Total allocation due to atLeastOne: 0.545 * 88001188 = 47,960,647 bytes
Recursive Version
-----------------
I wrote 'atLeastOne' by hand so that it wouldn't use GHC's builtin
version, which has rewrite rules that may allow better optimization.
> default (Int)
> main = print (atLeastOne (> 1000000) [0..999999])
> atLeastOne :: (a -> Bool) -> [a] -> Bool
> atLeastOne _ [] = False
> atLeastOne p (x:xs) = p x || atLeastOne p xs
Here are the results:
Tue Jan 23 16:01 2001 Time and Allocation Profiling Report (Final)
bar +RTS -p -RTS
total time = 0.76 secs (38 ticks @ 20 ms)
total alloc = 64,001,096 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
atLeastOne Main 71.1 37.5
SYSTEM MAIN 39.5 0.2
main Main 28.9 62.5
Total allocation due to atLeastOne: 0.375 * 64001096 = 24,000,411 bytes
Summary
-------
I realize that this is not a perfect test, but it does say something.
To those who read my previous post, when I said that 'any' takes
linear space, I meant in the worst case. And as Tom Pledger pointed
out to me privately via email, all of that space immediately becomes
garbage, so it may not be fair to count it against the space
requirements of the program. However, it does take time to reclaim
it.
Thanks to all who replied.
--
Dr. Eric Shade, Associate Professor
Computer Science Department (CSAB Accredited)
Southwest Missouri State University
From koen@cs.chalmers.se Wed Jan 24 02:45:09 2001
Date: Wed, 24 Jan 2001 03:45:09 +0100 (MET)
From: Koen Claessen koen@cs.chalmers.se
Subject: 'any' and 'all' compared with the rest of the Report
Eric Shade wrote:
| Then I get to 'any' and 'all', whose specification
| requires linear time and *linear* space when it should
| run in constant space.
I do not understand this remark. What do you mean by this?
It is very difficult to say anything about space usage in a
lazy functional language, but let us assume that a list "xs"
is lazily produced in a one-by-one element fashion, and that
noone else than the following expression is looking at that
list. Then:
any p xs
Runs in constant space (with respect to the size of the
list), for any of the discussed implementations of "any".
Or did you mean something else?
/Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
From tdouglas@home.com Wed Jan 24 03:09:05 2001
Date: Tue, 23 Jan 2001 21:09:05 -0600
From: Timmy Douglas tdouglas@home.com
Subject: optimization in the report's prelude, again
well, I'm a newbie and I was looking through the prelude to try to
learn some more haskell and I came across the sample definition of the
(^) operator on page 98. i saw a post for optimization, but and it
got mostly negative replies so i'll go the other way.
if we are writing for clarity and not efficency as it says, then would
it be better to write it as something like
n ^ e | n >= 0 = product $ take (e+1) (1 : repeat n)
_ ^ _ = error "negative exponent"
well, i could care less, but i have nothing better to do so i thought
i'd just ask if this was ok technique or something.
or maybe someone can tell me if there is like an order of "clearest
ways"... for example, using pattern matching if convenient first, then
using standard functions, then list comp., then guards, etc. because i
sometimes think that filter might be clearer as:
filter' f list = [ item | item <- list, f item]
rather than using guards... oh well, enough ranting.
thanks for replies.
From kuchen@uni-muenster.de Wed Jan 24 08:52:18 2001
Date: Wed, 24 Jan 2001 09:52:18 +0100
From: Herbert Kuchen kuchen@uni-muenster.de
Subject: FLOPS 2001 - 2nd Call for Participation
*********************************************************************
* SECOND CALL FOR PARTICIPATION *
* *
* FLOPS 2001 *
* Fifth International Symposium on Functional and Logic Programming *
* *
* Waseda University, Tokyo, Japan *
* March 7-9, 2001 *
* *
* http://www.ueda.info.waseda.ac.jp/flops2001/ *
*********************************************************************
The symposium is a forum for research on all issues concerning
functional programming and logic programming. In particular, it aims
to stimulate the cross-fertilization as well as integration of the two
paradigms. This is the fifth in the series of FLOPS symposia held
every 1.5 years in Japan.
The symposium program will consist of 3 invited talks and 21 technical
research talks. The proceedings will be published by Springer-Verlag
in the Lecture Notes in Computer Science series.
Invited Talks
=============
Gopalan Nadathur (Univ. of Minnesota, USA)
"The Metalanguage lambda-Prolog and Its Implementation"
George C. Necula (Univ. of California, Berkeley, USA)
"A Scalable Architecture for Proof-Carrying Code"
Taisuke Sato (Tokyo Institute of Technology, Japan)
"Parameterized Logic Programs where Computing Meets Learning"
Important Dates
===============
Early Registration Deadline: January 30, 2001
Symposium: March 7-9, 2001
Venue
=====
The symposium will be held at the Conference Room 1 (third floor) of
the International Conference Center of Waseda University, which is
located in central Tokyo and can be accessed easily. For details,
please visit the FLOPS2001 Web page
http://www.ueda.info.waseda.ac.jp/flops2001/ .
Registration and Hotel Information
==================================
Details of registration and hotel booking information are available
on the FLOPS2001 Web page. Registration fees are as follows:
Before Jan. 30 After Jan. 31
Regular 22,000 yen 32,000 yen
Student 12,000 yen 22,000 yen
The fees include participation, proceedings, banquet and
refreshments for one person. Additional banquet tickets are
available. The current exchange rate for Japanese yen is
US$1 = 116 yen and 1 Euro = 109 yen.
Detailed information on accommodations near the conference site,
ranging from luxuary to inexpensive, is available on the FLOPS Web
page.
Preliminary Programme
=====================
Wednesday, March 7
09:00 - 09:30 Registration
09:30 - 09:45 Opening
09:45 - 11:00 Invited Talk 1
The Metalanguage lambda-Prolog and Its Implementation
Gopalan Nadathur
11:00 - 11:30 Break
11:30 - 12:30 Lambda-Calculus
A Simply Typed Context Calculus with First-Class Environments
Masahiko Sato, Takafumi Sakurai, and Yukiyoshi Kameyama
Refining the Barendregt Cube using Parameters
Fairouz Kamareddine, Twan Laan, and Rob Nederpelt
12:30 - 14:00 Lunch
14:00 - 15:30 Functional Logic Programmig 1
A Framework for Goal-Directed Bottom-Up Evaluation of Functional
Logic Programs
Jesus M. Almendros-Jimenez and Antonio Becerra-Teron
Theoretical Foundations for the Declarative Debugging of Lazy
Functional Logic Programs
Rafael Caballero, Francisco J. Lopez-Fraguas, and
Mario Rodriguez-Artalejo
Adding Linear Constrains over Real Numbers to Curry
Wolfgang Lux
15:30 - 16:00 Break
16:00 - 17:30 Logic Programming
A Higher-Order Logic Programming Language with Constraints
Javier Leach and Susana Nieva
Specifying and Debugging Security Protocols via Hereditary Harrop
Formulas and lambdaProlog --- A Case-study
Giorgio Delzanno
An Effective Bottom-Up Semantics for First-Order Linear Logic
Programs
Marco Bozzano, Giorgio Delzanno, and Maurizio Martelli
Thursday, March 8
09:30 - 10:30 Program Analysis and Transformation 1
A Framework for Analysis of Typed Logic Programs
Vitaly Lagoon and Peter J. Stuckey
Abstract Compilation for Sharing Analysis
Gianluca Amato and Fausto Spoto
10:30 - 11:00 Break
11:00 - 12:15 Invited Talk 2
Parameterized Logic Programs where Computing Meets Learning
Taisuke Sato
12:15 - 13:45 Lunch
13:45 - 15:15 Functional Logic Programming 2
A Complete Selection Function for Lazy Conditional Narrowing
Taro Suzuki and Aart Middeldorp
An Abstract Machine Based System for a Lazy Narrowing Calculus
Teresa Hortala-Gonzalez and Eva Ullan
Incremental Learning of Functional Logic Programs
Cesar Ferri-Ramirez, Jose Hernandez-Orallo, and
Maria Jose Ramirez-Quintana
15:15 - 15:45 Break
15:45 - 17:15 Functional Programming
Proving Syntactic Properties of Exceptions in an Ordered Logical
Framework
Jeff Polakow and Kwangkeun Yi
A Higher-Order Colon Translation
Olivier Danvy and Lasse R. Nielsen
Compiling Lazy Functional Programs Based on the Spineless Tagless
G-machine for the Java Virtual Machine
Kwanghoon Choi, Hyun-il Lim, and Taisook Han
18:45 - 21:00 Banquet at Rihga Royal Hotel
Friday, March 9
09:30 - 10:30 Program Analysis and Transformation 2
A Practical Partial Evaluator for a Multi-Paradigm Declarative
Language
Elvira Albert, Michael Hanus, and German Vidal
A Simple Take on Typed Abstract Syntax in ML-like Languages
Olivier Danvy and Morten Rhiger
10:30 - 11:00 Break
11:00 - 12:15 Invited Talk 3
A Scalable Architecture for Proof-Carrying Code
George C. Necula
12:15 - 13:45 Lunch
13:45 - 15:15 Types
A General Type Inference Framework for Hindley/Milner Style
Systems
Martin Sulzmann
Monadic Encapsulation with Stack of Regions
Koji Kagawa
Well-Typed Logic Programs Are not Wrong
Pierre Deransart and Jan-Georg Smaus
15:15 - 15:30 Closing
Symposium Organization
======================
Program Co-Chairs:
Herbert Kuchen Univ. of Muenster, Germany
Kazunori Ueda Waseda Univ., Tokyo, Japan
Program Committee:
Sergio Antoy Portland State Univ., USA
Gopal Gupta New Mexico State Univ., USA
Michael Hanus Univ. of Kiel, Germany
Fergus Henderson Univ. of Melbourne, Australia
Zhenjiang Hu Univ. of Tokyo, Japan
Herbert Kuchen Univ. of Muenster, Germany
Giorgio Levi Univ. of Pisa, Italy
Michael Maher Griffith Univ., Brisbane, Australia
Dale Miller Pennsylvania State Univ., USA
I.V. Ramakrishnan State Univ. of New York at Stony Brook, USA
Olivier Ridoux IRISA, France
Mario Rodriguez-Artalejo Complutense Univ., Madrid, Spain
Colin Runciman Univ. of York, UK
Akihiko Takano Hitachi Ltd., Japan
Peter Thiemann Freiburg Univ., Germany
Yoshihito Toyama Tohoku Univ., Japan
Kazunori Ueda Waseda Univ., Tokyo, Japan
Local Arrangements Chair:
Zhenjiang Hu Univ. of Tokyo, Japan
Sponsors
========
FLOPS2001 is sponsored by Japan Society of Software Science and
Technology (JSSST), Special Interest Group on Principles of
Programming, and held in cooperation with Association for Logic
Programming.
From karczma@info.unicaen.fr Wed Jan 24 11:08:54 2001
Date: Wed, 24 Jan 2001 11:08:54 +0000
From: Jerzy Karczmarczuk karczma@info.unicaen.fr
Subject: 'any' and 'all' compared with the rest of the Report
Eric Shade:
> It would be one thing if the
> Report were littered with functions whose specifications were
> obviously not intended as implementations. But 'any', 'all', and
> 'findIndices' were the only inefficient ones I noticed out of the
> entire Report.
>
> And it's obvious that clarity is not the only goal in the
> specifications. For example, why bother to write a messy O(log n)
> version of x^n when the following is more clear *and* more concise?
>
> x ^ n | n >= 0 = product (replicate n x)
> _ ^ _ = error "Prelude.^: negative exponent"
===
1. elem, notElem, etc. follow the same pattern.
2. The rational number package is not too optimal, as far as I can
judge it.
3. Now, now, you fight against the inefficiency of linear algorithms
which use map, and here you propose EXACTLY the same for the product?
(Unless, as Bjorn hopes, one day the compilers will do all the
parallelisation/logarithmoptimisation for us.)
BY THE WAY.
The power algorithm which uses the binary splitting of the exponent
is very popular in the pedagogical context, and sometimes abused, for
example to compute huge powers of "infinite precision" integers.
If we assume that the multiplication algorithm for two long numbers
of lengths M and N is proportional to M*N, see for yourself what is
the asymptotic complexity of the power which uses the logarithmic
method vs. the linear one. You might be surprised. //Sorry for
deviating from Haskell...//
On the other hand, having an even more generic logarithmic iterator
for associative operations seems to me a decent idea. You might even
need it one day (I had this pleasure) for the multiplication of an
object by an integer, where the object was so non-standard, that the
only way of implementing N*X was: X+X+...+X.
So, Eric, don't call this algorithm "messy". (I suspect that you
are joking, but ALL comp. sci students should know it, and perhaps
some of them read this list and may believe you...)
Jerzy Karczmarczuk
Caen, France
From qrczak@knm.org.pl Wed Jan 24 22:36:58 2001
Date: 24 Jan 2001 22:36:58 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
Mon, 22 Jan 2001 16:42:32 +0000, Keith Wansbrough <Keith.Wansbrough@cl.cam.ac.uk> pisze:
> http://www.cl.cam.ac.uk/~kw217/research/papers.html#Wansbrough99:Macros
hsc2hs, although designed for embedding Haskell constructs depending
on C headers, can be used as a Haskell preprocessor.
It avoids lexing Haskell source using C rules. Among C-specific things
it provides #if/#ifdef/etc., #define/#undef, #include, #error/#warning,
and an ugly way to define macros with optional parameters, token
pasting, stringification and controlled layout.
The implementation delegates all hard work to a C compiler applied to
a C program which outputs the Haskell program. {-# LINE #-} pragmas
are understood and generated. #define and #include are also put into
ghc's .hc files. The only part which differs much from cpp and is
quite ugly is macros to be used in the Haskell program. They can be
defined and used for example thus:
------------------------------------------------------------------------
#let assert e = "(if (%s) then id else " \
"const (error \"Assertion failed: %s, %s:%d\")) $", \
e, e, __FILE__, __LINE__
main =
#assert "length [1,2,3] == 3"
putStrLn "Hello world"
------------------------------------------------------------------------
and if you don't mind applying C lexical syntax to bits of Haskell code,
you can replace uses of e above by #e and call
#assert (length [1,2,3] == 3)
where parens are necessary only because the expression contains commas
outside parens.
You can also embed e into the string constant thus:
"(if (" e ") then id else " ...
instead of using printf format, but this fails if the expression
contains % characters.
Macro expansion is not applied to all occurrences of an identifier
in the source, but just to explicitly used new #-constructs as
#assert above.
A macro definition can be written in an equivalent, more low-level
way thus:
#define hsc_assert(e) printf ( \
"(if (%s) then id else " \
"const (error \"Assertion failed: %s, %s:%d\")) $", \
e, e, __FILE__, __LINE__);
and can make use of arbitrary C statements which are a part of the
C program created and run during preprocessing.
I once made a file preprocessed twice. The first pass generates
#ifdefs for each identifier passed as a macro argument, the second
pass applies these #ifdefs.
hsc2hs is in the CVS version of ghc and QForeign.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From Sven.Panne@informatik.uni-muenchen.de Thu Jan 25 00:33:43 2001
Date: Thu, 25 Jan 2001 01:33:43 +0100
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: 'any' and 'all' compared with the rest of the Report
Hmmm,
I'm slowly using track of this whole discusssion. But as a simple matter
of fact: Using or not using optimizations (aka -O) changes the space
behaviour of your Haskell programm. Sad as it may sound, it seems to be
the price you have to pay for lazy evaluation. Of course it depends on
the exact reading of "space behaviour" (temporary allocation vs. max
heap usage), but it basically remains the same. On a positive side, this
shifts debugging to a much higher level (searching for space leaks) than
commonly done in imperative/OO/... languages (searching for semantic
bugs
in the first place, space leaks only come after that).
Just my 2 cents,
Sven
From don_wakefield@mentorg.com Thu Jan 25 21:26:24 2001
Date: Thu, 25 Jan 2001 13:26:24 -0800 (PST)
From: Don Wakefield don_wakefield@mentorg.com
Subject: Question about 'Tackling the Awkward Squad'
I posed the following question on comp.lang.functional, and a helpful
reader emailed me to suggest that I should ask it here. Briefly, I
dabble in Haskell to exercise my mind in a way that my C++ heritage
doesn't, so if I'm asking silly questions or missing seemingly obvious
notions, I beg forgiveness.
The Question. I was reading Simon Peyton Jones' fascinating paper:
Tackling the awkward squad: monadic input/output, concurrency,
exceptions, and foreign-language calls in Haskell
(the January 9th 2001 draft)
when I ran across what appears to be an error. On page 34, while
discussing Channels, he proposes a function called dupChan:
dupChan (read, write)
= do { new_read <- newEmptyMVar ;
hole <- takeMVar write ;
putMVar write hole ;
putMVar new_read hole ;
return (new_read, write) }
The rationale is given thusly:
"For example, consider a multi-cast channel, in which there are
multiple readers, each of which should see all the values written to
the channel ... The idea is that the channel returned by dupChan can
be read independently of the original, and sees all (and only) the
data written to the channel after the dupChan call."
But earlier he has defined getChan thusly:
getchan (read, write)
= do { head_var <- takeMVar read ;
MkItem val new_head <- takeMVar head_var ;
putMVar read new_head ;
return val }
Since the line which performs the 'takeMVar head_var' leaves the MVar
referenced by head_var empty, the dupChan 'new_read' Stream should block
when the reader tries to *also* use getChan on this Stream, isn't this
so? Am I missing some subtlety? I drew all the pictures :^)~
--
Don Wakefield Mentor Graphics Corporation
(503) 685-1262 8005 S.W. Boeckman Road
don_wakefield@mentorg.com Wilsonville, OR 97070-7777
From C.Reinke@ukc.ac.uk Fri Jan 26 20:28:16 2001
Date: Fri, 26 Jan 2001 20:28:16 +0000
From: C.Reinke C.Reinke@ukc.ac.uk
Subject: Combinator library gets software prize
[oops, somehow this ended up in my drafts folder, not on the list;
sorry for the delay]
First, to avoid confusion: I'm not criticising the work described. I'm
just pointing out that, in my view, the major advantages of functional
programming lie beyond what is used in this application (in other
words, there is yet more to be gained, and we should not underestimate
the role of the facilities imported from the functional host language,
such as functional abstraction).
[one quibble: I don't like the idea of using floating point numbers to
represent real money without further comments. Even after avoiding
representation error surprises by using base10 instead of binary
floating points, aren't there precise standards for rounding in the
financial market? Or have I missed an explanation of this in the paper?]
> > Am I the only one who finds the exclusive emphasis on combinator
> > languages slightly disappointing (in fact, the article seems to equate
> > functional language with domain-specific combinator languages, which is
> > more than a bit mistleading)?
>
> What declarative approach(es) (other than combinators) are you
> referring to here?
Mostly lambda-calculus; more generally, all approaches that deal
explicitly with variables and variable binding, and the resulting
languages, which are general enough that DSLs for many domains can be
embedded in them.
Even within combinator languages, I am not always sure whether those
reporting on the paper are aware how much the DSL gains by being
embedded in a full functional language, and how simply exporting the
core DSL to another context would severe all those useful connections.
In the present context, most of the excitement seems to focus on the
contract combinators, because they bring a new approach towards order
in the application domain. They can be viewed as a first-order
functional language on contracts. This core part of the DSL could be
used in other modern languages as well, provided their expression
sub-language is sufficiently expressive (although the syntax, e.g., new
And(..) and new Give(..) in Java, or <Give>..</Give> in other contexts,
would quite likely annoy the user).
But the paper goes beyond that, e.g., it defines and uses some
higher-order features for observables. Also, functional programmers
will be tempted to use partially applied contract combinators in
higher-order compositions (as a simple example, take
"all = foldr and zero :: [Contract] -> Contract" --
acquiring "all contracts" acquires a list of contracts).
Such uses are already slightly more difficult (and typically much more
ugly) in non-functional languages, so simply providing the same basic
DSL as a library embedded in a non-functional language will not
necessarily give the same flexibility (and a dedicated implementation
of the DSL would have to decide between supporting only simple uses of
the combinators or adding some more advanced features).
Of course, in addition to combinators, we also need definitions, so
that we can give names to useful combinations of combinators. This
comes for free if the DSL is embedded in Haskell, but if we take it
out of this context, we need to start thinking about what kind of
definitions we can or want to support: parameters? certainly.
what types of parameters? what types of things can be defined?
how are parameters passed?..
And suddenly, we're into the definition and implementation of a little
(higher-order?) functional language, with support for functional
abstraction (how much support?). Does the host language (or the
dedicated implementation) support all the things we want in the way we
expect?
In any case, the core contract combinator DSL doesn't stand in
isolation - we need to work with the contracts, operate on dates,
evaluate options, iterate through sequences or alternatives, ..
Do we do this in functional style, or by shouting imperatives at
those poor contract combinations?
> > The consequence (and the intention, as far as one can gather from the
> > paper) of the limitation to combinators is that this language can and
> > will be used mainly in non-functional languages, not inheriting all
> > that much from a functional style of programming. The same will
> > probably hold for any communication standards based on it.
>
> Why is that? I'm new to the functional programming world, and haven't
> reallystruck the concept of combinator libraries elsewhere. I assumed
> they were largely a functional programming concept. Even though I can
> see how they could be implemented in imperative languages, it doesn't
> seem that they would be a nice fit.
That's my point. But so far, I don't see any external commitment to a
functional host language for the core combinators. Of course, that
impression could well be wrong..
The paper suggests the Haskell implementation as a prototype to help
the development of an existing C++ implementation as well as a new
implementation in OCaml (implementation language, not host language).
Most positive external comments seem to focus on the core contract
combinators as a possible means to standardize the way professionals
and software are talking about contracts (XML-like).
Now, if you cut out the contract combinators from the DSL embedded in
Haskell and try to find something that can be used across
C++,OCaml,XML-processing Java, etc., you might end up writing
for-loops, assigning contract combinations to global variables, sending
messages to contract objects, and all the other funny non-functional
things that are so happily used outside the Haskell world.
> > [Several interesting elided]
>
> More generally, is there any more information or forums on declarative
> approaches to financial engineering? I found this paper intriguing, as
> it focuses on both my current academic interests, and my work!
I'm not an expert in this area, but from the few references in the
paper, it seems that there hasn't been much work, and from the comments
on the paper, it seems there there is a growing interest. Perhaps there
are enough people interested now to warrant setting up such a forum.
Claus
From tdouglas@home.com Sat Jan 27 06:03:49 2001
Date: Sat, 27 Jan 2001 00:03:49 -0600
From: Timmy Douglas tdouglas@home.com
Subject: binary files in haskell
I was wondering if anyone here has a solution for writing binary files
that works in hugs and ghc that doesn't require getting libs.
I looked at this page:
http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html
and the haskell.org libraries page and I didn't see anything. the ghc
documentation didn't provide any examples so I was unable to figure
out how to write a binary file.
From Sven.Panne@informatik.uni-muenchen.de Sat Jan 27 17:19:08 2001
Date: Sat, 27 Jan 2001 18:19:08 +0100
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: binary files in haskell
[ OK, let's see if I get a typo-free mail out of the door *this* time... :-]
Timmy Douglas wrote:
> I was wondering if anyone here has a solution for writing binary files
> that works in hugs and ghc that doesn't require getting libs.
I dont' know exactly about the current status of Hugs' libs, but I fear
the answer to your question is "no".
> I looked at this page:
> http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html
... and that was exactly the right place, see section "Bulk transfers"
hGetBuf :: Handle -> Addr -> Int -> IO Int
hGetBufFull :: Handle -> Addr -> Int -> IO Int
hPutBuf :: Handle -> Addr -> Int -> IO Int
hPutBufFull :: Handle -> Addr -> Int -> IO ()
>
> and the haskell.org libraries page and I didn't see anything. the ghc
> documentation didn't provide any examples so I was unable to figure
> out how to write a binary file.
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
--
Sven Panne Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:sven.panne@informatik.uni-muenchen.de D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
From rjljr2@yahoo.com Sat Jan 27 17:32:34 2001
Date: Sat, 27 Jan 2001 09:32:34 -0800 (PST)
From: Ronald Legere rjljr2@yahoo.com
Subject: Combinator library gets software prize
--- "C.Reinke" <C.Reinke@ukc.ac.uk> wrote:
>Even within combinator languages, I am not always
> sure whether those
> reporting on the paper are aware how much the DSL
> gains by being
> embedded in a full functional language, and how
> simply exporting the
> core DSL to another context would severe all those
> useful connections.
>
Heh, this is something that I ran into when trying to
write a combinator language for Java based on Haskore.
I gave up when I realized i really needed those other
features of a functinal language to :). It is a bit
difficult in many domains to seperate what you are
defining from the language you are defining it in, so
I guess this is not such a large suprise.
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
From Sven.Panne@informatik.uni-muenchen.de Sat Jan 27 17:35:49 2001
Date: Sat, 27 Jan 2001 18:35:49 +0100
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: binary files in haskell
[ Seems I *can't* mail in a sane way anymore, so please excuse my last
half-baked one. But at least I've learned now that Ctrl-RET means
"send immediately" in Netscape. Great idea! Here my next try... ]
Timmy Douglas wrote:
> I was wondering if anyone here has a solution for writing binary files
> that works in hugs and ghc that doesn't require getting libs.
I dont' know exactly about the current status of Hugs' libs, but I fear
the answer to your question is "no".
> I looked at this page:
> http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html [...]
... and that was exactly the right place, see section "Bulk transfers":
(http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html#SEC-BULK-TRANSFERS)
hGetBuf :: Handle -> Addr -> Int -> IO Int
hGetBufFull :: Handle -> Addr -> Int -> IO Int
hPutBuf :: Handle -> Addr -> Int -> IO Int
hPutBufFull :: Handle -> Addr -> Int -> IO ()
These action read/write a given amount of bytes to/from a buffer. There
hasn't been much consensus about a higher level interface yet, but you
can have a look at my variant sitting on top of this:
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/OpenGL/GL/GL_BinaryIO.hs?rev=1.2&content-type=text/x-cvsweb-markup
Not the nicest and most efficient code on earth, but it should be enough
to get the idea. Note that in more recent (CVS) versions of GHC, `Addr'
(which is deprecated now) has been replaced by `Ptr a'.
Any ideas & suggestions for a good binary I/O interface are highly welcome!
Cheers,
Sven "The Typo" P.
From tdouglas@home.com Sat Jan 27 18:11:48 2001
Date: Sat, 27 Jan 2001 12:11:48 -0600
From: Timmy Douglas tdouglas@home.com
Subject: binary files in haskell
Sven Panne <Sven.Panne@informatik.uni-muenchen.de> said:
>[ Seems I *can't* mail in a sane way anymore, so please excuse my last
> half-baked one. But at least I've learned now that Ctrl-RET means
> "send immediately" in Netscape. Great idea! Here my next try... ]
>
>Timmy Douglas wrote:
>> I was wondering if anyone here has a solution for writing binary files
>> that works in hugs and ghc that doesn't require getting libs.
>
>I dont' know exactly about the current status of Hugs' libs, but I fear
>the answer to your question is "no".
>
>> I looked at this page:
>> http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html [...]
>
>... and that was exactly the right place, see section "Bulk transfers":
>(http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html#SEC-BULK-TRANSFERS)
>
> hGetBuf :: Handle -> Addr -> Int -> IO Int
> hGetBufFull :: Handle -> Addr -> Int -> IO Int
>
> hPutBuf :: Handle -> Addr -> Int -> IO Int
> hPutBufFull :: Handle -> Addr -> Int -> IO ()
>
>These action read/write a given amount of bytes to/from a buffer. There
>hasn't been much consensus about a higher level interface yet, but you
>can have a look at my variant sitting on top of this:
I saw this part but I couldn't figure out how I was supposed to open a
file and use these functions. So maybe I was looking for an example. I
want to try to write a compiler for some language in haskell, but I
don't know how to write binary files...
It looks like I use openFileEx but I can't get anything to compile
without seeing an example of it.
Thanks for the reply.
From conal@microsoft.com Tue Jan 23 19:22:41 2001
Date: Tue, 23 Jan 2001 11:22:41 -0800
From: Conal Elliott conal@microsoft.com
Subject: Combinator library gets software prize
> From: C.Reinke [mailto:C.Reinke@ukc.ac.uk]
> Am I the only one who finds the exclusive emphasis on combinator
> languages slightly disappointing [...]?
> [...]
> The paper somewhat downplays the role of embedding the
> combinator-based DSL in a full functional language while also
> mentioning that some features gained for free in the Haskell
> prototype considerably complicate implementations in other
> languages. I would be interested to hear more about these aspects:
> [...]
Another important consideration is whether the combinator library is
higher-order. If so, it will be awkward to use from a language
without a lightweight notation for (first-class) functions. This lack
was a huge drawback in DirectAnimation, the now-defunct product cousin
of Fran, which eviscerated the crucially higher-order event algebra.
Similarly, when a combinator lib uses parametric polymorphism, it is
painful to use from a language without. (Same example.) It seems
that these features just weren't important in the case of "Composing
Contracts".
- Conal
From simonpj@microsoft.com Fri Jan 26 09:11:45 2001
Date: Fri, 26 Jan 2001 01:11:45 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Question about 'Tackling the Awkward Squad'
Don
Crumbs! You're right!
The MVars that are drawn as heavy black boxes in Figure 7 of Tackling
the Awkward Squad are used to block the consumer when it catches up
with the producer. But if there is more than one consumer, it's not
OK to leave these MVars empty. Instead, getChan should do a put after
its take; or, more elegantly, should use readMVar, which has the
semantics of take-followed-by-put:
getchan (read, write)
= do { head_var <- takeMVar read ;
MkItem val new_head <- readMVar head_var ;
putMVar read new_head ;
return val }
Concurrent programming is tricky. I owe you a beer!
I'll fix the version on the Web
Simon
| when I ran across what appears to be an error. On page 34, while
| discussing Channels, he proposes a function called dupChan:
|
| dupChan (read, write)
| = do { new_read <- newEmptyMVar ;
| hole <- takeMVar write ;
| putMVar write hole ;
| putMVar new_read hole ;
| return (new_read, write) }
|
| The rationale is given thusly:
|
| "For example, consider a multi-cast channel, in which there are
| multiple readers, each of which should see all the values written to
| the channel ... The idea is that the channel returned by dupChan can
| be read independently of the original, and sees all (and only) the
| data written to the channel after the dupChan call."
|
| But earlier he has defined getChan thusly:
|
| getchan (read, write)
| = do { head_var <- takeMVar read ;
| MkItem val new_head <- takeMVar head_var ;
| putMVar read new_head ;
| return val }
|
| Since the line which performs the 'takeMVar head_var' leaves the MVar
| referenced by head_var empty, the dupChan 'new_read' Stream
| should block
| when the reader tries to *also* use getChan on this Stream, isn't this
| so? Am I missing some subtlety? I drew all the pictures :^)~
|
| --
| Don Wakefield Mentor Graphics Corporation
| (503) 685-1262 8005 S.W. Boeckman Road
| don_wakefield@mentorg.com Wilsonville, OR 97070-7777
|
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|
From Dominic.J.Steinitz@BritishAirways.com Mon Jan 29 09:56:00 2001
Date: 29 Jan 2001 09:56:00 Z
From: Steinitz, Dominic J Dominic.J.Steinitz@BritishAirways.com
Subject: Question about 'Tackling the Awkward Squad'
This is probably superfluous now but I still don't understand Hugs' behaviour. I ran the following with ghc 4.08.1:
module Main(main) where
import Concurrent
main =
do chan <- newChan
writeChan chan "One"
dup <- dupChan chan
writeChan chan "Two"
x <- readChan dup
y <- readChan chan
z <- readChan chan
putStrLn (x++y++z)
I expected the answer "TwoOneTwo" but instead got
$ ./main
d:\dom\hugs98\concurrent\main.exe: no threads to run: infinite loop or
deadlock?
which confirmed the problem that Don highlighted.
With Hugs I got the following:
Main> main
(232 reductions, 458 cells)
which was puzzling. I'm running Version: May 1999 with -98.
Dominic.
simonpj@microsoft.com on 28/01/2001 11:18:00
To: don_wakefield
haskell
cc:
bcc: Dominic Steinitz
Subject: RE: Question about 'Tackling the Awkward Squad'
Don
Crumbs! You're right!
The MVars that are drawn as heavy black boxes in Figure 7 of Tackling
the Awkward Squad are used to block the consumer when it catches up
with the producer. But if there is more than one consumer, it's not
OK to leave these MVars empty. Instead, getChan should do a put after
its take; or, more elegantly, should use readMVar, which has the
semantics of take-followed-by-put:
getchan (read, write)
= do { head_var <- takeMVar read ;
MkItem val new_head <- readMVar head_var ;
putMVar read new_head ;
return val }
Concurrent programming is tricky. I owe you a beer!
I'll fix the version on the Web
Simon
| when I ran across what appears to be an error. On page 34, while
| discussing Channels, he proposes a function called dupChan:
|
| dupChan (read, write)
| = do { new_read <- newEmptyMVar ;
| hole <- takeMVar write ;
| putMVar write hole ;
| putMVar new_read hole ;
| return (new_read, write) }
|
| The rationale is given thusly:
|
| "For example, consider a multi-cast channel, in which there are
| multiple readers, each of which should see all the values written to
| the channel ... The idea is that the channel returned by dupChan can
| be read independently of the original, and sees all (and only) the
| data written to the channel after the dupChan call."
|
| But earlier he has defined getChan thusly:
|
| getchan (read, write)
| = do { head_var <- takeMVar read ;
| MkItem val new_head <- takeMVar head_var ;
| putMVar read new_head ;
| return val }
|
| Since the line which performs the 'takeMVar head_var' leaves the MVar
| referenced by head_var empty, the dupChan 'new_read' Stream
| should block
| when the reader tries to *also* use getChan on this Stream, isn't this
| so? Am I missing some subtlety? I drew all the pictures :^)~
|
| --
| Don Wakefield Mentor Graphics Corporation
| (503) 685-1262 8005 S.W. Boeckman Road
| don_wakefield@mentorg.com Wilsonville, OR 97070-7777
|
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From simonpj@microsoft.com Mon Jan 29 15:05:58 2001
Date: Mon, 29 Jan 2001 07:05:58 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: FW: Consortium Caml
Here's an interesting model for collaboration which the
Caml folk are taking up.
Simon
-----Original Message-----
From: Michel Mauny [mailto:Michel.Mauny@inria.fr]
Sent: 26 January 2001 21:38
To: caml-list@inria.fr
Subject: Consortium Caml
-- [ English version below ] ---
Dear Colleagues,
We are pleased to announce the creation of the Caml Consortium, whose
aim is to federate the design and development efforts around the Caml
programming language. The Caml Consortium will therefore try to bring
together, around the language development team, industries, research
centres and educational establishments interested in contributing
their support to the design and development of the language and
related tools.
Comprising a group of highly-motivated users, the Consortium will be
the place where the members can identify their common requirements,
exchange their experiences and solutions, and co-operate to propose a
particular development of general interest. One of the Consortium's
roles is therefore to be a place where users of the language can meet
and exchange information. It is here that a true community will be
created with the specific intention of assisting in the development of
the language and to provide it with such a visibility that this
community will expand by itself.
The motivation and industrial importance of its members will also
attract companies to the Consortium which want to be present on the
Caml applications and training market. Another role of the Consortium
will therefore be to attract new members, whether they are users of
the language or service providers.
Finally, the Consortium will provide a response to the question on the
language's continuity. The essential elements for the continuity of a
programming language are the continuity of its compilers (or their
free availability), its user base, and the volume of existing (stable)
codes. The success of the Caml Consortium will make it possible to
measure the user base and the volume of the existing Caml code. As for
the availability and development of the Caml compilers, these are
already freely distributed with their sources. If INRIA decides at
some point to withdraw from Caml development, and therefore to
dissolve the Caml Consortium as it presently stands, the members of
the Consortium will be sufficiently numerous, they will have
sufficiently diversified profiles, and the market for the language
will be such that the members of the Consortium will have no
difficulty in continuing the existence and development of the
language. INRIA will facilitate this transition, which is in the
general interest.
For more information, I suggest that you consult
http://caml.inria.fr/consortium/
Best regards,
-- Michel Mauny
From jans@numeric-quest.com Mon Jan 29 10:35:54 2001
Date: Mon, 29 Jan 2001 05:35:54 -0500 (EST)
From: Jan Skibinski jans@numeric-quest.com
Subject: FW: Consortium Caml
If this idea is also being considered for Haskell
I suggest to examine NICE pages to see how it works
in practice.
NICE = Non-profit International Consortium for Eiffel.
http://www.eiffel-nice.org
Jan
From cm@pochta.net Tue Jan 30 12:30:10 2001
Date: Tue, 30 Jan 2001 18:30:10 +0600
From: Eugene Nonko cm@pochta.net
Subject: Problems with GHC-4.08.1 on Windows 2000 Professional
Dear Colleagues,
I've encountered some problems after ghc-4.08.1 installation on by w2kpro.
When I'm trying to compile simple 'Hello world!' program (ghc main.hs -o
main.exe), linker outputs messages:
===
gcc: D:/ghc/lib/Main.dll_o: No such file or directory
gcc: D:/ghc/lib/PrelMain.dll_o: No such file or directory
===
When I'm trying to compile it with -static command line switch (ghc
main.hs -o main.exe -static), it compiles, but resulting .exe does nothing
(it doesn't displays message).
What's the problem, can someone explain me?
PS. Just in case, this is full source code of this 'Hello world!' program.
;)
===
module Main (main) where
main = putStrLn "Hello, world!"
===
Best regards,
Eugene Nonko
Novosoft Inc.
From simonpj@microsoft.com Tue Jan 30 16:31:32 2001
Date: Tue, 30 Jan 2001 08:31:32 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Problems with GHC-4.08.1 on Windows 2000 Professional
You have to compile with the flag -static, I'm afraid.
4.08.2 will have this built in.
Simon
| -----Original Message-----
| From: Eugene Nonko [mailto:cm@pochta.net]
| Sent: 30 January 2001 12:30
| To: haskell@haskell.org
| Subject: Problems with GHC-4.08.1 on Windows 2000 Professional
|
|
| Dear Colleagues,
|
| I've encountered some problems after ghc-4.08.1 installation
| on by w2kpro.
| When I'm trying to compile simple 'Hello world!' program (ghc
| main.hs -o
| main.exe), linker outputs messages:
| ===
| gcc: D:/ghc/lib/Main.dll_o: No such file or directory
| gcc: D:/ghc/lib/PrelMain.dll_o: No such file or directory
| ===
|
| When I'm trying to compile it with -static command line switch (ghc
| main.hs -o main.exe -static), it compiles, but resulting .exe
| does nothing
| (it doesn't displays message).
|
| What's the problem, can someone explain me?
|
| PS. Just in case, this is full source code of this 'Hello
| world!' program.
| ;)
| ===
| module Main (main) where
|
| main = putStrLn "Hello, world!"
| ===
|
| Best regards,
| Eugene Nonko
| Novosoft Inc.
|
|
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|
From meurig@dcs.gla.ac.uk Tue Jan 30 18:41:21 2001
Date: Tue, 30 Jan 2001 18:41:21 -0000
From: Meurig Sage meurig@dcs.gla.ac.uk
Subject: Problems with GHC-4.08.1 on Windows 2000 Professional
Hi
I had the same problem.
The problem is with one of your cygwin libraries.
Reuben Thomas sent me this reply:
-------------
You probably need to change the mingw package: if its date is 200012xx, try
downgrading to 200011xx. This recommendation also applies to Janna Khegai's
message.
-------------
You'll have to download and install the slightly older mingw package.
Meurig
----- Original Message -----
From: "Eugene Nonko" <cm@pochta.net>
To: <haskell@haskell.org>
Sent: Tuesday, January 30, 2001 12:30 PM
Subject: Problems with GHC-4.08.1 on Windows 2000 Professional
> Dear Colleagues,
>
> I've encountered some problems after ghc-4.08.1 installation on by w2kpro.
> When I'm trying to compile simple 'Hello world!' program (ghc main.hs -o
> main.exe), linker outputs messages:
> ===
> gcc: D:/ghc/lib/Main.dll_o: No such file or directory
> gcc: D:/ghc/lib/PrelMain.dll_o: No such file or directory
> ===
>
> When I'm trying to compile it with -static command line switch (ghc
> main.hs -o main.exe -static), it compiles, but resulting .exe does nothing
> (it doesn't displays message).
>
> What's the problem, can someone explain me?
>
> PS. Just in case, this is full source code of this 'Hello world!' program.
> ;)
> ===
> module Main (main) where
>
> main = putStrLn "Hello, world!"
> ===
>
> Best regards,
> Eugene Nonko
> Novosoft Inc.
>
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From simonpj@microsoft.com Fri Jan 26 10:10:34 2001
Date: Fri, 26 Jan 2001 02:10:34 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: fixity for (\\)
This proposal makes sense to me, but I'm only supposed to be fixing=20
serious bugs in the Haskell 98 definition, not making unforced changes.
So even though this change would be non-invasive and break no programs
I'm reluctant to adopt it. Adding those extra parens is no big deal.
Unless there's a lot of support, I propose to make no change (in H98,
that is).
Simon
| -----Original Message-----
| From: Koen Claessen [mailto:koen@cs.chalmers.se]
| Sent: 17 January 2001 15:32
| To: The Haskell Mailing List
| Subject: fixity for (\\)
|=20
|=20
| Hi all,
|=20
| The Haskell report defines the fixity of (\\) to be:
|=20
| infix 5 \\
|=20
| I propose that it gets the following fixity:
|=20
| infixl 5 \\
|=20
| This means that one can write:
|=20
| as \\ bs \\ cs \\ ds
|=20
| Which means:
|=20
| (((as \\ bs) \\ cs) \\ ds)
|=20
| I think that one less often means the following:
|=20
| as \\ (bs \\ (cs \\ ds))
|=20
| /Koen.
|=20
| --
| Koen Claessen http://www.cs.chalmers.se/~koen
| phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
| -----------------------------------------------------
| Chalmers University of Technology, Gothenburg, Sweden
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|=20
From Christian.Laaser@icn.siemens.de Wed Jan 31 12:12:19 2001
Date: Wed, 31 Jan 2001 13:12:19 +0100
From: Laaser Christian Christian.Laaser@icn.siemens.de
Subject: What does "Compiled code too complex" error message of Hugs mean?
When loading some Haskell files with Hugs, I get the error message "Compiled code too complex". However, the compilation with GHC 4.08.1 succeeds.
What does this message mean? What can I do about it?
Christian
From kort@wins.uva.nl Wed Jan 31 12:33:33 2001
Date: Wed, 31 Jan 2001 13:33:33 +0100
From: Jan Kort kort@wins.uva.nl
Subject: What does "Compiled code too complex" error message of Hugs mean?
Laaser Christian wrote:
>
> When loading some Haskell files with Hugs, I get the error message "Compiled code too complex". However, the compilation with GHC 4.08.1 succeeds.
> What does this message mean? What can I do about it?
>
You can grep for that sentence in "hugs98/src", it will point to the
file "machine.c". There you will see it says "if (nextLab>=NUM_FIXUPS) ...".
So grep for "NUM_FIXUPS" it will point to the file "prelude.h". I
think the default value is 400, you should increase it to 1000 or so.
I have it at 10000, but that's probably not necesary in your case
and if you increase constants too much starting up Hugs will become
slower.
Jan
From simonpj@microsoft.com Fri Jan 26 10:42:33 2001
Date: Fri, 26 Jan 2001 02:42:33 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Yet more on functional dependencies
| | I am finding functional dependencies confusing. (I suspect I am=20
| | not alone.) Should the following code work?
| |=20
| | class HasConverter a b | a -> b where
| | convert :: a -> b
| |=20
| | instance (HasConverter a b,Show b) =3D> Show a where
| | show value =3D show (convert value)
|=20
| It's a separate issue. There's no reason why a system using
| functional dependencies *should* support this. But it is an
| attractive and useful extension that such a system would
| probably *want* to include. (i.e., it's a desirable feature,
| not a requirement.)
There are two things going on here
a) The 'head' of the instance declaration is just "Show a", so this
purports to give an instance declaration for all types "a". So it
overlaps with other instance declarations, and GHC currently rejects
it for that reason. (Arguably, if you accept overlapping instance=20
declarations, then this should be acceptable too.)
b) There's a "b" in the instance declaration context that doesn't
appear in the head. This is quite OK, because the functional dependency
ensures that "a" uniquely determines "b". =20
So here's a variant that works in the (as-yet-unreleased) GHC 5.0:
data Foo a =3D MkFoo a
instance (HasConverter a b,Show b) =3D> Show (Foo a) where
show (MkFoo value) =3D show (convert value)
[Incidentally, functional dependencies don't work at all in GHC 4.08;
don't
even try.]
Simon
From cllan@263.net Tue Jan 23 00:16:55 2001
From: cllan@263.net (Onwall.net)
Date: Tue, 23 Jan 2001 00:16:55
Subject: Ñ¡»¡¢ñÑ»¡¢×Ô¼º¶¨ÖÆ×°Êλ...
Message-ID: <20020121160807.E96AD255AB@www.haskell.org>
´º½Ú¿ìÒªµ½ÁË!
ÄãÊÇ·ñ×¼±¸°Ñ°®¼Ò×°ÊÎÒ»ÐÂÄØ£¿
ÊÇ·ñÕýΪËÍÇ×ÅóºÃÓÑʲôÀñÎï·¢³îÄØ£¿
¿ìÀ´ÎÒÃǵÄÍøÕ¾¶¨ÖƺÏÊÊ×Ô¼º»òÄãÅóÓѵÄ×°Êλ¡¢µçÓ°º£±¨À²£¡
Ñ¡»¡¢ñÑ»¡¢×Ô¼º¶¨ÖÆ×°Êλ...
http://www.onwall.net
E-mail:Server@onwall.net
QQ×°ñÑÖ§³Ö:28888808
±§Ç¸ÔÚδÕ÷µÃÄúͬÒâµÄÇé¿öÏ·¢Ëͱ¾Óʼþ
µ«Ô¸ÎÒÃǵÄÍøÕ¾ÕæÄÜΪÄãÌṩ·þÎñ!
ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡
ÏÂÔØÍøÖ·£ºhttp://love2net.51.net/£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡¡
----------------------------------------------------
INFORMATION
This message has been sent using a trial-run version
of the TSmtpRelayServer Delphi Component.
----------------------------------------------------
From gmh@Cs.Nott.AC.UK Tue Jan 2 10:52:36 2001
From: gmh@Cs.Nott.AC.UK (Graham Hutton)
Date: Tue, 02 Jan 2001 10:52:36 +0000
Subject: JFP Special Issue on Haskell
Message-ID: <20010102105313.4684FFCE@www.haskell.org>
Dear all,
Please note that the deadline for submission to the JFP Special Issue
on Haskell is in one months time --- 1st February 2001.
Graham Hutton
----------------------------------------------------------------------
CALL FOR PAPERS
Journal of Functional Programming
Special Issue on Haskell
Since its inception in 1987, Haskell has provided a focal point for
research in lazy functional programming. During this time the
language has continually evolved, as a result of both theoretical
advances and practical experience. Haskell has proved to be a
powerful tool for many kinds of programming tasks, and applications in
industry are beginning to emerge. The recent definition of Haskell 98
provides a long-awaited stable version of the language, but there are
many exciting possibilities for future versions of Haskell.
The fourth Haskell Workshop was held as part of the PLI 2000
colloquium on Principles, Logics, and Implementations of high-level
programming languages in Montreal, 17th September 2000. Previous
Haskell Workshops have been held in Paris (1999), Amsterdam (1997) and
La Jolla (1995). Following on from these workshops, a special issue
of the Journal of Functional Programming will be devoted to Haskell.
Possible topics include, but are not limited to:
Critiques of Haskell 98;
New proposals for Haskell;
Applications or case studies;
Programming techniques;
Reasoning about programs;
Semantic issues;
Pedagogical issues;
Implementation.
Contributors to any of the Haskell workshops are invited to submit
full papers to the special issue on Haskell, but submission is open to
everyone. Submissions should be sent to the guest editor (address
below), with a copy to Nasreen Ahmad (nasreen@dcs.gla.ac.uk).
Submitted articles should be sent in postscript format, preferably
gzipped and uuencoded. In addition, please send, as plain text, title,
abstract, and contact information. The submission deadline is 1st
February 2001. For other submission details, please consult an issue
of JFP or see the Journal's web pages.
Guest Editor:
Graham Hutton
School of Computer Science and IT
The University of Nottingham
Nottingham NG8 1BB
United Kingdom
gmh@cs.nott.ac.uk
Useful Links:
2000 Haskell Workshop www.cs.nott.ac.uk/~gmh/hw00.html
JFP Special Issue on Haskell www.cs.nott.ac.uk/~gmh/jfp.html
JFP Home Page www.dcs.gla.ac.uk/jfp
----------------------------------------------------------------------
From paul.hudak@yale.edu Tue Jan 2 14:14:33 2001
From: paul.hudak@yale.edu (Paul Hudak)
Date: Tue, 02 Jan 2001 09:14:33 -0500
Subject: Learning Haskell and FP
References: <3233BEE02CB3D4118DBA00A0C99869401D61EA@hermes.pml.com> <200012281250500955.006178FD@mail>
Message-ID: <3A51E249.AE219202@yale.edu>
> Unforunately, the "Gentle Introduction To Haskell" that
> haskell.org links to is not a very useful introduction.
John and I should probably rename this document, since it really isn't a
very gentle intro at all. We should probably also downplay it's
prominance on the haskell website. It was written rather quickly many
years ago, at a time when there was not a single textbook on Haskell.
So it's probably outlived it's purpose, although I do believe that some
people still find it useful.
-Paul
From ger@tzi.de Tue Jan 2 14:27:20 2001
From: ger@tzi.de (George Russell)
Date: Tue, 02 Jan 2001 15:27:20 +0100
Subject: Learning Haskell and FP
References: <3233BEE02CB3D4118DBA00A0C99869401D61EA@hermes.pml.com> <200012281250500955.006178FD@mail> <3A51E249.AE219202@yale.edu>
Message-ID: <3A51E548.93C835AB@tzi.de>
Paul Hudak wrote:
>
> > Unforunately, the "Gentle Introduction To Haskell" that
> > haskell.org links to is not a very useful introduction.
>
> John and I should probably rename this document, since it really isn't a
> very gentle intro at all. We should probably also downplay it's
> prominance on the haskell website. It was written rather quickly many
> years ago, at a time when there was not a single textbook on Haskell.
> So it's probably outlived it's purpose, although I do believe that some
> people still find it useful.
I think Paul is being unduly modest. I found it very useful when I first learnt
Haskell. But I did already know ML, so maybe the "Gentle Introduction" would be
harder going for someone who didn't know anything about functional programming.
Nevertheless I think it might be a mistake to downplay it unless there's a better
publicly-available introduction with which you can replace it.
The introduction states quite clearly that
> Our goal is to provide a gentle introduction to Haskell for someone
> who has experience with at least one other language, preferably a
> functional language (even if only an "almost-functional" language
> such as ML or Scheme).
and then goes on to recommend a couple of texts giving more detailed
introductions to functional programming. I don't think one can ask for more.
From simonpj@microsoft.com Tue Jan 2 15:39:42 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 2 Jan 2001 07:39:42 -0800
Subject: List.partition a bit too eager
Message-ID: <74096918BE6FD94B9068105F877C002D01378487@red-pt-02.redmond.corp.microsoft.com>
It's a bug in the defn of 'partition' in the Haskell 98 report.
I have (still) failed to publish this as an errata, let alone revise
the report itself, so the buggy defn stands at present, I'm afraid.
I really plan to get to the revision in early '01.
Simon
| -----Original Message-----
| From: George Russell [mailto:ger@tzi.de]
| Sent: 22 December 2000 15:57
| To: haskell@haskell.org
| Subject: List.partition a bit too eager
|
|
| I think the following program
|
| import List
| main = putStr . show . fst . (partition id) . cycle $ [True,False]
|
| should display [True,True,True,...]. But instead, for both
| GHC and Hugs,
| you get a stack overflow. Is this a bug, or could someone
| explain it to me?
|
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|
From jans@numeric-quest.com Tue Jan 2 10:52:57 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Tue, 2 Jan 2001 05:52:57 -0500 (EST)
Subject: Learning Haskell and FP
In-Reply-To: <3A51E548.93C835AB@tzi.de>
Message-ID:
On Tue, 2 Jan 2001, George Russell wrote:
> Paul Hudak wrote:
> >
> > > Unforunately, the "Gentle Introduction To Haskell" that
> > > haskell.org links to is not a very useful introduction.
> >
> > John and I should probably rename this document, since it really isn't a
> > very gentle intro at all. We should probably also downplay it's
> > prominance on the haskell website. It was written rather quickly many
> > years ago, at a time when there was not a single textbook on Haskell.
> > So it's probably outlived it's purpose, although I do believe that some
> > people still find it useful.
> [cut]
> Nevertheless I think it might be a mistake to downplay it unless
> there's a better publicly-available introduction with which you can
> replace it.
Very valid observation.
John, Paul:
Wouldn't be worthwhile and possible to gradually upgrade
it within some sort of a supervised documentation project at
Yale, as part of your regular teaching curriculum?
Jan
From ger@tzi.de Tue Jan 2 15:59:18 2001
From: ger@tzi.de (George Russell)
Date: Tue, 02 Jan 2001 16:59:18 +0100
Subject: List.partition a bit too eager
References: <74096918BE6FD94B9068105F877C002D01378487@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <3A51FAD6.9EFCC578@tzi.de>
Simon Peyton-Jones wrote:
>
> It's a bug in the defn of 'partition' in the Haskell 98 report.
> I have (still) failed to publish this as an errata, let alone revise
> the report itself, so the buggy defn stands at present, I'm afraid.
>
> I really plan to get to the revision in early '01.
One thing I would like to see changed is that every function should also
appear with a short description in English, as for the SML basis library.
This would be a huge improvement for those of us whose mother-tongue is
English and not Haskell, and would also mean that in cases such as these
the implementors would have more liberty to choose the best interpretation
consistent with the spirit of the standard.
(Irrelevant comment: I believe something similar happens with European
Union treaties, which are in a variety of versions in different languages
from Irish Gaelic to Swedish, all of which are deemed to have equal weight.
Translation errors are not unknown, and have to be sorted out by the
European Court of Justice.)
From patrick@watson.org Wed Jan 3 00:43:00 2001
From: patrick@watson.org (Patrick M Doane)
Date: Tue, 2 Jan 2001 19:43:00 -0500 (EST)
Subject: Learning Haskell and FP
In-Reply-To: <3A51E249.AE219202@yale.edu>
Message-ID:
On Tue, 2 Jan 2001, Paul Hudak wrote:
> > Unforunately, the "Gentle Introduction To Haskell" that
> > haskell.org links to is not a very useful introduction.
>
> John and I should probably rename this document, since it really isn't a
> very gentle intro at all. We should probably also downplay it's
> prominance on the haskell website. It was written rather quickly many
> years ago, at a time when there was not a single textbook on Haskell.
> So it's probably outlived it's purpose, although I do believe that some
> people still find it useful.
>
As another point of reference, I decided it was time to learn Haskell
recently and this guide is what I started with. I'm familiar with Standard
ML and O'Caml, and found the guide to be very easy to read and was a good
starting point. I had enough information that I could read other Haskell
source and understand what it was trying to do even if I didn't feel
comfortable about all the details for writing programs.
However, a related issue that has been causing a lot of difficulty is
system installation. I'm primarily interested in building stand-alone
executables where speed is an important factor, so ghc seemed the best
system to work with. I've been unable to get this to work at all on a
Windows system. It seems configured to use dynamic libraries but doesn't
come with any in the package. I tried building from source, but it
requires Happy to build (and that too needed the .dlls).
On the Unix side, the installation was much smoother. I installed from
source using the FreeBSD port system and everything came together without
a hitch (it was a rather lengthy compile process though!).
There is a definite lack of "Getting Started" material in the ghc
distribution.
Documentation on libraries is also rather distributed. Sometimes I need to
look in the GHC manual about a library that is included with the
distribution, other times I need to look in the Haskell standard library
report. And if that fails, look in the Haskell standard language report
for information on what is included in the Prelude. Collecting this
information together would be a big benefit.
I've installed Hugs on the Windows side recently, and it seemed to boot up
okay. I haven't tried looking into its documentation to see if things are
any different.
Overall, I'm very pleased with the lannguage design and am excited about
its future.
Patrick
From kh0ndor@aeiou.pt Wed Jan 3 03:01:53 2001
From: kh0ndor@aeiou.pt (kh0ndor@aeiou.pt)
Date: Wed, 3 Jan 2001 03:01:53 GMT
Subject: (no subject)
Message-ID: <200101030301.DAA22807@xekmail.aeiou.pt>
somebody can tell me where I can find some ideas that help me in the
construction of a minesweeper programmed in haskell
I thank any type of help because I am a little confused
__________________________________________________________
Mensagem enviada pelo Xekmail: webmail grátis do AEIOU
http://xekmail.aeiou.pt
From ketil@ii.uib.no Wed Jan 3 07:28:22 2001
From: ketil@ii.uib.no (Ketil Malde)
Date: 03 Jan 2001 08:28:22 +0100
Subject: Learning Haskell and FP
In-Reply-To: George Russell's message of "Tue, 02 Jan 2001 15:27:20 +0100"
References: <3233BEE02CB3D4118DBA00A0C99869401D61EA@hermes.pml.com>
<200012281250500955.006178FD@mail> <3A51E249.AE219202@yale.edu>
<3A51E548.93C835AB@tzi.de>
Message-ID:
George Russell writes:
> I think Paul is being unduly modest. I found it very useful when I first learnt
> Haskell. But I did already know ML, so maybe the "Gentle Introduction" would be
> harder going for someone who didn't know anything about functional programming.
Mind if I "me too" a bit? I had just read the SICP, and I too found
that the Gentle Introduction served well as an introduction to the
Haskell syntax. I think it'd be fine if the title were a bit less
ambitious - it isn't really aimed at the novice, I think.
It's been a while since I read it tho'
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From syring@email.com Wed Jan 3 07:53:21 2001
From: syring@email.com (Karl M. Syring)
Date: Wed, 3 Jan 2001 08:53:21 +0100
Subject: Learning Haskell and FP
In-Reply-To:
Message-ID: <000101c0755a$3e1083b0$1e08363e@fenris>
> -----Original Message-----
> From: haskell-admin@haskell.org [mailto:haskell-admin@haskell.org]On
> Behalf Of Ketil Malde
> Sent: Wednesday, January 03, 2001 8:28 AM
> To: George Russell
> Cc: paul.hudak@yale.edu; i r thomas; haskell@haskell.org
> Subject: Re: Learning Haskell and FP
>
>
> George Russell writes:
>
> > I think Paul is being unduly modest. I found it very useful
> when I first learnt
> > Haskell. But I did already know ML, so maybe the "Gentle
> Introduction" would be
> > harder going for someone who didn't know anything about
> functional programming.
>
> Mind if I "me too" a bit? I had just read the SICP, and I too found
> that the Gentle Introduction served well as an introduction to the
> Haskell syntax. I think it'd be fine if the title were a bit less
> ambitious - it isn't really aimed at the novice, I think.
>
> It's been a while since I read it tho'
If you start out with zero knowledge in functional programming, as I do, the
GITH is really not very helpful. I have found the Clean tutorial
(cleanBookI.pdf) a good place to get my feet wet. Now, I gently try to move
on.
Regards
Karl M. Syring
PS: are the members of the list expecting to get replies by private mail?
From shlomif@vipe.technion.ac.il Wed Jan 3 08:11:51 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Wed, 3 Jan 2001 10:11:51 +0200 (IST)
Subject: (no subject)
In-Reply-To: <200101030301.DAA22807@xekmail.aeiou.pt>
Message-ID:
On Wed, 3 Jan 2001 kh0ndor@aeiou.pt wrote:
> somebody can tell me where I can find some ideas that help me in the=20
> construction of a minesweeper programmed in haskell
> I thank any type of help because I am a little confused=20
>
Check out the Haskell Gtk bindings.
Regards,
=09Shlomi Fish
=20
> __________________________________________________________
> Mensagem enviada pelo Xekmail: webmail gr=E1tis do AEIOU
> http://xekmail.aeiou.pt
>=20
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>=20
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il=20
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of=20
converting any statement that follows it into a true one.
From ketil@ii.uib.no Wed Jan 3 08:25:23 2001
From: ketil@ii.uib.no (Ketil Malde)
Date: 03 Jan 2001 09:25:23 +0100
Subject: Learning Haskell and FP
In-Reply-To: "Karl M. Syring"'s message of "Wed, 3 Jan 2001 08:53:21 +0100"
References: <000101c0755a$3e1083b0$1e08363e@fenris>
Message-ID:
"Karl M. Syring" writes:
>> Mind if I "me too" a bit? I had just read the SICP, and I too found
>> that the Gentle Introduction served well as an introduction to the
>> Haskell syntax.
> If you start out with zero knowledge in functional programming, as I do, the
> GITH is really not very helpful.
Exactly. It's "gentle" if you know functional programming, but
probably not otherwise.
> PS: are the members of the list expecting to get replies by private mail?
Expecting? I'd have no qualms about replying to people privately, but
then perhaps I am the obnoxious kind of person. :-) Negative feedback
is scarce (although this thread might favorably diverge to -cafe?
Followup-To: set).
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From simonpj@microsoft.com Wed Jan 3 09:02:00 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 3 Jan 2001 01:02:00 -0800
Subject: Learning Haskell and FP
Message-ID: <74096918BE6FD94B9068105F877C002D013784B8@red-pt-02.redmond.corp.microsoft.com>
| PS: are the members of the list expecting to get replies by
| private mail?
The thing to do is to switch the thread to
haskell-cafe@haskell.org
haskell@haskell-org is meant for openers; longer threads should
move to haskell-cafe. That way people can control how inundated they
get.
You can "move" by simply adding "-cafe" into the address when you reply.
Simon
From sk@mathematik.uni-ulm.de Wed Jan 3 09:14:45 2001
From: sk@mathematik.uni-ulm.de (Stefan Karrmann)
Date: Wed, 3 Jan 2001 10:14:45 +0100
Subject: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
In-Reply-To: <3A42661E.7FCCAFFA@tzi.de>; from ger@tzi.de on Thu, Dec 21, 2000 at 09:20:46PM +0100
References: <3A42661E.7FCCAFFA@tzi.de>
Message-ID: <20010103091445.481.qmail@theseus.mathematik.uni-ulm.de>
A syntax to choose the active instances may be useful, too.
E.g.:
use EccenticOrd, SetCollection in exp
then in exp the instances EccenticOrd, SetCollection are known (or preferred).
This is similiar to the open syntax in Cayenne.
--
Stefan Karrmann
From simonpj@microsoft.com Wed Jan 3 09:28:41 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 3 Jan 2001 01:28:41 -0800
Subject: Learning Haskell and FP
Message-ID: <74096918BE6FD94B9068105F877C002D013784BC@red-pt-02.redmond.corp.microsoft.com>
| There is a definite lack of "Getting Started" material in the ghc
| distribution.
I'm sure that's right. Trouble is, we're the last people qualified
to write one!
Here's a suggestion: would someone like to write such a guide,
from the point of view of a beginner, leaving blanks that we can fill in,
when you come across a task or issue you don't know the answer
to? That is, you provide the skeleton, and we fill in the blanks.
Simon
From syring@email.com Wed Jan 3 09:59:41 2001
From: syring@email.com (Karl M. Syring)
Date: Wed, 3 Jan 2001 10:59:41 +0100
Subject: Learning Haskell and FP
In-Reply-To: <74096918BE6FD94B9068105F877C002D013784B8@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <000401c0756b$e456ad10$1e08363e@fenris>
> -----Original Message-----
> From: Simon Peyton-Jones [mailto:simonpj@microsoft.com]
> Sent: Wednesday, January 03, 2001 10:02 AM
> To: syring@email.com; haskell@haskell.org
> Subject: RE: Learning Haskell and FP
>
>
> | PS: are the members of the list expecting to get replies by
> | private mail?
>
> The thing to do is to switch the thread to
>
> haskell-cafe@haskell.org
>
> haskell@haskell-org is meant for openers; longer threads should
> move to haskell-cafe. That way people can control how inundated they
> get.
>
> You can "move" by simply adding "-cafe" into the address when you reply.
I was somewhat irritated about the inclusion of the individual reply
adresses. Most mailing list software seems to remove the email adresses of
the senders. On the other hand, there are people that use the private mail
for archiving purposes, iff the content seems to be potentially important
while forwarding the letters send to the list to bit nirvana.
Regards
Karl M. Syring
From atze@cs.uu.nl Wed Jan 3 10:05:49 2001
From: atze@cs.uu.nl (Atze Dijkstra)
Date: Wed, 3 Jan 2001 11:05:49 +0100
Subject: GHC/Happy on MacOS X/Darwin
In-Reply-To: <20001221170104.9CDA21030@www.haskell.org>
References: <20001221170104.9CDA21030@www.haskell.org>
Message-ID:
On http://www.cs.uu.nl/~atze/Programming/index.html a version of ghc (4.08.1) and happy (still 1.8) for MacOS X/Darwin can be downloaded. However, a few remarks do apply: this version of ghc is not a completely ported version but built with generic settings and meant as a bootstrapping compiler. It also is distributed as binaries for a specific location (/usr/local/{ghc,happy}) in the UNIX directory structure. The main reasons for distributing it in this unfinished form are:
- The MacOS X cc (c compiler) has some (blocking) bugs (for example, problems with asm statements) which hinder progress.
- I consider 'unfinished' availability now of greater importance than 'perfect' availability later, so people can play with it.
- The compiler seems to run ok, that is, after minimal testing (compiling ghc libraries and a local AG + parsercombinator system).
--
- Atze -
Atze Dijkstra, Dept. of Computer Science, Utrecht University /|\
Tel.: +31-30-2534093/1454 | WWW : http://www.cs.uu.nl/~atze / | \
Fax : +31-30-2513971 | Email: atze@cs.uu.nl /--| \
atze.dijkstra@hetnet.nl / |___|
From israelt@optushome.com.au Wed Jan 3 13:36:25 2001
From: israelt@optushome.com.au (i r thomas)
Date: Wed, 03 Jan 2001 23:36:25 +1000
Subject: Writing a beginners guide to Haskell
In-Reply-To: <74096918BE6FD94B9068105F877C002D013784BC@red-pt-02.redmond.corp.microsoft.com>
References: <74096918BE6FD94B9068105F877C002D013784BC@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <200101032336250747.00A255A5@mail>
>Here's a suggestion: would someone like to write such a guide,
>from the point of view of a beginner, leaving blanks that we can fill in,
>when you come across a task or issue you don't know the answer
>to? That is, you provide the skeleton, and we fill in the blanks.
Well, I am definitely a beginner and am prepared to take this on
I have had some exposure to Ada, C , C++, Prolog etc but definitely no=
previous FP experience before.
For some time now, I had been planning to write an introduction to Haskell=
for my son
He is a bright 14 year old who is familiar with Delphi and VB but has like=
me
has not done any functional programming before . If it is simple enough
for him, it should work as a true "Beginners guide to Haskell".
I propose that I write it section by section, and either post to the=
mailing list for corrections and feedback.
If there are objections , I will send it to those willing to correct it (=
hopefully these will include Paul Hudak and Simon Peyton Jones ) . If my=
ability to continue this falters or if I encounter a section that is too=
hard for me, ( at the moment, monads seem a likely candidate ! ) I'll pass=
the enterprise along to anyone else who is willing to take it on !
From shlomif@vipe.technion.ac.il Wed Jan 3 12:44:16 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Wed, 3 Jan 2001 14:44:16 +0200 (IST)
Subject: Learning Haskell and FP
In-Reply-To: <3A51E249.AE219202@yale.edu>
Message-ID:
On Tue, 2 Jan 2001, Paul Hudak wrote:
> > Unforunately, the "Gentle Introduction To Haskell" that
> > haskell.org links to is not a very useful introduction.
>
> John and I should probably rename this document, since it really isn't a
> very gentle intro at all. We should probably also downplay it's
> prominance on the haskell website. It was written rather quickly many
> years ago, at a time when there was not a single textbook on Haskell.
> So it's probably outlived it's purpose, although I do believe that some
> people still find it useful.
>
I learned Haskell from it. Later, people corrected my style and I learned
some more. Of course, I did not do any serious Haskell programming yet,
except for my infamous primes finding algorithms.
Regards,
Shlomi Fish
> -Paul
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From paul.hudak@yale.edu Wed Jan 3 14:51:10 2001
From: paul.hudak@yale.edu (Paul Hudak)
Date: Wed, 03 Jan 2001 09:51:10 -0500
Subject: Learning Haskell and FP
References:
Message-ID: <3A533C5E.5F0879B5@yale.edu>
Thanks to everyone for their comments regarding "GITH". I conclude
that:
-- it is useful to people who have previously programmed in Scheme
or some other functional language
-- it is a difficult read for those not familiar with FP concepts,
and certainly not appropriate for novice programmers
-- given the dearth of free documentation on Haskell, it serves a
useful purpose
-- the title is misleading
Also thanks to George Russell for reminding me that the intro states
clearly that:
> Our goal is to provide a gentle introduction to Haskell for someone
> who has experience with at least one other language, preferably a
> functional language (even if only an "almost-functional" language
> such as ML or Scheme).
So I suppose the main thing that John and I should think about is
changing the title. Something like "An Introduction to Haskell for
People Who Have Previously Programmed in Scheme or Some Other Functional
Language" might be good! :-) Of course changing the title might confuse
people to whom the document was recommended. It may be that a
clarifying remark on haskell.org is warranted.
Anyway, thanks again for the comments.
Best to All for the New Year,
-Paul
From peterson-john@cs.yale.edu Wed Jan 3 15:02:01 2001
From: peterson-john@cs.yale.edu (John Peterson)
Date: Wed, 3 Jan 2001 10:02:01 -0500
Subject: Learning Haskell and FP
In-Reply-To: <3A533C5E.5F0879B5@yale.edu> (message from Paul Hudak on Wed, 03
Jan 2001 09:51:10 -0500)
References: <3A533C5E.5F0879B5@yale.edu>
Message-ID: <200101031502.KAA27959@ragged.cs.yale.edu>
One more thing: I'm happy to incorporate any tutorial material into
haskell.org. If you have material that would be appropriate please
let me know and I'll add it to the site. I know there are some very
good slides from Haskell courses that could be put into haskell.org.
The document sources to the Gentle Intro are also available. We've
already had some very generous help with it and Paul and I will be
happy to support anyone that would like to improve it further.
Finally, another thing that would be really nice in the way of
tutorials is one from the perspective of an experienced C++ / Java
programmer. Even a relatively short work that maps between the O-O
terminology and the Haskell world would be quite useful.
John
From ger@tzi.de Wed Jan 3 15:07:15 2001
From: ger@tzi.de (George Russell)
Date: Wed, 03 Jan 2001 16:07:15 +0100
Subject: Learning Haskell and FP
References: <3A533C5E.5F0879B5@yale.edu>
Message-ID: <3A534023.11EA3037@tzi.de>
Paul Hudak wrote:
[snip]
> So I suppose the main thing that John and I should think about is
> changing the title. Something like "An Introduction to Haskell for
> People Who Have Previously Programmed in Scheme or Some Other Functional
> Language" might be good! :-)
"A Gentle Introduction to Haskell for Functional Programmers" might be better.
Then hopefully people who have been directed to "A Gentle Introduction" will
not be confused.
From zawrotny@gecko.sb.fsu.edu Wed Jan 3 16:26:53 2001
From: zawrotny@gecko.sb.fsu.edu (Michael Zawrotny)
Date: Wed, 03 Jan 2001 11:26:53 -0500
Subject: Learning Haskell and FP
In-Reply-To: Your message of "Wed, 03 Jan 2001 09:51:10 EST."
<3A533C5E.5F0879B5@yale.edu>
Message-ID: <20010103162602.86980FCE@www.haskell.org>
Paul Hudak wrote:
> Thanks to everyone for their comments regarding "GITH". I conclude
> that:
>
> -- it is useful to people who have previously programmed in Scheme
> or some other functional language
> -- it is a difficult read for those not familiar with FP concepts,
> and certainly not appropriate for novice programmers
> -- given the dearth of free documentation on Haskell, it serves a
> useful purpose
> -- the title is misleading
>
> Also thanks to George Russell for reminding me that the intro states
> clearly that:
>
> > Our goal is to provide a gentle introduction to Haskell for someone
> > who has experience with at least one other language, preferably a
> > functional language (even if only an "almost-functional" language
> > such as ML or Scheme).
GITH was a bit much for me. However, I have a slightly different
take on the reason why. My original background (undergrad
and PhD) is in biochemistry. Most of my programming, etc. is
self-taught, although I got through about third year's worth of
course work for an undergrad CS degree while I was at my previous
job. In the course of teaching myself various things, I dabbled
in both scheme and common lisp and more recently in SML and OCaml
(and obviously Haskell as well).
The reason that I found GITH difficult wasn't that the concept
of programming with functions/functional style was new to
me. What got me was that the concepts and notations were much
more "mathematical" than "programmatic". In my explorations
of various languages, my experience with introductions to
scheme/CL has mostly been that they tend to show how to do
things that are familiar to imperative programmers, plus all
of the things that you can do with functions as first class
values. With intros to SML, OCaml and Haskell, there is a
much greater emphasis on types, type systems, and provable
program correctness. The main difference being the emphasis
on doing familiar things in a better way followed by some new
things (scheme/lisp intros) versus throwing you into what may
be completely uncharted territory (formal type systems, monads,
functors) in SML/OCaml/Haskell intros.
There also seems to be the tendency to assume that the meaning of
a type signature like
map :: (a->b) -> [a] -> [b]
is inherently obvious. To someone unfamiliar with HM type
systems and whose last course in mathematics was more than a
decade ago, it might as well be greek.
The thing that I would most like to see would entitled "A
Practical Guide to Haskell" or something of that nature. After
working through some of the online tutorials and a fair portion
of "Craft of Functional Programming", I thought, "Ok, I do most
of these excercises, and am comfortable. Let's try that utility
program I've been thinking about for the last couple weeks."
What I ran into was scenarios like the ones listed below (some of
which have since been solved):
1. How the #$!? do I read some data from a file. Good, I've
got the data, now I can work on it. Nope, now I have an "IO
thingie" whatever that is, but all of the standard functions want
a regular "thingie" now what?
2. I need to do some XML processing. Go to haskell.org, find
links to HaXML and install it. Try to use it... Nope, no
documentation that is understandable to me. Ok, look at the
source to the one demo program that does something close to
what I want. Nope, it was written in the "It's functional and
therefore self-documenting" style. (Note, this is not intended
to be a shot at the implementors of HaXML. It is clear from
the description of the library and the functions of the included
programs that the library is complete and well thought out. I
am also sure that someone already fluent in Haskell who is used
to looking at type signatures to deduce the purpose of a function
can do sophisticated things with it. My only criticism was that
it wasn't approachable to someone who is starting to feel somewhat
comfortable with Haskell and wants to "do" something useful with it,
as opposed to exercises from a book or tutorial.)
3. I gave up on Haskell for that particular utility and wrote it
OCaml.
One is tempted to come to the conclusion that Haskell is not
suited for "normal" programmers writing "normal" programs. I
don't necessarily think that is true, but it is difficult for
someone who is used to imperative/OO style programming and has
dabbled in impure functional languages.
To be fair, I had almost the same reaction to SML/OCaml when I
first encountered them. Working on Haskell and reading "Craft"
made it much easier to go back and look at them again. It's
probably that in the spectrum of imperative ----> functional
languages, scheme/CL are farther to the left than SML/OCaml,
which is still left of Haskell. In the case of someone like me
coming from C, C++, perl, python, etc., the extreme right is
inherently much less familiar territory than the middle ground.
The tendency of the written materials to get more mathematical as
one moves to the right also exacerbates the problem.
That was my reaction when I read GITH and some of the other
introductory material around. A lot of this probably is
more relevant to the people who are thinking of writing
a lower-level intro than it is to the next edition of
The-Document-Formerly-Known-As-GITH.
My plea is for people include introductory material for people
who know how to program in general and want to do mundane tasks
in Haskell as opposed to C, Python, or whatever other language.
Mike
--
Michael Zawrotny
411 Molecular Biophysics Building
Florida State University | email: zawrotny@sb.fsu.edu
Tallahassee, FL 32306-4380 | phone: (850) 644-0069
From mpj@cse.ogi.edu Wed Jan 3 17:05:07 2001
From: mpj@cse.ogi.edu (Mark P Jones)
Date: Wed, 3 Jan 2001 09:05:07 -0800
Subject: Problem with functional dependencies
In-Reply-To: <74096918BE6FD94B9068105F877C002D013783CC@red-pt-02.redmond.corp.microsoft.com>
Message-ID:
| I think you can simplify the example. Given
|=20
| class HasFoo a b | a -> b where
| foo :: a -> b
| instance HasFoo Int Bool where ...
|=20
| Is this legal?
| f :: HasFoo Int b =3D> Int -> b
| f x =3D foo x
The theoretical foundation for functional dependencies goes back to
the work I did on "Simplifying and Improving Qualified Types".
(Interested parties can find a 1994 report on this on my web pages;
email me if you need a pointer.)
According to that theory, the type above is a "principal satisfiable
type" for f, as is the more accurate Int -> Bool: under the
satisfiability ordering described in the report, these two types
are (satisfiably) equivalent. There is, therefore, no technical
reason why the function f could not be treated as having the
polymorphic type shown above.
On the other hand, from a practical perspective, one can argue that
the polymorphic type is misleading, obfuscating, and cumbersome:
Misleading because f doesn't really have a polymorphic type as the
declaration pretends; Obfuscating because it forces a reader to
study instance declarations that are not included in the type;
and Cumbersome because it includes an unnecessary (HasFoo Int b)
constraint that could be eliminated to produce a shorter, simpler
type.
So it comes down to a language design *decision* for which functional
dependencies, by themselves, do not force a particular choice.
- The current Hugs implementation does not allow the polymorphic
type; the intention in that implementation was to infer more
accurate, less complex types. The idea here is to make programs
easier for programmers to read, write, and understand.
- Marcin indicates that he would prefer the more relaxed approach
that allows polymorphic types; he is writing a preprocessor that
generates type signatures, and his task is easier if he doesn't
have to worry about the "improvement" of class constraints.
The idea here is to make programs easier for generators to read,
write and manipulate.
Clearly, some compromise is needed because neither approach is right
for all purposes. If we look to other aspects of the language for
inspiration, then the best way to deal with this is (probably):
(i) to infer simpler types whenever possible, but
(ii) to allow more polymorphic types when they are requested by
means of an explicit type signature.
(Incidentally, in the interests of consistency, such a system should
also programmers to use types like Num Int =3D> Int -> Bool.)
All the best,
Mark
From fjh@cs.mu.oz.au Wed Jan 3 17:37:55 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Thu, 4 Jan 2001 04:37:55 +1100
Subject: Problem with functional dependencies
In-Reply-To:
References: <74096918BE6FD94B9068105F877C002D013783CC@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20010104043755.A27457@hg.cs.mu.oz.au>
On 03-Jan-2001, Mark P Jones wrote:
> ... the best way to deal with this is (probably):
> (i) to infer simpler types whenever possible, but
> (ii) to allow more polymorphic types when they are requested by
> means of an explicit type signature.
I agree.
> (Incidentally, in the interests of consistency, such a system should
> also programmers to use types like Num Int => Int -> Bool.)
Mercury uses the approach you've suggested above for constraints like
these. That is, you can declare types like that, and the Mercury
type checker will accept them, but it won't try to infer such types.
This feature could be a bit more useful in Mercury than in Haskell,
since in Mercury instance declarations can be private to a particular
module.
(Unfortunately, though, the Mercury runtime system's RTTI
representation of instances is not able to handle such constraints, so
for such examples, the current implementation of the compiler reports
"sorry, not implemented: constraints may only constrain type variables".)
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From haberg@matematik.su.se Wed Jan 3 18:01:38 2001
From: haberg@matematik.su.se (Hans Aberg)
Date: Wed, 3 Jan 2001 19:01:38 +0100
Subject: GHC/Happy on MacOS X/Darwin
In-Reply-To:
References: <20001221170104.9CDA21030@www.haskell.org>
<20001221170104.9CDA21030@www.haskell.org>
Message-ID:
[Replies please cc me or the hugs-bugs list, as I currently is not on the
Haskell list.]
At 11:05 +0100 1-01-03, Atze Dijkstra wrote:
>On http://www.cs.uu.nl/~atze/Programming/index.html a version of ghc
>(4.08.1) and happy (still 1.8) for MacOS X/Darwin can be downloaded.
>However, a few remarks do apply: this version of ghc is not a completely
>ported version but built with generic settings and meant as a
>bootstrapping compiler. It also is distributed as binaries for a specific
>location (/usr/local/{ghc,happy}) in the UNIX directory structure. The
>main reasons for distributing it in this unfinished form are:
>- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>problems with asm statements) which hinder progress.
Isn't this related to the "munging" that GHC makes use of on other platforms?
>- I consider 'unfinished' availability now of greater importance than
>'perfect' availability later, so people can play with it.
>- The compiler seems to run ok, that is, after minimal testing (compiling
>ghc libraries and a local AG + parsercombinator system).
Otherwise it sounds great: As no-one before has been able to port anything
of GHC to MacOS (as far as I know), any kind of progress is important. (I
do not have access to MacOS X right now, so unfortunatley I cannot try out
your port.)
Hans Aberg
From qrczak@knm.org.pl Wed Jan 3 18:40:30 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 3 Jan 2001 18:40:30 GMT
Subject: Problem with functional dependencies
References:
Message-ID:
I don't fully understand fundeps. Would the following transform
legal programs (without overlapping instances) into legal programs?
I hope yes.
Let's imagine a class with a set of instances and uses, without
fundeps.
- Add some additional type variables to the class header.
- Add a fundep: all old type variables -> all new type variables.
- For each instance, in places corresponding to new type variables
write arbitrary types.
- For each constraint based on this class, in places corresponding
to new type variables write unique type variables.
In particular, should the following be legal:
class C a b c | a -> b c
instance C [a] b b
f:: C [a] b c => a
f = undefined
ghc panics and Hugs rejects it.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From atze@cs.uu.nl Wed Jan 3 19:48:59 2001
From: atze@cs.uu.nl (Atze Dijkstra)
Date: Wed, 3 Jan 2001 20:48:59 +0100
Subject: GHC/Happy on MacOS X/Darwin
In-Reply-To:
References: <20001221170104.9CDA21030@www.haskell.org>
<20001221170104.9CDA21030@www.haskell.org>
Message-ID:
At 19:01 +0100 03/01/2001, Hans Aberg wrote:
> >- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>>problems with asm statements) which hinder progress.
>
>Isn't this related to the "munging" that GHC makes use of on other platforms?
Apple's cc (actually gcc) does not accept 'asm' statements the way the manual describes it (it fails to parse them). asm statements are used to map GHC runtime pseudo registers to actual powerpc machine registers. The assembly source postprocessing does not work either (it is turned off) but is not related to this problem (to my knowledge).
--
- Atze -
Atze Dijkstra, Dept. of Computer Science, Utrecht University /|\
Tel.: +31-30-2534093/1454 | WWW : http://www.cs.uu.nl/~atze / | \
Fax : +31-30-2513971 | Email: atze@cs.uu.nl /--| \
atze.dijkstra@hetnet.nl / |___|
From haberg@matematik.su.se Wed Jan 3 20:03:56 2001
From: haberg@matematik.su.se (Hans Aberg)
Date: Wed, 3 Jan 2001 21:03:56 +0100
Subject: GHC/Happy on MacOS X/Darwin
In-Reply-To:
References:
<20001221170104.9CDA21030@www.haskell.org>
<20001221170104.9CDA21030@www.haskell.org>
Message-ID:
At 20:48 +0100 1-01-03, Atze Dijkstra wrote:
>At 19:01 +0100 03/01/2001, Hans Aberg wrote:
>> >- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>>>problems with asm statements) which hinder progress.
>>
>>Isn't this related to the "munging" that GHC makes use of on other platforms?
>
>Apple's cc (actually gcc) does not accept 'asm' statements the way the
>manual describes it (it fails to parse them). asm statements are used to
>map GHC runtime pseudo registers to actual powerpc machine registers. The
>assembly source postprocessing does not work either (it is turned off) but
>is not related to this problem (to my knowledge).
I think that it was Will Partain that described the problem as though one
had to do some assembly local to the CPU in order to get put the munging
through (perhaps I misunderstood it). -- So even if Apple's gcc accepted
asm, there would some (hard) work to do, in figuring out how the PPC (G3 &
G4) assmebly worked.
Hans Aberg
From russell@brainlink.com Thu Jan 4 04:11:38 2001
From: russell@brainlink.com (Benjamin L. Russell)
Date: Wed, 03 Jan 2001 23:11:38 -0500
Subject: Learning Haskell and FP
In-Reply-To: <20010103162602.86980FCE@www.haskell.org>
Message-ID:
On Wed, 03 Jan 2001 11:26:53 -0500
Michael Zawrotny wrote:
>
> [snip]
>
> The reason that I found GITH difficult wasn't that the
> concept
> of programming with functions/functional style was new to
> me. What got me was that the concepts and notations were
> much
> more "mathematical" than "programmatic". In my
> explorations
> of various languages, my experience with introductions to
> scheme/CL has mostly been that they tend to show how to
> do
> things that are familiar to imperative programmers, plus
> all
> of the things that you can do with functions as first
> class
> values. With intros to SML, OCaml and Haskell, there is
> a
> much greater emphasis on types, type systems, and
> provable
> program correctness.
>
> [snip]
>
> The thing that I would most like to see would entitled "A
> Practical Guide to Haskell" or something of that nature.
>
> [snip]
>
> One is tempted to come to the conclusion that Haskell is
> not
> suited for "normal" programmers writing "normal"
> programs.
How would you define a "'normal' programmer writing 'normal' programs?" What exactly is a "'normal' program?"
(Perhaps another way of phrasing the issue is as the "declarative" vs. "procedural" distinction, since the issue seems to be that of "what is" (types) vs. "how to" (imperative expression; i.e., procedures).)
While I agree that "A Practical Guide to Haskell" would indeed be a suitable alternative for programmers from the procedural school of expression, I would caution that such an introduction would probably not be suitable for all.
If I may give my own case as an example, I studied both C and Scheme (in addition to auditing a course in Haskell) in college, and favored Scheme over C precisely because of my Scheme course's emphasis on provable program correctness. This is largely a matter of background and taste: my course background was relatively focused on the design and analysis of algorithms, with provable program correctness being a related topic.
Perhaps, ideally, two separate tutorials (or perhaps a single tutorial with two sections based on different viewpoints?) may be needed? The difficulty is that the conceptual distance between the declarative and procedural schools of thought seems too great to be bridged by a single viewpoint. It seems that any introduction favoring either one would risk alienating the other.
Personally, I would really prefer "A Gentle Elementary Introduction to Haskell: Elements of the Haskell School of Expression with Practical Examples," but some would no doubt choose "Haskell in a Nutshell: How to Write Practical Programs in Haskell."
--Ben
--
Benjamin L. Russell
russell@brainlink.com
benjamin.russell.es.94@aya.yale.edu
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
From wli@holomorphy.com Thu Jan 4 07:18:49 2001
From: wli@holomorphy.com (William Lee Irwin III)
Date: Wed, 3 Jan 2001 23:18:49 -0800
Subject: Learning Haskell and FP
In-Reply-To: <74096918BE6FD94B9068105F877C002D013784BC@red-pt-02.redmond.corp.microsoft.com>; from simonpj@microsoft.com on Wed, Jan 03, 2001 at 01:28:41AM -0800
References: <74096918BE6FD94B9068105F877C002D013784BC@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20010103231849.A16876@holomorphy.com>
On Wed, Jan 03, 2001 at 01:28:41AM -0800, Simon Peyton-Jones wrote:
> Here's a suggestion: would someone like to write such a guide,
> from the point of view of a beginner, leaving blanks that we can fill in,
> when you come across a task or issue you don't know the answer
> to? That is, you provide the skeleton, and we fill in the blanks.
If someone should be bold enough to start writing such a guide, I would
be more than happy than to try to contribute to it and also set it up as
a Debian package.
Cheers,
Bill
--
"AIX is Unix from the universe where Spock had a beard."
-- Unknown
From d95lars@dtek.chalmers.se Thu Jan 4 08:45:19 2001
From: d95lars@dtek.chalmers.se (Lars Lundgren)
Date: Thu, 4 Jan 2001 09:45:19 +0100 (MET)
Subject: Learning Haskell and FP
In-Reply-To: <20010103162602.86980FCE@www.haskell.org>
Message-ID:
On Wed, 3 Jan 2001, Michael Zawrotny wrote:
> 1. How the #$!? do I read some data from a file. Good, I've
> got the data, now I can work on it. Nope, now I have an "IO
> thingie" whatever that is, but all of the standard functions want
> a regular "thingie" now what?
>
I do not know if you actually wanted an answer to this, but I'm sick of
hearing this FAQ everywhere when the answer is so simple. There are
exactly two ways to do this (one of them is actually syntactic sugar for
the other).
1. Use the do notation:
do regularThingie <- IOThingie
return (doWhateverYouWantWith regularThingie)
2. Use bind ( >>= ):
IOThingie >>=
\regularThingie -> return (doWhateverYouWantWith regularThingie)
Note: Both constructs produces IO thingies. This is the real beauty of it,
if you have a value that is dependent on the environment (i.e. a IO value)
you can use it as a regular value inside one of the above constructs, but
the result will always be an IO value (The result will depend on the
environment because it uses a value dependent of the environment). This is
no problem, just accept it.
Can everyone include an answer to this FAQ everywhere, phleaze!
/Lars L
From Keith.Wansbrough@cl.cam.ac.uk Thu Jan 4 10:42:08 2001
From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough)
Date: Thu, 04 Jan 2001 10:42:08 +0000
Subject: Learning Haskell and FP
In-Reply-To: Your message of "Thu, 04 Jan 2001 09:45:19 +0100."
Message-ID:
> I do not know if you actually wanted an answer to this, but I'm sick of
> hearing this FAQ everywhere when the answer is so simple. There are
> exactly two ways to do this (one of them is actually syntactic sugar for
> the other).
[..]
> Can everyone include an answer to this FAQ everywhere, phleaze!
>
> /Lars L
Thanks Lars... I've added it to the Wiki.
HINT TO EVERYONE: *Anyone* can add this kind of thing to the Wiki.
Just find the appropriate page and click the EditText link at the
bottom. To create a new page just name it (in BiCapitalised form), and
the name becomes a hyperlink. Click on the link, then EditText on the
new page and you're done.
The Haskell Wiki is at:
http://haskell.org/wiki/wiki
I *do not* maintain it, I just evangelise for it. :-)
--KW 8-)
From simonpj@microsoft.com Thu Jan 4 10:51:23 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 4 Jan 2001 02:51:23 -0800
Subject: Learning Haskell and FP
Message-ID: <74096918BE6FD94B9068105F877C002D01378531@red-pt-02.redmond.corp.microsoft.com>
| > 1. How the #$!? do I read some data from a file. Good, I've
| > got the data, now I can work on it. Nope, now I have an "IO
| > thingie" whatever that is, but all of the standard functions want
| > a regular "thingie" now what?
Perhaps this would be a good moment to advertise the revised version of
Tackling the Tackling the Awkward Squad:
monadic input/output, concurrency, exceptions,
and foreign-language calls in Haskell
http://research.microsoft.com/~simonpj/#marktoberdorf
(Concerning the thread I'm responding to, it gives an introduction
to monadic input/output.)
I've revised and extended this tutorial quite a bit since I announced it
last year,
with a lot of help from people on the Haskell mailing list: thank you!
Further suggestions are most welcome.
Simon
Abstract
Functional programming may be beautiful, but to write real
applications we must grapple with awkward real-world issues:
input/output, robustness, concurrency, and interfacing to programs
written in other languages.
These lecture notes give an overview of the techniques that have
been
developed by the Haskell community to address these problems. I
introduce various proposed extensions to Haskell along the way, and
I
offer an operational semantics that explains what these extensions
mean.
From israelt@optushome.com.au Thu Jan 4 13:04:33 2001
From: israelt@optushome.com.au (i r thomas)
Date: Thu, 04 Jan 2001 23:04:33 +1000
Subject: Learning Haskell and FP
In-Reply-To: <74096918BE6FD94B9068105F877C002D01378531@red-pt-02.redmond.corp.microsoft.com>
References: <74096918BE6FD94B9068105F877C002D01378531@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <200101042304330644.029280C6@mail>
>Perhaps this would be a good moment to advertise the revised version of
> Tackling the Tackling the Awkward Squad:
> monadic input/output, concurrency, exceptions,
> and foreign-language calls in Haskell
> http://research.microsoft.com/~simonpj/#marktoberdorf
>(Concerning the thread I'm responding to, it gives an introduction
>to monadic input/output.)
Many thanks !
This is just what I need.
Will read it before bed tonight...
From dfields@interpage.net Thu Jan 4 14:59:28 2001
From: dfields@interpage.net (Doug Fields)
Date: Thu, 4 Jan 2001 09:59:28 -0500 (EST)
Subject: Learning Haskell and FP
In-Reply-To: <200101031502.KAA27959@ragged.cs.yale.edu> from "John Peterson" at Jan 03, 2001 10:02:01 AM
Message-ID:
> One more thing: I'm happy to incorporate any tutorial material into
> haskell.org. If you have material that would be appropriate please
> let me know and I'll add it to the site. I know there are some very
> good slides from Haskell courses that could be put into haskell.org.
For what it's worth,
I'm happy to contribute my solutions to the exercises in
"Haskell: Craft" for posting on haskell.org. However, I assume that
in at least one place, the book is used for coursework and would, hence,
such posting would be discouraged.
Hi Paul. Hi Benjamin.
Cheers,
Doug
From rrt1001@cam.ac.uk Thu Jan 4 15:03:17 2001
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Thu, 4 Jan 2001 15:03:17 +0000 (GMT)
Subject: Happy InstallShield update
Message-ID:
I just noticed that the Happy 1.9 InstallShield contained a dynamically
linked executable for Happy. This was a Bad Idea, so I've replaced it with a
statically linked executable. This should work for more people.
--
http://sc3d.org/rrt/ | maxim, n. wisdom for fools
From C.Reinke@ukc.ac.uk Thu Jan 4 18:34:26 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Thu, 04 Jan 2001 18:34:26 +0000
Subject: ANNOUNCE: GHood -- a Graphical Hood (pre-release)
Message-ID:
Ever wanted to see what your Haskell program is doing?
Andy Gill's Hood library (http://www.haskell.org/hood/) represents
a big improvement over previous uses of trace & co. It doesn't affect
strictness properties, and instead of displaying debug information
in the nearly incomprehensible order in which it is generated, it
collects, post-processes and pretty-prints the information and displays
the results after program evaluation, in a more readable form.
However, as Andy already noted in the Hood documentation, there is
a lot of useful information to be gathered from the order in which
(parts of) data structures are observed. Now that Hood associates
individual observation events with the data structures to which they
belong, thus facilitating comprehension of observations, it would be
nice to find a way to visualise the observation order as well.
Andy's plan was to incorporate such a feature into a textual browser
add-on for Hood (in CVS, not released yet?). But for tasks for which
structural context and relationships between parts dominate over details,
my personal preference would be a graphical form of visualisation.
GHood is my current attempt to add a such a graphical viewer to Hood.
It hasn't yet reached its final form, but it is quite useful and usable
already. We have played with it locally, and I can't spent too much
time on this, but I would like to get some external feedback before
I finalise the development. Hence this pre-release.
Currently, GHood comes in two files: a drop-in replacement for the
Hugs98 variant of Hood (only minimal changes, same interface) and
a Java class file archive for the graphical viewer itself.
To find the two files, please visit my Haskell corner at:
http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/
Enjoy (and let me know what you think about it),
Claus
--
Claus Reinke, http://www.cs.ukc.ac.uk/people/staff/cr3/
Computing Lab, University of Kent at Canterbury
From mpj@cse.ogi.edu Thu Jan 4 21:01:56 2001
From: mpj@cse.ogi.edu (Mark P Jones)
Date: Thu, 4 Jan 2001 13:01:56 -0800
Subject: Problem with functional dependencies
In-Reply-To:
Message-ID:
Hi Marcin,
| In particular, should the following be legal:
|=20
| class C a b c | a -> b c
| instance C [a] b b
| f:: C [a] b c =3D> a
| f =3D undefined
|=20
| ghc panics and Hugs rejects it.
No, it is not legal. Even if you delete the definition of f, the code
is still not legal because the class and the instance declaration are
inconsistent.
The class declaration says that you want to define a three place =
relation
on types called C. We can think of the entries in this relation as rows
in a table with columns headed a, b, and c:
a | b | c
C =3D -----+-----+------
| |
Before we take a look at any instance declarations, this table is empty
(i.e., there are no rows). But the functional dependency a -> b c that
you have specified establishes a constraint that any data that gets =
added
to the table by subsequent instance declarations must satisfy. It says
that, if two rows have the same type in the a column, then they must =
also
have the same types in the b and c columns; "the values of b and c are
uniquely determined by the value of a."
So here are two plausible instance declarations that you could use:
instance C Int Int Char
instance C (Maybe t) t Int
Notice that the second declaration here is really an instance scheme;
the presence of a variable "t" means that it introduces a whole family
of instances, one for each possible instantiation of the variable "t".
With these two instance declarations in hand, our table looks something
like the following:
a | b | c
C =3D ------------------+-----------+------
Int | Int | Char
Maybe Int | Int | Int
Maybe Bool | Bool | Int
Maybe Char | Char | Int
Maybe [Int] | [Int] | Int
Maybe (Maybe Int) | Maybe Int | Int
... | ... | ...
Conceptually, of course, there are now infinitely many rows in the =
table,
so what you see here is just a small part of the relation. But notice =
that
the data in the table is entirely consistent with the functional =
dependency
a -> b c because no two rows have the same type in the a column.
Now consider the instance declaration that you have given:
instance C [t] s s
Again, this is an instance scheme, generating one row in the table
for each possible instantiation of variables "t" and "s". (To avoid
confusion with the names of the columns in C, I've chosen different
variable names from the ones you've used.) For example, based on
this instance declaration, we would expect to continue adding rows
to the table along the following lines:
a | b | c
C =3D ------------+-------+-------
[Int] | Int | Int t=3DInt, s=3DInt
[Int] | Bool | Bool t=3DInt, s=3DBool
[Bool] | Int | Int t=3DBool, s=3DInt
... | ... | ...
I hope now that the problem is becoming clear: this instance declaration
is not consistent with the dependency; in the first two lines above, for
example, we see two rows that violate the specification because they =
have
the same value of "a", but different values for "b" and "c".
In summary, the class declaration and its associated dependency are not
consistent with the instance declaration. If you really wanted the rows
described by the instance declaration to be part of the relation C, then
the dependency you have written is not valid. If you really did want =
the
restriction captured by the dependency, then the instance declaration is
not valid. Hugs can't tell which of these is the real source of the
problem, but it does report, correctly, that there is an inconsistency.
A little more generally, given the class declaration and the dependency
that you've specified, Hugs will not allow any instance declaration for
something of the form C t1 t2 t3 if there are variables in t2 or t3
that do not appear in t1. If this restriction were not enforced, then
it would again be possible for there to be multiple rows with the same
"a" value, but different "b" and "c" entries.
I noticed the same problem in one of the earlier examples that you sent
to the list:
| class Foo a b | a
| instance Foo Int [a]
| -- This is rejected by Hugs (with fundep a->b) but I would definitely
| -- accept it.
I hope that it is now clear why Hugs rejects this definition.
| I don't fully understand fundeps.
The specific point described above is actually discussed twice in my =
ESOP
paper, once informally, and once in a more general setting. I encourage
you to take a look at that paper for more details. If you're basing =
your
knowledge of fundeps on the (now quite outdated) note on my web page, or
on the section of the Hugs manual on which it was based, you may well =
have
some gaps to fill in. I'm not too happy with the ESOP paper either; I
couldn't include as much technical material there as I wanted because of
limited space. If you have read the ESOP paper and still have =
questions,
please let me know and I will do my best to answer them.
All the best,
Mark
From qrczak@knm.org.pl Thu Jan 4 22:33:50 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 4 Jan 2001 22:33:50 GMT
Subject: Problem with functional dependencies
References:
Message-ID:
Thu, 4 Jan 2001 13:01:56 -0800, Mark P Jones pisze:
> I hope now that the problem is becoming clear: this instance
> declaration is not consistent with the dependency; in the first
> two lines above, for example, we see two rows that violate the
> specification because they have the same value of "a", but different
> values for "b" and "c".
I see. So fundeps are not capable of expressing what I hoped, and what
a related but simpler concept I talked about once can express. I wonder
if there are practical uses of fundeps which are not expressible by
this concept.
What I have in mind is the following. A subset of type variables
of a class is chosen. Only that subset is used to find an instance
for resolving constraints with this class. The instance chosen
determines the rest of types. Instances must make this possible,
i.e. be non-unifiable wrt. the active subset of type variables. Voila.
An extended variant: several such subsets instead of one. Probably
each subset should be considered independently, with their results
unified. Or something like that.
This provides an equivalent of types contained in classes in C++.
It does not matter if the passive types in an instance use additional
type variables. This is where fundeps fail.
Having types with type variables which are never instantiated nor
constrained should be equivalent to having ground types!
Why, oh why haven't a more friendly and less problematic concept been
used, instead of fundeps which forever can't be finished in ghc and
have some different semantics in Hugs?
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From russell@brainlink.com Fri Jan 5 00:04:10 2001
From: russell@brainlink.com (Benjamin L. Russell)
Date: Thu, 04 Jan 2001 19:04:10 -0500
Subject: Learning Haskell and FP
In-Reply-To: <200101040655.WAA10861@gemini.willamette.edu>
Message-ID:
On Wed, 3 Jan 2001 22:55:17 -0800 (PST)
Fritz K Ruehr wrote:
>
> [snip]
>
> An O'Reilly "nutshell" book is an even better suggestion
> than
> my "Design Patterns in Haskell" of a few days back, at
> least
> from the perspective of marketing and promotion.
>
> But it raises the issue of an appropriate animal mascot
> for
> the cover; I can only come up with the Uakari, an
> exotic-looking
> rainforest monkey, which sounds similar to "Curry".
>
> (look here for a picture:)
>
>
Lalit Pant ( lalitp@acm.org ) (alternatively, lalit_pant@yahoo.com ) wrote an article in the May 2000 issue of _Java Report_ entitled "Developing Intelligent Systems With Java and Prolog" that described a Prolog implementation of the A-star search algorithm. Lalit stated that Prolog was useful for algorithm prototyping.
Perhaps Lalit Pant and Simon Peyton Jones could collaborate together on an article, perhaps overseen by Paul Hudak, on prototyping search algorithms in Haskell, also for _The Java Report?_ If this article then had a high readership, maybe the article's success could then justify publication of an O'Reilly _Haskell in a Nutshell_ book?
--Ben
P. S. (Hi Doug Fields. I didn't know that you were reading this mailing list. I guess that I should also greet Professor Paul Hudak: Hello, Professor Hudak. Sorry about Collectively Speaking. How's jazz in general?)
Benjamin L. Russell
russell@brainlink.com
benjamin.russell.es.94@aya.yale.edu
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
From peterd@availant.com Fri Jan 5 20:13:49 2001
From: peterd@availant.com (Peter Douglass)
Date: Fri, 5 Jan 2001 15:13:49 -0500
Subject: Are anonymous type classes the right model at all? (replying
to Re: Are fundeps the right model at all?)
Message-ID: <8BDAB3CD0E67D411B02400D0B79EA49A5F6CFF@smail01.clam.com>
Julian Assange wrote (Dec 28, 2000):
> This is why all non S-exp like lanaguage are doomed to progressive
> syntactic cancer as the useful parts of operator name space and syntax
> space become progressively polluted and mutated by one fad after
> another.
Could you expand on this? I would think that all languages have identifies
that, through common usage become standardized, and that this meaning
becomes a de-facto part of the language. Do you feel that this has not
happened in Lisp/Scheme?
--PeterD
From proff@iq.org Sat Jan 6 00:29:59 2001
From: proff@iq.org (Julian Assange)
Date: 06 Jan 2001 11:29:59 +1100
Subject: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
In-Reply-To: Peter Douglass's message of "Fri, 5 Jan 2001 15:13:49 -0500"
References: <8BDAB3CD0E67D411B02400D0B79EA49A5F6CFF@smail01.clam.com>
Message-ID:
Peter Douglass writes:
> Julian Assange wrote (Dec 28, 2000):
>
> > This is why all non S-exp like lanaguage are doomed to progressive
> > syntactic cancer as the useful parts of operator name space and syntax
> > space become progressively polluted and mutated by one fad after
> > another.
>
> Could you expand on this? I would think that all languages have identifies
> that, through common usage become standardized, and that this meaning
> becomes a de-facto part of the language. Do you feel that this has not
> happened in Lisp/Scheme?
The identifier space in lisp/scheme has wide tree depth and is
(essentially) lexically scoped. Infix operator identifiers in other
languages are the antithesis of this. It could be argued, both fairly
and unfairly, that the verbosity of S-exp bracketing leaves short
identifiers less desirable than they otherwise would be, however
tree-width arguments remain.
Polution of syntax space is a more difficult problem. As new syntactic
axioms are intruded, they should remain consistant with the existing
syntax elements. This poses ever increasing restraint on the evolution
of the language. New syntax elements appear less intuitive and more
arbitary in an attempt to fit in with the morass of ever increasing
restraints. If these restraints are not honnored, the language becomes
inconsistant. Eventually the language is guarenteed to become either
inconsistant or moribund as the number of interactions between
language elements overwhelms a language designers attempts understand
them.
The same is even more true of language semantics. The trouble lays in
finding initial axioms which can cleave large sections of future
concept space between them.
--
Julian Assange |If you want to build a ship, don't drum up people
|together to collect wood or assign them tasks and
proff@iq.org |work, but rather teach them to long for the endless
proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery
From kh0ndor@aeiou.pt Sun Jan 7 00:06:29 2001
From: kh0ndor@aeiou.pt (kh0ndor@aeiou.pt)
Date: Sun, 7 Jan 2001 00:06:29 GMT
Subject: (no subject)
Message-ID: <200101070006.AAA22676@xekmail.aeiou.pt>
which is the function in haskell that allows to generate us an amount
of aleatory numbers
I thank your help
__________________________________________________________
Mensagem enviada pelo Xekmail: webmail grátis do AEIOU
http://xekmail.aeiou.pt
From chak@cse.unsw.edu.au Sun Jan 7 09:13:45 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sun, 07 Jan 2001 20:13:45 +1100
Subject: (no subject)
In-Reply-To: <200101070006.AAA22676@xekmail.aeiou.pt>
References: <200101070006.AAA22676@xekmail.aeiou.pt>
Message-ID: <20010107201345R.chak@cse.unsw.edu.au>
kh0ndor@aeiou.pt wrote,
> which is the function in haskell that allows to generate us an amount
> of aleatory numbers
I guess, you want to generate random numbers. Check out
http://haskell.org/onlinelibrary/random.html
Cheers,
Manuel
From sebc@posse42.net Sun Jan 7 14:03:07 2001
From: sebc@posse42.net (Sebastien Carlier)
Date: Sun, 7 Jan 2001 15:03:07 +0100
Subject: Extending the do-notation
Message-ID: <20010107140312.09192FCF@www.haskell.org>
Sometimes I need to write code which looks like this:
> do x <- m1
> let y = unzip x
> ... -- never using x anymore
I thinks the following extension to do-notation would be useful:
> pat <- exp1 # exp2 ; exp3
would be rewritten as
> exp2 >>= ((\pat -> exp3) . exp1)
so that the above example could be rewritten more compactly:
> do y <- unzip # m1
I think the biggest problem with this extension is the choice
of a proper symbol.
Does this extension already exist ? (I only checked the Haskell 98
report).
From rje33@cam.ac.uk Sun Jan 7 14:41:48 2001
From: rje33@cam.ac.uk (Robert Ennals)
Date: Sun, 7 Jan 2001 14:41:48 +0000 (GMT)
Subject: Extending the do-notation
In-Reply-To: <20010107140312.09192FCF@www.haskell.org>
Message-ID:
On Sun, 7 Jan 2001, Sebastien Carlier wrote:
>
> Sometimes I need to write code which looks like this:
> > do x <- m1
> > let y = unzip x
> > ... -- never using x anymore
>
> I thinks the following extension to do-notation would be useful:
> > pat <- exp1 # exp2 ; exp3
> would be rewritten as
> > exp2 >>= ((\pat -> exp3) . exp1)
>
> so that the above example could be rewritten more compactly:
> > do y <- unzip # m1
>
> I think the biggest problem with this extension is the choice
> of a proper symbol.
Why not just use a user defined operator. eg:
infixr #
(#) :: Monad m => (a -> b) -> m a -> m b
f # p = p >>= (return . f)
Alternatively, define it to be "fmap", and be a bit more general.
-Rob
From qrczak@knm.org.pl Sun Jan 7 14:14:05 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 7 Jan 2001 14:14:05 GMT
Subject: Extending the do-notation
References: <20010107140312.09192FCF@www.haskell.org>
Message-ID:
Sun, 7 Jan 2001 15:03:07 +0100, Sebastien Carlier pisze:
> Does this extension already exist ?
Yes.
import Monad
...
do y <- liftM unzip m1
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From sebc@posse42.net Sun Jan 7 15:34:53 2001
From: sebc@posse42.net (Sebastien Carlier)
Date: Sun, 7 Jan 2001 16:34:53 +0100
Subject: Extending the do-notation
Message-ID: <20010107153452.E52BC1013@www.haskell.org>
> import Monad
> ...
> do y <- liftM unzip m1
Thanks.
I'm constantly amazed by the number of tricks one has
to know before he can write concise code using the
do-notation (among other things, I used to write
"x <- return $ m" instead of "let x = m").
Is there a paper demonstrating the most common
coding styles for do-notation ?
Another question concerning the do-notation: I noticed
that most parts of ghc do not use it. Is it because
the code was written before the notation was available,
because the do-notation is too weak to express these
parts, or for another fundamental reason ?
From R.Daniel@Europe.com Sun Jan 7 15:45:30 2001
From: R.Daniel@Europe.com (R.Daniel)
Date: Sun, 07 Jan 2001 15:45:30 +0000
Subject: Movement in a frictionless environment
Message-ID: <5.0.0.25.2.20010107154054.009f1a20@mail.ip.pt>
--=====================_1052009==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi, could anyone tell me where to find some info about generating movement
on a frictionless environment?
I need to put a ball running in a window, given an initial speed and then
let it run along with the rules of phisics....can anyone give me a hint on
where to find info, or on how to do that?
I would be most greatefull.
Thankx
----->R.Daniel
ICQ 28959546
--=====================_1052009==_.ALT
Content-Type: text/html; charset="us-ascii"
Hi, could anyone tell me where to find some info about generating
movement on a frictionless environment?
I need to put a ball running in a window, given an initial speed and then
let it run along with the rules of phisics....can anyone give me a hint
on where to find info, or on how to do that?
I would be most greatefull.
Thankx
----->R.Daniel
ICQ
28959546
--=====================_1052009==_.ALT--
From Sven.Panne@informatik.uni-muenchen.de Sun Jan 7 16:21:06 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Sun, 07 Jan 2001 17:21:06 +0100
Subject: Extending the do-notation
References: <20010107153452.E52BC1013@www.haskell.org>
Message-ID: <3A589772.8A84F4E8@informatik.uni-muenchen.de>
Sebastien Carlier wrote:
> I'm constantly amazed by the number of tricks one has
> to know before he can write concise code using the
> do-notation [...]
In my experience it is not the do-notation itself, but the mixture
of monadic actions and higher-order functions. But after a while
you´ll really like it. :-)
> Another question concerning the do-notation: I noticed
> that most parts of ghc do not use it. Is it because
> the code was written before the notation was available,
> because the do-notation is too weak to express these
> parts, or for another fundamental reason ?
It's only because of historical reasons, nothing more.
Cheers,
Sven
From Sven.Panne@informatik.uni-muenchen.de Sun Jan 7 16:24:19 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Sun, 07 Jan 2001 17:24:19 +0100
Subject: Movement in a frictionless environment
References: <5.0.0.25.2.20010107154054.009f1a20@mail.ip.pt>
Message-ID: <3A589833.256726CF@informatik.uni-muenchen.de>
"R.Daniel" wrote:
> Hi, could anyone tell me where to find some info about generating
> movement on a frictionless environment? [...]
I'd recommend one of the game programming sites, they have tons of
useful stuff related to physics, too:
http://www.devgames.com/
http://www.gdmag.com/
http://www.gamasutra.com/
http://www.flipcode.com/
http://www.gamesdomain.co.uk/gamedev/gprog.html
http://www.3dgamedev.com/
Cheers,
Sven
From shlomif@vipe.technion.ac.il Sun Jan 7 18:00:51 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Sun, 7 Jan 2001 20:00:51 +0200 (IST)
Subject: A dictionary implementation in Hasekll
Message-ID:
Does anybody knows of an implementation for an efficient dictionary (such
as a hash, an AVL tree, a B-Tree etc. ) in Haskell? Can an array do that?
I'd like something that can map any type to any other type based on a
comparison function, and perhaps a hashing function.
TIA,
Shlomi Fish
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From jenglish@flightlab.com Sun Jan 7 19:08:32 2001
From: jenglish@flightlab.com (Joe English)
Date: Sun, 07 Jan 2001 11:08:32 -0800
Subject: Extending the do-notation
In-Reply-To: <20010107140312.09192FCF@www.haskell.org>
References: <20010107140312.09192FCF@www.haskell.org>
Message-ID: <200101071908.LAA00838@dragon.flightlab.com>
Sebastien Carlier wrote:
> Sometimes I need to write code which looks like this:
> > do x <- m1
> > let y = unzip x
> > ... -- never using x anymore
>
> I thinks the following extension to do-notation would be useful:
> > pat <- exp1 # exp2 ; exp3
> would be rewritten as
> > exp2 >>= ((\pat -> exp3) . exp1)
>
> so that the above example could be rewritten more compactly:
> > do y <- unzip # m1
This can be done in Haskell without any changes to the
'do' notation at all: just define
| f # m = m >>= (return . f)
and add an appropriate fixity declaration for '#'.
--Joe English
jenglish@flightlab.com
From qrczak@knm.org.pl Sun Jan 7 21:25:58 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 7 Jan 2001 21:25:58 GMT
Subject: A dictionary implementation in Hasekll
References:
Message-ID:
Sun, 7 Jan 2001 20:00:51 +0200 (IST), Shlomi Fish pisze:
> Does anybody knows of an implementation for an efficient dictionary
> (such as a hash, an AVL tree, a B-Tree etc. ) in Haskell?
ghc's library contains FiniteMap, implemented as a balanced binary tree
(not exactly AVL), over any comparable type as the key.
I haven't seen a hash table. It's harder to do in the functional
context. It would either have to be mutable, or provide bulk operations
on many elements at once to be efficient - or use a trick with hidden
mutations in place to obtain a modified value while substituting
a backward difference for the old value, to have the functional
interface and cheap access to newest versions.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From Tom.Pledger@peace.com Mon Jan 8 04:53:35 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Mon, 8 Jan 2001 17:53:35 +1300
Subject: Are fundeps the right model at all?
In-Reply-To:
References:
Message-ID: <14937.18383.904979.841600@waytogo.peace.co.nz>
Marcin 'Qrczak' Kowalczyk writes:
> Could somebody show an example which requires fundeps and cannot be
> expressed using a simpler model explained below - a model that I
> can even understand? Is the model self-consistent at all?
>
[a model which uses key constraints instead of functional dependencies]
Hi.
Try this:
class C a b c | b -> c
instance C t () t
Hugs rejects it.
If we try to express C with keys instead of fundeps, the key must
contain both a and b, which is equivalent to this:
class C a b c | a b -> c
instance C t () t
Hugs accepts this, but only because the constraint has been weakened
to something which can be expressed with keys.
It's quite a contrived example, and I'm not sure how it relates to
your later statement:
> Having types with type variables which are never instantiated nor
> constrained should be equivalent to having ground types!
Do you have any examples of such a type variable in an instance decl?
I'm having trouble imagining it, because I keep running into
unnecessary class parameters and overlapping instances.
Regards,
Tom
From ahey@iee.org Mon Jan 8 04:57:17 2001
From: ahey@iee.org (Adrian Hey)
Date: Mon, 8 Jan 2001 04:57:17 +0000 (GMT)
Subject: First Class Modules? was Re: Are anonymous type classes the right model at all?
In-Reply-To:
Message-ID:
Hello,
All this talk about Haskell classes, ML modules and improved record types
reminds me of the rumours of a "First Class Modules" system for Haskell,
but the only documentation I found was a fairly brief document that looked
like an application for a research grant. So...
Could somebody explain what a first class module is?
How does it differ from a record?
What could I do with a first class module (if Haskell provided them)?
Thanks
--
Adrian Hey
From ger@tzi.de Mon Jan 8 10:55:49 2001
From: ger@tzi.de (George Russell)
Date: Mon, 08 Jan 2001 11:55:49 +0100
Subject: Extending the do-notation
References: <20010107153452.E52BC1013@www.haskell.org>
Message-ID: <3A599CB5.8D3A7823@tzi.de>
Sebastien Carlier wrote:
>
> > import Monad
> > ...
> > do y <- liftM unzip m1
>
> Thanks.
>
> I'm constantly amazed by the number of tricks one has
> to know before he can write concise code using the
> do-notation (among other things, I used to write
> "x <- return $ m" instead of "let x = m").
[snip]
Why do you WANT to write concise code using the do-notation?
Has someone revived the Obfuscated Haskell Contest, or
do you find touch-typing difficult?
From ger@tzi.de Mon Jan 8 14:58:06 2001
From: ger@tzi.de (George Russell)
Date: Mon, 08 Jan 2001 15:58:06 +0100
Subject: Yet more on functional dependencies
Message-ID: <3A59D57E.6F5E0489@tzi.de>
I am finding functional dependencies confusing. (I suspect I am not alone.)
Should the following code work?
class HasConverter a b | a -> b where
convert :: a -> b
instance (HasConverter a b,Show b) => Show a where
show value = show (convert value)
From qrczak@knm.org.pl Mon Jan 8 17:21:52 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 8 Jan 2001 17:21:52 GMT
Subject: Are fundeps the right model at all?
References: <14937.18383.904979.841600@waytogo.peace.co.nz>
Message-ID:
Mon, 8 Jan 2001 17:53:35 +1300, Tom Pledger pisze:
> > Having types with type variables which are never instantiated nor
> > constrained should be equivalent to having ground types!
>
> Do you have any examples of such a type variable in an instance decl?
Not quite. When the type variable is never instantiated, like in ST
(ghc's and hbc's state threads), I don't see fundeps.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From Tom.Pledger@peace.com Mon Jan 8 20:15:10 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Tue, 9 Jan 2001 09:15:10 +1300
Subject: Yet more on functional dependencies
In-Reply-To: <3A59D57E.6F5E0489@tzi.de>
References: <3A59D57E.6F5E0489@tzi.de>
Message-ID: <14938.8142.601890.119998@waytogo.peace.co.nz>
George Russell writes:
> I am finding functional dependencies confusing. (I suspect I am not alone.)
> Should the following code work?
>
> class HasConverter a b | a -> b where
> convert :: a -> b
>
> instance (HasConverter a b,Show b) => Show a where
> show value = show (convert value)
Yes.
Let's assume that multi-parameter classes and overlapping instances
are enabled.
Without the functional dependency, the instance decl would be rejected
because the type variable b occurs in the context (HasConverter a b,
Show b) but not in the head (Show a). The compiler needs to generate
some code for `show value', but it's not allowed to make an arbitrary
substitution for b.
The functional dependency provides a way to determine b uniquely once
a is matched. So, the compiler can generate the code for `show value'
without being arbitrary.
Regards,
Tom
From Tom.Pledger@peace.com Mon Jan 8 21:30:52 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Tue, 9 Jan 2001 10:30:52 +1300
Subject: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
In-Reply-To:
References:
<3A42661E.7FCCAFFA@tzi.de>
<20001229003745.A11084@mark.ugcs.caltech.edu>
Message-ID: <14938.12684.532876.890748@waytogo.peace.co.nz>
Marcin 'Qrczak' Kowalczyk writes:
[...]
> My new record scheme proposal does not provide such lightweight
> extensibility, but fields can be added and deleted in a controlled
> way if the right types and instances are made.
Johan Nordlander must be on holiday or something, so I'll deputise for
him. :-)
O'Haskell also has add-a-field subtyping. Here's the coloured point
example (from http://www.cs.chalmers.se/~nordland/ohaskell/survey.html):
struct Point =
x,y :: Float
struct CPoint < Point =
color :: Color
Regards,
Tom
From nellardo@concentric.net Tue Jan 9 00:13:21 2001
From: nellardo@concentric.net (Brook Conner)
Date: Mon, 08 Jan 2001 19:13:21 -0500
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Message-ID: <3A5A57A1.6000609@concentric.net>
Inspired by the recent discussions of what kinds of books would
encourage the spread of Haskell, I whipped up a draft table of contents
for "Haskell in a Nutshell."
You can find it in PDF form at
http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts
embedded - OReilly uses a couple of oddballs) and in ASCII text at
http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt.
While there are page numbers attached, you should simply ignore those
for the moment :-) Rather, I'd be interested in feedback on the
structure etc. Oh, and please don't just rip it off and write it
yourself :-)
Like "Java in a Nutshell", the first part is a firehose description of
the language. As Haskell is somewhat different from what most OReilly
readers are used to, I've included a bit more about different ways you
can run Haskell (which, incidentally, points out that it runs *everywhere*).
Also like "Java in a Nutshell", the last part is a reference to common
packages.
The middle part is a bit different - a short "cookbook" of
semi-practical programs addressing fairly common programming tasks -
some of the kinds of things you'd typically do with Perl or C++. I think
it needs more "recipes" of course, but I'd like to know if the general
idea is working.
Brook
ps - for the curious, I have in fact written a textbook before
(object-oriented programming for a first-semester course, from 1994...).
And I'm using O'Reilly's FrameMaker templates, so the draft is
"camera-ready" (hence the page numbers - the TOC is automatically
generated).
From chak@cse.unsw.edu.au Tue Jan 9 02:43:59 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 09 Jan 2001 13:43:59 +1100
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
In-Reply-To: <3A5A57A1.6000609@concentric.net>
References: <3A5A57A1.6000609@concentric.net>
Message-ID: <20010109134359E.chak@cse.unsw.edu.au>
Brook Conner wrote,
> You can find it in PDF form at
> http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts
> embedded - OReilly uses a couple of oddballs) and in ASCII text at
> http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt.
Makes sense to me. However, I would move IO further to the
front. For any "real life" programming, IO is essential
and, I think, it is bad for the image of Haskell to treat it
as something dirty that is relegated to end of every (at
least, many) introduction of Haskell.
I have just given an Introduction to Computing course using
Haskell and written a set of lecture notes, which introduce
a couple of concepts (including IO) differently than
commonly done. The whole stuff is at
http://www.cse.unsw.edu.au/~cs1011/lectures/index.html
Feel free to get inspiration from the material (except Weeks
8 - 10, which weren't given by me). You will find IO in
Week 5. Note that I haven't used the word monad a single
time. IMHO, monads are an advanced concept, IO is not.
It's like you can introduce recursion without discussing
stacks. If you understand stacks, you can gain a deeper
understanding of recursion, but if you hear about recursion
for the first time, the mention of stacks will only distract
the average student.
> The middle part is a bit different - a short "cookbook" of
> semi-practical programs addressing fairly common programming tasks -
> some of the kinds of things you'd typically do with Perl or C++. I think
> it needs more "recipes" of course, but I'd like to know if the general
> idea is working.
I think, that this is a good idea.
Cheers,
Manuel
From bhalchin@hotmail.com Tue Jan 9 03:15:34 2001
From: bhalchin@hotmail.com (Bill Halchin)
Date: Tue, 09 Jan 2001 03:15:34
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Message-ID:
Yes! I agree with Manuel about the IO. It looks bad being towards
the end.
Regards,
Bill Halchin
>From: "Manuel M. T. Chakravarty"
>Reply-To: chak@cse.unsw.edu.au
>To: nellardo@concentric.net
>CC: haskell@haskell.org
>Subject: Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
>Date: Tue, 09 Jan 2001 13:43:59 +1100
>
>Brook Conner wrote,
>
> > You can find it in PDF form at
> > http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts
> > embedded - OReilly uses a couple of oddballs) and in ASCII text at
> > http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt.
>
>Makes sense to me. However, I would move IO further to the
>front. For any "real life" programming, IO is essential
>and, I think, it is bad for the image of Haskell to treat it
>as something dirty that is relegated to end of every (at
>least, many) introduction of Haskell.
>
>I have just given an Introduction to Computing course using
>Haskell and written a set of lecture notes, which introduce
>a couple of concepts (including IO) differently than
>commonly done. The whole stuff is at
>
> http://www.cse.unsw.edu.au/~cs1011/lectures/index.html
>
>Feel free to get inspiration from the material (except Weeks
>8 - 10, which weren't given by me). You will find IO in
>Week 5. Note that I haven't used the word monad a single
>time. IMHO, monads are an advanced concept, IO is not.
>It's like you can introduce recursion without discussing
>stacks. If you understand stacks, you can gain a deeper
>understanding of recursion, but if you hear about recursion
>for the first time, the mention of stacks will only distract
>the average student.
>
> > The middle part is a bit different - a short "cookbook" of
> > semi-practical programs addressing fairly common programming tasks -
> > some of the kinds of things you'd typically do with Perl or C++. I think
> > it needs more "recipes" of course, but I'd like to know if the general
> > idea is working.
>
>I think, that this is a good idea.
>
>Cheers,
>Manuel
>
>_______________________________________________
>Haskell mailing list
>Haskell@haskell.org
>http://www.haskell.org/mailman/listinfo/haskell
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
From ketil@ii.uib.no Tue Jan 9 06:39:47 2001
From: ketil@ii.uib.no (Ketil Malde)
Date: 09 Jan 2001 07:39:47 +0100
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
In-Reply-To: Brook Conner's message of "Mon, 08 Jan 2001 19:13:21 -0500"
References: <3A5A57A1.6000609@concentric.net>
Message-ID:
Brook Conner writes:
> Inspired by the recent discussions of what kinds of books would encourage the
> spread of Haskell, I whipped up a draft table of contents for "Haskell in a
> Nutshell."
Let's see. It all depends on what you put into the chapters, of
course, but you seem to jump directly from simple concepts into
Haskell for web servers. Wouldn't it be better to push this further
out, until at least some of the syntax has been explored?
From the headlines, one might get the impression that type
declarations are only important when the compiler can't figure it out
itself - I'm sure the actual text will give a different view, no?
The cookbook looks great, and it's certainly something I'd buy the
book for. I can, of course, think of many kinds of example programs
I'd like to see - how about a GUI oriented program, for instance?
Perhaps you could finish it off with a "real" application, say a GUIed
JPEG viewer, where you sort of string it all (the JPEG codec, a C
library interface for something or other, and GUI stuff, etc.)
together into a whole?
On the whole, I think it looks good. Best of luck!
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From joe@isun.informatik.uni-leipzig.de Tue Jan 9 08:00:27 2001
From: joe@isun.informatik.uni-leipzig.de (Johannes Waldmann)
Date: Tue, 9 Jan 2001 09:00:27 +0100 (MET)
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
In-Reply-To: <20010109134359E.chak@cse.unsw.edu.au> from "Manuel M. T. Chakravarty"
at "Jan 9, 2001 01:43:59 pm"
Message-ID: <200101090800.JAA19782@isun11.informatik.uni-leipzig.de>
> However, I would move IO further to the front.
> For any "real life" programming, IO is essential...
I am currently teaching a Functional Programming lecture (notes in German:
http://www.informatik.uni-leipzig.de/~joe/edu/ws00/praxis/skript/)
and I also used this approach: use the do-notation intuitively
(for text IO and graphics, using SOE book),
and explain monads later (with parser combinators and interpreters).
This could be driven to the extreme: not only hide the word "monad",
but also "functional". The title would be "Imperative programming in Haskell"
(as S. Peyton Jones says in Tackling the Awkward Squad:
"Haskell is the world's finest imperative programming language").
The students would start writing do-notated programs in the IO monad,
starting with putStrLn "Hello World";
and gradually the emphasis is shifted from sequencing (the "semicolon")
to "what can we do on the righthand side of let x = ... ",
thus introducing functional programming.
Not sure if this is really a good idea, though...
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From joe@isun.informatik.uni-leipzig.de Tue Jan 9 08:46:31 2001
From: joe@isun.informatik.uni-leipzig.de (Johannes Waldmann)
Date: Tue, 9 Jan 2001 09:46:31 +0100 (MET)
Subject: Defaults in datatype definitions
Message-ID: <200101090846.JAA19878@isun11.informatik.uni-leipzig.de>
Below are some suggestions for extensions to Haskell records.
These are just naive ideas.
Of course the extensions should integrate nicely
w.r.t. the existing syntax, type system, and module system.
Perhaps you can point me to opinions and research
on what has already been done, or to why it should not, or can not.
1) I would like to write down default values for record components
data Foo = Foo { x :: Bar; y :: Baz; x = some_expression }
We can do this for methods in type classes, so why not here.
2) With classes, we can do even more: in the default method,
we can access other methods.
This suggests that the above example should in fact read
data Foo = Foo { x :: Bar; y :: Baz; x = \ self -> some_expression }
where `self' might occur in some_expression. that is,
the default value of `me.x ' gets computed by applying a function to `me'.
3) I want to be able, in modules that use the type,
to add more components (with defaults) to the type:
This would avoid lengthy recomputations (at the cost of additional space).
Imagine the difference between
data Tree a = Node { key :: a, children :: [ Tree a ] }
size t = 1 + sum (map size (children t))
and
data Tree a = Node { key :: a, children :: [ Tree a ]
, size :: Integer
, size = \ self -> 1 + sum (map size (children self)) }
when you have one large tree and frequently need sizes of subtrees.
(by the way, what type does `size' have now -
do we write `Integer' or `Tree a -> Integer'?)
yes, I can do this manually, replacing `Node' by a smart constructor
that computes and stores the size. What I don't like about this
is that I have to know in advance (i. e. at the moment I define the type)
what functions I want to be "cached" this way.
Imagine `size' as some more complicated function,
only defined many modules later.
Of course I see that this would be difficult to implement
w.r.t. separate compilation. But I would be happy with a compiler
that ignores the "cache" specs during single-module compilations,
but honors them when doing a full rebuild of a set of modules.
I imagine that inter-module inlining behaves similar.
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From chak@cse.unsw.edu.au Tue Jan 9 09:41:05 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 09 Jan 2001 20:41:05 +1100
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
In-Reply-To: <200101090800.JAA19782@isun11.informatik.uni-leipzig.de>
References: <20010109134359E.chak@cse.unsw.edu.au>
<200101090800.JAA19782@isun11.informatik.uni-leipzig.de>
Message-ID: <20010109204105S.chak@cse.unsw.edu.au>
Johannes Waldmann wrote,
> > However, I would move IO further to the front.
> > For any "real life" programming, IO is essential...
>
> I am currently teaching a Functional Programming lecture (notes in German:
> http://www.informatik.uni-leipzig.de/~joe/edu/ws00/praxis/skript/)
> and I also used this approach: use the do-notation intuitively
> (for text IO and graphics, using SOE book),
> and explain monads later (with parser combinators and interpreters).
>
> This could be driven to the extreme: not only hide the word "monad",
> but also "functional". The title would be "Imperative programming in Haskell"
> (as S. Peyton Jones says in Tackling the Awkward Squad:
> "Haskell is the world's finest imperative programming language").
>
> The students would start writing do-notated programs in the IO monad,
> starting with putStrLn "Hello World";
> and gradually the emphasis is shifted from sequencing (the "semicolon")
> to "what can we do on the righthand side of let x = ... ",
> thus introducing functional programming.
Starting with
putStrLn "Hello World"
is a good idea and this would exactly be my approach when
teaching students who already know some programming language
(in the course I did last term, it was their first
programming experience; therefore, I waited until Week 5).
However, I don't think it is necessary (or desirable) to
hide "functional". With "monad" it is a different story, as
it is a complicated sounding word, which is not easily
explained (to non-mathematicians). And it is not necessary;
we are not starting on fixed point and domain theory either
when explaining recursive functions.
Actually, I did run a moderately detailed survey at the end
about what the students found interesting/boring and
difficult/easy etc (and with a good sample size, too: close
to 500 students filled in the survey). I am planing to
summarise the results and post them here sometime.
Cheers,
Manuel
From nellardo@concentric.net Tue Jan 9 16:55:11 2001
From: nellardo@concentric.net (Brook Conner)
Date: Tue, 09 Jan 2001 11:55:11 -0500
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
References: <3A5A57A1.6000609@concentric.net>
Message-ID: <3A5B426E.50009@concentric.net>
Ketil Malde wrote:
> Let's see. It all depends on what you put into the chapters, of
> course, but you seem to jump directly from simple concepts into
> Haskell for web servers. Wouldn't it be better to push this further
> out, until at least some of the syntax has been explored?
The second chapter is meant to be a brief overview of some of the ways
you can execute Haskell code. For a programmer familiar with some of the
more common languages (C++, Java, Perl is the kind I'm expecting),
showing them right off the bat that Haskell *can* be used in web servers
seemed like a good idea. It met two goals:
a) this list's objective in spreading the good word about how useful
Haskell is :-)
b) the objective of "Nutshell" books to let experienced people transfer
their existing skills as quickly as possible.
> >From the headlines, one might get the impression that type
> declarations are only important when the compiler can't figure it out
> itself - I'm sure the actual text will give a different view, no?
Of course - I have something of an informal writing tone when I'm
writing for education, and some of the headlines reflect that (I mean,
really, "hash"? :-) ) But part of what I was trying to do was to get
some key concepts across to two different audiences of programmers:
a) the Perl programmers, who have types but generally don't ever write
them down. These people will like type inferencing - it will seem more
natural to them.
b) the C++ and Java programmers. They'll be just fine declaring types -
showing them how to get strong typing without necessarily declaring the
types explicitly will seem nifty cool to them (it did to me, ten years
ago :-) )
I'm not about to get into any of the old arguments about static vs
dynamic typing or that stuff - been there, done that. Haskell is a
strongly typed language, and that will be apparent in the text.
> The cookbook looks great, and it's certainly something I'd buy the
Do you think the cookbook would be better as its own book?
> I can, of course, think of many kinds of example programs
> I'd like to see - how about a GUI oriented program, for instance?
Actually, last night after sending the announcement, I added exactly
that :-)
Years and years ago, Paul Haeberli of SGI implemented this cute little
hack of having a brush attached to the cursor with a spring - real
simple - moving the mouse changed the velocity vector of the brush, with
settable strength and inertia and such. It made it insanely easy to
produce a swooping, calligraphic stroke. Haeberli did it in C to OpenGL
- using Fran, it would be perhaps a one-liner.
Scott Snibbe, then of Brown University, did another cute hack that
showed up at SIGGRAPH later under the name "MotionPhone". He set up a
loop of screen buffers that ran at a constant frame rate. As you drew,
your mouse left behind moving streaks. Faster motion, longer streaks.
This would be another one-liner with Fran (Scott originally did it in C
to Pixrect, Sun's ancient direct screen access API).
I figured those kinds of examples showed off the power of Haskell.
> Perhaps you could finish it off with a "real" application, say a GUIed
> JPEG viewer, where you sort of string it all (the JPEG codec, a C
> library interface for something or other, and GUI stuff, etc.)
> together into a whole?
This morning I've been thinking about data visualization from an SQL DB....
> On the whole, I think it looks good. Best of luck!
Thanks!
Brook
From qrczak@knm.org.pl Tue Jan 9 18:52:11 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 9 Jan 2001 18:52:11 GMT
Subject: Are fundeps the right model at all?
References: <14937.18383.904979.841600@waytogo.peace.co.nz>
Message-ID:
Mon, 8 Jan 2001 17:53:35 +1300, Tom Pledger pisze:
> > Having types with type variables which are never instantiated nor
> > constrained should be equivalent to having ground types!
>
> Do you have any examples of such a type variable in an instance decl?
Now I have a practical example where fundeps don't work and keys
would work - but the type variable is later instantiated.
Let's take Parsec from ghc's libraries which includes the following
(this is cut down):
data TokenParser = TokenParser {
identifier :: Parser String,
reserved :: String -> Parser (),
operator :: Parser String,
reservedOp :: String -> Parser (),
parens :: forall a. Parser a -> Parser a}
makeTokenParser:: LanguageDef -> TokenParser
I would like to express this "first-class module" in my records
proposal, to make it extensible (there can be different types similar
to TokenParser with similar fields and used polymorphically together
with TokenParser).
Each record field in my proposal induces a class:
class Has_field r a | r -> a where
get_field :: r -> a
The fundep, or something which allows to find the instance from the
type of the record only, is required to make this practical. A type
which includes Has_field r a in its context, and includes r but not a
in its body, is legal.
For non-polymorphic fields it works great. But parens cause trouble:
instance Has_parens TokenParser (Parser a -> Parser a)
This instance is illegal because of the fundep. What it should mean is:
instance Has_parens TokenParser (forall a. Parser a -> Parser a)
but this is not possible either.
With keys instead of fundeps it works! The first instance is OK.
The record type is specified to be a key in all Has_field classes,
meaning that the record type alone is sufficient to determine which
instance of a field getter to use.
It is not always sufficient to determine the exact type of the field,
but this is not needed. For example here many types are good because
the instance is polymorphic wrt. a type variable used in the field's
type.
I want keys instead of fundeps! :-)
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From qrczak@knm.org.pl Tue Jan 9 18:37:03 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 9 Jan 2001 18:37:03 GMT
Subject: Defaults in datatype definitions
References: <200101090846.JAA19878@isun11.informatik.uni-leipzig.de>
Message-ID:
Tue, 9 Jan 2001 09:46:31 +0100 (MET), Johannes Waldmann pisze:
> 1) I would like to write down default values for record components
My proposal for remaking records ina more flexible way includes this.
> 2) With classes, we can do even more: in the default method,
> we can access other methods.
And this too.
> 3) I want to be able, in modules that use the type,
> to add more components (with defaults) to the type:
>
> This would avoid lengthy recomputations (at the cost of additional space).
> Imagine the difference between
>
> data Tree a = Node { key :: a, children :: [ Tree a ] }
> size t = 1 + sum (map size (children t))
>
> and
>
> data Tree a = Node { key :: a, children :: [ Tree a ]
> , size :: Integer
> , size = \ self -> 1 + sum (map size (children self)) }
>
> when you have one large tree and frequently need sizes of subtrees.
And this too, but it's a bit tricky because a field changes the
type covariantly.
data Tree a = record
key :: a
children :: [Tree a]
children = []
-- A function working on a tree must be prepared for extensions.
-- The following function does not actually refer to the above type,
-- but can be used on Tree Int.
isInTree:: (Eq a, tree.key :: a, tree.children :: [tree])
=> a -> tree -> Bool
isInTree a tree = a == tree.key || any (isInTree a) tree.children
-- Trees extended by size cache. The type below does not refer to
-- the type Tree because the type of children has changed. Otherwise
-- it could include Tree as a field and delegate key and children to
-- this field instead of defining them itself. Well, it could do it,
-- but it would have to store children as SizedTrees somewhere too.
-- I don't know yet if it can be solved more elegantly.
data SizedTree a = record
key :: a
children :: [SizedTree a]
size :: Int
children = []
size = 1 + sum (map (.size) children)
-- Creation of a tree is the same for both kinds. A different kind of
-- context is needed to create a record than to extract its fields.
-- This context includes the context used in isInTree (except Eq a)
-- in its superclasses.
flatTree:: (tree.record {key :: a; children :: [tree]})
=> a -> [a] -> tree
flatTree root leaves = record
key = root
children = [record key = leaf | leaf <- leaves]
I haven't written a complete description of the proposal yet, but
will do it in two weeks. I posted basic info here some time ago.
Some details changed since then.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From msk@post.tepkom.ru Tue Jan 9 21:10:46 2001
From: msk@post.tepkom.ru (Anton Moscal)
Date: Wed, 10 Jan 2001 00:10:46 +0300 (MSK)
Subject: Just for fun
Message-ID:
Hello!
This is well-known definition of the existential quantification through
universal:
(E x.P(x)) <=> A y.(A x.P (x) => y) => y
I try to translate in to Haskell. The following program can be compiled
by "ghc -fglasgow-exts ..." and works correctly:
----------------------------------------
import Char
type E a = forall t . (forall x . a x -> t) -> t
newtype Pair a b = MkPair (b, (b -> a))
newtype App a = MkApp (E (Pair a))
mk_app :: (a -> b) -> a -> App b
mk_app f v = MkApp (\g -> g (MkPair (v, f)))
app_s = mk_app Char.ord '1'
app_id = mk_app (\x->x) 239
eval :: App a -> a
eval (MkApp g) = g (\(MkPair (x, f)) -> f x)
main = print (map eval [mk_app (\x->x) 239, mk_app Char.ord '1'])
---------------------------------------
Regards,
Anton Moscal
From Tom.Pledger@peace.com Tue Jan 9 22:40:17 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Wed, 10 Jan 2001 11:40:17 +1300
Subject: Just for fun
In-Reply-To:
References:
Message-ID: <14939.37713.16403.320221@waytogo.peace.co.nz>
Anton Moscal writes:
> Hello!
>
> This is well-known definition of the existential quantification
> through universal:
>
> (E x.P(x)) <=> A y.(A x.P (x) => y) => y
>
> I try to translate in to Haskell. The following program can be
> compiled by "ghc -fglasgow-exts ..." and works correctly:
>
[...]
> main = print (map eval [mk_app (\x->x) 239, mk_app Char.ord '1'])
import Char(ord)
main = print (tail [error "I'm too lazy to be explicitly existential.",
(\x->x) 239,
ord '1'])
{- Regards, Tom :-}
From qrczak@knm.org.pl Tue Jan 9 23:10:40 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 9 Jan 2001 23:10:40 GMT
Subject: Haskell 98 (Library) Report: contradiction about fail :: String -> IO a
Message-ID:
The Haskell 98 Report says that fail in instance Monad IO invokes error.
The Library Report says that fail in instance Monad IO raises a user error.
I would let it raise a user error, to be able to use fail in exception
monads where strings suffice as the error type.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From ketil@ii.uib.no Wed Jan 10 07:36:03 2001
From: ketil@ii.uib.no (Ketil Malde)
Date: 10 Jan 2001 08:36:03 +0100
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
In-Reply-To: Brook Conner's message of "Tue, 09 Jan 2001 11:55:11 -0500"
References: <3A5A57A1.6000609@concentric.net>
<3A5B426E.50009@concentric.net>
Message-ID:
Brook Conner writes:
> Do you think the cookbook would be better as its own book?
Perhaps it could? I think it's a natural component in a "nutshell"
book, but it seems clear that there's tons of example programs that
would be immensely useful as well-documented howtos.
[Cool graphics hacks]
> I figured those kinds of examples showed off the power of Haskell.
Sounds good to me.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From msk@post.tepkom.ru Wed Jan 10 09:58:36 2001
From: msk@post.tepkom.ru (Anton Moscal)
Date: Wed, 10 Jan 2001 12:58:36 +0300 (MSK)
Subject: About fundeps
Message-ID:
Hello!
When I apply hugs to the following program:
import Char (ord) class Conv a b | a -> b where conv:: a -> b
instance Conv Char Int where conv = ord
instance (Conv a b, Conv b c) => Conv a c where conv = conv . conv
Hugs reports:
ERROR "fdep.hs" (line 4): Instances are not consistent with dependencies
*** This instance : Conv a b
*** Conflicts with : Conv Char Int
*** For class : Conv a b
*** Under dependency : a -> b
But why?
Regards,
Anton Moscal
From lennart@mail.augustsson.net Wed Jan 10 10:03:26 2001
From: lennart@mail.augustsson.net (Lennart Augustsson)
Date: Wed, 10 Jan 2001 05:03:26 -0500
Subject: About fundeps
References:
Message-ID: <3A5C336E.5A26666F@mail.augustsson.net>
Anton Moscal wrote:
> Hello!
>
> When I apply hugs to the following program:
>
> import Char (ord) class Conv a b | a -> b where conv:: a -> b
> instance Conv Char Int where conv = ord
> instance (Conv a b, Conv b c) => Conv a c where conv = conv . conv
>
> Hugs reports:
>
> ERROR "fdep.hs" (line 4): Instances are not consistent with dependencies
> *** This instance : Conv a b
> *** Conflicts with : Conv Char Int
> *** For class : Conv a b
> *** Under dependency : a -> b
>
> But why?
Because they aren't.
Assume you have
> instance Char Int
and also
> instance Int Float
According to your second instance declaration you now also have
> instance Char Float
But the functional dependency states that the first parameter uniquely
determines the second and now there are two conflicting instances
for Char.
-- Lennart
From kris@CoLi.Uni-SB.DE Mon Jan 8 08:13:04 2001
From: kris@CoLi.Uni-SB.DE (Kristina Striegnitz)
Date: Mon, 8 Jan 2001 09:13:04 +0100 (MET)
Subject: 2nd CfP: ESSLLI 01 Student Session
Message-ID:
!!! Concerns all students in Logic, Linguistics and Computer Science !!!=20
!!! Please circulate and post among students !!!
We apologize, if you receive this message more than once.
ESSLLI 2001 STUDENT SESSION
SECOND CALL FOR PAPERS
August 13-24 2001, Helsinki, Finland
Deadline: February 18, 2001
http://www.coli.uni-sb.de/~kris/esslli
We are pleased to announce the Student Session of the 13th European
Summer School in Logic, Language and Information (ESSLLI 2001)
organized by the University of Helsinki under the auspices of the
European Association for Logic, Language and Information
(FoLLI). ESSLLI 2001 will be held at the University of Helsinki in
August 2001. We invite submission of papers for presentation at the
ESSLLI 2001 Student Session and for appearance in the proceedings.
PURPOSE:
This sixth ESSLLI Student Session will provide, like the other
editions, an opportunity for ESSLLI participants who are students to
present their own work in progress and get feedback from senior
researchers and fellow-students. The ESSLLI Student Session
encourages submissions from students at any level, from undergraduates
(before completion of the Master Thesis) as well as postgraduates
(before completion of the PhD degree). Papers co-authored by
non-students will not be accepted. Papers may be accepted for full
presentation (30 minutes including 10 minutes of discussion) or for a
poster presentation. The accepted papers will be published in the
ESSLLI 2001 Student Session proceedings, which will be made available
during the summer school.
KLUWER BEST PAPER AWARD:=20
As in previous years, the best paper will be selected by the program
committee and will be offered a prize by Kluwer Academic Publishers
consisting in 1000 Dfl worth of books.
REQUIREMENTS:=20
The Student Session papers should describe original, unpublished work,
completed or in progress that demonstrates insight, creativity, and
promise. No previously published papers should be submitted. All
topics within the six ESSLLI subject areas (Logic, Language,
Computation, Logic & Language, Logic & Computation, Language &
Computation) are of interest.
FORMAT OF SUBMISSION:
Student authors should submit an anonymous extended abstract headed by
the paper title, not to exceed 5 pages in length exclusive of
references and send a separate identification page (see below). Note
that the length of the full papers will not be allowed to exceed 10
pages. Since reviewing will be blind, the body of the abstract should
omit author names and addresses. Furthermore, self-references that
reveal the author's identity (e.g., "We previously showed (Smith,
1991)... ") should be avoided. It is possible to use instead
references like "Smith (1991) previously showed...". For any
submission, a plain ASCII text version of the identification page
should be sent separately, using the following format:
Title: title of the submission=20
First author: firstname lastname
Address: address of the first author=20
=2E.....=20
Last author: firstname lastname=20
Address: address of the last author=20
Short summary: abstract (5 lines)=20
Subject area (one of): Logic | Language | Computation | Logic and
Language | Logic and Computation | Language and Computation
If necessary, the program committee may reassign papers to a more
appropriate subject area. The submission of the extended abstract
should be in one of the following formats: PostScript, PDF, RTF, or
plain text. But note that, in case of acceptance, the final version of
the paper has to be submitted in LaTeX format. Please, use A4 size
pages, 11pt or 12pt fonts, and standard margins. Submissions outside
the specified length and formatting requirements may be subject to
rejection without review.
The extended abstract and separate identification page must be sent by
e-mail to:
kris@coli.uni-sb.de by FEBRUARY 18, 2001
ESSLLI 2001 INFORMATION:=20
In order to present a paper at ESSLLI 2001 Student Session, at least
one student author of each accepted paper has to register as a
participant at ESSLLI 2001. The authors of accepted papers will be
eligible for reduced registration fees. For all information concerning
ESSLLI 2001, please consult the ESSLLI 2001 web site at
http://www.helsinki.fi/esslli.=20
IMPORTANT DATES:
Deadline for submission of abstracts: February 18, 2001.
Authors Notifications: April 17, 2001.
Final version due: May 18, 2001.=20
ESSLLI-2001 Student Session: August 13-24, 2001.=20
PROGRAM COMMITTEE:
Raffaella Bernardi, University of Utrecht (Logic & Language)
Patrick Blackburn, Loria Nancy (Logic & Language)
Gilles Dowek, INRIA (Computation)
Ruth Kempson, King`s College London (Language)
Carsten Lutz, University of Aachen (Logic & Computation)
Ani Nenkova, Columbia University (Logic)
Ilkka Niemel=E4, Helsinki University of Technology (Logic & Computation)
Malvina Nissim, University of Pavia (Language)
Susanne Salmon-Alt, Loria, Nancy (Language & Computation)
Jan Schwinghammer, University of the Saarland (Computation)
Kristina Striegnitz, University of the Saarland (Chair)
Yde Venema, University of Amsterdam (Logic)
Shuly Wintner, University of Haifa (Language & Computation)
For any question concerning the ESSLLI 2001 Student Session, please,
do not hesitate to contact me:=20
Kristina Striegnitz
Computational Linguistics, University of the Saarland, Germany
phone: +49 - 681 - 302 4503 email: kris@coli.uni-sb.de
From russell@brainlink.com Wed Jan 10 15:48:29 2001
From: russell@brainlink.com (Benjamin L. Russell)
Date: Wed, 10 Jan 2001 10:48:29 -0500
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
In-Reply-To: <200101090800.JAA19782@isun11.informatik.uni-leipzig.de>
Message-ID:
On Tue, 9 Jan 2001 09:00:27 +0100 (MET)
Johannes Waldmann wrote:
>
> [snip]
>
> This could be driven to the extreme: not only hide the
> word "monad",
> but also "functional". The title would be "Imperative
> programming in Haskell"
> (as S. Peyton Jones says in Tackling the Awkward Squad:
> "Haskell is the world's finest imperative programming
> language").
Couldn't this choice potentially backfire, though? For example, many people choose Java over C because they prefer OO to straight imperative programming, which they see at The Old Way.
If I went to a bookstore and saw one book entitled, "Imperative Programming in Haskell," and another entitled, "OO Programming in Java," I wouldn't buy the Haskell book, especially if had already had a bad experience with imperative programming in C.
How about, "The Post-OO Age: Haskell: Back to the Future in Imperative Programming"?
--Ben
--
Benjamin L. Russell
russell@brainlink.com
benjamin.russell.es.94@aya.yale.edu
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
From Krprtn@aol.com Wed Jan 10 19:52:08 2001
From: Krprtn@aol.com (Krprtn@aol.com)
Date: Wed, 10 Jan 2001 14:52:08 EST
Subject: Hugs
Message-ID: <50.fdb0f92.278e1768@aol.com>
--part1_50.fdb0f92.278e1768_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
I've currently installed Hugs on my PC, could you tell me how I can configure
Hugs to use an editor. The editor I have got installed on my computer is
winedt.
--part1_50.fdb0f92.278e1768_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
I've currently installed Hugs on my PC, could you tell me how I can configure
Hugs to use an editor. The editor I have got installed on my computer is
winedt.
--part1_50.fdb0f92.278e1768_boundary--
From trinder@cee.hw.ac.uk Thu Jan 11 13:58:11 2001
From: trinder@cee.hw.ac.uk (Phil Trinder)
Date: Thu, 11 Jan 2001 13:58:11 +0000 (GMT Standard Time)
Subject: Haskell PhD Scholarship
Message-ID:
Folks,
Are you planning to do a PhD and interested in parallel or distributed versions
of Haskell? There's a PhD scholarship available at Heriot-Watt University,
Edinburgh, Scotland. To win the scholarship you'll need to have, or get, a
first-class degree and have excellent references.
The group at Heriot-Watt have implemented and used parallel versions of Haskell
and ML, and a distributed Haskell. We're part of a vibrant functional
programming community in the central belt of Scotland. More information on who
we are and what we do is available at
http://www.cee.hw.ac.uk/~trinder/projects.html
http://www.cee.hw.ac.uk/~trinder/
http://www.cee.hw.ac.uk/~dsg/
If you're interested in applying for the scholarship please contact me.
Phil
--------------------------------------------------
Phil Trinder
Department of Computing and Electrical Engineering
Heriot Watt University
Riccarton
Edinburgh, EH14 4AS
E-mail: trinder@cee.hw.ac.uk
Teleph: +44 (0)131 451 3435
Depart: +44 (0)131 451 3328
Fasmly: +44 (0)131 451 3327
Intrnt: http://www.cee.hw.ac.uk/~trinder
From Krprtn@aol.com Thu Jan 11 18:33:27 2001
From: Krprtn@aol.com (Krprtn@aol.com)
Date: Thu, 11 Jan 2001 13:33:27 EST
Subject: Hugs
Message-ID:
--part1_fe.d460b4.278f5677_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
I tried sending this message to the hugs email address but it kept being sent
back!
I have installed Hugs on my PC, could you please tell me how I can configure
Hugs to use winedt (editor). I have alreadly tried using the hugs user manual
(section 4). Also is it a problem if I use the latest version of winedt with
hugs 98. thankyou
--part1_fe.d460b4.278f5677_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
I tried sending this message to the hugs email address but it kept being sent
back!
I have installed Hugs on my PC, could you please tell me how I can configure
Hugs to use winedt (editor). I have alreadly tried using the hugs user manual
(section 4). Also is it a problem if I use the latest version of winedt with
hugs 98. thankyou
--part1_fe.d460b4.278f5677_boundary--
From Dominic.J.Steinitz@BritishAirways.com Fri Jan 12 08:41:37 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 12 Jan 2001 08:41:37 Z
Subject: Hash Functions
Message-ID: <"017A63A5EC341001*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
I was thinking of using MD5 or SHA-1 for an application. Is there a Haskell library that contains these or other hash algorithms that have a very low probability of giving clashes?
Dominic.
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From simonpj@microsoft.com Fri Jan 12 09:31:22 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 12 Jan 2001 01:31:22 -0800
Subject: Haskell 98 (Library) Report: contradiction about fail :: Stri
ng -> IO a
Message-ID: <74096918BE6FD94B9068105F877C002D01378627@red-pt-02.redmond.corp.microsoft.com>
Marcin writes:
| The Haskell 98 Report says that fail in instance Monad IO invokes error.
| The Library Report says that fail in instance Monad IO raises a user
error.
|
| I would let it raise a user error, to be able to use fail in exception
| monads where strings suffice as the error type.
He's right. The instance declaration in the Prelude (p101) should say
instance Monad IO where
...
fail s = ioError (userError s)
This was always intended (see Library report p55, 11.1).
Other clarifications should be
* Index the reference to userError in Sec 7.3 of the Report
and give a type signature for userError
* In that same section, specify that fail s = ioError (userError s)
I'll do these as part of the (long-postponed) H98 report revision.
Any objections? I don't think this is controversial. Implementors take
note,
though.
Simon
From Dominic.J.Steinitz@BritishAirways.com Mon Jan 15 09:08:13 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 15 Jan 2001 09:08:13 Z
Subject: Too Strict?
Message-ID: <"0288E3A62BDFD005*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Can someone help? The program below works fine with small files but when I try to use it on the one I need to (about 3 million lines of data) it produces no output. The hard disk is hammered - I assume this is the run time system paging. My suspicion is that the program is trying to read in the whole file before processing it. Is this correct? If so, how do I make the program lazy so that it processes a line at time?
By the way, the MD5 function which I use and is included as part of HSLIBS has the type String -> IO String. The MD5 algorithm really is a function and should have type String -> String. Do people agree and if so how do I get it changed?
Dominic.
-- Compile with ghc -o test test.hs -static -package util
-- under Windows.
module Main(main) where
import IO(openFile,
hPutStr,
IOMode(ReadMode,WriteMode,AppendMode))
import MD5
import Char
-- showHex and showHex' convert the hashed values to
-- human-readable hexadecimal strings.
showHex :: Integer -> String
showHex =
map hexDigit .
map (fromInteger . (\x -> mod x 16)) .
takeWhile (/=0) .
iterate (\x -> div x 16) .
toInteger
hexDigit x
| (0 <= x) && (x <= 9) = chr(ord '0' + x)
| (10 <= x) && (x <=16) = chr(ord 'a' + (x-10))
| otherwise = error "Outside hexadecimal range"
powersOf256 = 1 : map (*256) powersOf256
showHex' x =
showHex $
sum (zipWith (*)
(map ((\x -> (mod x 16)*16 + (div x 16)) .
toInteger .
ord) x)
powersOf256)
-- The type Anon and function anonymize hide the anonymisation
-- process. In this case, it's a hash function
-- digest :: String -> IO String which implements MD5.
type Anon a = IO a
class Anonymizable a where
anonymize :: a -> Anon a
-- MyString avoids overlapping instances of Strings
-- with the [Char]
data MyString = MyString String
deriving Show
instance Anonymizable MyString where
anonymize (MyString x)
= do s <- digest x
return ((MyString . showHex') s)
instance Anonymizable a => Anonymizable [a] where
anonymize xs = mapM anonymize xs
filename = "ldif1.txt"
fileout = "ldif.out"
readAndWriteAttrVals =
do h <- openFile fileout WriteMode
s <- readFile filename
a <- anonymize((map MyString) (lines s))
hPutStr h (unlines (map (\(MyString x) -> x) a))
main = readAndWriteAttrVals
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From matt@CadMOS.COM Fri Jan 12 22:10:07 2001
From: matt@CadMOS.COM (Matthew Liberty)
Date: Fri, 12 Jan 2001 14:10:07 -0800
Subject: gui building in haskell
Message-ID: <3A5F80BE.75F674B3@cadmos.com>
This is a multi-part message in MIME format.
--------------863106FFDA2059FB84119F6B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Greetings,
I've been looking at http://www.haskell.org/libraries/#guis and trying
to figure out which package is "best" for building a gui. Can anyone
give a comparison of the strengths/weaknesses of these packages (or any
others)?
thanks
-Matt
--------------863106FFDA2059FB84119F6B
Content-Type: text/x-vcard; charset=us-ascii;
name="matt.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Matthew Liberty
Content-Disposition: attachment;
filename="matt.vcf"
begin:vcard
n:Liberty;Matthew
tel;fax:408-795-1210
tel;work:408-795-1212 x514
x-mozilla-html:FALSE
url:http://www.cadmos.com
version:2.1
email;internet:matt@CadMOS.com
title:Software Architect
adr;quoted-printable:;;111 North Market Street=0D=0ASuite 440;San Jose;CA;95113-1117;USA
x-mozilla-cpt:;0
fn:Matthew Liberty
end:vcard
--------------863106FFDA2059FB84119F6B--
From mpj@cse.ogi.edu Mon Jan 15 10:01:27 2001
From: mpj@cse.ogi.edu (Mark P Jones)
Date: Mon, 15 Jan 2001 02:01:27 -0800
Subject: Yet more on functional dependencies
In-Reply-To: <3A59D57E.6F5E0489@tzi.de>
Message-ID:
| I am finding functional dependencies confusing. (I suspect I am=20
| not alone.) Should the following code work?
|=20
| class HasConverter a b | a -> b where
| convert :: a -> b
|=20
| instance (HasConverter a b,Show b) =3D> Show a where
| show value =3D show (convert value)
It's a separate issue. There's no reason why a system using
functional dependencies *should* support this. But it is an
attractive and useful extension that such a system would
probably *want* to include. (i.e., it's a desirable feature,
not a requirement.)
I typed your example into Hugs on my machine and it seemed to
accept the syntax (which suggests that the implementation is
intended to allow this kind of thing). But then it choked on
the definition with a curious error message that I suspect is
an indication of a bug in Hugs' treatment of functional
dependencies. And, for that reason, I'm crossposting this
message to hugs-bugs. [Let me take the opportunity to remind
good readers of these lists that it is now more than a year
since I retired from the joys of maintaining Hugs, so I'm not
planning to try and track down the source of this bug myself!]
Of course, it could be that my version of Hugs is out of date!
All the best,
Mark
From mpj@cse.ogi.edu Mon Jan 15 10:01:18 2001
From: mpj@cse.ogi.edu (Mark P Jones)
Date: Mon, 15 Jan 2001 02:01:18 -0800
Subject: Are fundeps the right model at all?
In-Reply-To:
Message-ID:
| Now I have a practical example where fundeps don't work and keys
| would work - but the type variable is later instantiated.
| ...
| Each record field in my proposal induces a class:
| class Has_field r a | r -> a where
| get_field :: r -> a
|=20
| The fundep, or something which allows to find the instance from the
| type of the record only, is required to make this practical. A type
| which includes Has_field r a in its context, and includes r but not a
| in its body, is legal.
|=20
| For non-polymorphic fields it works great. But parens cause trouble:
| instance Has_parens TokenParser (Parser a -> Parser a)
| This instance is illegal because of the fundep. What it should mean =
is:
| instance Has_parens TokenParser (forall a. Parser a -> Parser a)
| but this is not possible either.
Let's explore the design space a little more carefully. There's a wide
spectrum of options, and it's not yet entirely clear which one Marcin is
referring to by "keys". Perhaps it will be one of the entries on the
following list:
0) "Standard multiple parameter classes": A class constraint Has_parens =
r a
does not imply any connection between the different parameters, and a
type like Has_parens r a =3D> r is ambiguous. This kind of class has =
its
uses, but also tends to lead to ambiguity problems. It doesn't =
address
Marcin's needs.
1) "A weaker notion of ambiguity" (title of Section 5.8.3 in my =
dissertation,
which is where I think the following idea originated): We can modify =
the
definition of ambiguity for certain kinds of class constraint by =
considering
(for example) only certain subsets of parameters. In this setting, a =
type
P =3D> t is ambiguous if and only if there is a variable in AV(P) =
that is not
in t. The AV function returns the set of potentially ambiguous =
variables in
the predicates P. It is defined so that AV(Eq t) =3D TV(t), but also =
can
accommodate things like AV(Has_field r a) =3D TV(r). A semantic =
justification
for the definition of AV(...) is needed in cases where only some =
parameters
are used; this is straightforward in the case of Has_field-like =
classes.
Note that, in this setting, the only thing that changes is the =
definition
of an ambiguous type.
A similar weakening of the notion of ambiguity is permitted by each =
of the
following points in the design space.
2) "Partial dependencies": At this point in the spectrum, we allow the =
values
of one or more class parameters to specify something about the shape =
of the
values of the other parameters, without uniquely determining them. =
This is
perhaps closest to what Marcin is asking for in the text included =
above.
For his example, a partial dependency might ensure that the type t in =
any
constraint of the form Has_parens TokenParser t is of the form
Parser a -> Parser a for *some* a, which may be chosen in different =
ways
at each use. My old work on improvement provides a theoretical =
foundation
for this. And, in fact, an unimplemented proposal for supporting =
this kind
of extension is included in the source code for Hugs (subst.c), =
predating
functional dependencies by several years. With the syntax used =
there, the
improvement would be specified as follows:
instance Has_parens TokenParser (Parser a -> Parser a)
improves Has_parens TokenParser b where ...
The idea here is to use improvement at the level of individual =
instances,
whereas functional dependencies use improvement at the level of whole
classes. Given a declaration instance P =3D> p where ... we expect =
the
instance to be used for any constraint that matches p. If an =
improves
clause is specified, possibly with multiple predicates, as in:
instance P =3D> p improves p1, ..., pn where ...
then we expect p to be a substitution instance of each of p1, ..., =
pn,
and we expect the instance to apply to any constraint that matches =
one
(or more) of p1, ..., pn, with an appropriate improving substitution
applied to bring it into line with p.
3) "Underspecified/Inferred Functional Dependencies": Here, we insist =
that
the values of certain parameters in a constraint are *uniquely* =
determined
by the values of other parameters ... but we allow the values of the
determined types to be inferred rather than declared explicitly. For
example, one might write:
instance C Int b where ...
and then leave type inference to figure out that the value for b in =
this
particular instance must actually be Bool (say). I don't know =
whether
anyone has seriously explored this point in the design space, in =
particular
to determine conditions under which we can be sure that missing =
parameters
can be inferred, or to come up with a good, clean syntax. The whole =
idea
may seem a bit odd, but it is in line with proposals circulating a =
couple
of weeks ago by folks who want to allow declared types like
forall b. C Int b =3D> b -> Bool
in situations where they knew that the only possible instantiation =
for b was
some fixed type like Int (say).
4) "Functional Dependencies": As described in my ESOP 00 paper (the =
Hugs
manual, and the HTML note on my web page, don't tell the whole =
story).
This allows a programmer to indicate that, like (3), some of the
parameters in a constraint will be *uniquely* determined by other
parameters. Unlike (3), the assumption in the ESOP paper, and in
current implementations, is that these uniquely determined types will
be mentioned explicitly in each instance declaration. With =
functional
dependencies, inferred constraint sets can be improved in ways that =
are
(a) important in practice, and (b) not possible in any of the options
mentioned previously. For example, given class Collects c e | c -> =
e,
we can simplify (Collects c e, Collects c f) =3D> e -> f -> c -> c =
to
(Collects c e) =3D> e -> e -> c -> c.
[Aside: Marcin's specific problem with Has_parens could be dealt with =
in
this framework also, but that would probably require the introduction =
of
a newtype like:
newtype PP =3D forall a. PP (Parser a -> Parser a)
instance Has_parens TokenParser PP where ...
This, of course, would require extra games with the PP constructor =
(and
an appropriately defined inverse) in expressions, which would =
probably
be too messy and awkward in practice; a record system designed to =
support
polymorphic fields from the outset would be a better solution here.]
5) And so on. There are other alternatives ...
| I want keys instead of fundeps! :-)
I've found it hard to assess or make sense of your descriptions of keys =
in
previous postings; at different times it has seemed as though keys could =
be
any of options 1, 2, 3, 4, or 5 in the above. But I hope that my =
analysis
of the design space above is helping us to reach a better shared =
understanding
of exactly what you are proposing. In terms of what I've written above, =
my
current guess at interpreting your proposal goes something like this:
- You want to allow each class declaration to be annotated with zero or =
more
subsets of the parameters, each of which you refer to as a "key" for =
the
class.
- When a user writes an instance declaration:
instance P =3D> C t1 ... tn where ...
you treat it, in the notation of (2) above, as if they'd written:
instance P =3D> C t1 ... tn=20
improves C t11 ... t1n, ..., C tm1 ... tmn where ...
Here, m is the number of keys, and: tij =3D ti, if parameter i is =
in key j
=3D ai, otherwise
where a1, ..., an are distinct new variables.
If this is correct, then it seems to me that:
- Keys will provide a more concise, but less expressive notation than =
(2).
The notation of (2) is considerably more expressive because it isn't
limited to the form used in the translation above, and because it can
be used on an instance by instance basis rather than a specification =
that
applies uniformly to all instances of a class. It's hard to know what =
the
tradeoffs will be in practice, but I'm inclined to believe that keys =
are
too limited, and the more general mechanism will not be too cumbersome =
in
many practical cases.
- Keys will not give you the full functionality of functional =
dependencies,
and that missing functionality is important in some cases.
All the best,
Mark
PS. If we're going to continue this discussion any further, let's take =
it
over into the haskell-cafe ...
From Tom.Pledger@peace.com Mon Jan 15 00:05:58 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Mon, 15 Jan 2001 13:05:58 +1300
Subject: Are fundeps the right model at all?
In-Reply-To:
References:
<14937.18383.904979.841600@waytogo.peace.co.nz>
Message-ID: <14946.16102.471410.416736@waytogo.peace.co.nz>
Marcin 'Qrczak' Kowalczyk writes:
> Mon, 8 Jan 2001 17:53:35 +1300, Tom Pledger pisze:
>
> > > Having types with type variables which are never instantiated nor
> > > constrained should be equivalent to having ground types!
> >
> > Do you have any examples of such a type variable in an instance decl?
>
> Now I have a practical example where fundeps don't work and keys
> would work - but the type variable is later instantiated.
>
> Let's take Parsec from ghc's libraries which includes the following
> (this is cut down):
>
> data TokenParser = TokenParser {
> identifier :: Parser String,
> reserved :: String -> Parser (),
> operator :: Parser String,
> reservedOp :: String -> Parser (),
> parens :: forall a. Parser a -> Parser a}
>
> makeTokenParser:: LanguageDef -> TokenParser
>
> I would like to express this "first-class module" in my records
> proposal, to make it extensible (there can be different types similar
> to TokenParser with similar fields and used polymorphically together
> with TokenParser).
>
> Each record field in my proposal induces a class:
> class Has_field r a | r -> a where
> get_field :: r -> a
>
> The fundep, or something which allows to find the instance from the
> type of the record only, is required to make this practical. A type
> which includes Has_field r a in its context, and includes r but not a
> in its body, is legal.
>
> For non-polymorphic fields it works great. But parens cause trouble:
> instance Has_parens TokenParser (Parser a -> Parser a)
> This instance is illegal because of the fundep. What it should mean is:
> instance Has_parens TokenParser (forall a. Parser a -> Parser a)
> but this is not possible either.
[...]
Hallo again.
The second instance decl expresses the situation better, because it's
faithful to the rank-2 polymorphism in TokenParser, i.e. the
requirement that the TokenParser constructor's 5th argument have a
type at *least* as general as forall a. Parser a -> Parser a. The first instance decl
Should we be able to put a local forall in an instance decl?
I suspect that we shouldn't in general, because it would cause leaks
in the rank-2 polymorphism restrictions. For example:
module MA where
class C a where f :: () -> a -> ()
module MB where
import MA
f' :: C a => a -> ()
f' = f ()
module MC where
import MA
instance C (forall a. a -> a) where f z g = if g True then g () else z
If any other module imports both MB and MC, the partial application of
f in MB will break the "maximal function application subexpressions
must include arguments for all rank-2 polymorphic parameters"
restriction. (I don't actually know the purpose of this restriction
and its friends, but I'm sure there's a good reason for them.)
Trex avoids the question of field types in contexts, by using a Lacks
context which only mentions the row type and the label. Is the
combination of Trex and newtype worth another look? This sort of
thing:
newtype T1 a = T1 {unT1 :: Rec (foo :: a)}
newtype T2 a = T2 {unT2 :: Rec (foo :: a, bar :: a)}
Regards,
Tom
From ess_lli@cc.helsinki.fi Fri Jan 12 15:41:34 2001
From: ess_lli@cc.helsinki.fi (Ahti Pietarinen)
Date: Fri, 12 Jan 2001 17:41:34 +0200 (EET)
Subject: FORMAL GRAMMAR/MATHEMATICS OF LANGUAGE'01
Message-ID:
[apologies if you receive this more than once]
FGMOL'01 FGMOL'01 FGMOL'01 FGMOL'01 FGMOL'01 FGMOL'01 FGMOL'01 FGMOL'01
FORMAL GRAMMAR/MATHEMATICS OF LANGUAGE CONFERENCE
August 10--12, 2001
Helsinki, Finland
FIRST CALL FOR PAPERS
We are pleased to announce the joint meeting of two conferences:
the sixth conferene on Formal Grammar and the seventh on the
Mathematics of Language. The joint meeting will be held just prior
to the European Summer School in Logic, Language, and Information.
AIMS and SCOPE
especially with regard to the application of formal methods to natural
language analysis.
Themes of interest include, but are not limited to,
* formal and computational syntax, semantics, pragmatics, and phonology;
* model-theoretic and proof-theoretic methods in linguistics;
* constraint-based and resource-sensitive approaches to grammar;
* foundational, methodological and architectural issues in grammar.
* mathematical properties of linguistic frameworks
* theories and models of natural language processing and generation
* parsing theory
* statistical and quantitative models of language
INVITED SPEAKERS will be announced with the circulation
of the second call for papers in early February
SUBMISSION DETAILS
We invite E-MAIL submissions of abstracts for 30-minute papers (including
questions, comments, and discussion).
A submission should consist of two parts:
- an information sheet (in ascii), containing the name of the author(s),
affiliation(s), e-mail and postal address(es) and a title;
- an abstract, consisting of a description of not more than 5 pages
(including figures and references). Abstracts may be either in plain
ASCII or in (unix-compatible encoded) postscript, PDF, or DVI.
Abstracts can be sent to
fgmol@cs.indiana.edu
ABSTRACT SUBMISSION DEADLINE
April 1, 2001
NOTIFICATION OF ACCEPTANCE
May 15, 2001
PROCEEDINGS
A full version of each accepted paper will be included in the conference
proceedings, to be distributed at the conference. Full papers are due
June 30, 2001.
PROGRAMME COMMITTEE
Anne Abeill'e (Paris)
Patrick Blackburn (INRIA)
Gosse Bouma (Groningen)
Mary Dalrymple (Xerox Parc)
Nissim Francez (Haifa)
Thilo Goetz (IBM)
David Johnson (IBM)
Mark Johnson (Brown)
Aravind Joshi (UPenn)
Gerhard J"ager (Utrecht)
Ruth Kempson (London)
Alain Lecomte (LORIA)
Uwe Moennich (T"ubingen)
Glyn Morrill (U.P. Catalunya)
Michael Moortgat (Utrecht)
Owen Rambow (Cogentex)
James Rogers (Earlham)
Giorgio Satta (Padova)
Mark Steedman (Edinburgh)
FURTHER INFORMATION
Web site for ESSLLI XIII: http://www.helsinki.fi/esslli/
Web site for FGMOL'01 :http://www.cis.upenn.edu/~ircs/mol/mol7.html
The organizers:
Geert-Jan Kruijff gj@cogsci.ed.ac.uk
Larry Moss lsm@cs.indiana.edu
Dick Oehrle oehrle@linc.cis.upenn.edu
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%[LaTeX2E Source File]%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{article}
\usepackage{tabularx}
\setlength{\textwidth}{7in}
\setlength{\oddsidemargin}{-.5in}
\setlength{\topmargin}{-36pt}
\pagestyle{empty}
\begin{document}
\begin{center}
{\em Please Post}\\[.1cm]
{\large{\bf Formal Grammar / Mathematics of Language Conference ---
FGMOL'01\\
CALL FOR PAPERS}}\\
{August 10--12, 2001}\qquad Helsinki\\
\end{center}
\begin{center}
\begin{tabular}{@{}p{.27\textwidth}|p{.70\textwidth}@{}}
%\small\ixpt\setlength{\baselineskip}{9pt}
\footnotesize
\begin{flushleft}
{\bf Programme Committee}
\end{flushleft}
\begin{tabular}{l@{}}
Anne Abeill\'{e} (Paris) \\
Patrick Blackburn (INRIA) \\
Gosse Bouma (Groningen) \\
Mary Dalrymple (Xerox Parc) \\
Nissim Francez (Haifa)\\
Thilo Goetz (IBM)\\
David Johnson (IBM) \\
Mark Johnson (Brown)\\
Aravind Joshi (UPenn)\\
Gerhard J\"{a}ger (Utrecht)\\
Ruth Kempson (London)\\
Alain Lecomte (LORIA)\\
Uwe M\"{o}nnich (T\"{u}bingen)\\
Glyn Morrill (U.P. Catalunya) \\
Michael Moortgat (Utrecht) \\
Owen Rambow (Cogentex)\\
James Rogers (Earlham) \\
Giorgio Satta (Padova) \\
Mark Steedman (Edinburgh)\\
[12pt]
{\bf Organizing Committee}\\
Geert-Jan Kruijff (Prague)\\
Larry Moss (Indiana)\\
Richard Oehrle (Ashford)
\end{tabular}
\medskip
{\bf Important Dates}
\smallskip
\begin{tabular}{l@{}}
Abstracts Due: March 31, 2001\\
Notification: May 15, 2001\\
Final Versions: June 30, 2001\\
Conference: August 10-12, 2001\\
\end{tabular}
\medskip
{\bf Addresses:\quad}
\smallskip
\begin{tabular}{l@{}}
ESSLLI XIII: \\
\texttt{http://www.helsinki.fi/esslli}\\
FGMOL'01:\\
\texttt{http://www.cis.upenn.edu/\ldots}\\
$\quad$ \texttt{\ldots $^{\sim}$ircs/mol/mol7.html}
\end{tabular}
&
\setlength{\parskip}{2pt}
We are pleased to announce the joint meeting of two conferences:
the sixth conferene on Formal Grammar and the seventh on the
Mathematics of Language. The joint meeting will be held just prior
to the European Summer School in Logic, Language, and Information.
\medskip
{\it Aims And Scope} FGMOL'01 provides a forum for the presentation of new
and
original research on formal grammar and mathematical aspects of language,
especially with regard to the application of formal methods to natural
language
analysis. Themes of interest include, but are not limited to,
\begin{itemize}
\setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}
\item formal and computational syntax, semantics, pragmatics, and
phonology;
\item model-theoretic and proof-theoretic methods in linguistics;
\item constraint-based and resource-sensitive approaches to grammar;
\item foundational, methodological and architectural issues in grammar.
\item mathematical properties of linguistic frameworks
\item theories and models of natural language processing and generation
\item parsing theory
\item statistical and quantitative models of language
\end{itemize}
\noindent We welcome papers from
a wide variety of frameworks.
\medskip
{\it Invited Speakers} will be announced with the circulation
of the second call for papers in early February.
\medskip
{\it Submission Details} We invite E-MAIL submissions of abstracts
for 30-minute papers (including questions, comments, and discussion).
A submission should consist of two parts:
\begin{itemize}
\setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}
\item an information sheet (in ascii), containing the name of the
author(s),
affiliation(s), e-mail and postal address(es) and a title;
\item an abstract, consisting of a description of not more than 5 pages
(including figures and references). Abstracts may be either in plain
ASCII or in (unix-compatible encoded) postscript, PDF, or DVI.
\end{itemize}
\noindent Abstracts can be sent to {\tt fgmol@cs.indiana.edu} (Larry
Moss).
\medskip
{\it Abstract Submission Deadline} March 31, 2001
{\it Notification of Acceptance} May 15, 2001
{\it Proceedings} A full version of each accepted paper will be
included in the conference proceedings, to be distributed at the
conference. Full papers are due June 30, 2001.
\end{tabular}
\end{center}
\end{document}
From jans@numeric-quest.com Fri Jan 12 08:41:45 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Fri, 12 Jan 2001 03:41:45 -0500 (EST)
Subject: Hash Functions
In-Reply-To: <"017A63A5EC341001*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Message-ID:
On 12 Jan 2001, Steinitz, Dominic J wrote:
> I was thinking of using MD5 or SHA-1 for an application.
> Is there a Haskell library that contains these or other hash algorithms
> that have a very low probability of giving clashes?
>
> Dominic.
http://www.numeric-quest.com/haskell/bridge/index.html
contains interface to MD5 code in C via Greencard. There
is a support for one function only (the only
function I really needed for a certain CGI application)
digest :: String -> String.
It uses 'unsafePerformIO' but you could redesign it
changing its signature to
digest :: String -> String IO
or extend it to supply other functions you need.
Jan
From wli@holomorphy.com Mon Jan 15 00:05:47 2001
From: wli@holomorphy.com (William Lee Irwin III)
Date: Sun, 14 Jan 2001 16:05:47 -0800
Subject: bootstrapping GHC
Message-ID: <20010114160547.D701@holomorphy.com>
I've recently acquired access to SPARC and PPC Linux boxen. GHC 4.04 is
presently bootstrapping on the SPARC, and I was wondering if there were
PPC hc files floating about anywhere, or documentation on how to
generate them.
Thanks,
Bill
From C.Reinke@ukc.ac.uk Mon Jan 15 14:56:46 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Mon, 15 Jan 2001 14:56:46 +0000
Subject: Too Strict?
In-Reply-To: Message from "Steinitz, Dominic J"
of "15 Jan 2001 09:08:13." <"0288E3A62BDFD005*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Message-ID:
> Can someone help? The program below works fine with small files but when I
> try to use it on the one I need to (about 3 million lines of data) it
> produces no output. The hard disk is hammered - I assume this is the run time
> system paging. My suspicion is that the program is trying to read in the
> whole file before processing it. Is this correct? If so, how do I make the
> program lazy so that it processes a line at time?
I was about to apply GHood to your program to see whether such a tool could
help to find the problem, so I started to cut down your code. However,
in the simplified version of the program, one can see what is going on
without any graphical tool.. (nevertheless, observation of the simplified
code with GHood confirms your suspicion immediately, and it points out
the spine of the list as the problem, too, so the tool is useful!-) (*)
In effect, your anonymize comes down to a "mapM" over a list of actions
applied to input lines, and all of the resulting IO-actions are placed
before the single "hPutStr". So, even if the results of the individual
actions in the list may not be needed until later, the whole spine of
the list of lines has to be traversed before "hPutStr" can be executed,
meaning that all input is read before any output is produced (and thus
before any computation results are requested, blowing up memory usage).
For the problem at hand, you could simply output each line as it is
processed instead of just returning it into a list for later use (see
variant _1 below). If you would want to keep both the modular program
structure and the explicit line-by-line IO-style, you would need to
interleave the input and output commands somehow (perhaps similar to
variant _2 below?).
Hth,
Claus
(*) Please note that our web-server is being upgraded today..
(web-pages and GHood download will not be available until
tomorrow, hence no URL here :-(
PS The simplified code (+ variations) with observations:
module Main(main) where
import Observe
import IO(openFile,
hPutStr,
IOMode(ReadMode,WriteMode,AppendMode))
filename = "ldif1.txt"
fileout = "ldif.out"
readAndWriteAttrVals =
do h <- openFile fileout WriteMode
s <- readFile filename
let action l = return (':':l)
a <- mapM action (observe "input" (lines s))
hPutStr h (unlines (observe "output" a))
main = runO readAndWriteAttrVals
readAndWriteAttrVals_1 =
do h <- openFile fileout WriteMode
s <- readFile filename
let action_and_output l = hPutStr h (':':l)
mapM_ (observe "output" action_and_output) (observe "input" (lines s))
main_1 = runO readAndWriteAttrVals_1
readAndWriteAttrVals_2 =
do h <- openFile fileout WriteMode
s <- readFile filename
let { action l = return (':':l)
; as = map action (observe "input" (lines s))
; os = repeat (hPutStr h)
}
mapM id (observe "output" (zipWith (>>=) as os))
main_2 = runO readAndWriteAttrVals_2
From jeff@galconn.com Mon Jan 15 16:36:52 2001
From: jeff@galconn.com (Jeffrey R. Lewis)
Date: Mon, 15 Jan 2001 08:36:52 -0800
Subject: Yet more on functional dependencies
References:
Message-ID: <3A632724.698F9C49@galconn.com>
Mark P Jones wrote:
> | I am finding functional dependencies confusing. (I suspect I am
> | not alone.) Should the following code work?
> |
> | class HasConverter a b | a -> b where
> | convert :: a -> b
> |
> | instance (HasConverter a b,Show b) => Show a where
> | show value = show (convert value)
>
> It's a separate issue. There's no reason why a system using
> functional dependencies *should* support this. But it is an
> attractive and useful extension that such a system would
> probably *want* to include. (i.e., it's a desirable feature,
> not a requirement.)
>
> I typed your example into Hugs on my machine and it seemed to
> accept the syntax (which suggests that the implementation is
> intended to allow this kind of thing). But then it choked on
> the definition with a curious error message that I suspect is
> an indication of a bug in Hugs' treatment of functional
> dependencies. And, for that reason, I'm crossposting this
> message to hugs-bugs. [Let me take the opportunity to remind
> good readers of these lists that it is now more than a year
> since I retired from the joys of maintaining Hugs, so I'm not
> planning to try and track down the source of this bug myself!]
> Of course, it could be that my version of Hugs is out of date!
Could you share the error message please. Boy, even old maintainers don't know how to submit a bug report... ;-)
Actually, I suspect whatever the problem was has been fixed, because (with -98 +o), it compiles fine. (I'm using the bleeding edge, out-of-the-repository version.)
--Jeff
From qrczak@knm.org.pl Sat Jan 13 13:09:25 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 13 Jan 2001 13:09:25 GMT
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
Message-ID:
What should be the preferred way of marking correspondence to source
positions after some preprocessing?
Here is what is currently supported:
| {-# LINE 100 "Foo.hs #-} | # 100 "Foo.hs"
------------------------+------------------------------+----------------
Released ghc, no -cpp | understand | error
Released ghc, with -cpp | understand | understand
Developed ghc | understand | understand
hbc | understand (ignore filename) | understand (warning)
Hugs | ignore | error
Released nhc98 | error | understand
Developed nhc98 | ignore | understand
I would choose LINE pragma. In this case nhc98 should be taught
about it.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From shlomif@vipe.technion.ac.il Mon Jan 15 17:07:29 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Mon, 15 Jan 2001 19:07:29 +0200 (IST)
Subject: A Regular Expression Library for Haskell
Message-ID:
Does such a thing exists? Is it part of Happy?
Regards,
Shlomi Fish
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From simonmar@microsoft.com Mon Jan 15 17:03:29 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 15 Jan 2001 09:03:29 -0800
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61157AB@TVP-MSG-01.europe.corp.microsoft.com>
> What should be the preferred way of marking correspondence to source
> positions after some preprocessing?
>
> Here is what is currently supported:
>
> | {-# LINE 100 "Foo.hs #-} | #
> 100 "Foo.hs"
> ------------------------+------------------------------+------
> ----------
> Released ghc, no -cpp | understand | error
> Released ghc, with -cpp | understand | understand
> Developed ghc | understand | understand
> hbc | understand (ignore filename) |
> understand (warning)
> Hugs | ignore | error
> Released nhc98 | error | understand
> Developed nhc98 | ignore | understand
>
> I would choose LINE pragma. In this case nhc98 should be taught
> about it.
CPP generates the '# 100 "Foo.hs"' form, which is why GHC understands
them. We used to convert these into LINE pragmas automatically before
feeding to the compiler, but this required an extra script and
preprocessing step (hscpp), so we don't do that anymore.
The preferred way should presumably be LINE pragmas.
Cheers,
Simon
From icsm2001@dsi.unifi.it Sat Jan 13 10:33:40 2001
From: icsm2001@dsi.unifi.it (icsm2001 (NESI))
Date: Sat, 13 Jan 2001 11:33:40 +0100 (MET)
Subject: IEEE Conference Software Maint. Italy,Florence, ICSM2001
Message-ID: <200101131033.LAA09656@dsiI.dsi.unifi.it>
Dear Colleague
I would like to invite you to propose papers, experiences, tutorials, tool
expositions, dissertations at the
IEEE International Conference on Software Maintenance, 2001,
and workshops: SCAM, WESS, WSE and TABOO, etc., November 2001, Florence, Italy.
ICSM is the major international conference in the field of software and
systems maintenance, evolution, management, software metrics and quality, etc.
Outstanding Keynotes such as:
>->->Prof. David Lorge Parnas, Prof. Dieter Rombach, Prof. Ivar Jacobson<-<-<-
Awards, workshops, panels, and other exciting activities have been planned.
Please note in the following the new deadline that has been moved to satisfy the
several requests recevied, next deadline >->->->-29 January 2001<-<-<-<-<-<-
Please forward this remind to anybody who you think may be interested.
Apologies if you have already seen this.
If you would like to be removed from our list please send an email to
icsm2001@dsi.unifi.it with REMOVE in the subject.
ICSM2001
Paolo Nesi
(General Chair)
_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=
>->->CALL---FOR---PAPERs<-<-<
IEEE International Conference on Software Maintenance 2001
FLORENCE, ITALY, 6-10 November 2001
http://www.dsi.unifi.it/icsm2001
Theme: Systems and Software Evolution in the era of the Internet
IMPORTANT DATES, DEADLINES
Research Paper submission 29 January 2001
Dissertation submission 29 January 2001
Industrial Application submission 12 March 2001
Tools request and submission 12 March 2001
Tutorial submission 12 February 2001
_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=
From wli@holomorphy.com Mon Jan 15 19:46:17 2001
From: wli@holomorphy.com (William Lee Irwin III)
Date: Mon, 15 Jan 2001 11:46:17 -0800
Subject: bootstrapping GHC
In-Reply-To: <20010114160547.D701@holomorphy.com>; from wli@holomorphy.com on Sun, Jan 14, 2001 at 04:05:47PM -0800
References: <20010114160547.D701@holomorphy.com>
Message-ID: <20010115114617.G701@holomorphy.com>
On Sun, Jan 14, 2001 at 04:05:47PM -0800, William Lee Irwin III wrote:
> I've recently acquired access to SPARC and PPC Linux boxen. GHC 4.04 is
> presently bootstrapping on the SPARC, and I was wondering if there were
> PPC hc files floating about anywhere, or documentation on how to
> generate them.
I found the mailing list discussion on generating the hc boot files and
unregisterized code after a tip from Michael Weber and will eventually
get around to trying to bootstrap on Linux/PPC.
On the other hand, I'm running into a bit of trouble on the SPARC. It's
actually an UltraSPARC (sparc64). My assumption was that ordinary SPARC
code should just run on it. What's actually happen is illegal instructions
everywhere. The one that seems to stop me dead cold every time is here:
00000000009c4cfc :
9c4cfc: 00 9c 4c f8 bn 10d80dc <_end+0x69bff4>
9c4d00: 00 00 00 00 unimp 0
9c4d04: 00 11 00 01 unimp 0x110001
and this is in hsc, which is as far into the bootstrap as I got.
This disassembly looks wrong to me. Perhaps asm mangling is needed; I
had -fno-asm-mangling set because the assembler was barfing on prologue
nonsense. I'll be looking into that, as I'm not very familiar with the
real guts of the compiler, or, for that matter, modern SPARC's.
Any pointers will be appreciated.
Thanks,
Bill
--
'the Baire category theorem has no connection with category theory'
nonsense. *everything* is connected to category theory.
--
From ashley@semantic.org Tue Jan 16 02:11:09 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Mon, 15 Jan 2001 18:11:09 -0800
Subject: O'Haskell OOP Polymorphic Functions
Message-ID: <200101160211.SAA00248@mail4.halcyon.com>
How do you do OOP-style polymorphic functions in O'Haskell? My first
attempt looked something like this:
struct Base
struct Derived < Base =
value :: Int
theValue :: Base -> Maybe Int
theValue x = Just (x.value) -- problem line
theValue _ = Nothing
In the problem line, x is considered to be of type Base, so x.value gives
an error. I tried replacing it with
theValue (x :: Derived) = Just (x.value)
...but that doesn't work either.
--
Ashley Yakeley, Seattle WA
From nordland@cse.ogi.edu Tue Jan 16 08:03:31 2001
From: nordland@cse.ogi.edu (Johan Nordlander)
Date: Tue, 16 Jan 2001 00:03:31 -0800
Subject: O'Haskell OOP Polymorphic Functions
References: <200101160211.SAA00248@mail4.halcyon.com>
Message-ID: <3A640053.936028C2@cse.ogi.edu>
Ashley Yakeley wrote:
>
> How do you do OOP-style polymorphic functions in O'Haskell? My first
> attempt looked something like this:
>
> struct Base
>
> struct Derived < Base =
> value :: Int
>
> theValue :: Base -> Maybe Int
> theValue x = Just (x.value) -- problem line
> theValue _ = Nothing
>
> In the problem line, x is considered to be of type Base, so x.value
> gives an error.
I'm not sure what OOP-style you're referring to. This is like trying
to access the "color" field of an ordinary, uncolored "point". How
would you program your function in Java?
> I tried replacing it with
>
> theValue (x :: Derived) = Just (x.value)
>
> ...but that doesn't work either.
But that's just because O'Haskell doesn't support type annotated
variables in patterns (yet). Change the type signature of your function
to
theValue :: Derived -> Maybe Int
instead, and it should typecheck (it still wouldn't make much sense, though).
However, as a general remark, I'd like to point out that record terms in
O'Haskell don't carry their type with them at run-time. Like in C++,
the type of a record term is a purely static notion that only exists at
compile time. Hence it's not possible to define a function that returns
a value that depends on the dynamic type of its argument (a big win when
one wants to enforce information hiding).
The solution is instead to use an ordinary datatype for values that one
would like to scrutinize at run-time by pattern-matching (the FP way),
or to internalize the function in question into the record type itself
(the OOP way).
-- Johan
From ashley@semantic.org Tue Jan 16 08:54:17 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 16 Jan 2001 00:54:17 -0800
Subject: O'Haskell OOP Polymorphic Functions
Message-ID: <200101160854.AAA06608@mail4.halcyon.com>
At 2001-01-16 00:03, Johan Nordlander wrote:
>Ashley Yakeley wrote:
>>
>> How do you do OOP-style polymorphic functions in O'Haskell? My first
>> attempt looked something like this:
>>
>> struct Base
>>
>> struct Derived < Base =
>> value :: Int
>>
>> theValue :: Base -> Maybe Int
>> theValue x = Just (x.value) -- problem line
>> theValue _ = Nothing
>>
>> In the problem line, x is considered to be of type Base, so x.value
>> gives an error.
>
>I'm not sure what OOP-style you're referring to. This is like trying
>to access the "color" field of an ordinary, uncolored "point".
Right, but returning 'Nothing' for uncolored points and (Just) the color
for colored points.
> How would you program your function in Java?
Library code:
public class Base
{
}
public class Derived
extends Base
{
public int value;
public Derived(int v)
{
value = v;
}
}
Application code:
public static MaybeInt theValue(Base x)
{
if (x instanceof Derived)
return new MaybeInt(((Derived) x).value);
else return MaybeInt.NOTHING;
}
>> I tried replacing it with
>>
>> theValue (x :: Derived) = Just (x.value)
>>
>> ...but that doesn't work either.
>
>But that's just because O'Haskell doesn't support type annotated
>variables in patterns (yet). Change the type signature of your function
>to
>
> theValue :: Derived -> Maybe Int
>
>instead, and it should typecheck (it still wouldn't make much sense, though).
I want a function of type 'Base -> Maybe Int' that returns the value of a
Derived and Nothing for any other Base.
Is it possible to construct such a function?
>However, as a general remark, I'd like to point out that record terms in
>O'Haskell don't carry their type with them at run-time. Like in C++,
>the type of a record term is a purely static notion that only exists at
>compile time. Hence it's not possible to define a function that returns
>a value that depends on the dynamic type of its argument (a big win when
>one wants to enforce information hiding).
>
>The solution is instead to use an ordinary datatype for values that one
>would like to scrutinize at run-time by pattern-matching (the FP way),
This requires knowing the entire type structure before defining any such
functions.
>or to internalize the function in question into the record type itself
>(the OOP way).
This requires knowing all such functions before defining the type
structure. It also makes multiple dispatch difficult. I'm not sure this
can even be done by adding a dynamic-type field, since you still need to
cast to the Derived type to get the value.
--
Ashley Yakeley, Seattle WA
From Dominic.J.Steinitz@BritishAirways.com Tue Jan 16 10:27:32 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 16 Jan 2001 10:27:32 Z
Subject: Too Strict?
Message-ID: <"0168C3A642214195*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Claus,
Thanks for this. I think I can see what the problem was: mapM has to process the whole input before making a value available for hPutStr. Also I can see how to fix the problem.
What I can't see at the moment is how to keep what I was doing modular. I had a module Anonymize, the implementation of which I wanted to change without the user of it having to change their code. The initial implementation was a state monad which generated a new string every time it needed one but if it was a string it had already anonymized then it looked it up in the state. I initially used a list but with 100,000+ strings it took a long time. The next implementation used FiniteMap which improved things considerably. I only had to make three changes in Anonymize and none in Main. Using MD5 is quicker still but isn't so good from the program maintenance point of view.
Dominic.
C.Reinke@ukc.ac.uk on 15/01/2001 15:02:00
To: Dominic Steinitz
cc: haskell
glasgow-haskell-users
bcc:
Subject: Re: Too Strict?
> Can someone help? The program below works fine with small files but when I
> try to use it on the one I need to (about 3 million lines of data) it
> produces no output. The hard disk is hammered - I assume this is the run time
> system paging. My suspicion is that the program is trying to read in the
> whole file before processing it. Is this correct? If so, how do I make the
> program lazy so that it processes a line at time?
I was about to apply GHood to your program to see whether such a tool could
help to find the problem, so I started to cut down your code. However,
in the simplified version of the program, one can see what is going on
without any graphical tool.. (nevertheless, observation of the simplified
code with GHood confirms your suspicion immediately, and it points out
the spine of the list as the problem, too, so the tool is useful!-) (*)
In effect, your anonymize comes down to a "mapM" over a list of actions
applied to input lines, and all of the resulting IO-actions are placed
before the single "hPutStr". So, even if the results of the individual
actions in the list may not be needed until later, the whole spine of
the list of lines has to be traversed before "hPutStr" can be executed,
meaning that all input is read before any output is produced (and thus
before any computation results are requested, blowing up memory usage).
For the problem at hand, you could simply output each line as it is
processed instead of just returning it into a list for later use (see
variant _1 below). If you would want to keep both the modular program
structure and the explicit line-by-line IO-style, you would need to
interleave the input and output commands somehow (perhaps similar to
variant _2 below?).
Hth,
Claus
(*) Please note that our web-server is being upgraded today..
(web-pages and GHood download will not be available until
tomorrow, hence no URL here :-(
PS The simplified code (+ variations) with observations:
module Main(main) where
import Observe
import IO(openFile,
hPutStr,
IOMode(ReadMode,WriteMode,AppendMode))
filename = "ldif1.txt"
fileout = "ldif.out"
readAndWriteAttrVals =
do h <- openFile fileout WriteMode
s <- readFile filename
let action l = return (':':l)
a <- mapM action (observe "input" (lines s))
hPutStr h (unlines (observe "output" a))
main = runO readAndWriteAttrVals
readAndWriteAttrVals_1 =
do h <- openFile fileout WriteMode
s <- readFile filename
let action_and_output l = hPutStr h (':':l)
mapM_ (observe "output" action_and_output) (observe "input" (lines s))
main_1 = runO readAndWriteAttrVals_1
readAndWriteAttrVals_2 =
do h <- openFile fileout WriteMode
s <- readFile filename
let { action l = return (':':l)
; as = map action (observe "input" (lines s))
; os = repeat (hPutStr h)
}
mapM id (observe "output" (zipWith (>>=) as os))
main_2 = runO readAndWriteAttrVals_2
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From magnus@cse.ogi.edu Tue Jan 16 18:23:06 2001
From: magnus@cse.ogi.edu (Magnus Carlsson)
Date: Tue, 16 Jan 2001 10:23:06 -0800
Subject: O'Haskell OOP Polymorphic Functions
In-Reply-To: <200101160211.SAA00248@mail4.halcyon.com>
References: <200101160211.SAA00248@mail4.halcyon.com>
Message-ID: <14948.37258.738847.940224@sokanon.cse.ogi.edu>
You can use overloading for the definition of theValue instead:
class TheValue a where theValue :: a -> Maybe Int
instance TheValue Base where theValue _ = Nothing
instance TheValue Derived where theValue x = Just (x.value)
/M
Ashley Yakeley writes:
> How do you do OOP-style polymorphic functions in O'Haskell? My first
> attempt looked something like this:
>
> struct Base
>
> struct Derived < Base =
> value :: Int
>
> theValue :: Base -> Maybe Int
> theValue x = Just (x.value) -- problem line
> theValue _ = Nothing
>
> In the problem line, x is considered to be of type Base, so x.value gives
> an error. I tried replacing it with
>
> theValue (x :: Derived) = Just (x.value)
>
> ...but that doesn't work either.
>
> --
> Ashley Yakeley, Seattle WA
From nordland@cse.ogi.edu Tue Jan 16 18:38:30 2001
From: nordland@cse.ogi.edu (Johan Nordlander)
Date: Tue, 16 Jan 2001 10:38:30 -0800
Subject: O'Haskell OOP Polymorphic Functions
References: <200101160211.SAA00248@mail4.halcyon.com> <14948.37258.738847.940224@sokanon.cse.ogi.edu>
Message-ID: <3A649526.9164AC16@cse.ogi.edu>
Magnus Carlsson wrote:
>
> You can use overloading for the definition of theValue instead:
>
> class TheValue a where theValue :: a -> Maybe Int
>
> instance TheValue Base where theValue _ = Nothing
> instance TheValue Derived where theValue x = Just (x.value)
>
... or rather, you will be able to use overloading when the new version of
O'Hugs is released in a few days :-)
-- Johan
From Malcolm.Wallace@cs.york.ac.uk Tue Jan 16 19:47:31 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Tue, 16 Jan 2001 19:47:31 +0000
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
Message-ID:
> Here is what is currently supported:
> {-# LINE 100 "Foo.hs #-} | # 100 "Foo.hs"
I recently discovered that some of the GHC toolset actually
generates and recognises
{-# LINE 100 "Foo.hs -}
which is somewhere in between a comment and a pragma. Has
this been fixed yet?
> I would choose LINE pragma. In this case nhc98 should be taught
> about it.
The 1.00 release of nhc98 (incorrectly) rejects almost all pragmas.
The 1.01 (CVS) version correctly accepts (but ignores) almost all
pragmas. In time, it will learn to use the information from a small
number of pragmas. When that happens, LINE can certainly be one
of them.
Regards,
Malcolm
From C.Reinke@ukc.ac.uk Tue Jan 16 19:59:03 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Tue, 16 Jan 2001 19:59:03 +0000
Subject: ANNOUNCE: GHood (updated pre-release)
Message-ID:
Ever wanted to see what your Haskell program is doing?-)
-----------------------------------------------------------------
GHood (pre-release, 11 January 2001)
"Graphical Hood" -- a Java-based graphical observation event viewer, as
a back-end for Andy Gill's Hood (Haskell Object Observation Debugger).
Currently, GHood comes in two files: a drop-in replacement for the
Hugs98 variant of Hood (only minimal changes, same interface) and a
Java class file archive for the graphical viewer itself.
To find the two files, please visit my Haskell corner at:
http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/#GHood
-----------------------------------------------------------------
The GHood pre-release has been updated. The main change (apart from
single-stepping through the observation event stream, which you might
have been missing in the previous version):
GHood can now be used as an applet (requires Java 2/Swing-capable
browser or a suitable Java plug-in).
This means that GHood animations can now be used to enrich webpages.
If you ever wanted to discuss the behaviour of Haskell programs on your
webpages, you can now add applets to those pages that visualise and
animate the issues you describe. If you never dared to write about
program behaviour for lack of illustrations, you might now consider
adding such discussions to your webpages. Potential uses:
- educators: as part of your functional programming course webpages,
- programmers: as part of the description of a clever functional algorithm,
or to document problems in a misbehaving functional program
- GHood implementors (me;-): show examples of GHood animations online.
I would be interested to learn about example problems from practice for
which GHood has been found helpful. Please let me know, too, if you
create websites that use GHood as an applet.
Enjoy,
Claus
--
Claus Reinke, http://www.cs.ukc.ac.uk/people/staff/cr3/
Computing Lab, University of Kent at Canterbury
From ashley@semantic.org Tue Jan 16 21:06:54 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 16 Jan 2001 13:06:54 -0800
Subject: O'Haskell OOP Polymorphic Functions
Message-ID: <200101162106.NAA11243@mail4.halcyon.com>
At 2001-01-16 10:23, Magnus Carlsson wrote:
>You can use overloading for the definition of theValue instead:
>
> class TheValue a where theValue :: a -> Maybe Int
>
> instance TheValue Base where theValue _ = Nothing
> instance TheValue Derived where theValue x = Just (x.value)
Doesn't this imply that run-time type information is kept with the
structs?
Consider:
d :: Derived
d = struct
value = 3
b :: Base
b = d
idb :: Base -> Base
idb x = x
f1 = theValue d
f2 = theValue b
f3 = theValue (idb d)
f4 = theValue (idb b)
What are the values of f1, f2, f3 & f4?
--
Ashley Yakeley, Seattle WA
From qrczak@knm.org.pl Tue Jan 16 21:09:07 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 16 Jan 2001 21:09:07 GMT
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
References:
Message-ID:
Tue, 16 Jan 2001 19:47:31 +0000, Malcolm Wallace pisze:
> I recently discovered that some of the GHC toolset actually
> generates and recognises
> {-# LINE 100 "Foo.hs -}
> which is somewhere in between a comment and a pragma. Has
> this been fixed yet?
I've heard about it... Oops, it appears that since the CVS version
of ghc no longer translates cpp-style markers into LINE pragmas in
a separate pass, but interprets them itself in the compiler proper,
ghc -E does not perform that pass and now outputs cpp-style markers,
which do get into happy's templates. So it's indeed "fixed": to
cpp-style markers :-(
It can be properly fixed either by postprocessing the templates
during building of happy, or implementing that pass separately again
for explicit invocation of ghc -E. Since ghc -E does not seem to be
a widely used and very standard feature, perhaps it's enough to do
the former.
Moreover, there was one place internal to ghc which output
{-# LINE 1 "File" -}
and I will commit a fix in a minute.
> The 1.00 release of nhc98 (incorrectly) rejects almost all pragmas.
> The 1.01 (CVS) version correctly accepts (but ignores) almost all
> pragmas. In time, it will learn to use the information from a small
> number of pragmas. When that happens, LINE can certainly be one
> of them.
ghc recognizes {-# together with the pragma's keyword during lexical
analysis, emits e.g. '{-# SPECIALIZE' as a single token, and treats
unrecognized pragmas as comments. nhc98 passes all pragmas to the
parser.
The difference is that ghc ignores pragmas with unknown keywords
placed in unusual places (e.g. in the middle of an expression),
where nhc98 flags them as errors.
Of course LINE can appear anywhere without respect to layout so must
be dealt with during the lexical analysis.
Haskell 98 does not say anything about case sensitivity of pragmas'
keywords but uses lowercase and mixedCase examples. ghc ignores the
case. hbc understands both all-uppercase and all-lowercase forms but
no mixing. I've seen only uppercase in practice. Perhaps something
should be said about it more explicitly. Perhaps official support
for uppercase only is enough (the rest of Haskell is case sensitive).
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From magnus@cse.ogi.edu Tue Jan 16 21:18:02 2001
From: magnus@cse.ogi.edu (Magnus Carlsson)
Date: Tue, 16 Jan 2001 13:18:02 -0800
Subject: O'Haskell OOP Polymorphic Functions
In-Reply-To: <200101162106.NAA11243@mail4.halcyon.com>
References: <200101162106.NAA11243@mail4.halcyon.com>
Message-ID: <14948.47754.729548.657521@sokanon.cse.ogi.edu>
Ashley Yakeley writes:
> At 2001-01-16 10:23, Magnus Carlsson wrote:
>
> >You can use overloading for the definition of theValue instead:
> >
> > class TheValue a where theValue :: a -> Maybe Int
> >
> > instance TheValue Base where theValue _ = Nothing
> > instance TheValue Derived where theValue x = Just (x.value)
>
> Doesn't this imply that run-time type information is kept with the
> structs?
The overloading is resolved statically, so no run-time type
information is needed.
>
> Consider:
>
> d :: Derived
> d = struct
> value = 3
>
> b :: Base
> b = d
>
> idb :: Base -> Base
> idb x = x
>
> f1 = theValue d
> f2 = theValue b
> f3 = theValue (idb d)
> f4 = theValue (idb b)
>
> What are the values of f1, f2, f3 & f4?
f1 = Just 3
f2 = f3 = f4 = Nothing
> --
> Ashley Yakeley, Seattle WA
/M
From ashley@semantic.org Tue Jan 16 21:27:05 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 16 Jan 2001 13:27:05 -0800
Subject: O'Haskell OOP Polymorphic Functions
Message-ID: <200101162127.NAA14109@mail4.halcyon.com>
At 2001-01-16 13:18, Magnus Carlsson wrote:
>f1 = Just 3
>f2 = f3 = f4 = Nothing
So I've declared b = d, but 'theValue b' and 'theValue d' are different
because theValue is looking at the static type of its argument?
What's to stop 'instance TheValue Base' applying in 'theValue d'?
--
Ashley Yakeley, Seattle WA
From john@foo.net Tue Jan 16 22:04:22 2001
From: john@foo.net (John Meacham)
Date: Tue, 16 Jan 2001 14:04:22 -0800
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
In-Reply-To: ; from qrczak@knm.org.pl on Tue, Jan 16, 2001 at 09:09:07PM +0000
References:
Message-ID: <20010116140422.A5586@mark.ugcs.caltech.edu>
With all this talk of preprocessor generated information and whatnot, I
am reminded of a paper I read not too long ago but can't seem to find
anymore about a dedicated pre-processor for haskell based on the C
preprocessor but made to deal with haskell constructs a bit more sanely.
I was wondering whatever happened to that Idea as I find myself in need
of a preprocessor every now and again... I imagine a small pure Haskell 98
implementation of the preprocessor would be very useful because then it
can be included directly with programs that require it and compiled
first as part of the make process until compilers have it integrated...
any thoughts? anyone have a link to the original paper I am talking
about?
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@foo.net
--------------------------------------------------------------
From nordland@cse.ogi.edu Tue Jan 16 22:41:52 2001
From: nordland@cse.ogi.edu (Johan Nordlander)
Date: Tue, 16 Jan 2001 14:41:52 -0800
Subject: O'Haskell OOP Polymorphic Functions
References: <200101162220.OAA21394@mail4.halcyon.com>
Message-ID: <3A64CE30.77EAF5CA@cse.ogi.edu>
Ashley Yakeley wrote:
>
> At 2001-01-16 14:04, Tom Pledger wrote:
>
> >The subtyping (struct Derived < Base ...) makes the two instances
> >overlap, with 'instance TheValue Derived' being strictly more specific
> >than 'instance TheValue Base'. If the system preferred the less
> >specific one, the more specific one would never be used.
> >
> >This is quite similar to the way overlapping instances are handled
> >when they occur via substitutions for type variables (e.g. 'instance C
> >[Char]' is strictly more specific than 'instance C [a]') in
> >implementations which support than language extension.
>
> Subtyping-overlapping is quite different from type-substitution
> overlapping.
>
> Consider:
>
> struct B
>
> struct D1 < Base =
> a1 :: Int
>
> struct D2 < Base =
> a2 :: Int
>
> class TheValue a where theValue :: a -> Int
> instance TheValue B where theValue _ = 0
> instance TheValue D1 where theValue _ = 1
> instance TheValue D2 where theValue _ = 2
>
> struct M < D1,D2
>
> m = struct
> a1 = 0
> a2 = 0
>
> f = theValue m
>
> What's the value of f?
This program is rejected on the grounds that it lacks an instance
delaration for TheValue M. Declare one and you will be fine.
Or (when the upcoming release becomes available) remove the instance
decl for either D1 or D2 and the remaining one will be chosen.
-- Johan
From chak@cse.unsw.edu.au Tue Jan 16 23:04:30 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 16 Jan 2001 23:04:30 GMT
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61157AB@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C61157AB@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010116230430R.chak@cse.unsw.edu.au>
Simon Marlow wrote,
> The preferred way should presumably be LINE pragmas.
Indeed. Or do you want to tell me that you are going to
break one of my favourite programs?
import Char
instance Eq (a -> b) where
_ ==_ = False
instance Show (a -> b) where
show = const ""
instance Num b => Num (a -> b) where
fromInteger = const . fromInteger
(+) = undefined
(*) = undefined
signum = undefined
abs = undefined
(#) :: Int -> Int -> String
(x # y) = chr x : chr y : "!"
main = putStrLn $ 78
# 111 "Foo.hs"
Cheers,
Manuel
From chak@cse.unsw.edu.au Wed Jan 17 00:01:33 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Wed, 17 Jan 2001 00:01:33 GMT
Subject: A Regular Expression Library for Haskell
In-Reply-To:
References:
Message-ID: <20010117000133P.chak@cse.unsw.edu.au>
> Does such a thing exists?
Yes. See the lexer library in
http://www.cse.unsw.edu.au/~chak/haskell/ctk/
You can use it without most of the other stuff and it is
fast, too.
Cheers,
Manuel
From sebc@posse42.net Wed Jan 17 08:53:26 2001
From: sebc@posse42.net (Sebastien Carlier)
Date: Wed, 17 Jan 2001 09:53:26 +0100
Subject: An Haskell compilation server
Message-ID: <20010117085242.E267FFCE@www.haskell.org>
How about turning ghc into a compilation server ?
It would run as a daemon waiting for network
connections, retrieve source files (through the
same network socket, or nfs, or cvs, ...), compile
them locally, and send back the result.
This would prevent having to reload the compiler
for each file - as the executable is quite large, this
may already speed up compilation a bit.
It could also cache .hi files, which would remove
the need to parse them.
It would also enable distributed compilation, on a
properly configured site. That would be easy to do
with hmake.
There are many details to think about (should the
parsing be made locally by the driver, or remotely...).
How does it sound ?
--
Sebastien Carlier
EPITA, Posse42
From john@foo.net Wed Jan 17 09:28:00 2001
From: john@foo.net (John Meacham)
Date: Wed, 17 Jan 2001 01:28:00 -0800
Subject: An Haskell compilation server
In-Reply-To: <20010117085242.E267FFCE@www.haskell.org>; from sebc@posse42.net on Wed, Jan 17, 2001 at 09:53:26AM +0100
References: <20010117085242.E267FFCE@www.haskell.org>
Message-ID: <20010117012759.B19762@mark.ugcs.caltech.edu>
the benefits may not be as great as you suppose, modern operating
systems keep a buffer cache which contains all recently used data in
memory including executables, if your machine is not memory limited
(such that the OS would have to throw away your ghc pages to make room
for something else) then probably most of ghc's pages will already be
resident in RAM for subsequent runs. if you wish to distribute the make
over several machines that can be done easily by using 'ssh' or 'rsh' to
start jobs on remote machines and share the results via nfs or smb or
some other remote filesystem. there are also certain versions of make
such as 'pmake' which specialize in distributing building across
clusters of machines... modifying 'hmake' to distribute the builds
automagically might be an interesting and useful project though.
John
On Wed, Jan 17, 2001 at 09:53:26AM +0100, Sebastien Carlier wrote:
> How about turning ghc into a compilation server ?
> It would run as a daemon waiting for network
> connections, retrieve source files (through the
> same network socket, or nfs, or cvs, ...), compile
> them locally, and send back the result.
> This would prevent having to reload the compiler
> for each file - as the executable is quite large, this
> may already speed up compilation a bit.
> It could also cache .hi files, which would remove
> the need to parse them.
> It would also enable distributed compilation, on a
> properly configured site. That would be easy to do
> with hmake.
> There are many details to think about (should the
> parsing be made locally by the driver, or remotely...).
> How does it sound ?
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@foo.net
--------------------------------------------------------------
From sebc@posse42.net Wed Jan 17 09:48:20 2001
From: sebc@posse42.net (Sebastien Carlier)
Date: Wed, 17 Jan 2001 10:48:20 +0100
Subject: An Haskell compilation server
Message-ID: <20010117094737.88DFA1049@www.haskell.org>
John Meacham wrote:
> the benefits may not be as great as you suppose, modern operating
> systems keep a buffer cache which contains all recently used data in
> memory including executables, if your machine is not memory limited
> (such that the OS would have to throw away your ghc pages to make room
> for something else) then probably most of ghc's pages will already be
> resident in RAM for subsequent runs.
Even if the executable file is cached, there is still dynamic linking
to be done. Are pages of the executable memory mapped, or does the
binary file format get in the way and force the code segment to be
copied ? (this is architecture dependent, it would be interesting to
find out for the most common ones)
Even if the loading time is only slightly shorter, I think more
interesting speed-ups can be achieved by removing any work which
is duplicated by the compiler at each run. This probably includes
parsing .hi files. Where does the compiler spend most of its time ?
> if you wish to distribute the make over several machines that can be
> done easily by using 'ssh' or 'rsh' to start jobs on remote machines
> and share the results via nfs or smb or some other remote filesystem.
This would be very difficult without analysing the dependencies
between modules, I think the compilation has to be globally coordinated.
Also, you probably want to use only compilers for the sate architecture,
although you might have compilation servers for several. They should
register themselves to a central coordination server, which could also
balance the workload between servers.
I do not think this would be efficiently done with shell scripts.
> there are also certain versions of make such as 'pmake' which
> specialize in distributing building across clusters of machines...
> modifying 'hmake' to distribute the builds automagically might be
> an interesting and useful project though.
This would indeed be nice for universities and large sites.
And rebuilding ghc would be a breeze :)
> --
> --------------------------------------------------------------
> John Meacham http://www.ugcs.caltech.edu/~john/
> California Institute of Technology, Alum. john@foo.net
> --------------------------------------------------------------
From mh@informatik.uni-kiel.de Wed Jan 17 09:50:37 2001
From: mh@informatik.uni-kiel.de (Michael Hanus)
Date: Wed, 17 Jan 2001 10:50:37 +0100 (MET)
Subject: An Haskell compilation server
In-Reply-To: Sebastien Carlier's message of January 17 (09:53)
References: <20010117085242.E267FFCE@www.haskell.org>
Message-ID: <14949.27373.236107.948103@petrus.informatik.uni-kiel.de>
Sebastien Carlier wrote:
> How about turning ghc into a compilation server ?
> It would run as a daemon waiting for network
> connections, retrieve source files (through the
> same network socket, or nfs, or cvs, ...), compile
> them locally, and send back the result.
> This would prevent having to reload the compiler
> for each file - as the executable is quite large, this
> may already speed up compilation a bit.
> It could also cache .hi files, which would remove
> the need to parse them.
> It would also enable distributed compilation, on a
> properly configured site. That would be easy to do
> with hmake.
> There are many details to think about (should the
> parsing be made locally by the driver, or remotely...).
> How does it sound ?
This is a good idea. We have done this for our Curry implementation
(http://www.informatik.uni-kiel.de/~pakcs)
(Curry is an extension of Haskell to deal with logic and concurrent
programming features) and made very good experiences with it,
in particular, there was a considerably speed-up when recompiling
larger applications.
Michael
From simonmar@microsoft.com Wed Jan 17 09:49:25 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 17 Jan 2001 01:49:25 -0800
Subject: An Haskell compilation server
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F3BC@TVP-MSG-01.europe.corp.microsoft.com>
> How about turning ghc into a compilation server ?
> It would run as a daemon waiting for network
> connections, retrieve source files (through the
> same network socket, or nfs, or cvs, ...), compile
> them locally, and send back the result.
> This would prevent having to reload the compiler
> for each file - as the executable is quite large, this
> may already speed up compilation a bit.
> It could also cache .hi files, which would remove
> the need to parse them.
> It would also enable distributed compilation, on a
> properly configured site. That would be easy to do
> with hmake.
> There are many details to think about (should the
> parsing be made locally by the driver, or remotely...).
> How does it sound ?
Funny you should say that. The next version of GHC (5.00 - to be
released soon) will have hmake-like functionality enabling it to compile
multiple modules without exiting, caching .hi files between
compilations. This speeds up compilations by as much as a factor of 2
for large programs.
Cheers,
Simon
From qrczak@knm.org.pl Wed Jan 17 13:06:36 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 17 Jan 2001 13:06:36 GMT
Subject: An Haskell compilation server
References: <9584A4A864BD8548932F2F88EB30D1C60171F3BC@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Wed, 17 Jan 2001 01:49:25 -0800, Simon Marlow pisze:
> Funny you should say that. The next version of GHC (5.00 - to be
> released soon) will have hmake-like functionality enabling it to
> compile multiple modules without exiting,
How to specify .c files to be linked in?
Or to not bother with linking so I will link manually.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From till@Informatik.Uni-Bremen.DE Wed Jan 17 14:13:37 2001
From: till@Informatik.Uni-Bremen.DE (Till Mossakowski)
Date: Wed, 17 Jan 2001 15:13:37 +0100
Subject: Research assistant positions in Bremen
Message-ID: <3A65A891.24A8CF18@informatik.uni-bremen.de>
The following two research assistant positions
are available at the University of Bremen, Germany.
The Bremen Institute of Safe Systems in the Center for Computing
Technologies at the University of Bremen hosts the research projects
"Multi-logic systems as a basis for heterogeneous specification
and development" (MULTIPLE)
and
"Algebraic specification + functional programming =
environment for formal software development" (HasCASL)
funded by the Deutsche Forschungsgemeinschaft (DFG).
Within the framework of each of these projects, one position in the
working group of Prof. Dr. Krieg-Brückner is to be immediately
filled for at least two years (additional option for another two
years),
subject to availability of funds:
Research Assistant
Verg. Gr. IIa BAT (full time)
In addition to successful university studies in computer science,
experience and skills in functional programming (e.g. Haskell, ML)
are expected. Familiarity with at least one of formal specification
methods (like CoFI/CASL), theorem proving or category theory is
desirable.
Applicants with a PhD are welcome. However, there will also be the
oppurtunity to prepare a PhD thesis in connection with the research
project.
In case of essentially equal qualification in the subject and personal
suitability, severely handicapped applicants will be preferred. The
University of Bremen intends to increase the share of women in
scientific activities and does therefore strongly encourage women to
apply for these positions.
More detailed information about the projects can be found under
http://www.tzi.de/cofi/projects/multiple.html
http://www.tzi.de/cofi/projects/hascasl.html
Please address your application with the usual documents and the
reference number A164/00 (MULTIPLE) resp. A165/00 (HasCASL)
before 01.02.2001 to:
UNIVERSITÄT BREMEN
Prof. Dr. B. Krieg-Brückner
Fachbereich 3
Postfach 33 04 40
28334 Bremen
e-Mail: cofi@tzi.de
--
Till Mossakowski Phone: +49-421-218-4683, monday:
+49-4252-1859
Dept. of Computer Science Fax: +49-421-218-3054
University of Bremen EMail: till@tzi.de
P.O.Box 330440, D-28334 Bremen WWW: http://www.tzi.de/~till
From koen@cs.chalmers.se Wed Jan 17 15:32:29 2001
From: koen@cs.chalmers.se (Koen Claessen)
Date: Wed, 17 Jan 2001 16:32:29 +0100 (MET)
Subject: fixity for (\\)
Message-ID:
Hi all,
The Haskell report defines the fixity of (\\) to be:
infix 5 \\
I propose that it gets the following fixity:
infixl 5 \\
This means that one can write:
as \\ bs \\ cs \\ ds
Which means:
(((as \\ bs) \\ cs) \\ ds)
I think that one less often means the following:
as \\ (bs \\ (cs \\ ds))
/Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
From pamela@research.att.com Wed Jan 17 15:31:35 2001
From: pamela@research.att.com (Pamela Zave)
Date: Wed, 17 Jan 2001 10:31:35 -0500 (EST)
Subject: FME2001 Call for Participation
Message-ID: <200101171531.KAA26216@raptor.research.att.com>
To learn about Formal Methods Europe 2001, to be held in Berlin 12-16 March,
please visit the symposium website at:
www.informatik.hu-berlin.de/top/fme2001
Registration and hotel reservation are available on the website. The deadline
for early registration is 9 February.
Please register now so we can look forward to seeing you in Berlin!
From jf15@hermes.cam.ac.uk Wed Jan 17 16:41:07 2001
From: jf15@hermes.cam.ac.uk (Jon Fairbairn)
Date: Wed, 17 Jan 2001 16:41:07 +0000 (GMT)
Subject: fixity for (\\)
In-Reply-To:
Message-ID:
On Wed, 17 Jan 2001, Koen Claessen wrote:
> I propose that it gets the following fixity:
>=20
> infixl 5 \\
Unless the it's common usage outside of Haskell, I oppose!
Getting=20
List> [1,2,3]\\[2]\\[3]
ERROR: Ambiguous use of operator "(\\)" with "(\\)"
at compile time does no harm, but getting [1] instead of
[1,3] _at run time_ does do harm.
J=F3n
--=20
J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.uk
31 Chalmers Road jf@cl.cam.ac.uk
Cambridge CB1 3SZ +44 1223 570179 (pm only, please)
From igloo@earth.li Wed Jan 17 19:11:40 2001
From: igloo@earth.li (Ian Lynagh)
Date: Wed, 17 Jan 2001 19:11:40 +0000
Subject: MD5 in Haskell
Message-ID: <20010117191140.A26059@stu163.keble.ox.ac.uk>
I apologise if this is off topic for this list - I haven't been here long.
Someone recently mentioned that the MD5 function in GHC uses C code to do the
work so returns an IO String rather than a String. I have written an MD5
implementation in pure Haskell code (following the RFC - I don't know if a
better optimised version could be written although I may look into this).
I've put the code at http://c93.keble.ox.ac.uk/~ian/md5/
License is GPL.
Ian
From ashley@semantic.org Wed Jan 17 23:48:55 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Wed, 17 Jan 2001 15:48:55 -0800
Subject: O'Haskell OOP Polymorphic Functions
Message-ID: <200101172348.PAA28747@mail4.halcyon.com>
OK, I've figured it out. In this O'Haskell statement,
> struct Derived < Base =
> value :: Int
...Derived is not, in fact, a subtype of Base. Derived and Base are
disjoint types, but an implicit map of type "Derived -> Base" has been
defined.
--
Ashley Yakeley, Seattle WA
From uk1o@rz.uni-karlsruhe.de Wed Jan 17 23:58:59 2001
From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter)
Date: Thu, 18 Jan 2001 00:58:59 +0100
Subject: Finding primes using a primes map with Haskell and Hugs98
In-Reply-To: ; from shlomif@vipe.technion.ac.il on Wed, Dec 20, 2000 at 04:02:23PM +0200
References: <74096918BE6FD94B9068105F877C002D0137839D@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20010118005859.B11618@rz.uni-karlsruhe.de>
Hello!
On Wed, Dec 20, 2000 at 04:02:23PM +0200, Shlomi Fish wrote:
> [...]
> primes :: Int -> [Int]
> primes how_much = sieve [2..how_much] where
> sieve (p:x) =
> p : (if p <= mybound
> then sieve (remove (p*p) x)
> else x) where
> remove what (a:as) | what > how_much = (a:as)
> | a < what = a:(remove what as)
> | a == what = (remove (what+step) as)
> | a > what = a:(remove (what+step) as)
> remove what [] = []
> step = (if (p == 2) then p else (2*p))
> sieve [] = []
> mybound = ceiling(sqrt(fromIntegral how_much))
> [...]
How about this: Yet another infinite list version, however
only sieving numbers to the square of the current maximum:
primes :: [Int]
primes = 2:fil' 4 primes [3..]
where
fil' cutoff fl@(f:fs) rl@(r:rs) =
if r < cutoff then r:fil' cutoff fl rs
else fil' (square (head fs)) fs [y|y<-rl, (y `mod` f) /= 0]
square x = x*x
Comparison:
my version (with a small main around it):
hannah@mamba:~/src/haskell $ time ./primes 1000000 >/tmp/p1
real 0m31.928s
user 0m31.690s
sys 0m0.317s
your version (with adapted small main around it):
hannah@mamba:~/src/haskell $ time ./primes2 1000000 >/tmp/p2
real 0m42.993s
user 0m42.023s
sys 0m0.236s
(measurements with ghc 4.08, -O2 -O2-for-C, Pentium I 200 MHz 64 MB RAM)
The outputs (primes list + number of found primes) are the same.
In contrast, take the simple two-liner
primes :: [Int]
primes = p' [2..] where p' (p:ps) = p:p' [y|y<-ps, (y `mod` p) /= 0]
with the same small main:
hannah@mamba:~/src/haskell $ time ./primes0 100000 >/tmp/p0
real 2m17.460s
user 2m15.773s
sys 0m1.170s
(mine with 100000 limit)
hannah@mamba:~/src/haskell $ time ./primes 100000 >/tmp/p1
real 0m1.666s
user 0m1.607s
sys 0m0.048s
(yours with 100000 limit)
hannah@mamba:~/src/haskell $ time ./primes2 100000 >/tmp/p2
real 0m1.903s
user 0m1.827s
sys 0m0.064s
Kind regards,
Hannah.
From kuchen@uni-muenster.de Thu Jan 18 10:59:59 2001
From: kuchen@uni-muenster.de (Herbert Kuchen)
Date: Thu, 18 Jan 2001 11:59:59 +0100
Subject: FLOPS 2001 - Call for Participation
Message-ID: <3A66CCAF.51081490@uni-muenster.de>
*********************************************************************
* CALL FOR PARTICIPATION *
* *
* FLOPS 2001 *
* Fifth International Symposium on Functional and Logic Programming *
* *
* Waseda University, Tokyo, Japan *
* March 7-9, 2001 *
* *
* http://www.ueda.info.waseda.ac.jp/flops2001/ *
*********************************************************************
The symposium is a forum for research on all issues concerning
functional programming and logic programming. In particular, it aims
to stimulate the cross-fertilization as well as integration of the two
paradigms. This is the fifth in the series of FLOPS symposia held
every 1.5 years in Japan.
The symposium program will consist of 3 invited talks and 21 technical
research talks. The proceedings will be published by Springer-Verlag
in the Lecture Notes in Computer Science series.
Invited Talks
=============
Gopalan Nadathur (Univ. of Minnesota, USA)
"The Metalanguage lambda-Prolog and Its Implementation"
George C. Necula (Univ. of California, Berkeley, USA)
"A Scalable Architecture for Proof-Carrying Code"
Taisuke Sato (Tokyo Institute of Technology, Japan)
"Parameterized Logic Programs where Computing Meets Learning"
Important Dates
===============
Early Registration Deadline: January 30, 2001
Symposium: March 7-9, 2001
Venue
=====
The symposium will be held at the International Conference Center of
Waseda University, which is located in central Tokyo and can be
accessed easily. For details, please visit the FLOPS2001 Web page
http://www.ueda.info.waseda.ac.jp/flops2001/ .
Registration and Hotel Information
==================================
Details of registration and hotel booking information are available
on the FLOPS2001 Web page. Registration fees are as follows:
Before Jan. 30 After Jan. 31
Regular 22,000 yen 32,000 yen
Student 12,000 yen 22,000 yen
The fees include participation, proceedings, banquet and
refreshments for one person. Additional banquet tickets are
available. The current exchange rate for Japanese yen is
US$1 = 116 yen and 1 Euro = 109 yen.
Detailed information on accommodations near the conference site,
ranging from luxuary to inexpensive, is available on the FLOPS Web
page.
Accepted Papers
===============
(A timetable will be available on the FLOPS2001 Web page shortly.)
Proving Syntactic Properties of Exceptions in an Ordered Logical
Framework
Jeff Polakow and Kwangkeun Yi
A Higher-Order Colon Translation
Olivier Danvy and Lasse R. Nielsen
Compiling Lazy Functional Programs Based on the Spineless Tagless
G-machine for the Java Virtual Machine
Kwanghoon Choi, Hyun-il Lim, and Taisook Han
A Higher-Order Logic Programming Language with Constraints
Javier Leach and Susana Nieva
Specifying and Debugging Security Protocols via Hereditary Harrop
Formulas and lambdaProlog - A Case-study
Giorgio Delzanno
An Effective Bottom-Up Semantics for First-Order Linear Logic Programs
Marco Bozzano, Giorgio Delzanno, and Maurizio Martelli
A Framework for Goal-Directed Bottom-Up Evaluation
of Functional Logic Programs
Jesus M. Almendros-Jimenez and Antonio Becerra-Teron
Theoretical Foundations for the Declarative Debugging of
Lazy Functional Logic Programs
Rafael Caballero, Francisco J. Lopez-Fraguas, and
Mario Rodriguez-Artalejo
Adding Linear Constrains over Real Numbers to Curry
Wolfgang Lux
A Complete Selection Function for Lazy Conditional Narrowing
Taro Suzuki and Aart Middeldorp
An Abstract Machine Based System for a Lazy Narrowing Calculus
Teresa Hortala-Gonzalez and Eva Ullan
Incremental Learning of Functional Logic Programs
Cesar Ferri-Ramirez, Jose Hernandez-Orallo,
and Maria Jose Ramirez-Quintana
A General Type Inference Framework for Hindley/Milner Style Systems
Martin Sulzmann
Monadic Encapsulation with Stack of Regions
Koji Kagawa
Well-Typed Logic Programs Are not Wrong
Pierre Deransart and Jan-Georg Smaus
A Framework for Analysis of Typed Logic Programs
Vitaly Lagoon and Peter J. Stuckey
Abstract Compilation for Sharing Analysis
Gianluca Amato and Fausto Spoto
A Practical Partial Evaluator for a Multi-Paradigm Declarative
Language
Elvira Albert, Michael Hanus, and German Vidal
A Simple Take on Typed Abstract Syntax in ML-like Languages
Olivier Danvy and Morten Rhiger
A Simply Typed Context Calculus with First-Class Environments
Masahiko Sato, Takafumi Sakurai, and Yukiyoshi Kameyama
Refining the Barendregt Cube using Parameters
Fairouz Kamareddine, Twan Laan, and Rob Nederpelt
Symposium Organization
======================
Program Co-Chairs:
Herbert Kuchen Univ. of Muenster, Germany
Kazunori Ueda Waseda Univ., Tokyo, Japan
Program Committee:
Sergio Antoy Portland State Univ., USA
Gopal Gupta New Mexico State Univ., USA
Michael Hanus Univ. of Kiel, Germany
Fergus Henderson Univ. of Melbourne, Australia
Zhenjiang Hu Univ. of Tokyo, Japan
Herbert Kuchen Univ. of Muenster, Germany
Giorgio Levi Univ. of Pisa, Italy
Michael Maher Griffith Univ., Brisbane, Australia
Dale Miller Pennsylvania State Univ., USA
I.V. Ramakrishnan State Univ. of New York at Stony Brook, USA
Olivier Ridoux IRISA, France
Mario Rodriguez-Artalejo Complutense Univ., Madrid, Spain
Colin Runciman Univ. of York, UK
Akihiko Takano Hitachi Ltd., Japan
Peter Thiemann Freiburg Univ., Germany
Yoshihito Toyama Tohoku Univ., Japan
Kazunori Ueda Waseda Univ., Tokyo, Japan
Local Arrangements Chair:
Zhenjiang Hu Univ. of Tokyo, Japan
Sponsors
========
FLOPS2001 is sponsored by Japan Society of Software Science and
Technology (JSSST), Special Interest Group on Principles of
Programming, and held in cooperation with Association for Logic
Programming (ALP).
From harald@cs.mu.OZ.AU Thu Jan 18 00:45:36 2001
From: harald@cs.mu.OZ.AU (Harald Sondergaard)
Date: Thu, 18 Jan 2001 11:45:36 +1100
Subject: PPDP 2001: Call for Papers (second call)
Message-ID: <200101180045.LAA21256@mundook.cs.mu.OZ.AU>
(Apologies if you receive multiple copies of this announcement.)
Third International Conference on
PRINCIPLES AND PRACTICE OF DECLARATIVE PROGRAMMING
Firenze, Italy, 5-7 September 2001
CALL FOR PAPERS
PPDP 2001 aims to stimulate research on the use of declarative methods
in programming and on the design, implementation and application of
programming languages that support such methods. Topics of interest
include any aspect related to understanding, integrating and extending
programming paradigms such as those for functional, logic, constraint
and object-oriented programming; concurrent extensions and mobile
computing; type theory; support for modularity; use of logical methods
in the design of program development tools; program analysis and
verification; abstract interpretation; development of implementation
methods; application of the relevant paradigms and associated methods
in industry and education. This list is not exhaustive: submissions
describing new and interesting ideas relating broadly to declarative
programming are encouraged. The technical program of the conference
will combine presentations of the accepted papers with invited talks
and advanced tutorials.
PPDP 2001 is part of a federation of colloquia known as Principles,
Logics and Implementations of high-level programming languages
(PLI 2001) which includes the ACM SIGPLAN International Conference on
Functional Programming (ICFP 2001) and a large number of workshops
devoted to aspects of programming languages.
The colloquia will run from 2 to 8 September, 2001. The venue for the
conference is Firenze (Florence), one of Europe's most attractive
cities, famous for its churches, galleries and museums.
More details can be found on the conference web site.
Web Sites and Email Contact:
PPDP 2001: http://music.dsi.unifi.it/pli01/ppdp
PLI 2001: http://music.dsi.unifi.it/pli01
mailto:ppdp01@cs.mu.oz.au
Important Dates:
Submission 15 March 2001
Notification 7 May 2001
Final Version 11 June 2001
Conference Chair:
Rocco De Nicola, Universita di Firenze
http://www.dsi.unifi.it/~denicola/
mailto:denicola@dsi.unifi.it
Program Chair:
Harald Sondergaard, The University of Melbourne
http://www.cs.mu.oz.au/~harald/
mailto:harald@cs.mu.oz.au
Program Committee:
Maria Alpuente, Univ. Politecnica de Valencia, ES
Yves Caseau, Bouygues, FR
Michael Codish, Ben-Gurion Univ. of the Negev, IL
Saumya Debray, Univ. of Arizona, US
Conal Elliott, Microsoft Research, US
Sandro Etalle, Univ. Maastricht, NL
Roberto Giacobazzi, Univ. di Verona, IT
Michael Leuschel, Univ. of Southampton, GB
John Lloyd, Australian National Univ., AU
Torben Mogensen, Kobenhavns Univ., DK
Alan Mycroft, Cambridge Univ., GB
Gopalan Nadathur, Univ. of Minnesota, US
Martin Odersky, Ecole Polyt. Fed. Lausanne, CH
Catuscia Palamidessi, Penn State Univ., US
Andreas Podelski, Max-Planck-Inst. Informatik, DE
Kostis Sagonas, Uppsala Univ., SE
Christian Schulte, Univ. des Saarlandes, DE
Michael Schwartzbach, Aarhus Univ., DK
Harald Sondergaard, Univ. of Melbourne, AU
Peter J. Stuckey, Univ. of Melbourne, AU
From slucas@dsic.upv.es Thu Jan 18 10:59:43 2001
From: slucas@dsic.upv.es (Salvador Lucas Alba)
Date: Thu, 18 Jan 2001 11:59:43 +0100
Subject: WRS'2001 - First call for papers
Message-ID: <3A66CC9D.73206BC3@dsic.upv.es>
[Apologies for multiple copies of this announcement]
**************************************************************
*************** first call for papers and participation
****************
**************************************************************
International Workshop on Reduction Strategies in Rewriting and
Programming (WRS 2001)
http://www.logic.at/wrs01/
held in conjunction with RTA 2001
Utrecht, The Netherlands, May 26, 2001
--------------------------------------------------------------------------
BACKGROUND AND AIMS
Reduction strategies in rewriting and programming have attracted an
increasing attention within the last years. New types of reduction
strategies have been invented and investigated, and new results on
rewriting / computation under particular strategies have
been obtained. Research in this field ranges from primarily
theoretical
questions about reduction strategies to very practical application and
implementation issues. The need for a deeper understanding of
reduction
strategies in rewriting and programming, both in theory and practice,
is obvious, since they bridge the gap between unrestricted general
rewriting (computation) and (more deterministic) rewriting with
particular strategies (programming). Moreover, reduction strategies
provide a natural way to go from operational principles (e.g., graph
and term rewriting, narrowing, lambda-calculus) and semantics (e.g.,
normalization, computation of values, infinitary normalization,
head-normalization) to implementations of programming
languages.
Therefore any progress in this area is likely to be of interest not
only to the rewriting community, but also to neighbouring fields like
functional programming, functional-logic programming, and termination
proofs of algorithms.
The workshop wants to provide a forum for the presentation and
discussion of new ideas and results, recent developments, new research
directions, as well as of surveys on existing knowledge in this
area. Furthermore we aim at fostering interaction and exchange between
researchers and students actively working on such topics.
The workshop will be held in conjunction with RTA 2001 in Utrecht (The
Netherlands) on May 26, 2001. It will feature 2 invited talks, a panel
discussion, and contributed presentations selected from the
submissions, with ample time for discussion.
The workshop is (co-)organized by U Utrecht, TU Valencia and TU Wien.
TOPICS OF INTEREST
Topics of interest include, but are not restricted to,
- theoretical foundations for the definition and semantic description
of reduction strategies
- strategies in different frameworks (term rewriting, graph rewriting,
infinitary rewriting, lambda calculi, higher order rewriting,
conditional rewriting, rewriting with built-ins, narrowing,
constraint solving, etc.) and their application in (equational,
functional, functional-logic) programming (languages)
- properties of reduction strategies / computations under
strategies (e.g., completeness, computability, decidability,
complexity, optimality, (hyper-)normalization, cofinality,
fairness, perpetuality, context-freeness, neededness, lazyness,
eagerness, strictness)
- interrelations, combinations and applications of
reduction under different strategies (e.g., equivalence
conditions for fundamental properties like termination and
confluence, applications in modularity analysis, connections
between strategies of different frameworks, etc.)
- program analysis and other semantics-based optimization techniques
dealing with reduction strategies
- rewrite systems / tools / implementations with flexible /
programmable strategies as essential concept / ingredient
- specification of reduction strategies in (real) languages
- data structures and implementation techniques for reduction
strategies.
SUBMISSIONS
We solicit papers on all aspects of reduction strategies in
rewriting and programming. Submissions should describe unpublished
work, except for survey papers which are explicitly welcome,
too. Submissions should not exceed 10 pages (however, survey papers
may be longer) and be sent in postscript format to the PC co-chairs
(wrs01@logic.at) by March 1, 2001. Selection of papers by the PC
will be based on originality, significance, and correctness.
Accepted papers will be included in the workshop proceedings that will
be available at the workshop, and electronically on the web.
Depending on the number and quality of submissions, formal publication
of the proceedings is envisaged.
Researchers just interested in attending the workshop may send a
corresponding email to wrs01@logic.at by March 1, 2001, preferably
together with a brief position paper (up to two pages in postscript)
describing their interest and/or work in the area. However, we will
also consider late requests for attendance.
INVITED TALKS
Richard Kennaway (UEA Norwich, UK):
(to be confirmed)
Eelco Visser (U Utrecht, The Netherlands):
A Survey of Strategies in Program Transformation Systems
PANEL DISCUSSION on ``Hot Topics in Reduction Strategies'' with
Michael Hanus U Kiel (Germany)
Tetsuo Ida U Tsukuba (Japan)
Paul Klint (to be confirmed) CWI & U Amsterdam (The Netherlands)
PROGRAM COMMITTEE
Maria Alpuente TU Valencia (Spain)
Rachid Echahed IMAG Grenoble (France)
Bernhard Gramlich (co-chair) TU Wien (Austria)
Salvador Lucas (co-chair) TU Valencia (Spain)
Vincent van Oostrom U Utrecht (The Netherlands)
Rinus Plasmeijer KU Nijmegen (The Netherlands)
Manfred Schmidt-Schauss U Frankfurt a.M. (Germany)
Yoshihito Toyama U Tohoku (Japan)
LOCAL ORGANIZATION
Vincent van Oostrom U Utrecht (The Netherlands)
IMPORTANT DATES
Submission March 1, 2001
Notification March 31, 2001
Final version April 30, 2001
Workshop May 26, 2001
FURTHER INFORMATION
workshop website http://www.logic.at/wrs01/
workshop email address wrs01@logic.at
**************************************************************************
From iscp9157@nus.edu.sg Thu Jan 18 13:16:03 2001
From: iscp9157@nus.edu.sg (Saswat Anand)
Date: Thu, 18 Jan 2001 21:16:03 +0800
Subject: A simple problem
Message-ID: <834541D9D742D211A18F0000F81E6921016E3797@exs27.comp.nus.edu.sg>
class C a where
fun :: a -> Integer
instance C Integer where
fun x = x+ 1
with these definitons:
fun 3 --gives error in Hugs
fun (3::Integer) -- OK
I am a building an embedded language, so don't want user to cast. Is there a
solution?
Thanks,
Saswat
From igloo@earth.li Thu Jan 18 15:52:08 2001
From: igloo@earth.li (Ian Lynagh)
Date: Thu, 18 Jan 2001 15:52:08 +0000
Subject: MD5 in Haskell
In-Reply-To: <20010117191140.A26059@stu163.keble.ox.ac.uk>; from igloo@earth.li on Wed, Jan 17, 2001 at 07:11:40PM +0000
References: <20010117191140.A26059@stu163.keble.ox.ac.uk>
Message-ID: <20010118155208.A31131@stu163.keble.ox.ac.uk>
On Wed, Jan 17, 2001 at 07:11:40PM +0000, Ian Lynagh wrote:
>
> I've put the code at http://c93.keble.ox.ac.uk/~ian/md5/
>
> License is GPL.
0.1.1 now there which changes the license to GPL/BSD so it can be used
as a drop-in replacement for the GHC code.
Ian
From burton@sfu.ca Thu Jan 18 22:53:00 2001
From: burton@sfu.ca (F. Warren Burton)
Date: Thu, 18 Jan 2001 14:53:00 -0800
Subject: Student Cheating?
Message-ID:
How many readers of this list got a copy of the following? Did
somebody reading this list assign this problem?
Warren
>X-Originating-IP: [194.83.240.16]
>From: "Rachael Maguire"
>To: burton@cs.sfu.ca
>Subject: haskell programming problem
>Date: Thu, 18 Jan 2001 21:21:25 -0000
>X-OriginalArrivalTime: 18 Jan 2001 21:21:25.0578 (UTC)
>FILETIME=[9D03AAA0:01C08194]
>
>I come across your e-mail address via the haskell.org website. I am
>having some difficulty with the language and am wondering if you can
>help due to your programming experience in Haskell. Could you write
>me a small program to count the number of words and characters from
>a string (the strings contents would be specified in the script
>containing the Haskell code for this mall program). Also the program
>must justify the string. Could you send me some code for a program
>of this kind as I do not know any people with experience of Haskell
>programming .
>
>Any help would be much appreciated.
>Thanks in advance Rachael.
>_________________________________________________________________________
>Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
From ashley@semantic.org Thu Jan 18 23:38:10 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Thu, 18 Jan 2001 15:38:10 -0800
Subject: A simple problem
Message-ID: <200101182338.PAA16529@mail4.halcyon.com>
At 2001-01-18 05:16, Saswat Anand wrote:
>class C a where
> fun :: a -> Integer
>
>instance C Integer where
> fun x = x+ 1
>
>with these definitons:
>
>fun 3 --gives error in Hugs
>fun (3::Integer) -- OK
>
>I am a building an embedded language, so don't want user to cast. Is there a
>solution?
3 is not always an Integer. It's of type "(Num a) => a".
I couldn't find a way to say that every Num is a C.
--
Ashley Yakeley, Seattle WA
From ashley@semantic.org Fri Jan 19 00:08:07 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Thu, 18 Jan 2001 16:08:07 -0800
Subject: A simple problem
Message-ID: <200101190008.QAA20452@mail4.halcyon.com>
At 2001-01-18 15:38, I wrote:
>3 is not always an Integer. It's of type "(Num a) => a".
Of course, it would be nice if 3 were an Integer, and Integer were a
subtype of Real. I haven't come across a language that does this, where
for instance 3.0 can be cast to Integer (because it is one) but 3.1
cannot be.
--
Ashley Yakeley, Seattle WA
From paul.hudak@yale.edu Fri Jan 19 13:30:37 2001
From: paul.hudak@yale.edu (Paul Hudak)
Date: Fri, 19 Jan 2001 08:30:37 -0500
Subject: Student Cheating?
References:
Message-ID: <3A68417D.423FF396@yale.edu>
> How many readers of this list got a copy of the following? Did
> somebody reading this list assign this problem?
I just got a copy of her message, similar to yours, but with a bunch of
code at the end that looks well written, so clearly it wasn't hers. But
she still couldn't get it to work, and asked, "Could you give me some
code to add to the end of the code below." :-) Pretty sad, despite the
smiley.
-Paul
From jans@numeric-quest.com Fri Jan 19 16:52:58 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Fri, 19 Jan 2001 11:52:58 -0500 (EST)
Subject: Haskell Module Browser with code
In-Reply-To:
Message-ID:
Classes available from the description page at
http://www.numeric-quest.com/haskell/explorer/browser.html
Works in Squeak. Supports Hugs and NHC. Support for other
environments is planned. Hugs Module Browser is good only for
Linux/Unix users due to current lack of a support for pipes
and processes in Mac/Windows. NHC Module Browser should work
in any environment since it does not need to communicate with
external processes.
This is the interim release, far from being finished, not
optimized, with some glitches and unfinished design.
Jan
From igloo@earth.li Sat Jan 20 21:17:43 2001
From: igloo@earth.li (Ian Lynagh)
Date: Sat, 20 Jan 2001 21:17:43 +0000
Subject: Doing IO in foldr repeats lines?
Message-ID: <20010120211743.A27515@stu163.keble.ox.ac.uk>
Hi all
The following code:
> module Main (main) where
> import IO
> main :: IO()
> main = do _ <- foldl foo (return 14) ["qq\n", "ww\n", "ee\n"]
> putStr ""
> foo :: IO Int -> String -> IO Int
> foo io_l s = do l <- io_l
> () <- putStr s
> io_l
prints (with both GHC and hugs):
qq
ww
qq
ee
qq
ww
qq
and I really don't understand why. Is the code re-evaluated every time
foldl is expanded or something?
Thanks
Ian, confused
From p.turner@computer.org Sat Jan 20 22:08:48 2001
From: p.turner@computer.org (Scott Turner)
Date: Sat, 20 Jan 2001 17:08:48 -0500
Subject: Doing IO in foldr repeats lines?
In-Reply-To: <20010120211743.A27515@stu163.keble.ox.ac.uk>
Message-ID: <3.0.5.32.20010120170848.00bb4330@mail.billygoat.org>
At 21:17 2001-01-20 +0000, Ian Lynagh wrote:
> main = do _ <- foldl foo (return 14) ["qq\n", "ww\n", "ee\n"]
> putStr ""
>
> foo :: IO Int -> String -> IO Int
> foo io_l s = do l <- io_l
> () <- putStr s
> io_l
It repeats lines
>and I really don't understand why. Is the code re-evaluated every time
>foldl is expanded or something?
Since the result type of foo is IO Int, it is building an IO action, in
other words it is calculating a sequence of effects. The combined effects
are performed by main.
Repetition occurs due to the structure of foo. Notice that its action
consists of first performing io_l, then putting a string, and then
performing io_l _again_. If io_l prints the lines qq, ww, and qq, then the
result will involve two such triplets.
Try this. Remove either of the occurrences of io_l from the do block, and
you will see quite different results.
--
Scott Turner
p.turner@computer.org http://www.billygoat.org/pkturner
From igloo@earth.li Sat Jan 20 22:25:18 2001
From: igloo@earth.li (Ian Lynagh)
Date: Sat, 20 Jan 2001 22:25:18 +0000
Subject: Doing IO in foldr repeats lines?
In-Reply-To: <3.0.5.32.20010120170848.00bb4330@mail.billygoat.org>; from p.turner@computer.org on Sat, Jan 20, 2001 at 05:08:48PM -0500
References: <20010120211743.A27515@stu163.keble.ox.ac.uk> <3.0.5.32.20010120170848.00bb4330@mail.billygoat.org>
Message-ID: <20010120222518.A27778@stu163.keble.ox.ac.uk>
On Sat, Jan 20, 2001 at 05:08:48PM -0500, Scott Turner wrote:
> At 21:17 2001-01-20 +0000, Ian Lynagh wrote:
> > main = do _ <- foldl foo (return 14) ["qq\n", "ww\n", "ee\n"]
> > putStr ""
> >
> > foo :: IO Int -> String -> IO Int
> > foo io_l s = do l <- io_l
> > () <- putStr s
> > io_l
>
> It repeats lines
> >and I really don't understand why. Is the code re-evaluated every time
> >foldl is expanded or something?
>
> Since the result type of foo is IO Int, it is building an IO action, in
> other words it is calculating a sequence of effects. The combined effects
> are performed by main.
Thanks, a private mail showing the evaluation highlighted my stupidity
wonderfully :-)
I now see what's going on and a return l instead of io_l as the last
line is what I wanted. The mixture of io_l and return bar also explains
why I was seeing really random looking output unlike the nice pattern
of the more minimal case :-)
Thanks
Ian
From simonpj@microsoft.com Sat Jan 20 13:09:58 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Sat, 20 Jan 2001 05:09:58 -0800
Subject: Combinator library gets software prize
Message-ID: <74096918BE6FD94B9068105F877C002D0137874B@red-pt-02.redmond.corp.microsoft.com>
You might enjoy this article, in Risk Magazine, a journal
of the financial engineering industry. Combinators in the real
world!
http://www.risk.net/riskawards2001/softwareproduct.htm
Simon
From guerby@acm.org Sun Jan 21 10:31:37 2001
From: guerby@acm.org (Laurent Guerby)
Date: Sun, 21 Jan 2001 11:31:37 +0100
Subject: Combinator library gets software prize
Message-ID: <200101211031.LAA01147@ulmo>
I don't know if Simon mentionned it but I found his & al. paper
proceedings of the fifth ACM SIGPLAN international conference on on
Functional programming, "Composing contracts: an adventure in
financial engineering (functional pearl) Pages 280-292" very
interesting:
http://www.acm.org/pubs/citations/proceedings/fp/351240/p280-jones/
--
Laurent Guerby
From davidbak@microsoft.com Sun Jan 21 18:57:19 2001
From: davidbak@microsoft.com (David Bakin)
Date: Sun, 21 Jan 2001 10:57:19 -0800
Subject: Combinator library gets software prize
Message-ID: <6605DE4621E5934593474F620A14D700CC0A87@red-msg-07.redmond.corp.microsoft.com>
This article is very good, and having read the conference paper earlier
in the year I finished it with only one question: What's a 'quant' ...
and is it good or bad to be one?
"Ten years ago, Jean-Marc Eber, then a quant at Soci=E9t=E9
G=E9n=E9rale, ..."
-- Dave
-----Original Message-----
From: Simon Peyton-Jones
Sent: Saturday, January 20, 2001 5:10 AM
To: haskell@haskell.org
Subject: Combinator library gets software prize
You might enjoy this article, in Risk Magazine, a journal
of the financial engineering industry. Combinators in the real
world!
http://www.risk.net/riskawards2001/softwareproduct.htm
=20
Simon
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
=20
From ashley@semantic.org Sun Jan 21 22:55:43 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Sun, 21 Jan 2001 14:55:43 -0800
Subject: Combinator library gets software prize
Message-ID: <200101212255.OAA09629@mail4.halcyon.com>
At 2001-01-21 10:57, David Bakin wrote:
>What's a 'quant' ...
>and is it good or bad to be one?
I think that depends on exactly how much of a quant you are.
--
Ashley Yakeley, Seattle WA
From jf15@hermes.cam.ac.uk Mon Jan 22 10:55:03 2001
From: jf15@hermes.cam.ac.uk (Jon Fairbairn)
Date: Mon, 22 Jan 2001 10:55:03 +0000 (GMT)
Subject: Combinator library gets software prize
In-Reply-To: <6605DE4621E5934593474F620A14D700CC0A87@red-msg-07.redmond.corp.microsoft.com>
Message-ID:
On Sun, 21 Jan 2001, David Bakin wrote:
> This article is very good, and having read the conference paper earlier
> in the year I finished it with only one question: What's a 'quant' ...
> and is it good or bad to be one?
>=20
> "Ten years ago, Jean-Marc Eber, then a quant at Soci=E9t=E9
> G=E9n=E9rale, ..."
The OED has:
1. A pole for propelling a barge, esp. one with a cap at
the top and a prong at the bottom to
prevent it from sinking in mud. Also attrib., as quant-pole.
and
2. In a windmill:=20
1924 Trans. Newcomen Soc. III. 42 All the framing and
gearing of these mills are of wood, the only important parts
of iron being the wrought iron gudgeons upon which the
shafts revolve, and perhaps the `quants' or spindles which
drove the runner stones.
So perhaps he was tall, thin and fond of wearing a cap?
:-)
--=20
J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.uk
31 Chalmers Road jf@cl.cam.ac.uk
Cambridge CB1 3SZ +44 1223 570179 (pm only, please)
From john@launchbury.org Mon Jan 22 11:43:16 2001
From: john@launchbury.org (John Launchbury)
Date: Mon, 22 Jan 2001 11:43:16 +0000
Subject: fixity for (\\)
References:
Message-ID: <3A6C1CD4.586B550D@launchbury.org>
I agree with Koen: \\ is list subtraction and we're all used to subtraction being left associative.
John.
Jon Fairbairn wrote:
>
> On Wed, 17 Jan 2001, Koen Claessen wrote:
> > I propose that it gets the following fixity:
> >
> > infixl 5 \\
>
> Unless the it's common usage outside of Haskell, I oppose!
>
> Getting
>
> List> [1,2,3]\\[2]\\[3]
> ERROR: Ambiguous use of operator "(\\)" with "(\\)"
>
> at compile time does no harm, but getting [1] instead of
> [1,3] _at run time_ does do harm.
> Jón
> --
> Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
> 31 Chalmers Road jf@cl.cam.ac.uk
> Cambridge CB1 3SZ +44 1223 570179 (pm only, please)
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From C.Reinke@ukc.ac.uk Mon Jan 22 13:45:12 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Mon, 22 Jan 2001 13:45:12 +0000
Subject: Combinator library gets software prize
Message-ID:
> > This article is very good, and having read the conference paper earlier
> > in the year I finished it with only one question: What's a 'quant' ...
> > and is it good or bad to be one?
> >
> > "Ten years ago, Jean-Marc Eber, then a quant at Société
> > Générale, ..."
>
> The OED has:
..
> So perhaps he was tall, thin and fond of wearing a cap?
>
> :-)
You might want to try
http://www.dictionary.com/cgi-bin/dict.pl?term=quant
An expert in the use of mathematics and related subjects,
particularly in investment management and stock trading.
...
http://www.investorwords.com/q1.htm#quant
One who performs quantitative analyses. Or more generally, a
securities analyst.
Am I the only one who finds the exclusive emphasis on combinator
languages slightly disappointing (in fact, the article seems to equate
functional language with domain-specific combinator languages, which is
more than a bit mistleading)?
This is a Haskell forum, not one on Backus' FP, so readers are well
aware of the advantages of functional abstraction. Domain-specific
languages, if embedded in Haskell, tend to inherit these advantages,
even if the language in question was designed as a pure combinator
language.
The consequence (and the intention, as far as one can gather from the
paper) of the limitation to combinators is that this language can and
will be used mainly in non-functional languages, not inheriting all
that much from a functional style of programming. The same will
probably hold for any communication standards based on it.
This appplication is undoubtely a success and a good step forward,
but there is more to functional languages.
The paper somewhat downplays the role of embedding the combinator-based
DSL in a full functional language while also mentioning that some
features gained for free in the Haskell prototype considerably
complicate implementations in other languages. I would be interested
to hear more about these aspects:
- Is the strictly combinator-based approach a pragmatic necessity
("one step at a time") or is there no need for more advanced
features (especially abstraction) in the application area?
- Has there been a comparison of the way the combinators of the
DSL are used in Haskell and in other implementations?
I would think that the use of abstraction to define more complex
instruments in terms of the basic combinators should play a rather
dominant role. On the other hand, I can imagine that users would
want to have each complex instrument explicitly named and studied,
instead of trusting large amounts of money to anonymous
abstractions created on-the-fly.
- What about interactive exploration of new instruments, e.g., in a
Hugs or OCaml session (as opposed to changing a C++ implementation,
or a stand-alone executable generated by an OCaml compiler, for
every experiment)?
Claus
From Keith.Wansbrough@cl.cam.ac.uk Mon Jan 22 16:42:32 2001
From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough)
Date: Mon, 22 Jan 2001 16:42:32 +0000
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
In-Reply-To: Your message of "Tue, 16 Jan 2001 14:04:22 PST."
<20010116140422.A5586@mark.ugcs.caltech.edu>
Message-ID:
> With all this talk of preprocessor generated information and whatnot, I
> am reminded of a paper I read not too long ago but can't seem to find
> anymore about a dedicated pre-processor for haskell based on the C
> preprocessor but made to deal with haskell constructs a bit more sanely.
This was me...
http://www.cl.cam.ac.uk/~kw217/research/papers.html#Wansbrough99:Macros
There wasn't sufficient interest, and no one has offered to implement
it. I think people are mostly happy using CPP, and the hassle of
writing a `decent' macro preprocessor isn't worth it. You may find
some of the ideas in the paper useful, though.
--KW 8-)
From EricShade@smsu.edu Mon Jan 22 17:19:42 2001
From: EricShade@smsu.edu (Eric Shade)
Date: Mon, 22 Jan 2001 11:19:42 -0600
Subject: Specifications of 'any', 'all', 'findIndices'
Message-ID: <20010122111942.A9605@gandalf.smsu.edu>
I have some questions about the specifications of 'any', 'all', and
'findIndices' in the Haskell 98 reports. The specifications of 'any'
and 'all' are
any p = or . map p
all p = and . map p
While this is correct, it seems to me that it generates a lot of
garbage because map will produce a list of Booleans until 'any' sees a
True or 'all' sees a False. 'elem' and 'notElem' inherit the problem
because they're defined in terms of 'any' and 'all'. I realize that
this is only a specification, but Hugs at least uses this as its
implementation. It seems clearer and more efficient to me to use the
following definitions:
any p [] = False
any p (x:xs) = p x || any p xs
all p [] = True
all p (x:xs) = p x && all p xs
leave 'elem' and 'notElem' as is, then define
and = notElem False
or = elem True
There is a similar problem with findIndices, whose specification is
findIndices p xs = [i | (x,i) <- zip xs [0..], p x]
While this is admittedly cool, it also seems to generate a lot of
garbage by producing pairs only to throw them away.
I'm not yet up to speed on the implementation of lazy functional
languages, so it may be that in all of these cases the compiler can
easily optimize away the garbage. If so, it would be nice to see some
documentation for non-wizards that explains what kinds of
optimizations one can reasonably expect (like tail-recursion
elimination in Scheme).
Even if the apparent inefficiencies melt away, I think that my
versions of 'any', 'all', 'and', and 'or' are clearer as specification
than the current ones.
--
Dr. Eric Shade, Associate Professor
Computer Science Department (CSAB Accredited)
Southwest Missouri State University
From uk1o@rz.uni-karlsruhe.de Mon Jan 22 21:29:50 2001
From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter)
Date: Mon, 22 Jan 2001 22:29:50 +0100
Subject: Specifications of 'any', 'all', 'findIndices'
In-Reply-To: <20010122111942.A9605@gandalf.smsu.edu>; from EricShade@smsu.edu on Mon, Jan 22, 2001 at 11:19:42AM -0600
References: <20010122111942.A9605@gandalf.smsu.edu>
Message-ID: <20010122222950.A27606@rz.uni-karlsruhe.de>
Hello!
On Mon, Jan 22, 2001 at 11:19:42AM -0600, Eric Shade wrote:
> I have some questions about the specifications of 'any', 'all', and
> 'findIndices' in the Haskell 98 reports. The specifications of 'any'
> and 'all' are
> any p = or . map p
> all p = and . map p
> While this is correct, it seems to me that it generates a lot of
> garbage because map will produce a list of Booleans until 'any' sees a
> True or 'all' sees a False. 'elem' and 'notElem' inherit the problem
> because they're defined in terms of 'any' and 'all'. I realize that
> this is only a specification, but Hugs at least uses this as its
> implementation. It seems clearer and more efficient to me to use the
> following definitions:
> any p [] = False
> any p (x:xs) = p x || any p xs
> all p [] = True
> all p (x:xs) = p x && all p xs
> leave 'elem' and 'notElem' as is, then define
> and = notElem False
> or = elem True
> There is a similar problem with findIndices, whose specification is
> findIndices p xs = [i | (x,i) <- zip xs [0..], p x]
> While this is admittedly cool, it also seems to generate a lot of
> garbage by producing pairs only to throw them away.
> I'm not yet up to speed on the implementation of lazy functional
> languages, so it may be that in all of these cases the compiler can
> easily optimize away the garbage. If so, it would be nice to see some
> documentation for non-wizards that explains what kinds of
> optimizations one can reasonably expect (like tail-recursion
> elimination in Scheme).
Depends on the implementation. GHC might remove some of the garbage,
at least, see the GHC documentation ("good producers"/"good consumers"/
"cheap deforestation").
> Even if the apparent inefficiencies melt away, I think that my
> versions of 'any', 'all', 'and', and 'or' are clearer as specification
> than the current ones.
I don't think so. The specifications are quite concise.
Kind regards,
Hannah.
From timd@macquarie.com.au Mon Jan 22 22:05:02 2001
From: timd@macquarie.com.au (Timothy Docker)
Date: Tue, 23 Jan 2001 09:05:02 +1100 (EST)
Subject: Combinator library gets software prize
In-Reply-To:
References:
Message-ID: <14956.44093.496758.105263@tcc2>
> Am I the only one who finds the exclusive emphasis on combinator
> languages slightly disappointing (in fact, the article seems to equate
> functional language with domain-specific combinator languages, which is
> more than a bit mistleading)?
What declarative approach(es) (other than combinators) are you
referring to here?
> The consequence (and the intention, as far as one can gather from the
> paper) of the limitation to combinators is that this language can and
> will be used mainly in non-functional languages, not inheriting all
> that much from a functional style of programming. The same will
> probably hold for any communication standards based on it.
Why is that? I'm new to the functional programming world, and haven't
reallystruck the concept of combinator libraries elsewhere. I assumed
they were largely a functional programming concept. Even though I can
see how they could be implemented in imperative languages, it doesn't
seem that they would be a nice fit.
> [Several interesting elided]
More generally, is there any more information or forums on declarative
approaches to financial engineering? I found this paper intriguing, as
it focuses on both my current academic interests, and my work!
Tim
From joe@isun.informatik.uni-leipzig.de Tue Jan 23 07:28:41 2001
From: joe@isun.informatik.uni-leipzig.de (Johannes Waldmann)
Date: Tue, 23 Jan 2001 08:28:41 +0100 (MET)
Subject: Specifications of 'any', 'all', 'findIndices'
In-Reply-To: <20010122111942.A9605@gandalf.smsu.edu> from Eric Shade at "Jan
22, 2001 11:19:42 am"
Message-ID: <200101230728.IAA05394@isun11.informatik.uni-leipzig.de>
I think a specification
> any p = or . map p
is much more concise than the implementation
> any p [] = False
> any p (x:xs) = p x || any p xs
another reason to prefer the higher-level variant
is that the compiler can apply fusion laws, as in
any p . map f = or . map p . map f = or . map (p . f)
(one could also do this starting from the second definition,
but then the compiler's first step would be to derive the
higher-level version from it, I guess)
so it's not at all clear that the above implementation
is indeed more efficient.
I'd rather write clear code, than worry about efficiency too early.
Who said this, "premature optimization is the root of all evil".
best regards
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From karczma@info.unicaen.fr Tue Jan 23 09:50:37 2001
From: karczma@info.unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 23 Jan 2001 09:50:37 +0000
Subject: Specifications of 'any', 'all', 'findIndices'
References: <20010122111942.A9605@gandalf.smsu.edu> <20010122222950.A27606@rz.uni-karlsruhe.de>
Message-ID: <3A6D53ED.DB42F72C@info.unicaen.fr>
Hannah Schroeter wrote:
> Eric Shade wrote:
> > I have some questions about the specifications of 'any', 'all', and
> > 'findIndices'
...
> > any p = or . map p
> > all p = and . map p
> > ...It seems clearer and more efficient to me to use the
> > following definitions:
>
> > any p [] = False
> > any p (x:xs) = p x || any p xs
>
> > all p [] = True
> > all p (x:xs) = p x && all p xs
...
> > Even if the apparent inefficiencies melt away, I think that my
> > versions of 'any', 'all', 'and', and 'or' are clearer as
> > specification
> > than the current ones.
>
> I don't think so. The specifications are quite concise.
> Hannah.
Just a moment, please. Do we speak about "concise" or "clear"?
Johannes Waldman makes the same fusion, first saying that it
is concise, and terminating with a statement on clear programming.
Personally I am a convinced lazy programmer, I adore concise
and obfuscated style, and I used with some internal pleasure the
original definitions, until I started using Haskell for teaching.
(I do not teach Haskell, we *use* it on compilation stuff, some-
times on some graphics projects, and they have to learn it
"off-line".) THREE TIMES I've been asked about that. Somebody
quite clever remarked that any or all are *typical* cases for
fold rather than for map.
There is plenty of historical accidents in the standard prelude.
[I won't complain any more about the Num stuff...]
Johannes Waldmann last sentence:
> Who said this, "premature optimization is the root of all evil".
Who said that what Eric Shade proposes is an evil optimization,
while a curried "pearl": "any p = or . map p" is a nice shorthand,
plenty of vitamines, especially for beginners.
BTW., why not promote something like
any = (or .) . map
to make everybody happy?
Jerzy Karczmarczuk
Caen, France
PS. Johannes Waldman raises some doubts:
> so it's not at all clear that the above implementation
> is indeed more efficient.
Please, don't speculate. If you have something to say in this
context, perform some tests. I did it with Hugs. Eric Shade
implementation seems to be indeed more efficient, but very
slightly (on my test, I won't claim anything general).
From koen@cs.chalmers.se Tue Jan 23 11:30:12 2001
From: koen@cs.chalmers.se (Koen Claessen)
Date: Tue, 23 Jan 2001 12:30:12 +0100 (MET)
Subject: Specifications of 'any', 'all', 'findIndices'
In-Reply-To: <20010122111942.A9605@gandalf.smsu.edu>
Message-ID:
Eric Shade wondered:
| I have some questions about the specifications of
| 'any', 'all', and 'findIndices' in the Haskell 98
| reports. [...] it seems to me that it generates a lot
| of garbage because map will produce a list of Booleans
| [...]
Several people have already commented on this. What I want
to add is the following.
The definitions in the Haskell report are a *specification*,
not an implementation. It probably depends on the compiler
which particular implementation runs faster.
Therefore, the Haskell report provides a clear (yes, this is
debatable) *possible* implementation, and the compiler
writer is free to implement this in whatever way (s)he
likes. As long as the implementation has the same functional
behavior as the specification in the report.
/Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
From lisper@it.kth.se Tue Jan 23 11:43:28 2001
From: lisper@it.kth.se (Bjorn Lisper)
Date: Tue, 23 Jan 2001 12:43:28 +0100 (MET)
Subject: Specifications of 'any', 'all', 'findIndices'
In-Reply-To:
(message from Koen Claessen on Tue, 23 Jan 2001 12:30:12 +0100 (MET))
References:
Message-ID: <200101231143.MAA06886@dentex.it.kth.se>
Koen:
>The definitions in the Haskell report are a *specification*,
>not an implementation. It probably depends on the compiler
>which particular implementation runs faster.
>Therefore, the Haskell report provides a clear (yes, this is
>debatable) *possible* implementation, and the compiler
>writer is free to implement this in whatever way (s)he
>likes. As long as the implementation has the same functional
>behavior as the specification in the report.
Hear, hear. What I in turn would like to add is that specifications like
any p = or . map p
are on a higher level of abstraction than definitions like
any p [] = False
any p (x:xs) = p x || any p xs
This makes it easier to find different implementations, which makes it
easier to adapt the implementation to fit different architectures. The first
specification is, for instance, directly data parallel which facilitates an
implementation on a parallel machine or in hardware.
Björn Lisper
From karczma@info.unicaen.fr Tue Jan 23 13:09:59 2001
From: karczma@info.unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 23 Jan 2001 13:09:59 +0000
Subject: Specifications of 'any', 'all', 'findIndices'
References: <200101231143.MAA06886@dentex.it.kth.se>
Message-ID: <3A6D82A7.89B28D3@info.unicaen.fr>
Koen Claessen wrote:
(about the definitions of any, all, etc.)
> The definitions in the Haskell report are a *specification*,
> not an implementation. It probably depends on the compiler
> which particular implementation runs faster.
>
> Therefore, the Haskell report provides a clear (yes, this is
> debatable) *possible* implementation, and the compiler
> writer is free to implement this in whatever way (s)he
> likes. As long as the implementation has the same functional
> behavior as the specification in the report.
I am sorry, but
any p = or . map p
is not an implementation-neutral specification, a
*functional* specification. This is a very concrete way
of doing things. As everybody knows, this is a folding process.
Of course, 'or' uses (normally, again, according to the Report
if I am not mistaken) 'foldr', and it is essentially trivial
to get rid of 'map', putting (||) and 'p' together in the
fold function, but:
1. Perhaps it is too optimistic to think that the compilers will
to that optimisation by themselves. Hugs uses literally this
"specification"
2. I maintain my opinion that from the pedagogical point of view
this definition is imperfect. I think that the specification
should say no more nor less what 'any', 'notElem' etc. functions
provide, and put (possibly) in the Report that possible
implementations are (...)
But the generation of this "garbage", the intermediate list of
booleans, whether real or virtual only, goes beyond the semantics
of 'all', etc.
As Koen said, several people already commented on that.
And, I am afraid that this will continue. I can promise
you that...
Bjorn Lisper adds:
> ... What I in turn would like to add is that specifications like
>
> any p = or . map p
>
> are on a higher level of abstraction than definitions like
>
> any p [] = False
> any p (x:xs) = p x || any p xs
>
> This makes it easier to find different implementations, which makes it
> easier to adapt the implementation to fit different architectures.
> The first specification is, for instance, directly data parallel
> which facilitates an implementation on a parallel machine or in hardware.
>
> Björn Lisper
Pardon?
map is data parallel. foldr not so obviously...
I am not sure about this higher level of abstraction. Unless, of course,
we want to use generalized, monadic maps, but then, also folds. And
we will produce, say, trees of boolean garbage instead of lists.
Jerzy Karczmarczuk
From lisper@it.kth.se Tue Jan 23 12:52:41 2001
From: lisper@it.kth.se (Bjorn Lisper)
Date: Tue, 23 Jan 2001 13:52:41 +0100 (MET)
Subject: Specifications of 'any', 'all', 'findIndices'
In-Reply-To: <3A6D82A7.89B28D3@info.unicaen.fr> (message from Jerzy
Karczmarczuk on Tue, 23 Jan 2001 13:09:59 +0000)
References: <200101231143.MAA06886@dentex.it.kth.se> <3A6D82A7.89B28D3@info.unicaen.fr>
Message-ID: <200101231252.NAA06959@dentex.it.kth.se>
>Pardon?
>map is data parallel. foldr not so obviously...
Sorry, a slip on my behalf: foldr in general is not data parallel, but if
the function being folded with is associative then foldr can be implemented
by a parallel (balanced binary-tree) reduction in time O(log n), where n is
the length of the list.
A compiler needs the information that or is a fold over an associative
operation in order to employ such a parallel implementation.
Björn Lisper
From rossberg@ps.uni-sb.de Tue Jan 23 14:04:40 2001
From: rossberg@ps.uni-sb.de (Andreas Rossberg)
Date: Tue, 23 Jan 2001 15:04:40 +0100
Subject: Doing IO in foldr repeats lines?
References: <20010120211743.A27515@stu163.keble.ox.ac.uk>
Message-ID: <3A6D8F78.44784113@ps.uni-sb.de>
Ian Lynagh wrote:
>
> > main :: IO()
> > main = do _ <- foldl foo (return 14) ["qq\n", "ww\n", "ee\n"]
> > putStr ""
>
> > foo :: IO Int -> String -> IO Int
> > foo io_l s = do l <- io_l
> > () <- putStr s
> > io_l
>
> prints (with both GHC and hugs):
>
> qq
> ww
> qq
> ee
> qq
> ww
> qq
>
> and I really don't understand why. Is the code re-evaluated every time
> foldl is expanded or something?
Nobody seems to have answered yet, so I try to explain it.
Look at your definition of foo: it actually duplicates its argument
action io_l. For the first application io_l is (return 14). Let's call
that io_l0. The resulting action is
io_l1 = do { l <- return 14; () <- putStr "qq"; return 14 }
which is passed at the next application. The result is
io_l2 = do { l <- do { l <- return 14; () <- putStr "qq"; return 14 }
; () <- putStr "ww"
; do { l <- return 14; () <- putStr "qq"; return 14 }
}
This can be reformulated as
io_l2'= do { l <- return 14
; () <- putStr "qq"
; l <- return 14
; () <- putStr "ww"
; l <- return 14
; () <- putStr "qq"
; return 14
}
And so on. Finally the complete action (io_l3) is executed by running
main and produces the output you observe.
Hope this helps,
- Andreas
--
Andreas Rossberg, rossberg@ps.uni-sb.de
:: be declarative. be functional. just be. ::
From mark.tullsen@yale.edu Tue Jan 23 18:11:33 2001
From: mark.tullsen@yale.edu (Mark Tullsen)
Date: Tue, 23 Jan 2001 13:11:33 -0500
Subject: Specifications of 'any', 'all', 'findIndices'
References: <200101230728.IAA05394@isun11.informatik.uni-leipzig.de>
Message-ID: <3A6DC955.1DCC97A7@yale.edu>
Johannes Waldmann wrote:
> ...
> I'd rather write clear code, than worry about efficiency too early.
> Who said this, "premature optimization is the root of all evil".
I've always attributed this to Donald Knuth:
Premature optimization is the root of all evil in programming.
Though I can't confirm it. I do find this similar statement
in his "Structured Programming with go to Statements"
(Computing Surveys 6 4, Dec 1974):
... premature emphasis on efficiency is a big mistake
which may well be the source of most programming complexity
and grief.
Note also one of Alan Perlis's epigrams:
Optimization hinders evolution.
(See http://www.cs.yale.edu/homes/perlis-alan/quotes.html)
- Mark Tullsen
From EricShade@smsu.edu Tue Jan 23 18:35:19 2001
From: EricShade@smsu.edu (Eric Shade)
Date: Tue, 23 Jan 2001 12:35:19 -0600
Subject: 'any' and 'all' compared with the rest of the Report
Message-ID: <20010123123519.A11539@gandalf.smsu.edu>
I didn't mean to get into a discussion about 'specification
vs. implementation' or 'clarity vs. conciseness', although those are
important distinctions. In my original post I didn't do a good job of
putting my objections in the proper context, so let me take one more
whack at it and then I'll leave it alone.
As a newcomer to Haskell, I read the entire Report, including all of
the purely functional code in the Prelude and Libraries (I glossed
over the monadic stuff initially). The code is not only clear as a
*specification*, but also seems perfectly suitable as a default
*implementation*. All the code seemed to have the time and space
requirements that one would expect.
Then I get to 'any' and 'all', whose specification requires linear
time and *linear* space when it should run in constant space. (By the
way, I checked and GHC does *not* use the Prelude definitions but
rather the obvious recursive ones, and most of its optimizations based
on "good consumers/producers" use meta-linguistic rewrite rules. So
without knowing the specific optimizations that a compiler provides, I
think it's safe to assume that the Prelude 'any' and 'all' *will*
require linear space.)
This is jarring; all the other code is clear *and* efficient, but
'any' and 'all' are not. I start to question whether I really
understand the language after all. (Do 'or' and 'map' work
differently than I thought? Did I misunderstand laziness? ...) After
all, why would the authors (who presumably know more about the
language than anyone on the planet) intentionally provide inefficient
code in *this* case when they provided efficient code for all the
*other* functions? This is why I don't think that the specifications
are good; they're OK in isolation but not in the context of the rest
of the Report. For me (and apparently for others), these
specifications didn't enhance my understanding; they led me to
question it.
I know that the Report clearly says that these are just
specifications, but that's one short paragraph. When I read 20 pages
of code that appears to be reasonably efficient as well, I assume that
that's by design and not accident. It would be one thing if the
Report were littered with functions whose specifications were
obviously not intended as implementations. But 'any', 'all', and
'findIndices' were the only inefficient ones I noticed out of the
entire Report.
And it's obvious that clarity is not the only goal in the
specifications. For example, why bother to write a messy O(log n)
version of x^n when the following is more clear *and* more concise?
x ^ n | n >= 0 = product (replicate n x)
_ ^ _ = error "Prelude.^: negative exponent"
Since the specifications of 'any' and 'all' are part of the Report,
they are part of the documentation for the language. They should be
judged by how well they help people understand the language. The
direct recursive versions, though slightly less concise, are equally
clear and will not cause any confusion. That's why I prefer them.
--
Dr. Eric Shade, Associate Professor
Computer Science Department (CSAB Accredited)
Southwest Missouri State University
From shlomif@vipe.technion.ac.il Tue Jan 23 18:56:49 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Tue, 23 Jan 2001 20:56:49 +0200 (IST)
Subject: Accpeting command-line arguments in GHC/Hugs
Message-ID:
How can I read the command-line arguments passed to the program. For
instance, if I run my compiled program by typing "./foo hello -o
file.txt", I wish to access the list ["hello", "-o", "file.txt"] somehow.
TIA,
Shlomi Fish
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From herrmann@infosun.fmi.uni-passau.de Tue Jan 23 19:22:07 2001
From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann)
Date: Tue, 23 Jan 2001 20:22:07 +0100 (MET)
Subject: 'any' and 'all' compared with the rest of the Report
In-Reply-To: <20010123123519.A11539@gandalf.smsu.edu>
References: <20010123123519.A11539@gandalf.smsu.edu>
Message-ID: <14957.55775.573290.221044@reger.fmi.uni-passau.de>
Hi,
Eric> use meta-linguistic rewrite rules. So without knowing the
Eric> specific optimizations that a compiler provides, I think it's
Eric> safe to assume that the Prelude 'any' and 'all' *will* require
Eric> linear space.)
I don't hope so. If (||) and (&&) are implemented short circuiting,
and = foldr (&&) True
or = foldr (||) False
"foldr", if applied lazily, will stop producing the list as soon
as the outcome is available. (This will not be possible with
"foldl" which is to be preferred for reductions with a strict
operation.) Short circuiting means that (&&) or (||) will not
force evaluation of their second argument if not necessary and
it even should mean that they drop the space for their first argument
as soon as they force evaluation of their second.
(&&) x y = if x then y else False
(||) x y = if x then True else y
should forget everything about x as soon as the case
is determined.
Laziness of "map" in
any, all :: (a -> Bool) -> [a] -> Bool
any p = or . map p
all p = and . map p
will produce the list also only as far as it is required by
"or" resp. "and".
Thus, there should be no significant efficiency differences between
the explicitly recursive definition and the "foldr" definition.
However, there is a methodical difference. Consider a data type with
10 or 20 constructors (instead of 2). Do you like always to give a
definition for each case seperately?
Christoph
--
Christoph Herrmann
E-mail: herrmann@fmi.uni-passau.de
WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html
From senganb@ia.nsc.com Tue Jan 23 19:27:08 2001
From: senganb@ia.nsc.com (Sengan)
Date: Tue, 23 Jan 2001 14:27:08 -0500
Subject: Accpeting command-line arguments in GHC/Hugs
References:
Message-ID: <3A6DDB0C.C5449A70@ia.nsc.com>
Shlomi Fish wrote:
>
> How can I read the command-line arguments passed to the program. For
> instance, if I run my compiled program by typing "./foo hello -o
> file.txt", I wish to access the list ["hello", "-o", "file.txt"] somehow.
> module Main (main) where
> import System
> main = getArgs >>= \args -> hugsMain args
> hugsMain :: [String] -> IO ()
> hugsMain = print
ghc Main.lhs
a.out foo bar --help
["foo","bar","--help"]
Sengan
From Sven.Panne@informatik.uni-muenchen.de Tue Jan 23 22:15:10 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Tue, 23 Jan 2001 23:15:10 +0100
Subject: Accpeting command-line arguments in GHC/Hugs
References:
Message-ID: <3A6E026E.F135FDFC@informatik.uni-muenchen.de>
Shlomi Fish wrote:
> How can I read the command-line arguments passed to the program. [...]
As already pointed out, System.getArgs is the basically the way to go.
If you want to use the list returned by it comfortably, see:
http://www.haskell.org/ghc/docs/latest/set/sec-util.html#SEC-GETOPT
Cheers,
Sven
From uk1o@rz.uni-karlsruhe.de Tue Jan 23 22:19:20 2001
From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter)
Date: Tue, 23 Jan 2001 23:19:20 +0100
Subject: Specifications of 'any', 'all', 'findIndices'
In-Reply-To: <3A6D53ED.DB42F72C@info.unicaen.fr>; from karczma@info.unicaen.fr on Tue, Jan 23, 2001 at 09:50:37AM +0000
References: <20010122111942.A9605@gandalf.smsu.edu> <20010122222950.A27606@rz.uni-karlsruhe.de> <3A6D53ED.DB42F72C@info.unicaen.fr>
Message-ID: <20010123231919.C21129@rz.uni-karlsruhe.de>
Hello!
On Tue, Jan 23, 2001 at 09:50:37AM +0000, Jerzy Karczmarczuk wrote:
> Hannah Schroeter wrote:
> > Eric Shade wrote:
> [...]
> > I don't think so. The specifications are quite concise.
> > Hannah.
> Just a moment, please. Do we speak about "concise" or "clear"?
I really probably spoke about "clear". However, I'm not a native
English speaker so I wasn't aware of the difference between those
two words until just now, when I looked them up.
In this case, I find
any p = or . map p
rather clear, and almost as concise as it can get (any = (or .) . map even
is shorter, thus perhaps more concise, but IMHO less clear for people
not so apt in a combinatorial style).
> [...]
> "off-line".) THREE TIMES I've been asked about that. Somebody
> quite clever remarked that any or all are *typical* cases for
> fold rather than for map.
You / they probably mean something like this:
any p = foldr (\ elem temp_res = p elem || temp_res) False
> [...]
> Please, don't speculate. If you have something to say in this
> context, perform some tests. I did it with Hugs. Eric Shade
> implementation seems to be indeed more efficient, but very
> slightly (on my test, I won't claim anything general).
Hugs is only a good test for --- hugs :-)
However, just tested with GHC and results were these:
hannah@c3po:/tmp $ cat x.hs
my_any p = or . map p
main =
print (my_any (== 0) [1..10000000])
hannah@c3po:/tmp $ time ./x
False
real 0m6.003s
user 0m5.917s
sys 0m0.024s
hannah@c3po:/tmp $ cat y.hs
my_any p [] = False
my_any p (x:xs) = p x || my_any p xs
main =
print (my_any (== 0) [1..10000000])
hannah@c3po:/tmp $ time ./y
False
real 0m4.403s
user 0m4.330s
sys 0m0.016s
GHC was 4.08.
Kind regards,
Hannah.
From EricShade@smsu.edu Tue Jan 23 22:38:57 2001
From: EricShade@smsu.edu (Eric Shade)
Date: Tue, 23 Jan 2001 16:38:57 -0600
Subject: Actual GHC memory usage for versions of 'any'
Message-ID: <20010123163857.A12203@gandalf.smsu.edu>
My questions about 'any' and 'all' really had more to do with pedagogy
than anything else, but now that I got GHC figured out, I ran some
tests using their profiler. I used version 4.08 on FreeBSD 4.2 and
did not enable optimization. I called the function 'atLeastOne'
instead of 'any' just to make sure I didn't confuse myself.
Prelude Version
---------------
GHC's default 'any' and 'or' differ from the Prelude specification, so
I wrote the equivalent versions by hand.
> default (Int)
> main = print (atLeastOne (> 1000000) [0..999999])
> atLeastOne :: (a -> Bool) -> [a] -> Bool
> atLeastOne p = foldr (||) False . map p
Here are the results:
Tue Jan 23 16:01 2001 Time and Allocation Profiling Report (Final)
foo +RTS -p -RTS
total time = 1.16 secs (58 ticks @ 20 ms)
total alloc = 88,001,188 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
atLeastOne Main 63.8 54.5
main Main 36.2 45.5
SYSTEM MAIN 17.2 0.1
Total allocation due to atLeastOne: 0.545 * 88001188 = 47,960,647 bytes
Recursive Version
-----------------
I wrote 'atLeastOne' by hand so that it wouldn't use GHC's builtin
version, which has rewrite rules that may allow better optimization.
> default (Int)
> main = print (atLeastOne (> 1000000) [0..999999])
> atLeastOne :: (a -> Bool) -> [a] -> Bool
> atLeastOne _ [] = False
> atLeastOne p (x:xs) = p x || atLeastOne p xs
Here are the results:
Tue Jan 23 16:01 2001 Time and Allocation Profiling Report (Final)
bar +RTS -p -RTS
total time = 0.76 secs (38 ticks @ 20 ms)
total alloc = 64,001,096 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
atLeastOne Main 71.1 37.5
SYSTEM MAIN 39.5 0.2
main Main 28.9 62.5
Total allocation due to atLeastOne: 0.375 * 64001096 = 24,000,411 bytes
Summary
-------
I realize that this is not a perfect test, but it does say something.
To those who read my previous post, when I said that 'any' takes
linear space, I meant in the worst case. And as Tom Pledger pointed
out to me privately via email, all of that space immediately becomes
garbage, so it may not be fair to count it against the space
requirements of the program. However, it does take time to reclaim
it.
Thanks to all who replied.
--
Dr. Eric Shade, Associate Professor
Computer Science Department (CSAB Accredited)
Southwest Missouri State University
From koen@cs.chalmers.se Wed Jan 24 02:45:09 2001
From: koen@cs.chalmers.se (Koen Claessen)
Date: Wed, 24 Jan 2001 03:45:09 +0100 (MET)
Subject: 'any' and 'all' compared with the rest of the Report
In-Reply-To: <20010123123519.A11539@gandalf.smsu.edu>
Message-ID:
Eric Shade wrote:
| Then I get to 'any' and 'all', whose specification
| requires linear time and *linear* space when it should
| run in constant space.
I do not understand this remark. What do you mean by this?
It is very difficult to say anything about space usage in a
lazy functional language, but let us assume that a list "xs"
is lazily produced in a one-by-one element fashion, and that
noone else than the following expression is looking at that
list. Then:
any p xs
Runs in constant space (with respect to the size of the
list), for any of the discussed implementations of "any".
Or did you mean something else?
/Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
From tdouglas@home.com Wed Jan 24 03:09:05 2001
From: tdouglas@home.com (Timmy Douglas)
Date: Tue, 23 Jan 2001 21:09:05 -0600
Subject: optimization in the report's prelude, again
Message-ID: <20010123210905E.timmy@localhost>
well, I'm a newbie and I was looking through the prelude to try to
learn some more haskell and I came across the sample definition of the
(^) operator on page 98. i saw a post for optimization, but and it
got mostly negative replies so i'll go the other way.
if we are writing for clarity and not efficency as it says, then would
it be better to write it as something like
n ^ e | n >= 0 = product $ take (e+1) (1 : repeat n)
_ ^ _ = error "negative exponent"
well, i could care less, but i have nothing better to do so i thought
i'd just ask if this was ok technique or something.
or maybe someone can tell me if there is like an order of "clearest
ways"... for example, using pattern matching if convenient first, then
using standard functions, then list comp., then guards, etc. because i
sometimes think that filter might be clearer as:
filter' f list = [ item | item <- list, f item]
rather than using guards... oh well, enough ranting.
thanks for replies.
From kuchen@uni-muenster.de Wed Jan 24 08:52:18 2001
From: kuchen@uni-muenster.de (Herbert Kuchen)
Date: Wed, 24 Jan 2001 09:52:18 +0100
Subject: FLOPS 2001 - 2nd Call for Participation
Message-ID: <3A6E97C1.C98C3F09@uni-muenster.de>
*********************************************************************
* SECOND CALL FOR PARTICIPATION *
* *
* FLOPS 2001 *
* Fifth International Symposium on Functional and Logic Programming *
* *
* Waseda University, Tokyo, Japan *
* March 7-9, 2001 *
* *
* http://www.ueda.info.waseda.ac.jp/flops2001/ *
*********************************************************************
The symposium is a forum for research on all issues concerning
functional programming and logic programming. In particular, it aims
to stimulate the cross-fertilization as well as integration of the two
paradigms. This is the fifth in the series of FLOPS symposia held
every 1.5 years in Japan.
The symposium program will consist of 3 invited talks and 21 technical
research talks. The proceedings will be published by Springer-Verlag
in the Lecture Notes in Computer Science series.
Invited Talks
=============
Gopalan Nadathur (Univ. of Minnesota, USA)
"The Metalanguage lambda-Prolog and Its Implementation"
George C. Necula (Univ. of California, Berkeley, USA)
"A Scalable Architecture for Proof-Carrying Code"
Taisuke Sato (Tokyo Institute of Technology, Japan)
"Parameterized Logic Programs where Computing Meets Learning"
Important Dates
===============
Early Registration Deadline: January 30, 2001
Symposium: March 7-9, 2001
Venue
=====
The symposium will be held at the Conference Room 1 (third floor) of
the International Conference Center of Waseda University, which is
located in central Tokyo and can be accessed easily. For details,
please visit the FLOPS2001 Web page
http://www.ueda.info.waseda.ac.jp/flops2001/ .
Registration and Hotel Information
==================================
Details of registration and hotel booking information are available
on the FLOPS2001 Web page. Registration fees are as follows:
Before Jan. 30 After Jan. 31
Regular 22,000 yen 32,000 yen
Student 12,000 yen 22,000 yen
The fees include participation, proceedings, banquet and
refreshments for one person. Additional banquet tickets are
available. The current exchange rate for Japanese yen is
US$1 = 116 yen and 1 Euro = 109 yen.
Detailed information on accommodations near the conference site,
ranging from luxuary to inexpensive, is available on the FLOPS Web
page.
Preliminary Programme
=====================
Wednesday, March 7
09:00 - 09:30 Registration
09:30 - 09:45 Opening
09:45 - 11:00 Invited Talk 1
The Metalanguage lambda-Prolog and Its Implementation
Gopalan Nadathur
11:00 - 11:30 Break
11:30 - 12:30 Lambda-Calculus
A Simply Typed Context Calculus with First-Class Environments
Masahiko Sato, Takafumi Sakurai, and Yukiyoshi Kameyama
Refining the Barendregt Cube using Parameters
Fairouz Kamareddine, Twan Laan, and Rob Nederpelt
12:30 - 14:00 Lunch
14:00 - 15:30 Functional Logic Programmig 1
A Framework for Goal-Directed Bottom-Up Evaluation of Functional
Logic Programs
Jesus M. Almendros-Jimenez and Antonio Becerra-Teron
Theoretical Foundations for the Declarative Debugging of Lazy
Functional Logic Programs
Rafael Caballero, Francisco J. Lopez-Fraguas, and
Mario Rodriguez-Artalejo
Adding Linear Constrains over Real Numbers to Curry
Wolfgang Lux
15:30 - 16:00 Break
16:00 - 17:30 Logic Programming
A Higher-Order Logic Programming Language with Constraints
Javier Leach and Susana Nieva
Specifying and Debugging Security Protocols via Hereditary Harrop
Formulas and lambdaProlog --- A Case-study
Giorgio Delzanno
An Effective Bottom-Up Semantics for First-Order Linear Logic
Programs
Marco Bozzano, Giorgio Delzanno, and Maurizio Martelli
Thursday, March 8
09:30 - 10:30 Program Analysis and Transformation 1
A Framework for Analysis of Typed Logic Programs
Vitaly Lagoon and Peter J. Stuckey
Abstract Compilation for Sharing Analysis
Gianluca Amato and Fausto Spoto
10:30 - 11:00 Break
11:00 - 12:15 Invited Talk 2
Parameterized Logic Programs where Computing Meets Learning
Taisuke Sato
12:15 - 13:45 Lunch
13:45 - 15:15 Functional Logic Programming 2
A Complete Selection Function for Lazy Conditional Narrowing
Taro Suzuki and Aart Middeldorp
An Abstract Machine Based System for a Lazy Narrowing Calculus
Teresa Hortala-Gonzalez and Eva Ullan
Incremental Learning of Functional Logic Programs
Cesar Ferri-Ramirez, Jose Hernandez-Orallo, and
Maria Jose Ramirez-Quintana
15:15 - 15:45 Break
15:45 - 17:15 Functional Programming
Proving Syntactic Properties of Exceptions in an Ordered Logical
Framework
Jeff Polakow and Kwangkeun Yi
A Higher-Order Colon Translation
Olivier Danvy and Lasse R. Nielsen
Compiling Lazy Functional Programs Based on the Spineless Tagless
G-machine for the Java Virtual Machine
Kwanghoon Choi, Hyun-il Lim, and Taisook Han
18:45 - 21:00 Banquet at Rihga Royal Hotel
Friday, March 9
09:30 - 10:30 Program Analysis and Transformation 2
A Practical Partial Evaluator for a Multi-Paradigm Declarative
Language
Elvira Albert, Michael Hanus, and German Vidal
A Simple Take on Typed Abstract Syntax in ML-like Languages
Olivier Danvy and Morten Rhiger
10:30 - 11:00 Break
11:00 - 12:15 Invited Talk 3
A Scalable Architecture for Proof-Carrying Code
George C. Necula
12:15 - 13:45 Lunch
13:45 - 15:15 Types
A General Type Inference Framework for Hindley/Milner Style
Systems
Martin Sulzmann
Monadic Encapsulation with Stack of Regions
Koji Kagawa
Well-Typed Logic Programs Are not Wrong
Pierre Deransart and Jan-Georg Smaus
15:15 - 15:30 Closing
Symposium Organization
======================
Program Co-Chairs:
Herbert Kuchen Univ. of Muenster, Germany
Kazunori Ueda Waseda Univ., Tokyo, Japan
Program Committee:
Sergio Antoy Portland State Univ., USA
Gopal Gupta New Mexico State Univ., USA
Michael Hanus Univ. of Kiel, Germany
Fergus Henderson Univ. of Melbourne, Australia
Zhenjiang Hu Univ. of Tokyo, Japan
Herbert Kuchen Univ. of Muenster, Germany
Giorgio Levi Univ. of Pisa, Italy
Michael Maher Griffith Univ., Brisbane, Australia
Dale Miller Pennsylvania State Univ., USA
I.V. Ramakrishnan State Univ. of New York at Stony Brook, USA
Olivier Ridoux IRISA, France
Mario Rodriguez-Artalejo Complutense Univ., Madrid, Spain
Colin Runciman Univ. of York, UK
Akihiko Takano Hitachi Ltd., Japan
Peter Thiemann Freiburg Univ., Germany
Yoshihito Toyama Tohoku Univ., Japan
Kazunori Ueda Waseda Univ., Tokyo, Japan
Local Arrangements Chair:
Zhenjiang Hu Univ. of Tokyo, Japan
Sponsors
========
FLOPS2001 is sponsored by Japan Society of Software Science and
Technology (JSSST), Special Interest Group on Principles of
Programming, and held in cooperation with Association for Logic
Programming.
From karczma@info.unicaen.fr Wed Jan 24 11:08:54 2001
From: karczma@info.unicaen.fr (Jerzy Karczmarczuk)
Date: Wed, 24 Jan 2001 11:08:54 +0000
Subject: 'any' and 'all' compared with the rest of the Report
References: <20010123123519.A11539@gandalf.smsu.edu>
Message-ID: <3A6EB7C6.3BAC9EEC@info.unicaen.fr>
Eric Shade:
> It would be one thing if the
> Report were littered with functions whose specifications were
> obviously not intended as implementations. But 'any', 'all', and
> 'findIndices' were the only inefficient ones I noticed out of the
> entire Report.
>
> And it's obvious that clarity is not the only goal in the
> specifications. For example, why bother to write a messy O(log n)
> version of x^n when the following is more clear *and* more concise?
>
> x ^ n | n >= 0 = product (replicate n x)
> _ ^ _ = error "Prelude.^: negative exponent"
===
1. elem, notElem, etc. follow the same pattern.
2. The rational number package is not too optimal, as far as I can
judge it.
3. Now, now, you fight against the inefficiency of linear algorithms
which use map, and here you propose EXACTLY the same for the product?
(Unless, as Bjorn hopes, one day the compilers will do all the
parallelisation/logarithmoptimisation for us.)
BY THE WAY.
The power algorithm which uses the binary splitting of the exponent
is very popular in the pedagogical context, and sometimes abused, for
example to compute huge powers of "infinite precision" integers.
If we assume that the multiplication algorithm for two long numbers
of lengths M and N is proportional to M*N, see for yourself what is
the asymptotic complexity of the power which uses the logarithmic
method vs. the linear one. You might be surprised. //Sorry for
deviating from Haskell...//
On the other hand, having an even more generic logarithmic iterator
for associative operations seems to me a decent idea. You might even
need it one day (I had this pleasure) for the multiplication of an
object by an integer, where the object was so non-standard, that the
only way of implementing N*X was: X+X+...+X.
So, Eric, don't call this algorithm "messy". (I suspect that you
are joking, but ALL comp. sci students should know it, and perhaps
some of them read this list and may believe you...)
Jerzy Karczmarczuk
Caen, France
From qrczak@knm.org.pl Wed Jan 24 22:36:58 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 24 Jan 2001 22:36:58 GMT
Subject: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
References:
Message-ID:
Mon, 22 Jan 2001 16:42:32 +0000, Keith Wansbrough pisze:
> http://www.cl.cam.ac.uk/~kw217/research/papers.html#Wansbrough99:Macros
hsc2hs, although designed for embedding Haskell constructs depending
on C headers, can be used as a Haskell preprocessor.
It avoids lexing Haskell source using C rules. Among C-specific things
it provides #if/#ifdef/etc., #define/#undef, #include, #error/#warning,
and an ugly way to define macros with optional parameters, token
pasting, stringification and controlled layout.
The implementation delegates all hard work to a C compiler applied to
a C program which outputs the Haskell program. {-# LINE #-} pragmas
are understood and generated. #define and #include are also put into
ghc's .hc files. The only part which differs much from cpp and is
quite ugly is macros to be used in the Haskell program. They can be
defined and used for example thus:
------------------------------------------------------------------------
#let assert e = "(if (%s) then id else " \
"const (error \"Assertion failed: %s, %s:%d\")) $", \
e, e, __FILE__, __LINE__
main =
#assert "length [1,2,3] == 3"
putStrLn "Hello world"
------------------------------------------------------------------------
and if you don't mind applying C lexical syntax to bits of Haskell code,
you can replace uses of e above by #e and call
#assert (length [1,2,3] == 3)
where parens are necessary only because the expression contains commas
outside parens.
You can also embed e into the string constant thus:
"(if (" e ") then id else " ...
instead of using printf format, but this fails if the expression
contains % characters.
Macro expansion is not applied to all occurrences of an identifier
in the source, but just to explicitly used new #-constructs as
#assert above.
A macro definition can be written in an equivalent, more low-level
way thus:
#define hsc_assert(e) printf ( \
"(if (%s) then id else " \
"const (error \"Assertion failed: %s, %s:%d\")) $", \
e, e, __FILE__, __LINE__);
and can make use of arbitrary C statements which are a part of the
C program created and run during preprocessing.
I once made a file preprocessed twice. The first pass generates
#ifdefs for each identifier passed as a macro argument, the second
pass applies these #ifdefs.
hsc2hs is in the CVS version of ghc and QForeign.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From Sven.Panne@informatik.uni-muenchen.de Thu Jan 25 00:33:43 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Thu, 25 Jan 2001 01:33:43 +0100
Subject: 'any' and 'all' compared with the rest of the Report
References: <20010123123519.A11539@gandalf.smsu.edu>
Message-ID: <3A6F7467.C74EA475@informatik.uni-muenchen.de>
Hmmm,
I'm slowly using track of this whole discusssion. But as a simple matter
of fact: Using or not using optimizations (aka -O) changes the space
behaviour of your Haskell programm. Sad as it may sound, it seems to be
the price you have to pay for lazy evaluation. Of course it depends on
the exact reading of "space behaviour" (temporary allocation vs. max
heap usage), but it basically remains the same. On a positive side, this
shifts debugging to a much higher level (searching for space leaks) than
commonly done in imperative/OO/... languages (searching for semantic
bugs
in the first place, space leaks only come after that).
Just my 2 cents,
Sven
From don_wakefield@mentorg.com Thu Jan 25 21:26:24 2001
From: don_wakefield@mentorg.com (Don Wakefield)
Date: Thu, 25 Jan 2001 13:26:24 -0800 (PST)
Subject: Question about 'Tackling the Awkward Squad'
Message-ID: <14960.39424.138943.843784@gargle.gargle.HOWL>
I posed the following question on comp.lang.functional, and a helpful
reader emailed me to suggest that I should ask it here. Briefly, I
dabble in Haskell to exercise my mind in a way that my C++ heritage
doesn't, so if I'm asking silly questions or missing seemingly obvious
notions, I beg forgiveness.
The Question. I was reading Simon Peyton Jones' fascinating paper:
Tackling the awkward squad: monadic input/output, concurrency,
exceptions, and foreign-language calls in Haskell
(the January 9th 2001 draft)
when I ran across what appears to be an error. On page 34, while
discussing Channels, he proposes a function called dupChan:
dupChan (read, write)
= do { new_read <- newEmptyMVar ;
hole <- takeMVar write ;
putMVar write hole ;
putMVar new_read hole ;
return (new_read, write) }
The rationale is given thusly:
"For example, consider a multi-cast channel, in which there are
multiple readers, each of which should see all the values written to
the channel ... The idea is that the channel returned by dupChan can
be read independently of the original, and sees all (and only) the
data written to the channel after the dupChan call."
But earlier he has defined getChan thusly:
getchan (read, write)
= do { head_var <- takeMVar read ;
MkItem val new_head <- takeMVar head_var ;
putMVar read new_head ;
return val }
Since the line which performs the 'takeMVar head_var' leaves the MVar
referenced by head_var empty, the dupChan 'new_read' Stream should block
when the reader tries to *also* use getChan on this Stream, isn't this
so? Am I missing some subtlety? I drew all the pictures :^)~
--
Don Wakefield Mentor Graphics Corporation
(503) 685-1262 8005 S.W. Boeckman Road
don_wakefield@mentorg.com Wilsonville, OR 97070-7777
From C.Reinke@ukc.ac.uk Fri Jan 26 20:28:16 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Fri, 26 Jan 2001 20:28:16 +0000
Subject: Combinator library gets software prize
In-Reply-To: Message from Timothy Docker
of "Tue, 23 Jan 2001 09:05:02 +1100." <14956.44093.496758.105263@tcc2>
Message-ID:
[oops, somehow this ended up in my drafts folder, not on the list;
sorry for the delay]
First, to avoid confusion: I'm not criticising the work described. I'm
just pointing out that, in my view, the major advantages of functional
programming lie beyond what is used in this application (in other
words, there is yet more to be gained, and we should not underestimate
the role of the facilities imported from the functional host language,
such as functional abstraction).
[one quibble: I don't like the idea of using floating point numbers to
represent real money without further comments. Even after avoiding
representation error surprises by using base10 instead of binary
floating points, aren't there precise standards for rounding in the
financial market? Or have I missed an explanation of this in the paper?]
> > Am I the only one who finds the exclusive emphasis on combinator
> > languages slightly disappointing (in fact, the article seems to equate
> > functional language with domain-specific combinator languages, which is
> > more than a bit mistleading)?
>
> What declarative approach(es) (other than combinators) are you
> referring to here?
Mostly lambda-calculus; more generally, all approaches that deal
explicitly with variables and variable binding, and the resulting
languages, which are general enough that DSLs for many domains can be
embedded in them.
Even within combinator languages, I am not always sure whether those
reporting on the paper are aware how much the DSL gains by being
embedded in a full functional language, and how simply exporting the
core DSL to another context would severe all those useful connections.
In the present context, most of the excitement seems to focus on the
contract combinators, because they bring a new approach towards order
in the application domain. They can be viewed as a first-order
functional language on contracts. This core part of the DSL could be
used in other modern languages as well, provided their expression
sub-language is sufficiently expressive (although the syntax, e.g., new
And(..) and new Give(..) in Java, or .. in other contexts,
would quite likely annoy the user).
But the paper goes beyond that, e.g., it defines and uses some
higher-order features for observables. Also, functional programmers
will be tempted to use partially applied contract combinators in
higher-order compositions (as a simple example, take
"all = foldr and zero :: [Contract] -> Contract" --
acquiring "all contracts" acquires a list of contracts).
Such uses are already slightly more difficult (and typically much more
ugly) in non-functional languages, so simply providing the same basic
DSL as a library embedded in a non-functional language will not
necessarily give the same flexibility (and a dedicated implementation
of the DSL would have to decide between supporting only simple uses of
the combinators or adding some more advanced features).
Of course, in addition to combinators, we also need definitions, so
that we can give names to useful combinations of combinators. This
comes for free if the DSL is embedded in Haskell, but if we take it
out of this context, we need to start thinking about what kind of
definitions we can or want to support: parameters? certainly.
what types of parameters? what types of things can be defined?
how are parameters passed?..
And suddenly, we're into the definition and implementation of a little
(higher-order?) functional language, with support for functional
abstraction (how much support?). Does the host language (or the
dedicated implementation) support all the things we want in the way we
expect?
In any case, the core contract combinator DSL doesn't stand in
isolation - we need to work with the contracts, operate on dates,
evaluate options, iterate through sequences or alternatives, ..
Do we do this in functional style, or by shouting imperatives at
those poor contract combinations?
> > The consequence (and the intention, as far as one can gather from the
> > paper) of the limitation to combinators is that this language can and
> > will be used mainly in non-functional languages, not inheriting all
> > that much from a functional style of programming. The same will
> > probably hold for any communication standards based on it.
>
> Why is that? I'm new to the functional programming world, and haven't
> reallystruck the concept of combinator libraries elsewhere. I assumed
> they were largely a functional programming concept. Even though I can
> see how they could be implemented in imperative languages, it doesn't
> seem that they would be a nice fit.
That's my point. But so far, I don't see any external commitment to a
functional host language for the core combinators. Of course, that
impression could well be wrong..
The paper suggests the Haskell implementation as a prototype to help
the development of an existing C++ implementation as well as a new
implementation in OCaml (implementation language, not host language).
Most positive external comments seem to focus on the core contract
combinators as a possible means to standardize the way professionals
and software are talking about contracts (XML-like).
Now, if you cut out the contract combinators from the DSL embedded in
Haskell and try to find something that can be used across
C++,OCaml,XML-processing Java, etc., you might end up writing
for-loops, assigning contract combinations to global variables, sending
messages to contract objects, and all the other funny non-functional
things that are so happily used outside the Haskell world.
> > [Several interesting elided]
>
> More generally, is there any more information or forums on declarative
> approaches to financial engineering? I found this paper intriguing, as
> it focuses on both my current academic interests, and my work!
I'm not an expert in this area, but from the few references in the
paper, it seems that there hasn't been much work, and from the comments
on the paper, it seems there there is a growing interest. Perhaps there
are enough people interested now to warrant setting up such a forum.
Claus
From tdouglas@home.com Sat Jan 27 06:03:49 2001
From: tdouglas@home.com (Timmy Douglas)
Date: Sat, 27 Jan 2001 00:03:49 -0600
Subject: binary files in haskell
Message-ID: <20010127000349A.timmy@localhost>
I was wondering if anyone here has a solution for writing binary files
that works in hugs and ghc that doesn't require getting libs.
I looked at this page:
http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html
and the haskell.org libraries page and I didn't see anything. the ghc
documentation didn't provide any examples so I was unable to figure
out how to write a binary file.
From Sven.Panne@informatik.uni-muenchen.de Sat Jan 27 17:19:08 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Sat, 27 Jan 2001 18:19:08 +0100
Subject: binary files in haskell
References: <20010127000349A.timmy@localhost>
Message-ID: <3A73030C.3CBDE6D8@informatik.uni-muenchen.de>
[ OK, let's see if I get a typo-free mail out of the door *this* time... :-]
Timmy Douglas wrote:
> I was wondering if anyone here has a solution for writing binary files
> that works in hugs and ghc that doesn't require getting libs.
I dont' know exactly about the current status of Hugs' libs, but I fear
the answer to your question is "no".
> I looked at this page:
> http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html
... and that was exactly the right place, see section "Bulk transfers"
hGetBuf :: Handle -> Addr -> Int -> IO Int
hGetBufFull :: Handle -> Addr -> Int -> IO Int
hPutBuf :: Handle -> Addr -> Int -> IO Int
hPutBufFull :: Handle -> Addr -> Int -> IO ()
>
> and the haskell.org libraries page and I didn't see anything. the ghc
> documentation didn't provide any examples so I was unable to figure
> out how to write a binary file.
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
--
Sven Panne Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:sven.panne@informatik.uni-muenchen.de D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
From rjljr2@yahoo.com Sat Jan 27 17:32:34 2001
From: rjljr2@yahoo.com (Ronald Legere)
Date: Sat, 27 Jan 2001 09:32:34 -0800 (PST)
Subject: Combinator library gets software prize
Message-ID: <20010127173234.3814.qmail@web10006.mail.yahoo.com>
--- "C.Reinke" wrote:
>Even within combinator languages, I am not always
> sure whether those
> reporting on the paper are aware how much the DSL
> gains by being
> embedded in a full functional language, and how
> simply exporting the
> core DSL to another context would severe all those
> useful connections.
>
Heh, this is something that I ran into when trying to
write a combinator language for Java based on Haskore.
I gave up when I realized i really needed those other
features of a functinal language to :). It is a bit
difficult in many domains to seperate what you are
defining from the language you are defining it in, so
I guess this is not such a large suprise.
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
From Sven.Panne@informatik.uni-muenchen.de Sat Jan 27 17:35:49 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Sat, 27 Jan 2001 18:35:49 +0100
Subject: binary files in haskell
References: <20010127000349A.timmy@localhost>
Message-ID: <3A7306F5.685C5A9D@informatik.uni-muenchen.de>
[ Seems I *can't* mail in a sane way anymore, so please excuse my last
half-baked one. But at least I've learned now that Ctrl-RET means
"send immediately" in Netscape. Great idea! Here my next try... ]
Timmy Douglas wrote:
> I was wondering if anyone here has a solution for writing binary files
> that works in hugs and ghc that doesn't require getting libs.
I dont' know exactly about the current status of Hugs' libs, but I fear
the answer to your question is "no".
> I looked at this page:
> http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html [...]
... and that was exactly the right place, see section "Bulk transfers":
(http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html#SEC-BULK-TRANSFERS)
hGetBuf :: Handle -> Addr -> Int -> IO Int
hGetBufFull :: Handle -> Addr -> Int -> IO Int
hPutBuf :: Handle -> Addr -> Int -> IO Int
hPutBufFull :: Handle -> Addr -> Int -> IO ()
These action read/write a given amount of bytes to/from a buffer. There
hasn't been much consensus about a higher level interface yet, but you
can have a look at my variant sitting on top of this:
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/OpenGL/GL/GL_BinaryIO.hs?rev=1.2&content-type=text/x-cvsweb-markup
Not the nicest and most efficient code on earth, but it should be enough
to get the idea. Note that in more recent (CVS) versions of GHC, `Addr'
(which is deprecated now) has been replaced by `Ptr a'.
Any ideas & suggestions for a good binary I/O interface are highly welcome!
Cheers,
Sven "The Typo" P.
From tdouglas@home.com Sat Jan 27 18:11:48 2001
From: tdouglas@home.com (Timmy Douglas)
Date: Sat, 27 Jan 2001 12:11:48 -0600
Subject: binary files in haskell
In-Reply-To: <3A7306F5.685C5A9D@informatik.uni-muenchen.de>
References: <20010127000349A.timmy@localhost>
<3A7306F5.685C5A9D@informatik.uni-muenchen.de>
Message-ID: <20010127121148N.timmy@localhost>
Sven Panne said:
>[ Seems I *can't* mail in a sane way anymore, so please excuse my last
> half-baked one. But at least I've learned now that Ctrl-RET means
> "send immediately" in Netscape. Great idea! Here my next try... ]
>
>Timmy Douglas wrote:
>> I was wondering if anyone here has a solution for writing binary files
>> that works in hugs and ghc that doesn't require getting libs.
>
>I dont' know exactly about the current status of Hugs' libs, but I fear
>the answer to your question is "no".
>
>> I looked at this page:
>> http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html [...]
>
>... and that was exactly the right place, see section "Bulk transfers":
>(http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html#SEC-BULK-TRANSFERS)
>
> hGetBuf :: Handle -> Addr -> Int -> IO Int
> hGetBufFull :: Handle -> Addr -> Int -> IO Int
>
> hPutBuf :: Handle -> Addr -> Int -> IO Int
> hPutBufFull :: Handle -> Addr -> Int -> IO ()
>
>These action read/write a given amount of bytes to/from a buffer. There
>hasn't been much consensus about a higher level interface yet, but you
>can have a look at my variant sitting on top of this:
I saw this part but I couldn't figure out how I was supposed to open a
file and use these functions. So maybe I was looking for an example. I
want to try to write a compiler for some language in haskell, but I
don't know how to write binary files...
It looks like I use openFileEx but I can't get anything to compile
without seeing an example of it.
Thanks for the reply.
From conal@microsoft.com Tue Jan 23 19:22:41 2001
From: conal@microsoft.com (Conal Elliott)
Date: Tue, 23 Jan 2001 11:22:41 -0800
Subject: Combinator library gets software prize
Message-ID:
> From: C.Reinke [mailto:C.Reinke@ukc.ac.uk]
> Am I the only one who finds the exclusive emphasis on combinator
> languages slightly disappointing [...]?
> [...]
> The paper somewhat downplays the role of embedding the
> combinator-based DSL in a full functional language while also
> mentioning that some features gained for free in the Haskell
> prototype considerably complicate implementations in other
> languages. I would be interested to hear more about these aspects:
> [...]
Another important consideration is whether the combinator library is
higher-order. If so, it will be awkward to use from a language
without a lightweight notation for (first-class) functions. This lack
was a huge drawback in DirectAnimation, the now-defunct product cousin
of Fran, which eviscerated the crucially higher-order event algebra.
Similarly, when a combinator lib uses parametric polymorphism, it is
painful to use from a language without. (Same example.) It seems
that these features just weren't important in the case of "Composing
Contracts".
- Conal
From simonpj@microsoft.com Fri Jan 26 09:11:45 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 26 Jan 2001 01:11:45 -0800
Subject: Question about 'Tackling the Awkward Squad'
Message-ID: <74096918BE6FD94B9068105F877C002D355EE5@red-pt-02.redmond.corp.microsoft.com>
Don
Crumbs! You're right!
The MVars that are drawn as heavy black boxes in Figure 7 of Tackling
the Awkward Squad are used to block the consumer when it catches up
with the producer. But if there is more than one consumer, it's not
OK to leave these MVars empty. Instead, getChan should do a put after
its take; or, more elegantly, should use readMVar, which has the
semantics of take-followed-by-put:
getchan (read, write)
= do { head_var <- takeMVar read ;
MkItem val new_head <- readMVar head_var ;
putMVar read new_head ;
return val }
Concurrent programming is tricky. I owe you a beer!
I'll fix the version on the Web
Simon
| when I ran across what appears to be an error. On page 34, while
| discussing Channels, he proposes a function called dupChan:
|
| dupChan (read, write)
| = do { new_read <- newEmptyMVar ;
| hole <- takeMVar write ;
| putMVar write hole ;
| putMVar new_read hole ;
| return (new_read, write) }
|
| The rationale is given thusly:
|
| "For example, consider a multi-cast channel, in which there are
| multiple readers, each of which should see all the values written to
| the channel ... The idea is that the channel returned by dupChan can
| be read independently of the original, and sees all (and only) the
| data written to the channel after the dupChan call."
|
| But earlier he has defined getChan thusly:
|
| getchan (read, write)
| = do { head_var <- takeMVar read ;
| MkItem val new_head <- takeMVar head_var ;
| putMVar read new_head ;
| return val }
|
| Since the line which performs the 'takeMVar head_var' leaves the MVar
| referenced by head_var empty, the dupChan 'new_read' Stream
| should block
| when the reader tries to *also* use getChan on this Stream, isn't this
| so? Am I missing some subtlety? I drew all the pictures :^)~
|
| --
| Don Wakefield Mentor Graphics Corporation
| (503) 685-1262 8005 S.W. Boeckman Road
| don_wakefield@mentorg.com Wilsonville, OR 97070-7777
|
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|
From Dominic.J.Steinitz@BritishAirways.com Mon Jan 29 09:56:00 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 29 Jan 2001 09:56:00 Z
Subject: Question about 'Tackling the Awkward Squad'
Message-ID: <"026673A753E30046*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
This is probably superfluous now but I still don't understand Hugs' behaviour. I ran the following with ghc 4.08.1:
module Main(main) where
import Concurrent
main =
do chan <- newChan
writeChan chan "One"
dup <- dupChan chan
writeChan chan "Two"
x <- readChan dup
y <- readChan chan
z <- readChan chan
putStrLn (x++y++z)
I expected the answer "TwoOneTwo" but instead got
$ ./main
d:\dom\hugs98\concurrent\main.exe: no threads to run: infinite loop or
deadlock?
which confirmed the problem that Don highlighted.
With Hugs I got the following:
Main> main
(232 reductions, 458 cells)
which was puzzling. I'm running Version: May 1999 with -98.
Dominic.
simonpj@microsoft.com on 28/01/2001 11:18:00
To: don_wakefield
haskell
cc:
bcc: Dominic Steinitz
Subject: RE: Question about 'Tackling the Awkward Squad'
Don
Crumbs! You're right!
The MVars that are drawn as heavy black boxes in Figure 7 of Tackling
the Awkward Squad are used to block the consumer when it catches up
with the producer. But if there is more than one consumer, it's not
OK to leave these MVars empty. Instead, getChan should do a put after
its take; or, more elegantly, should use readMVar, which has the
semantics of take-followed-by-put:
getchan (read, write)
= do { head_var <- takeMVar read ;
MkItem val new_head <- readMVar head_var ;
putMVar read new_head ;
return val }
Concurrent programming is tricky. I owe you a beer!
I'll fix the version on the Web
Simon
| when I ran across what appears to be an error. On page 34, while
| discussing Channels, he proposes a function called dupChan:
|
| dupChan (read, write)
| = do { new_read <- newEmptyMVar ;
| hole <- takeMVar write ;
| putMVar write hole ;
| putMVar new_read hole ;
| return (new_read, write) }
|
| The rationale is given thusly:
|
| "For example, consider a multi-cast channel, in which there are
| multiple readers, each of which should see all the values written to
| the channel ... The idea is that the channel returned by dupChan can
| be read independently of the original, and sees all (and only) the
| data written to the channel after the dupChan call."
|
| But earlier he has defined getChan thusly:
|
| getchan (read, write)
| = do { head_var <- takeMVar read ;
| MkItem val new_head <- takeMVar head_var ;
| putMVar read new_head ;
| return val }
|
| Since the line which performs the 'takeMVar head_var' leaves the MVar
| referenced by head_var empty, the dupChan 'new_read' Stream
| should block
| when the reader tries to *also* use getChan on this Stream, isn't this
| so? Am I missing some subtlety? I drew all the pictures :^)~
|
| --
| Don Wakefield Mentor Graphics Corporation
| (503) 685-1262 8005 S.W. Boeckman Road
| don_wakefield@mentorg.com Wilsonville, OR 97070-7777
|
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From simonpj@microsoft.com Mon Jan 29 15:05:58 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 29 Jan 2001 07:05:58 -0800
Subject: FW: Consortium Caml
Message-ID: <74096918BE6FD94B9068105F877C002D013787C4@red-pt-02.redmond.corp.microsoft.com>
Here's an interesting model for collaboration which the
Caml folk are taking up.
Simon
-----Original Message-----
From: Michel Mauny [mailto:Michel.Mauny@inria.fr]
Sent: 26 January 2001 21:38
To: caml-list@inria.fr
Subject: Consortium Caml
-- [ English version below ] ---
Dear Colleagues,
We are pleased to announce the creation of the Caml Consortium, whose
aim is to federate the design and development efforts around the Caml
programming language. The Caml Consortium will therefore try to bring
together, around the language development team, industries, research
centres and educational establishments interested in contributing
their support to the design and development of the language and
related tools.
Comprising a group of highly-motivated users, the Consortium will be
the place where the members can identify their common requirements,
exchange their experiences and solutions, and co-operate to propose a
particular development of general interest. One of the Consortium's
roles is therefore to be a place where users of the language can meet
and exchange information. It is here that a true community will be
created with the specific intention of assisting in the development of
the language and to provide it with such a visibility that this
community will expand by itself.
The motivation and industrial importance of its members will also
attract companies to the Consortium which want to be present on the
Caml applications and training market. Another role of the Consortium
will therefore be to attract new members, whether they are users of
the language or service providers.
Finally, the Consortium will provide a response to the question on the
language's continuity. The essential elements for the continuity of a
programming language are the continuity of its compilers (or their
free availability), its user base, and the volume of existing (stable)
codes. The success of the Caml Consortium will make it possible to
measure the user base and the volume of the existing Caml code. As for
the availability and development of the Caml compilers, these are
already freely distributed with their sources. If INRIA decides at
some point to withdraw from Caml development, and therefore to
dissolve the Caml Consortium as it presently stands, the members of
the Consortium will be sufficiently numerous, they will have
sufficiently diversified profiles, and the market for the language
will be such that the members of the Consortium will have no
difficulty in continuing the existence and development of the
language. INRIA will facilitate this transition, which is in the
general interest.
For more information, I suggest that you consult
http://caml.inria.fr/consortium/
Best regards,
-- Michel Mauny
From jans@numeric-quest.com Mon Jan 29 10:35:54 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Mon, 29 Jan 2001 05:35:54 -0500 (EST)
Subject: FW: Consortium Caml
In-Reply-To: <74096918BE6FD94B9068105F877C002D013787C4@red-pt-02.redmond.corp.microsoft.com>
Message-ID:
If this idea is also being considered for Haskell
I suggest to examine NICE pages to see how it works
in practice.
NICE = Non-profit International Consortium for Eiffel.
http://www.eiffel-nice.org
Jan
From cm@pochta.net Tue Jan 30 12:30:10 2001
From: cm@pochta.net (Eugene Nonko)
Date: Tue, 30 Jan 2001 18:30:10 +0600
Subject: Problems with GHC-4.08.1 on Windows 2000 Professional
Message-ID: <00ba01c08ab8$64846e30$7103a8c0@novosoft.ru>
Dear Colleagues,
I've encountered some problems after ghc-4.08.1 installation on by w2kpro.
When I'm trying to compile simple 'Hello world!' program (ghc main.hs -o
main.exe), linker outputs messages:
===
gcc: D:/ghc/lib/Main.dll_o: No such file or directory
gcc: D:/ghc/lib/PrelMain.dll_o: No such file or directory
===
When I'm trying to compile it with -static command line switch (ghc
main.hs -o main.exe -static), it compiles, but resulting .exe does nothing
(it doesn't displays message).
What's the problem, can someone explain me?
PS. Just in case, this is full source code of this 'Hello world!' program.
;)
===
module Main (main) where
main = putStrLn "Hello, world!"
===
Best regards,
Eugene Nonko
Novosoft Inc.
From simonpj@microsoft.com Tue Jan 30 16:31:32 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 30 Jan 2001 08:31:32 -0800
Subject: Problems with GHC-4.08.1 on Windows 2000 Professional
Message-ID: <37DA476A2BC9F64C95379BF66BA2690219F7CF@red-msg-09.redmond.corp.microsoft.com>
You have to compile with the flag -static, I'm afraid.
4.08.2 will have this built in.
Simon
| -----Original Message-----
| From: Eugene Nonko [mailto:cm@pochta.net]
| Sent: 30 January 2001 12:30
| To: haskell@haskell.org
| Subject: Problems with GHC-4.08.1 on Windows 2000 Professional
|
|
| Dear Colleagues,
|
| I've encountered some problems after ghc-4.08.1 installation
| on by w2kpro.
| When I'm trying to compile simple 'Hello world!' program (ghc
| main.hs -o
| main.exe), linker outputs messages:
| ===
| gcc: D:/ghc/lib/Main.dll_o: No such file or directory
| gcc: D:/ghc/lib/PrelMain.dll_o: No such file or directory
| ===
|
| When I'm trying to compile it with -static command line switch (ghc
| main.hs -o main.exe -static), it compiles, but resulting .exe
| does nothing
| (it doesn't displays message).
|
| What's the problem, can someone explain me?
|
| PS. Just in case, this is full source code of this 'Hello
| world!' program.
| ;)
| ===
| module Main (main) where
|
| main = putStrLn "Hello, world!"
| ===
|
| Best regards,
| Eugene Nonko
| Novosoft Inc.
|
|
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|
From meurig@dcs.gla.ac.uk Tue Jan 30 18:41:21 2001
From: meurig@dcs.gla.ac.uk (Meurig Sage)
Date: Tue, 30 Jan 2001 18:41:21 -0000
Subject: Problems with GHC-4.08.1 on Windows 2000 Professional
References: <00ba01c08ab8$64846e30$7103a8c0@novosoft.ru>
Message-ID: <06f101c08aec$3dddb9b0$2cf5d182@dcs.gla.ac.uk>
Hi
I had the same problem.
The problem is with one of your cygwin libraries.
Reuben Thomas sent me this reply:
-------------
You probably need to change the mingw package: if its date is 200012xx, try
downgrading to 200011xx. This recommendation also applies to Janna Khegai's
message.
-------------
You'll have to download and install the slightly older mingw package.
Meurig
----- Original Message -----
From: "Eugene Nonko"
To:
Sent: Tuesday, January 30, 2001 12:30 PM
Subject: Problems with GHC-4.08.1 on Windows 2000 Professional
> Dear Colleagues,
>
> I've encountered some problems after ghc-4.08.1 installation on by w2kpro.
> When I'm trying to compile simple 'Hello world!' program (ghc main.hs -o
> main.exe), linker outputs messages:
> ===
> gcc: D:/ghc/lib/Main.dll_o: No such file or directory
> gcc: D:/ghc/lib/PrelMain.dll_o: No such file or directory
> ===
>
> When I'm trying to compile it with -static command line switch (ghc
> main.hs -o main.exe -static), it compiles, but resulting .exe does nothing
> (it doesn't displays message).
>
> What's the problem, can someone explain me?
>
> PS. Just in case, this is full source code of this 'Hello world!' program.
> ;)
> ===
> module Main (main) where
>
> main = putStrLn "Hello, world!"
> ===
>
> Best regards,
> Eugene Nonko
> Novosoft Inc.
>
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From simonpj@microsoft.com Fri Jan 26 10:10:34 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 26 Jan 2001 02:10:34 -0800
Subject: fixity for (\\)
Message-ID: <74096918BE6FD94B9068105F877C002D355B92@red-pt-02.redmond.corp.microsoft.com>
This proposal makes sense to me, but I'm only supposed to be fixing=20
serious bugs in the Haskell 98 definition, not making unforced changes.
So even though this change would be non-invasive and break no programs
I'm reluctant to adopt it. Adding those extra parens is no big deal.
Unless there's a lot of support, I propose to make no change (in H98,
that is).
Simon
| -----Original Message-----
| From: Koen Claessen [mailto:koen@cs.chalmers.se]
| Sent: 17 January 2001 15:32
| To: The Haskell Mailing List
| Subject: fixity for (\\)
|=20
|=20
| Hi all,
|=20
| The Haskell report defines the fixity of (\\) to be:
|=20
| infix 5 \\
|=20
| I propose that it gets the following fixity:
|=20
| infixl 5 \\
|=20
| This means that one can write:
|=20
| as \\ bs \\ cs \\ ds
|=20
| Which means:
|=20
| (((as \\ bs) \\ cs) \\ ds)
|=20
| I think that one less often means the following:
|=20
| as \\ (bs \\ (cs \\ ds))
|=20
| /Koen.
|=20
| --
| Koen Claessen http://www.cs.chalmers.se/~koen
| phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
| -----------------------------------------------------
| Chalmers University of Technology, Gothenburg, Sweden
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|=20
From Christian.Laaser@icn.siemens.de Wed Jan 31 12:12:19 2001
From: Christian.Laaser@icn.siemens.de (Laaser Christian)
Date: Wed, 31 Jan 2001 13:12:19 +0100
Subject: What does "Compiled code too complex" error message of Hugs mean?
Message-ID: <115FD6FDE682D311A9500008C791E269AA7C28@MCHH262E>
When loading some Haskell files with Hugs, I get the error message "Compiled code too complex". However, the compilation with GHC 4.08.1 succeeds.
What does this message mean? What can I do about it?
Christian
From kort@wins.uva.nl Wed Jan 31 12:33:33 2001
From: kort@wins.uva.nl (Jan Kort)
Date: Wed, 31 Jan 2001 13:33:33 +0100
Subject: What does "Compiled code too complex" error message of Hugs mean?
References: <115FD6FDE682D311A9500008C791E269AA7C28@MCHH262E>
Message-ID: <3A78061D.3F46BDCA@wins.uva.nl>
Laaser Christian wrote:
>
> When loading some Haskell files with Hugs, I get the error message "Compiled code too complex". However, the compilation with GHC 4.08.1 succeeds.
> What does this message mean? What can I do about it?
>
You can grep for that sentence in "hugs98/src", it will point to the
file "machine.c". There you will see it says "if (nextLab>=NUM_FIXUPS) ...".
So grep for "NUM_FIXUPS" it will point to the file "prelude.h". I
think the default value is 400, you should increase it to 1000 or so.
I have it at 10000, but that's probably not necesary in your case
and if you increase constants too much starting up Hugs will become
slower.
Jan
From simonpj@microsoft.com Fri Jan 26 10:42:33 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 26 Jan 2001 02:42:33 -0800
Subject: Yet more on functional dependencies
Message-ID: <74096918BE6FD94B9068105F877C002D355B94@red-pt-02.redmond.corp.microsoft.com>
| | I am finding functional dependencies confusing. (I suspect I am=20
| | not alone.) Should the following code work?
| |=20
| | class HasConverter a b | a -> b where
| | convert :: a -> b
| |=20
| | instance (HasConverter a b,Show b) =3D> Show a where
| | show value =3D show (convert value)
|=20
| It's a separate issue. There's no reason why a system using
| functional dependencies *should* support this. But it is an
| attractive and useful extension that such a system would
| probably *want* to include. (i.e., it's a desirable feature,
| not a requirement.)
There are two things going on here
a) The 'head' of the instance declaration is just "Show a", so this
purports to give an instance declaration for all types "a". So it
overlaps with other instance declarations, and GHC currently rejects
it for that reason. (Arguably, if you accept overlapping instance=20
declarations, then this should be acceptable too.)
b) There's a "b" in the instance declaration context that doesn't
appear in the head. This is quite OK, because the functional dependency
ensures that "a" uniquely determines "b". =20
So here's a variant that works in the (as-yet-unreleased) GHC 5.0:
data Foo a =3D MkFoo a
instance (HasConverter a b,Show b) =3D> Show (Foo a) where
show (MkFoo value) =3D show (convert value)
[Incidentally, functional dependencies don't work at all in GHC 4.08;
don't
even try.]
Simon
From cllan@263.net Tue Jan 23 00:16:55 2001
From: cllan@263.net (Onwall.net)
Date: Tue, 23 Jan 2001 00:16:55
Subject: Ñ¡»¡¢ñÑ»¡¢×Ô¼º¶¨ÖÆ×°Êλ...
Message-ID: <20020121160807.E96AD255AB@www.haskell.org>
´º½Ú¿ìÒªµ½ÁË!
ÄãÊÇ·ñ×¼±¸°Ñ°®¼Ò×°ÊÎÒ»ÐÂÄØ£¿
ÊÇ·ñÕýΪËÍÇ×ÅóºÃÓÑʲôÀñÎï·¢³îÄØ£¿
¿ìÀ´ÎÒÃǵÄÍøÕ¾¶¨ÖƺÏÊÊ×Ô¼º»òÄãÅóÓѵÄ×°Êλ¡¢µçÓ°º£±¨À²£¡
Ñ¡»¡¢ñÑ»¡¢×Ô¼º¶¨ÖÆ×°Êλ...
http://www.onwall.net
E-mail:Server@onwall.net
QQ×°ñÑÖ§³Ö:28888808
±§Ç¸ÔÚδÕ÷µÃÄúͬÒâµÄÇé¿öÏ·¢Ëͱ¾Óʼþ
µ«Ô¸ÎÒÃǵÄÍøÕ¾ÕæÄÜΪÄãÌṩ·þÎñ!
ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡
ÏÂÔØÍøÖ·£ºhttp://love2net.51.net/£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡¡
----------------------------------------------------
INFORMATION
This message has been sent using a trial-run version
of the TSmtpRelayServer Delphi Component.
----------------------------------------------------
From gmh@Cs.Nott.AC.UK Tue Jan 2 10:52:36 2001
From: gmh@Cs.Nott.AC.UK (Graham Hutton)
Date: Tue, 02 Jan 2001 10:52:36 +0000
Subject: JFP Special Issue on Haskell
Message-ID: <20010102105313.4684FFCE@www.haskell.org>
Dear all,
Please note that the deadline for submission to the JFP Special Issue
on Haskell is in one months time --- 1st February 2001.
Graham Hutton
----------------------------------------------------------------------
CALL FOR PAPERS
Journal of Functional Programming
Special Issue on Haskell
Since its inception in 1987, Haskell has provided a focal point for
research in lazy functional programming. During this time the
language has continually evolved, as a result of both theoretical
advances and practical experience. Haskell has proved to be a
powerful tool for many kinds of programming tasks, and applications in
industry are beginning to emerge. The recent definition of Haskell 98
provides a long-awaited stable version of the language, but there are
many exciting possibilities for future versions of Haskell.
The fourth Haskell Workshop was held as part of the PLI 2000
colloquium on Principles, Logics, and Implementations of high-level
programming languages in Montreal, 17th September 2000. Previous
Haskell Workshops have been held in Paris (1999), Amsterdam (1997) and
La Jolla (1995). Following on from these workshops, a special issue
of the Journal of Functional Programming will be devoted to Haskell.
Possible topics include, but are not limited to:
Critiques of Haskell 98;
New proposals for Haskell;
Applications or case studies;
Programming techniques;
Reasoning about programs;
Semantic issues;
Pedagogical issues;
Implementation.
Contributors to any of the Haskell workshops are invited to submit
full papers to the special issue on Haskell, but submission is open to
everyone. Submissions should be sent to the guest editor (address
below), with a copy to Nasreen Ahmad (nasreen@dcs.gla.ac.uk).
Submitted articles should be sent in postscript format, preferably
gzipped and uuencoded. In addition, please send, as plain text, title,
abstract, and contact information. The submission deadline is 1st
February 2001. For other submission details, please consult an issue
of JFP or see the Journal's web pages.
Guest Editor:
Graham Hutton
School of Computer Science and IT
The University of Nottingham
Nottingham NG8 1BB
United Kingdom
gmh@cs.nott.ac.uk
Useful Links:
2000 Haskell Workshop www.cs.nott.ac.uk/~gmh/hw00.html
JFP Special Issue on Haskell www.cs.nott.ac.uk/~gmh/jfp.html
JFP Home Page www.dcs.gla.ac.uk/jfp
----------------------------------------------------------------------
From paul.hudak@yale.edu Tue Jan 2 14:14:33 2001
From: paul.hudak@yale.edu (Paul Hudak)
Date: Tue, 02 Jan 2001 09:14:33 -0500
Subject: Learning Haskell and FP
References: <3233BEE02CB3D4118DBA00A0C99869401D61EA@hermes.pml.com> <200012281250500955.006178FD@mail>
Message-ID: <3A51E249.AE219202@yale.edu>
> Unforunately, the "Gentle Introduction To Haskell" that
> haskell.org links to is not a very useful introduction.
John and I should probably rename this document, since it really isn't a
very gentle intro at all. We should probably also downplay it's
prominance on the haskell website. It was written rather quickly many
years ago, at a time when there was not a single textbook on Haskell.
So it's probably outlived it's purpose, although I do believe that some
people still find it useful.
-Paul
From ger@tzi.de Tue Jan 2 14:27:20 2001
From: ger@tzi.de (George Russell)
Date: Tue, 02 Jan 2001 15:27:20 +0100
Subject: Learning Haskell and FP
References: <3233BEE02CB3D4118DBA00A0C99869401D61EA@hermes.pml.com> <200012281250500955.006178FD@mail> <3A51E249.AE219202@yale.edu>
Message-ID: <3A51E548.93C835AB@tzi.de>
Paul Hudak wrote:
>
> > Unforunately, the "Gentle Introduction To Haskell" that
> > haskell.org links to is not a very useful introduction.
>
> John and I should probably rename this document, since it really isn't a
> very gentle intro at all. We should probably also downplay it's
> prominance on the haskell website. It was written rather quickly many
> years ago, at a time when there was not a single textbook on Haskell.
> So it's probably outlived it's purpose, although I do believe that some
> people still find it useful.
I think Paul is being unduly modest. I found it very useful when I first learnt
Haskell. But I did already know ML, so maybe the "Gentle Introduction" would be
harder going for someone who didn't know anything about functional programming.
Nevertheless I think it might be a mistake to downplay it unless there's a better
publicly-available introduction with which you can replace it.
The introduction states quite clearly that
> Our goal is to provide a gentle introduction to Haskell for someone
> who has experience with at least one other language, preferably a
> functional language (even if only an "almost-functional" language
> such as ML or Scheme).
and then goes on to recommend a couple of texts giving more detailed
introductions to functional programming. I don't think one can ask for more.
From simonpj@microsoft.com Tue Jan 2 15:39:42 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 2 Jan 2001 07:39:42 -0800
Subject: List.partition a bit too eager
Message-ID: <74096918BE6FD94B9068105F877C002D01378487@red-pt-02.redmond.corp.microsoft.com>
It's a bug in the defn of 'partition' in the Haskell 98 report.
I have (still) failed to publish this as an errata, let alone revise
the report itself, so the buggy defn stands at present, I'm afraid.
I really plan to get to the revision in early '01.
Simon
| -----Original Message-----
| From: George Russell [mailto:ger@tzi.de]
| Sent: 22 December 2000 15:57
| To: haskell@haskell.org
| Subject: List.partition a bit too eager
|
|
| I think the following program
|
| import List
| main = putStr . show . fst . (partition id) . cycle $ [True,False]
|
| should display [True,True,True,...]. But instead, for both
| GHC and Hugs,
| you get a stack overflow. Is this a bug, or could someone
| explain it to me?
|
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
|
From jans@numeric-quest.com Tue Jan 2 10:52:57 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Tue, 2 Jan 2001 05:52:57 -0500 (EST)
Subject: Learning Haskell and FP
In-Reply-To: <3A51E548.93C835AB@tzi.de>
Message-ID:
On Tue, 2 Jan 2001, George Russell wrote:
> Paul Hudak wrote:
> >
> > > Unforunately, the "Gentle Introduction To Haskell" that
> > > haskell.org links to is not a very useful introduction.
> >
> > John and I should probably rename this document, since it really isn't a
> > very gentle intro at all. We should probably also downplay it's
> > prominance on the haskell website. It was written rather quickly many
> > years ago, at a time when there was not a single textbook on Haskell.
> > So it's probably outlived it's purpose, although I do believe that some
> > people still find it useful.
> [cut]
> Nevertheless I think it might be a mistake to downplay it unless
> there's a better publicly-available introduction with which you can
> replace it.
Very valid observation.
John, Paul:
Wouldn't be worthwhile and possible to gradually upgrade
it within some sort of a supervised documentation project at
Yale, as part of your regular teaching curriculum?
Jan
From ger@tzi.de Tue Jan 2 15:59:18 2001
From: ger@tzi.de (George Russell)
Date: Tue, 02 Jan 2001 16:59:18 +0100
Subject: List.partition a bit too eager
References: <74096918BE6FD94B9068105F877C002D01378487@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <3A51FAD6.9EFCC578@tzi.de>
Simon Peyton-Jones wrote:
>
> It's a bug in the defn of 'partition' in the Haskell 98 report.
> I have (still) failed to publish this as an errata, let alone revise
> the report itself, so the buggy defn stands at present, I'm afraid.
>
> I really plan to get to the revision in early '01.
One thing I would like to see changed is that every function should also
appear with a short description in English, as for the SML basis library.
This would be a huge improvement for those of us whose mother-tongue is
English and not Haskell, and would also mean that in cases such as these
the implementors would have more liberty to choose the best interpretation
consistent with the spirit of the standard.
(Irrelevant comment: I believe something similar happens with European
Union treaties, which are in a variety of versions in different languages
from Irish Gaelic to Swedish, all of which are deemed to have equal weight.
Translation errors are not unknown, and have to be sorted out by the
European Court of Justice.)
From patrick@watson.org Wed Jan 3 00:43:00 2001
From: patrick@watson.org (Patrick M Doane)
Date: Tue, 2 Jan 2001 19:43:00 -0500 (EST)
Subject: Learning Haskell and FP
In-Reply-To: <3A51E249.AE219202@yale.edu>
Message-ID:
On Tue, 2 Jan 2001, Paul Hudak wrote:
> > Unforunately, the "Gentle Introduction To Haskell" that
> > haskell.org links to is not a very useful introduction.
>
> John and I should probably rename this document, since it really isn't a
> very gentle intro at all. We should probably also downplay it's
> prominance on the haskell website. It was written rather quickly many
> years ago, at a time when there was not a single textbook on Haskell.
> So it's probably outlived it's purpose, although I do believe that some
> people still find it useful.
>
As another point of reference, I decided it was time to learn Haskell
recently and this guide is what I started with. I'm familiar with Standard
ML and O'Caml, and found the guide to be very easy to read and was a good
starting point. I had enough information that I could read other Haskell
source and understand what it was trying to do even if I didn't feel
comfortable about all the details for writing programs.
However, a related issue that has been causing a lot of difficulty is
system installation. I'm primarily interested in building stand-alone
executables where speed is an important factor, so ghc seemed the best
system to work with. I've been unable to get this to work at all on a
Windows system. It seems configured to use dynamic libraries but doesn't
come with any in the package. I tried building from source, but it
requires Happy to build (and that too needed the .dlls).
On the Unix side, the installation was much smoother. I installed from
source using the FreeBSD port system and everything came together without
a hitch (it was a rather lengthy compile process though!).
There is a definite lack of "Getting Started" material in the ghc
distribution.
Documentation on libraries is also rather distributed. Sometimes I need to
look in the GHC manual about a library that is included with the
distribution, other times I need to look in the Haskell standard library
report. And if that fails, look in the Haskell standard language report
for information on what is included in the Prelude. Collecting this
information together would be a big benefit.
I've installed Hugs on the Windows side recently, and it seemed to boot up
okay. I haven't tried looking into its documentation to see if things are
any different.
Overall, I'm very pleased with the lannguage design and am excited about
its future.
Patrick
From kh0ndor@aeiou.pt Wed Jan 3 03:01:53 2001
From: kh0ndor@aeiou.pt (kh0ndor@aeiou.pt)
Date: Wed, 3 Jan 2001 03:01:53 GMT
Subject: (no subject)
Message-ID: <200101030301.DAA22807@xekmail.aeiou.pt>
somebody can tell me where I can find some ideas that help me in the
construction of a minesweeper programmed in haskell
I thank any type of help because I am a little confused
__________________________________________________________
Mensagem enviada pelo Xekmail: webmail grátis do AEIOU
http://xekmail.aeiou.pt
From ketil@ii.uib.no Wed Jan 3 07:28:22 2001
From: ketil@ii.uib.no (Ketil Malde)
Date: 03 Jan 2001 08:28:22 +0100
Subject: Learning Haskell and FP
In-Reply-To: George Russell's message of "Tue, 02 Jan 2001 15:27:20 +0100"
References: <3233BEE02CB3D4118DBA00A0C99869401D61EA@hermes.pml.com>
<200012281250500955.006178FD@mail> <3A51E249.AE219202@yale.edu>
<3A51E548.93C835AB@tzi.de>
Message-ID:
George Russell writes:
> I think Paul is being unduly modest. I found it very useful when I first learnt
> Haskell. But I did already know ML, so maybe the "Gentle Introduction" would be
> harder going for someone who didn't know anything about functional programming.
Mind if I "me too" a bit? I had just read the SICP, and I too found
that the Gentle Introduction served well as an introduction to the
Haskell syntax. I think it'd be fine if the title were a bit less
ambitious - it isn't really aimed at the novice, I think.
It's been a while since I read it tho'
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From syring@email.com Wed Jan 3 07:53:21 2001
From: syring@email.com (Karl M. Syring)
Date: Wed, 3 Jan 2001 08:53:21 +0100
Subject: Learning Haskell and FP
In-Reply-To:
Message-ID: <000101c0755a$3e1083b0$1e08363e@fenris>
> -----Original Message-----
> From: haskell-admin@haskell.org [mailto:haskell-admin@haskell.org]On
> Behalf Of Ketil Malde
> Sent: Wednesday, January 03, 2001 8:28 AM
> To: George Russell
> Cc: paul.hudak@yale.edu; i r thomas; haskell@haskell.org
> Subject: Re: Learning Haskell and FP
>
>
> George Russell writes:
>
> > I think Paul is being unduly modest. I found it very useful
> when I first learnt
> > Haskell. But I did already know ML, so maybe the "Gentle
> Introduction" would be
> > harder going for someone who didn't know anything about
> functional programming.
>
> Mind if I "me too" a bit? I had just read the SICP, and I too found
> that the Gentle Introduction served well as an introduction to the
> Haskell syntax. I think it'd be fine if the title were a bit less
> ambitious - it isn't really aimed at the novice, I think.
>
> It's been a while since I read it tho'
If you start out with zero knowledge in functional programming, as I do, the
GITH is really not very helpful. I have found the Clean tutorial
(cleanBookI.pdf) a good place to get my feet wet. Now, I gently try to move
on.
Regards
Karl M. Syring
PS: are the members of the list expecting to get replies by private mail?
From shlomif@vipe.technion.ac.il Wed Jan 3 08:11:51 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Wed, 3 Jan 2001 10:11:51 +0200 (IST)
Subject: (no subject)
In-Reply-To: <200101030301.DAA22807@xekmail.aeiou.pt>
Message-ID:
On Wed, 3 Jan 2001 kh0ndor@aeiou.pt wrote:
> somebody can tell me where I can find some ideas that help me in the=20
> construction of a minesweeper programmed in haskell
> I thank any type of help because I am a little confused=20
>
Check out the Haskell Gtk bindings.
Regards,
=09Shlomi Fish
=20
> __________________________________________________________
> Mensagem enviada pelo Xekmail: webmail gr=E1tis do AEIOU
> http://xekmail.aeiou.pt
>=20
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>=20
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il=20
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of=20
converting any statement that follows it into a true one.
From ketil@ii.uib.no Wed Jan 3 08:25:23 2001
From: ketil@ii.uib.no (Ketil Malde)
Date: 03 Jan 2001 09:25:23 +0100
Subject: Learning Haskell and FP
In-Reply-To: "Karl M. Syring"'s message of "Wed, 3 Jan 2001 08:53:21 +0100"
References: <000101c0755a$3e1083b0$1e08363e@fenris>
Message-ID:
"Karl M. Syring" writes:
>> Mind if I "me too" a bit? I had just read the SICP, and I too found
>> that the Gentle Introduction served well as an introduction to the
>> Haskell syntax.
> If you start out with zero knowledge in functional programming, as I do, the
> GITH is really not very helpful.
Exactly. It's "gentle" if you know functional programming, but
probably not otherwise.
> PS: are the members of the list expecting to get replies by private mail?
Expecting? I'd have no qualms about replying to people privately, but
then perhaps I am the obnoxious kind of person. :-) Negative feedback
is scarce (although this thread might favorably diverge to -cafe?
Followup-To: set).
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From simonpj@microsoft.com Wed Jan 3 09:02:00 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 3 Jan 2001 01:02:00 -0800
Subject: Learning Haskell and FP
Message-ID: <74096918BE6FD94B9068105F877C002D013784B8@red-pt-02.redmond.corp.microsoft.com>
| PS: are the members of the list expecting to get replies by
| private mail?
The thing to do is to switch the thread to
haskell-cafe@haskell.org
haskell@haskell-org is meant for openers; longer threads should
move to haskell-cafe. That way people can control how inundated they
get.
You can "move" by simply adding "-cafe" into the address when you reply.
Simon
From sk@mathematik.uni-ulm.de Wed Jan 3 09:14:45 2001
From: sk@mathematik.uni-ulm.de (Stefan Karrmann)
Date: Wed, 3 Jan 2001 10:14:45 +0100
Subject: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
In-Reply-To: <3A42661E.7FCCAFFA@tzi.de>; from ger@tzi.de on Thu, Dec 21, 2000 at 09:20:46PM +0100
References: <3A42661E.7FCCAFFA@tzi.de>
Message-ID: <20010103091445.481.qmail@theseus.mathematik.uni-ulm.de>
A syntax to choose the active instances may be useful, too.
E.g.:
use EccenticOrd, SetCollection in exp
then in exp the instances EccenticOrd, SetCollection are known (or preferred).
This is similiar to the open syntax in Cayenne.
--
Stefan Karrmann
From simonpj@microsoft.com Wed Jan 3 09:28:41 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 3 Jan 2001 01:28:41 -0800
Subject: Learning Haskell and FP
Message-ID: <74096918BE6FD94B9068105F877C002D013784BC@red-pt-02.redmond.corp.microsoft.com>
| There is a definite lack of "Getting Started" material in the ghc
| distribution.
I'm sure that's right. Trouble is, we're the last people qualified
to write one!
Here's a suggestion: would someone like to write such a guide,
from the point of view of a beginner, leaving blanks that we can fill in,
when you come across a task or issue you don't know the answer
to? That is, you provide the skeleton, and we fill in the blanks.
Simon
From syring@email.com Wed Jan 3 09:59:41 2001
From: syring@email.com (Karl M. Syring)
Date: Wed, 3 Jan 2001 10:59:41 +0100
Subject: Learning Haskell and FP
In-Reply-To: <74096918BE6FD94B9068105F877C002D013784B8@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <000401c0756b$e456ad10$1e08363e@fenris>
> -----Original Message-----
> From: Simon Peyton-Jones [mailto:simonpj@microsoft.com]
> Sent: Wednesday, January 03, 2001 10:02 AM
> To: syring@email.com; haskell@haskell.org
> Subject: RE: Learning Haskell and FP
>
>
> | PS: are the members of the list expecting to get replies by
> | private mail?
>
> The thing to do is to switch the thread to
>
> haskell-cafe@haskell.org
>
> haskell@haskell-org is meant for openers; longer threads should
> move to haskell-cafe. That way people can control how inundated they
> get.
>
> You can "move" by simply adding "-cafe" into the address when you reply.
I was somewhat irritated about the inclusion of the individual reply
adresses. Most mailing list software seems to remove the email adresses of
the senders. On the other hand, there are people that use the private mail
for archiving purposes, iff the content seems to be potentially important
while forwarding the letters send to the list to bit nirvana.
Regards
Karl M. Syring
From atze@cs.uu.nl Wed Jan 3 10:05:49 2001
From: atze@cs.uu.nl (Atze Dijkstra)
Date: Wed, 3 Jan 2001 11:05:49 +0100
Subject: GHC/Happy on MacOS X/Darwin
In-Reply-To: <20001221170104.9CDA21030@www.haskell.org>
References: <20001221170104.9CDA21030@www.haskell.org>
Message-ID:
On http://www.cs.uu.nl/~atze/Programming/index.html a version of ghc (4.08.1) and happy (still 1.8) for MacOS X/Darwin can be downloaded. However, a few remarks do apply: this version of ghc is not a completely ported version but built with generic settings and meant as a bootstrapping compiler. It also is distributed as binaries for a specific location (/usr/local/{ghc,happy}) in the UNIX directory structure. The main reasons for distributing it in this unfinished form are:
- The MacOS X cc (c compiler) has some (blocking) bugs (for example, problems with asm statements) which hinder progress.
- I consider 'unfinished' availability now of greater importance than 'perfect' availability later, so people can play with it.
- The compiler seems to run ok, that is, after minimal testing (compiling ghc libraries and a local AG + parsercombinator system).
--
- Atze -
Atze Dijkstra, Dept. of Computer Science, Utrecht University /|\
Tel.: +31-30-2534093/1454 | WWW : http://www.cs.uu.nl/~atze / | \
Fax : +31-30-2513971 | Email: atze@cs.uu.nl /--| \
atze.dijkstra@hetnet.nl / |___|
From israelt@optushome.com.au Wed Jan 3 13:36:25 2001
From: israelt@optushome.com.au (i r thomas)
Date: Wed, 03 Jan 2001 23:36:25 +1000
Subject: Writing a beginners guide to Haskell
In-Reply-To: <74096918BE6FD94B9068105F877C002D013784BC@red-pt-02.redmond.corp.microsoft.com>
References: <74096918BE6FD94B9068105F877C002D013784BC@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <200101032336250747.00A255A5@mail>
>Here's a suggestion: would someone like to write such a guide,
>from the point of view of a beginner, leaving blanks that we can fill in,
>when you come across a task or issue you don't know the answer
>to? That is, you provide the skeleton, and we fill in the blanks.
Well, I am definitely a beginner and am prepared to take this on
I have had some exposure to Ada, C , C++, Prolog etc but definitely no=
previous FP experience before.
For some time now, I had been planning to write an introduction to Haskell=
for my son
He is a bright 14 year old who is familiar with Delphi and VB but has like=
me
has not done any functional programming before . If it is simple enough
for him, it should work as a true "Beginners guide to Haskell".
I propose that I write it section by section, and either post to the=
mailing list for corrections and feedback.
If there are objections , I will send it to those willing to correct it (=
hopefully these will include Paul Hudak and Simon Peyton Jones ) . If my=
ability to continue this falters or if I encounter a section that is too=
hard for me, ( at the moment, monads seem a likely candidate ! ) I'll pass=
the enterprise along to anyone else who is willing to take it on !
From shlomif@vipe.technion.ac.il Wed Jan 3 12:44:16 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Wed, 3 Jan 2001 14:44:16 +0200 (IST)
Subject: Learning Haskell and FP
In-Reply-To: <3A51E249.AE219202@yale.edu>
Message-ID:
On Tue, 2 Jan 2001, Paul Hudak wrote:
> > Unforunately, the "Gentle Introduction To Haskell" that
> > haskell.org links to is not a very useful introduction.
>
> John and I should probably rename this document, since it really isn't a
> very gentle intro at all. We should probably also downplay it's
> prominance on the haskell website. It was written rather quickly many
> years ago, at a time when there was not a single textbook on Haskell.
> So it's probably outlived it's purpose, although I do believe that some
> people still find it useful.
>
I learned Haskell from it. Later, people corrected my style and I learned
some more. Of course, I did not do any serious Haskell programming yet,
except for my infamous primes finding algorithms.
Regards,
Shlomi Fish
> -Paul
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From paul.hudak@yale.edu Wed Jan 3 14:51:10 2001
From: paul.hudak@yale.edu (Paul Hudak)
Date: Wed, 03 Jan 2001 09:51:10 -0500
Subject: Learning Haskell and FP
References:
Message-ID: <3A533C5E.5F0879B5@yale.edu>
Thanks to everyone for their comments regarding "GITH". I conclude
that:
-- it is useful to people who have previously programmed in Scheme
or some other functional language
-- it is a difficult read for those not familiar with FP concepts,
and certainly not appropriate for novice programmers
-- given the dearth of free documentation on Haskell, it serves a
useful purpose
-- the title is misleading
Also thanks to George Russell for reminding me that the intro states
clearly that:
> Our goal is to provide a gentle introduction to Haskell for someone
> who has experience with at least one other language, preferably a
> functional language (even if only an "almost-functional" language
> such as ML or Scheme).
So I suppose the main thing that John and I should think about is
changing the title. Something like "An Introduction to Haskell for
People Who Have Previously Programmed in Scheme or Some Other Functional
Language" might be good! :-) Of course changing the title might confuse
people to whom the document was recommended. It may be that a
clarifying remark on haskell.org is warranted.
Anyway, thanks again for the comments.
Best to All for the New Year,
-Paul
From peterson-john@cs.yale.edu Wed Jan 3 15:02:01 2001
From: peterson-john@cs.yale.edu (John Peterson)
Date: Wed, 3 Jan 2001 10:02:01 -0500
Subject: Learning Haskell and FP
In-Reply-To: <3A533C5E.5F0879B5@yale.edu> (message from Paul Hudak on Wed, 03
Jan 2001 09:51:10 -0500)
References: <3A533C5E.5F0879B5@yale.edu>
Message-ID: <200101031502.KAA27959@ragged.cs.yale.edu>
One more thing: I'm happy to incorporate any tutorial material into
haskell.org. If you have material that would be appropriate please
let me know and I'll add it to the site. I know there are some very
good slides from Haskell courses that could be put into haskell.org.
The document sources to the Gentle Intro are also available. We've
already had some very generous help with it and Paul and I will be
happy to support anyone that would like to improve it further.
Finally, another thing that would be really nice in the way of
tutorials is one from the perspective of an experienced C++ / Java
programmer. Even a relatively short work that maps between the O-O
terminology and the Haskell world would be quite useful.
John
From ger@tzi.de Wed Jan 3 15:07:15 2001
From: ger@tzi.de (George Russell)
Date: Wed, 03 Jan 2001 16:07:15 +0100
Subject: Learning Haskell and FP
References: <3A533C5E.5F0879B5@yale.edu>
Message-ID: <3A534023.11EA3037@tzi.de>
Paul Hudak wrote:
[snip]
> So I suppose the main thing that John and I should think about is
> changing the title. Something like "An Introduction to Haskell for
> People Who Have Previously Programmed in Scheme or Some Other Functional
> Language" might be good! :-)
"A Gentle Introduction to Haskell for Functional Programmers" might be better.
Then hopefully people who have been directed to "A Gentle Introduction" will
not be confused.
From zawrotny@gecko.sb.fsu.edu Wed Jan 3 16:26:53 2001
From: zawrotny@gecko.sb.fsu.edu (Michael Zawrotny)
Date: Wed, 03 Jan 2001 11:26:53 -0500
Subject: Learning Haskell and FP
In-Reply-To: Your message of "Wed, 03 Jan 2001 09:51:10 EST."
<3A533C5E.5F0879B5@yale.edu>
Message-ID: <20010103162602.86980FCE@www.haskell.org>
Paul Hudak wrote:
> Thanks to everyone for their comments regarding "GITH". I conclude
> that:
>
> -- it is useful to people who have previously programmed in Scheme
> or some other functional language
> -- it is a difficult read for those not familiar with FP concepts,
> and certainly not appropriate for novice programmers
> -- given the dearth of free documentation on Haskell, it serves a
> useful purpose
> -- the title is misleading
>
> Also thanks to George Russell for reminding me that the intro states
> clearly that:
>
> > Our goal is to provide a gentle introduction to Haskell for someone
> > who has experience with at least one other language, preferably a
> > functional language (even if only an "almost-functional" language
> > such as ML or Scheme).
GITH was a bit much for me. However, I have a slightly different
take on the reason why. My original background (undergrad
and PhD) is in biochemistry. Most of my programming, etc. is
self-taught, although I got through about third year's worth of
course work for an undergrad CS degree while I was at my previous
job. In the course of teaching myself various things, I dabbled
in both scheme and common lisp and more recently in SML and OCaml
(and obviously Haskell as well).
The reason that I found GITH difficult wasn't that the concept
of programming with functions/functional style was new to
me. What got me was that the concepts and notations were much
more "mathematical" than "programmatic". In my explorations
of various languages, my experience with introductions to
scheme/CL has mostly been that they tend to show how to do
things that are familiar to imperative programmers, plus all
of the things that you can do with functions as first class
values. With intros to SML, OCaml and Haskell, there is a
much greater emphasis on types, type systems, and provable
program correctness. The main difference being the emphasis
on doing familiar things in a better way followed by some new
things (scheme/lisp intros) versus throwing you into what may
be completely uncharted territory (formal type systems, monads,
functors) in SML/OCaml/Haskell intros.
There also seems to be the tendency to assume that the meaning of
a type signature like
map :: (a->b) -> [a] -> [b]
is inherently obvious. To someone unfamiliar with HM type
systems and whose last course in mathematics was more than a
decade ago, it might as well be greek.
The thing that I would most like to see would entitled "A
Practical Guide to Haskell" or something of that nature. After
working through some of the online tutorials and a fair portion
of "Craft of Functional Programming", I thought, "Ok, I do most
of these excercises, and am comfortable. Let's try that utility
program I've been thinking about for the last couple weeks."
What I ran into was scenarios like the ones listed below (some of
which have since been solved):
1. How the #$!? do I read some data from a file. Good, I've
got the data, now I can work on it. Nope, now I have an "IO
thingie" whatever that is, but all of the standard functions want
a regular "thingie" now what?
2. I need to do some XML processing. Go to haskell.org, find
links to HaXML and install it. Try to use it... Nope, no
documentation that is understandable to me. Ok, look at the
source to the one demo program that does something close to
what I want. Nope, it was written in the "It's functional and
therefore self-documenting" style. (Note, this is not intended
to be a shot at the implementors of HaXML. It is clear from
the description of the library and the functions of the included
programs that the library is complete and well thought out. I
am also sure that someone already fluent in Haskell who is used
to looking at type signatures to deduce the purpose of a function
can do sophisticated things with it. My only criticism was that
it wasn't approachable to someone who is starting to feel somewhat
comfortable with Haskell and wants to "do" something useful with it,
as opposed to exercises from a book or tutorial.)
3. I gave up on Haskell for that particular utility and wrote it
OCaml.
One is tempted to come to the conclusion that Haskell is not
suited for "normal" programmers writing "normal" programs. I
don't necessarily think that is true, but it is difficult for
someone who is used to imperative/OO style programming and has
dabbled in impure functional languages.
To be fair, I had almost the same reaction to SML/OCaml when I
first encountered them. Working on Haskell and reading "Craft"
made it much easier to go back and look at them again. It's
probably that in the spectrum of imperative ----> functional
languages, scheme/CL are farther to the left than SML/OCaml,
which is still left of Haskell. In the case of someone like me
coming from C, C++, perl, python, etc., the extreme right is
inherently much less familiar territory than the middle ground.
The tendency of the written materials to get more mathematical as
one moves to the right also exacerbates the problem.
That was my reaction when I read GITH and some of the other
introductory material around. A lot of this probably is
more relevant to the people who are thinking of writing
a lower-level intro than it is to the next edition of
The-Document-Formerly-Known-As-GITH.
My plea is for people include introductory material for people
who know how to program in general and want to do mundane tasks
in Haskell as opposed to C, Python, or whatever other language.
Mike
--
Michael Zawrotny
411 Molecular Biophysics Building
Florida State University | email: zawrotny@sb.fsu.edu
Tallahassee, FL 32306-4380 | phone: (850) 644-0069
From mpj@cse.ogi.edu Wed Jan 3 17:05:07 2001
From: mpj@cse.ogi.edu (Mark P Jones)
Date: Wed, 3 Jan 2001 09:05:07 -0800
Subject: Problem with functional dependencies
In-Reply-To: <74096918BE6FD94B9068105F877C002D013783CC@red-pt-02.redmond.corp.microsoft.com>
Message-ID:
| I think you can simplify the example. Given
|=20
| class HasFoo a b | a -> b where
| foo :: a -> b
| instance HasFoo Int Bool where ...
|=20
| Is this legal?
| f :: HasFoo Int b =3D> Int -> b
| f x =3D foo x
The theoretical foundation for functional dependencies goes back to
the work I did on "Simplifying and Improving Qualified Types".
(Interested parties can find a 1994 report on this on my web pages;
email me if you need a pointer.)
According to that theory, the type above is a "principal satisfiable
type" for f, as is the more accurate Int -> Bool: under the
satisfiability ordering described in the report, these two types
are (satisfiably) equivalent. There is, therefore, no technical
reason why the function f could not be treated as having the
polymorphic type shown above.
On the other hand, from a practical perspective, one can argue that
the polymorphic type is misleading, obfuscating, and cumbersome:
Misleading because f doesn't really have a polymorphic type as the
declaration pretends; Obfuscating because it forces a reader to
study instance declarations that are not included in the type;
and Cumbersome because it includes an unnecessary (HasFoo Int b)
constraint that could be eliminated to produce a shorter, simpler
type.
So it comes down to a language design *decision* for which functional
dependencies, by themselves, do not force a particular choice.
- The current Hugs implementation does not allow the polymorphic
type; the intention in that implementation was to infer more
accurate, less complex types. The idea here is to make programs
easier for programmers to read, write, and understand.
- Marcin indicates that he would prefer the more relaxed approach
that allows polymorphic types; he is writing a preprocessor that
generates type signatures, and his task is easier if he doesn't
have to worry about the "improvement" of class constraints.
The idea here is to make programs easier for generators to read,
write and manipulate.
Clearly, some compromise is needed because neither approach is right
for all purposes. If we look to other aspects of the language for
inspiration, then the best way to deal with this is (probably):
(i) to infer simpler types whenever possible, but
(ii) to allow more polymorphic types when they are requested by
means of an explicit type signature.
(Incidentally, in the interests of consistency, such a system should
also programmers to use types like Num Int =3D> Int -> Bool.)
All the best,
Mark
From fjh@cs.mu.oz.au Wed Jan 3 17:37:55 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Thu, 4 Jan 2001 04:37:55 +1100
Subject: Problem with functional dependencies
In-Reply-To:
References: <74096918BE6FD94B9068105F877C002D013783CC@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20010104043755.A27457@hg.cs.mu.oz.au>
On 03-Jan-2001, Mark P Jones wrote:
> ... the best way to deal with this is (probably):
> (i) to infer simpler types whenever possible, but
> (ii) to allow more polymorphic types when they are requested by
> means of an explicit type signature.
I agree.
> (Incidentally, in the interests of consistency, such a system should
> also programmers to use types like Num Int => Int -> Bool.)
Mercury uses the approach you've suggested above for constraints like
these. That is, you can declare types like that, and the Mercury
type checker will accept them, but it won't try to infer such types.
This feature could be a bit more useful in Mercury than in Haskell,
since in Mercury instance declarations can be private to a particular
module.
(Unfortunately, though, the Mercury runtime system's RTTI
representation of instances is not able to handle such constraints, so
for such examples, the current implementation of the compiler reports
"sorry, not implemented: constraints may only constrain type variables".)
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From haberg@matematik.su.se Wed Jan 3 18:01:38 2001
From: haberg@matematik.su.se (Hans Aberg)
Date: Wed, 3 Jan 2001 19:01:38 +0100
Subject: GHC/Happy on MacOS X/Darwin
In-Reply-To:
References: <20001221170104.9CDA21030@www.haskell.org>
<20001221170104.9CDA21030@www.haskell.org>
Message-ID:
[Replies please cc me or the hugs-bugs list, as I currently is not on the
Haskell list.]
At 11:05 +0100 1-01-03, Atze Dijkstra wrote:
>On http://www.cs.uu.nl/~atze/Programming/index.html a version of ghc
>(4.08.1) and happy (still 1.8) for MacOS X/Darwin can be downloaded.
>However, a few remarks do apply: this version of ghc is not a completely
>ported version but built with generic settings and meant as a
>bootstrapping compiler. It also is distributed as binaries for a specific
>location (/usr/local/{ghc,happy}) in the UNIX directory structure. The
>main reasons for distributing it in this unfinished form are:
>- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>problems with asm statements) which hinder progress.
Isn't this related to the "munging" that GHC makes use of on other platforms?
>- I consider 'unfinished' availability now of greater importance than
>'perfect' availability later, so people can play with it.
>- The compiler seems to run ok, that is, after minimal testing (compiling
>ghc libraries and a local AG + parsercombinator system).
Otherwise it sounds great: As no-one before has been able to port anything
of GHC to MacOS (as far as I know), any kind of progress is important. (I
do not have access to MacOS X right now, so unfortunatley I cannot try out
your port.)
Hans Aberg
From qrczak@knm.org.pl Wed Jan 3 18:40:30 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 3 Jan 2001 18:40:30 GMT
Subject: Problem with functional dependencies
References:
Message-ID:
I don't fully understand fundeps. Would the following transform
legal programs (without overlapping instances) into legal programs?
I hope yes.
Let's imagine a class with a set of instances and uses, without
fundeps.
- Add some additional type variables to the class header.
- Add a fundep: all old type variables -> all new type variables.
- For each instance, in places corresponding to new type variables
write arbitrary types.
- For each constraint based on this class, in places corresponding
to new type variables write unique type variables.
In particular, should the following be legal:
class C a b c | a -> b c
instance C [a] b b
f:: C [a] b c => a
f = undefined
ghc panics and Hugs rejects it.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From atze@cs.uu.nl Wed Jan 3 19:48:59 2001
From: atze@cs.uu.nl (Atze Dijkstra)
Date: Wed, 3 Jan 2001 20:48:59 +0100
Subject: GHC/Happy on MacOS X/Darwin
In-Reply-To:
References: <20001221170104.9CDA21030@www.haskell.org>
<20001221170104.9CDA21030@www.haskell.org>
Message-ID:
At 19:01 +0100 03/01/2001, Hans Aberg wrote:
> >- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>>problems with asm statements) which hinder progress.
>
>Isn't this related to the "munging" that GHC makes use of on other platforms?
Apple's cc (actually gcc) does not accept 'asm' statements the way the manual describes it (it fails to parse them). asm statements are used to map GHC runtime pseudo registers to actual powerpc machine registers. The assembly source postprocessing does not work either (it is turned off) but is not related to this problem (to my knowledge).
--
- Atze -
Atze Dijkstra, Dept. of Computer Science, Utrecht University /|\
Tel.: +31-30-2534093/1454 | WWW : http://www.cs.uu.nl/~atze / | \
Fax : +31-30-2513971 | Email: atze@cs.uu.nl /--| \
atze.dijkstra@hetnet.nl / |___|
From haberg@matematik.su.se Wed Jan 3 20:03:56 2001
From: haberg@matematik.su.se (Hans Aberg)
Date: Wed, 3 Jan 2001 21:03:56 +0100
Subject: GHC/Happy on MacOS X/Darwin
In-Reply-To:
References:
<20001221170104.9CDA21030@www.haskell.org>
<20001221170104.9CDA21030@www.haskell.org>
Message-ID:
At 20:48 +0100 1-01-03, Atze Dijkstra wrote:
>At 19:01 +0100 03/01/2001, Hans Aberg wrote:
>> >- The MacOS X cc (c compiler) has some (blocking) bugs (for example,
>>>problems with asm statements) which hinder progress.
>>
>>Isn't this related to the "munging" that GHC makes use of on other platforms?
>
>Apple's cc (actually gcc) does not accept 'asm' statements the way the
>manual describes it (it fails to parse them). asm statements are used to
>map GHC runtime pseudo registers to actual powerpc machine registers. The
>assembly source postprocessing does not work either (it is turned off) but
>is not related to this problem (to my knowledge).
I think that it was Will Partain that described the problem as though one
had to do some assembly local to the CPU in order to get put the munging
through (perhaps I misunderstood it). -- So even if Apple's gcc accepted
asm, there would some (hard) work to do, in figuring out how the PPC (G3 &
G4) assmebly worked.
Hans Aberg
From russell@brainlink.com Thu Jan 4 04:11:38 2001
From: russell@brainlink.com (Benjamin L. Russell)
Date: Wed, 03 Jan 2001 23:11:38 -0500
Subject: Learning Haskell and FP
In-Reply-To: <20010103162602.86980FCE@www.haskell.org>
Message-ID:
On Wed, 03 Jan 2001 11:26:53 -0500
Michael Zawrotny wrote:
>
> [snip]
>
> The reason that I found GITH difficult wasn't that the
> concept
> of programming with functions/functional style was new to
> me. What got me was that the concepts and notations were
> much
> more "mathematical" than "programmatic". In my
> explorations
> of various languages, my experience with introductions to
> scheme/CL has mostly been that they tend to show how to
> do
> things that are familiar to imperative programmers, plus
> all
> of the things that you can do with functions as first
> class
> values. With intros to SML, OCaml and Haskell, there is
> a
> much greater emphasis on types, type systems, and
> provable
> program correctness.
>
> [snip]
>
> The thing that I would most like to see would entitled "A
> Practical Guide to Haskell" or something of that nature.
>
> [snip]
>
> One is tempted to come to the conclusion that Haskell is
> not
> suited for "normal" programmers writing "normal"
> programs.
How would you define a "'normal' programmer writing 'normal' programs?" What exactly is a "'normal' program?"
(Perhaps another way of phrasing the issue is as the "declarative" vs. "procedural" distinction, since the issue seems to be that of "what is" (types) vs. "how to" (imperative expression; i.e., procedures).)
While I agree that "A Practical Guide to Haskell" would indeed be a suitable alternative for programmers from the procedural school of expression, I would caution that such an introduction would probably not be suitable for all.
If I may give my own case as an example, I studied both C and Scheme (in addition to auditing a course in Haskell) in college, and favored Scheme over C precisely because of my Scheme course's emphasis on provable program correctness. This is largely a matter of background and taste: my course background was relatively focused on the design and analysis of algorithms, with provable program correctness being a related topic.
Perhaps, ideally, two separate tutorials (or perhaps a single tutorial with two sections based on different viewpoints?) may be needed? The difficulty is that the conceptual distance between the declarative and procedural schools of thought seems too great to be bridged by a single viewpoint. It seems that any introduction favoring either one would risk alienating the other.
Personally, I would really prefer "A Gentle Elementary Introduction to Haskell: Elements of the Haskell School of Expression with Practical Examples," but some would no doubt choose "Haskell in a Nutshell: How to Write Practical Programs in Haskell."
--Ben
--
Benjamin L. Russell
russell@brainlink.com
benjamin.russell.es.94@aya.yale.edu
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
From wli@holomorphy.com Thu Jan 4 07:18:49 2001
From: wli@holomorphy.com (William Lee Irwin III)
Date: Wed, 3 Jan 2001 23:18:49 -0800
Subject: Learning Haskell and FP
In-Reply-To: <74096918BE6FD94B9068105F877C002D013784BC@red-pt-02.redmond.corp.microsoft.com>; from simonpj@microsoft.com on Wed, Jan 03, 2001 at 01:28:41AM -0800
References: <74096918BE6FD94B9068105F877C002D013784BC@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <20010103231849.A16876@holomorphy.com>
On Wed, Jan 03, 2001 at 01:28:41AM -0800, Simon Peyton-Jones wrote:
> Here's a suggestion: would someone like to write such a guide,
> from the point of view of a beginner, leaving blanks that we can fill in,
> when you come across a task or issue you don't know the answer
> to? That is, you provide the skeleton, and we fill in the blanks.
If someone should be bold enough to start writing such a guide, I would
be more than happy than to try to contribute to it and also set it up as
a Debian package.
Cheers,
Bill
--
"AIX is Unix from the universe where Spock had a beard."
-- Unknown
From d95lars@dtek.chalmers.se Thu Jan 4 08:45:19 2001
From: d95lars@dtek.chalmers.se (Lars Lundgren)
Date: Thu, 4 Jan 2001 09:45:19 +0100 (MET)
Subject: Learning Haskell and FP
In-Reply-To: <20010103162602.86980FCE@www.haskell.org>
Message-ID:
On Wed, 3 Jan 2001, Michael Zawrotny wrote:
> 1. How the #$!? do I read some data from a file. Good, I've
> got the data, now I can work on it. Nope, now I have an "IO
> thingie" whatever that is, but all of the standard functions want
> a regular "thingie" now what?
>
I do not know if you actually wanted an answer to this, but I'm sick of
hearing this FAQ everywhere when the answer is so simple. There are
exactly two ways to do this (one of them is actually syntactic sugar for
the other).
1. Use the do notation:
do regularThingie <- IOThingie
return (doWhateverYouWantWith regularThingie)
2. Use bind ( >>= ):
IOThingie >>=
\regularThingie -> return (doWhateverYouWantWith regularThingie)
Note: Both constructs produces IO thingies. This is the real beauty of it,
if you have a value that is dependent on the environment (i.e. a IO value)
you can use it as a regular value inside one of the above constructs, but
the result will always be an IO value (The result will depend on the
environment because it uses a value dependent of the environment). This is
no problem, just accept it.
Can everyone include an answer to this FAQ everywhere, phleaze!
/Lars L
From Keith.Wansbrough@cl.cam.ac.uk Thu Jan 4 10:42:08 2001
From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough)
Date: Thu, 04 Jan 2001 10:42:08 +0000
Subject: Learning Haskell and FP
In-Reply-To: Your message of "Thu, 04 Jan 2001 09:45:19 +0100."
Message-ID:
> I do not know if you actually wanted an answer to this, but I'm sick of
> hearing this FAQ everywhere when the answer is so simple. There are
> exactly two ways to do this (one of them is actually syntactic sugar for
> the other).
[..]
> Can everyone include an answer to this FAQ everywhere, phleaze!
>
> /Lars L
Thanks Lars... I've added it to the Wiki.
HINT TO EVERYONE: *Anyone* can add this kind of thing to the Wiki.
Just find the appropriate page and click the EditText link at the
bottom. To create a new page just name it (in BiCapitalised form), and
the name becomes a hyperlink. Click on the link, then EditText on the
new page and you're done.
The Haskell Wiki is at:
http://haskell.org/wiki/wiki
I *do not* maintain it, I just evangelise for it. :-)
--KW 8-)
From simonpj@microsoft.com Thu Jan 4 10:51:23 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 4 Jan 2001 02:51:23 -0800
Subject: Learning Haskell and FP
Message-ID: <74096918BE6FD94B9068105F877C002D01378531@red-pt-02.redmond.corp.microsoft.com>
| > 1. How the #$!? do I read some data from a file. Good, I've
| > got the data, now I can work on it. Nope, now I have an "IO
| > thingie" whatever that is, but all of the standard functions want
| > a regular "thingie" now what?
Perhaps this would be a good moment to advertise the revised version of
Tackling the Tackling the Awkward Squad:
monadic input/output, concurrency, exceptions,
and foreign-language calls in Haskell
http://research.microsoft.com/~simonpj/#marktoberdorf
(Concerning the thread I'm responding to, it gives an introduction
to monadic input/output.)
I've revised and extended this tutorial quite a bit since I announced it
last year,
with a lot of help from people on the Haskell mailing list: thank you!
Further suggestions are most welcome.
Simon
Abstract
Functional programming may be beautiful, but to write real
applications we must grapple with awkward real-world issues:
input/output, robustness, concurrency, and interfacing to programs
written in other languages.
These lecture notes give an overview of the techniques that have
been
developed by the Haskell community to address these problems. I
introduce various proposed extensions to Haskell along the way, and
I
offer an operational semantics that explains what these extensions
mean.
From israelt@optushome.com.au Thu Jan 4 13:04:33 2001
From: israelt@optushome.com.au (i r thomas)
Date: Thu, 04 Jan 2001 23:04:33 +1000
Subject: Learning Haskell and FP
In-Reply-To: <74096918BE6FD94B9068105F877C002D01378531@red-pt-02.redmond.corp.microsoft.com>
References: <74096918BE6FD94B9068105F877C002D01378531@red-pt-02.redmond.corp.microsoft.com>
Message-ID: <200101042304330644.029280C6@mail>
>Perhaps this would be a good moment to advertise the revised version of
> Tackling the Tackling the Awkward Squad:
> monadic input/output, concurrency, exceptions,
> and foreign-language calls in Haskell
> http://research.microsoft.com/~simonpj/#marktoberdorf
>(Concerning the thread I'm responding to, it gives an introduction
>to monadic input/output.)
Many thanks !
This is just what I need.
Will read it before bed tonight...
From dfields@interpage.net Thu Jan 4 14:59:28 2001
From: dfields@interpage.net (Doug Fields)
Date: Thu, 4 Jan 2001 09:59:28 -0500 (EST)
Subject: Learning Haskell and FP
In-Reply-To: <200101031502.KAA27959@ragged.cs.yale.edu> from "John Peterson" at Jan 03, 2001 10:02:01 AM
Message-ID:
> One more thing: I'm happy to incorporate any tutorial material into
> haskell.org. If you have material that would be appropriate please
> let me know and I'll add it to the site. I know there are some very
> good slides from Haskell courses that could be put into haskell.org.
For what it's worth,
I'm happy to contribute my solutions to the exercises in
"Haskell: Craft" for posting on haskell.org. However, I assume that
in at least one place, the book is used for coursework and would, hence,
such posting would be discouraged.
Hi Paul. Hi Benjamin.
Cheers,
Doug
From rrt1001@cam.ac.uk Thu Jan 4 15:03:17 2001
From: rrt1001@cam.ac.uk (Reuben Thomas)
Date: Thu, 4 Jan 2001 15:03:17 +0000 (GMT)
Subject: Happy InstallShield update
Message-ID:
I just noticed that the Happy 1.9 InstallShield contained a dynamically
linked executable for Happy. This was a Bad Idea, so I've replaced it with a
statically linked executable. This should work for more people.
--
http://sc3d.org/rrt/ | maxim, n. wisdom for fools
From C.Reinke@ukc.ac.uk Thu Jan 4 18:34:26 2001
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Thu, 04 Jan 2001 18:34:26 +0000
Subject: ANNOUNCE: GHood -- a Graphical Hood (pre-release)
Message-ID:
Ever wanted to see what your Haskell program is doing?
Andy Gill's Hood library (http://www.haskell.org/hood/) represents
a big improvement over previous uses of trace & co. It doesn't affect
strictness properties, and instead of displaying debug information
in the nearly incomprehensible order in which it is generated, it
collects, post-processes and pretty-prints the information and displays
the results after program evaluation, in a more readable form.
However, as Andy already noted in the Hood documentation, there is
a lot of useful information to be gathered from the order in which
(parts of) data structures are observed. Now that Hood associates
individual observation events with the data structures to which they
belong, thus facilitating comprehension of observations, it would be
nice to find a way to visualise the observation order as well.
Andy's plan was to incorporate such a feature into a textual browser
add-on for Hood (in CVS, not released yet?). But for tasks for which
structural context and relationships between parts dominate over details,
my personal preference would be a graphical form of visualisation.
GHood is my current attempt to add a such a graphical viewer to Hood.
It hasn't yet reached its final form, but it is quite useful and usable
already. We have played with it locally, and I can't spent too much
time on this, but I would like to get some external feedback before
I finalise the development. Hence this pre-release.
Currently, GHood comes in two files: a drop-in replacement for the
Hugs98 variant of Hood (only minimal changes, same interface) and
a Java class file archive for the graphical viewer itself.
To find the two files, please visit my Haskell corner at:
http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/
Enjoy (and let me know what you think about it),
Claus
--
Claus Reinke, http://www.cs.ukc.ac.uk/people/staff/cr3/
Computing Lab, University of Kent at Canterbury
From mpj@cse.ogi.edu Thu Jan 4 21:01:56 2001
From: mpj@cse.ogi.edu (Mark P Jones)
Date: Thu, 4 Jan 2001 13:01:56 -0800
Subject: Problem with functional dependencies
In-Reply-To:
Message-ID:
Hi Marcin,
| In particular, should the following be legal:
|=20
| class C a b c | a -> b c
| instance C [a] b b
| f:: C [a] b c =3D> a
| f =3D undefined
|=20
| ghc panics and Hugs rejects it.
No, it is not legal. Even if you delete the definition of f, the code
is still not legal because the class and the instance declaration are
inconsistent.
The class declaration says that you want to define a three place =
relation
on types called C. We can think of the entries in this relation as rows
in a table with columns headed a, b, and c:
a | b | c
C =3D -----+-----+------
| |
Before we take a look at any instance declarations, this table is empty
(i.e., there are no rows). But the functional dependency a -> b c that
you have specified establishes a constraint that any data that gets =
added
to the table by subsequent instance declarations must satisfy. It says
that, if two rows have the same type in the a column, then they must =
also
have the same types in the b and c columns; "the values of b and c are
uniquely determined by the value of a."
So here are two plausible instance declarations that you could use:
instance C Int Int Char
instance C (Maybe t) t Int
Notice that the second declaration here is really an instance scheme;
the presence of a variable "t" means that it introduces a whole family
of instances, one for each possible instantiation of the variable "t".
With these two instance declarations in hand, our table looks something
like the following:
a | b | c
C =3D ------------------+-----------+------
Int | Int | Char
Maybe Int | Int | Int
Maybe Bool | Bool | Int
Maybe Char | Char | Int
Maybe [Int] | [Int] | Int
Maybe (Maybe Int) | Maybe Int | Int
... | ... | ...
Conceptually, of course, there are now infinitely many rows in the =
table,
so what you see here is just a small part of the relation. But notice =
that
the data in the table is entirely consistent with the functional =
dependency
a -> b c because no two rows have the same type in the a column.
Now consider the instance declaration that you have given:
instance C [t] s s
Again, this is an instance scheme, generating one row in the table
for each possible instantiation of variables "t" and "s". (To avoid
confusion with the names of the columns in C, I've chosen different
variable names from the ones you've used.) For example, based on
this instance declaration, we would expect to continue adding rows
to the table along the following lines:
a | b | c
C =3D ------------+-------+-------
[Int] | Int | Int t=3DInt, s=3DInt
[Int] | Bool | Bool t=3DInt, s=3DBool
[Bool] | Int | Int t=3DBool, s=3DInt
... | ... | ...
I hope now that the problem is becoming clear: this instance declaration
is not consistent with the dependency; in the first two lines above, for
example, we see two rows that violate the specification because they =
have
the same value of "a", but different values for "b" and "c".
In summary, the class declaration and its associated dependency are not
consistent with the instance declaration. If you really wanted the rows
described by the instance declaration to be part of the relation C, then
the dependency you have written is not valid. If you really did want =
the
restriction captured by the dependency, then the instance declaration is
not valid. Hugs can't tell which of these is the real source of the
problem, but it does report, correctly, that there is an inconsistency.
A little more generally, given the class declaration and the dependency
that you've specified, Hugs will not allow any instance declaration for
something of the form C t1 t2 t3 if there are variables in t2 or t3
that do not appear in t1. If this restriction were not enforced, then
it would again be possible for there to be multiple rows with the same
"a" value, but different "b" and "c" entries.
I noticed the same problem in one of the earlier examples that you sent
to the list:
| class Foo a b | a
| instance Foo Int [a]
| -- This is rejected by Hugs (with fundep a->b) but I would definitely
| -- accept it.
I hope that it is now clear why Hugs rejects this definition.
| I don't fully understand fundeps.
The specific point described above is actually discussed twice in my =
ESOP
paper, once informally, and once in a more general setting. I encourage
you to take a look at that paper for more details. If you're basing =
your
knowledge of fundeps on the (now quite outdated) note on my web page, or
on the section of the Hugs manual on which it was based, you may well =
have
some gaps to fill in. I'm not too happy with the ESOP paper either; I
couldn't include as much technical material there as I wanted because of
limited space. If you have read the ESOP paper and still have =
questions,
please let me know and I will do my best to answer them.
All the best,
Mark
From qrczak@knm.org.pl Thu Jan 4 22:33:50 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 4 Jan 2001 22:33:50 GMT
Subject: Problem with functional dependencies
References:
Message-ID:
Thu, 4 Jan 2001 13:01:56 -0800, Mark P Jones pisze:
> I hope now that the problem is becoming clear: this instance
> declaration is not consistent with the dependency; in the first
> two lines above, for example, we see two rows that violate the
> specification because they have the same value of "a", but different
> values for "b" and "c".
I see. So fundeps are not capable of expressing what I hoped, and what
a related but simpler concept I talked about once can express. I wonder
if there are practical uses of fundeps which are not expressible by
this concept.
What I have in mind is the following. A subset of type variables
of a class is chosen. Only that subset is used to find an instance
for resolving constraints with this class. The instance chosen
determines the rest of types. Instances must make this possible,
i.e. be non-unifiable wrt. the active subset of type variables. Voila.
An extended variant: several such subsets instead of one. Probably
each subset should be considered independently, with their results
unified. Or something like that.
This provides an equivalent of types contained in classes in C++.
It does not matter if the passive types in an instance use additional
type variables. This is where fundeps fail.
Having types with type variables which are never instantiated nor
constrained should be equivalent to having ground types!
Why, oh why haven't a more friendly and less problematic concept been
used, instead of fundeps which forever can't be finished in ghc and
have some different semantics in Hugs?
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From russell@brainlink.com Fri Jan 5 00:04:10 2001
From: russell@brainlink.com (Benjamin L. Russell)
Date: Thu, 04 Jan 2001 19:04:10 -0500
Subject: Learning Haskell and FP
In-Reply-To: <200101040655.WAA10861@gemini.willamette.edu>
Message-ID:
On Wed, 3 Jan 2001 22:55:17 -0800 (PST)
Fritz K Ruehr wrote:
>
> [snip]
>
> An O'Reilly "nutshell" book is an even better suggestion
> than
> my "Design Patterns in Haskell" of a few days back, at
> least
> from the perspective of marketing and promotion.
>
> But it raises the issue of an appropriate animal mascot
> for
> the cover; I can only come up with the Uakari, an
> exotic-looking
> rainforest monkey, which sounds similar to "Curry".
>
> (look here for a picture:)
>
>
Lalit Pant ( lalitp@acm.org ) (alternatively, lalit_pant@yahoo.com ) wrote an article in the May 2000 issue of _Java Report_ entitled "Developing Intelligent Systems With Java and Prolog" that described a Prolog implementation of the A-star search algorithm. Lalit stated that Prolog was useful for algorithm prototyping.
Perhaps Lalit Pant and Simon Peyton Jones could collaborate together on an article, perhaps overseen by Paul Hudak, on prototyping search algorithms in Haskell, also for _The Java Report?_ If this article then had a high readership, maybe the article's success could then justify publication of an O'Reilly _Haskell in a Nutshell_ book?
--Ben
P. S. (Hi Doug Fields. I didn't know that you were reading this mailing list. I guess that I should also greet Professor Paul Hudak: Hello, Professor Hudak. Sorry about Collectively Speaking. How's jazz in general?)
Benjamin L. Russell
russell@brainlink.com
benjamin.russell.es.94@aya.yale.edu
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
From peterd@availant.com Fri Jan 5 20:13:49 2001
From: peterd@availant.com (Peter Douglass)
Date: Fri, 5 Jan 2001 15:13:49 -0500
Subject: Are anonymous type classes the right model at all? (replying
to Re: Are fundeps the right model at all?)
Message-ID: <8BDAB3CD0E67D411B02400D0B79EA49A5F6CFF@smail01.clam.com>
Julian Assange wrote (Dec 28, 2000):
> This is why all non S-exp like lanaguage are doomed to progressive
> syntactic cancer as the useful parts of operator name space and syntax
> space become progressively polluted and mutated by one fad after
> another.
Could you expand on this? I would think that all languages have identifies
that, through common usage become standardized, and that this meaning
becomes a de-facto part of the language. Do you feel that this has not
happened in Lisp/Scheme?
--PeterD
From proff@iq.org Sat Jan 6 00:29:59 2001
From: proff@iq.org (Julian Assange)
Date: 06 Jan 2001 11:29:59 +1100
Subject: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
In-Reply-To: Peter Douglass's message of "Fri, 5 Jan 2001 15:13:49 -0500"
References: <8BDAB3CD0E67D411B02400D0B79EA49A5F6CFF@smail01.clam.com>
Message-ID:
Peter Douglass writes:
> Julian Assange wrote (Dec 28, 2000):
>
> > This is why all non S-exp like lanaguage are doomed to progressive
> > syntactic cancer as the useful parts of operator name space and syntax
> > space become progressively polluted and mutated by one fad after
> > another.
>
> Could you expand on this? I would think that all languages have identifies
> that, through common usage become standardized, and that this meaning
> becomes a de-facto part of the language. Do you feel that this has not
> happened in Lisp/Scheme?
The identifier space in lisp/scheme has wide tree depth and is
(essentially) lexically scoped. Infix operator identifiers in other
languages are the antithesis of this. It could be argued, both fairly
and unfairly, that the verbosity of S-exp bracketing leaves short
identifiers less desirable than they otherwise would be, however
tree-width arguments remain.
Polution of syntax space is a more difficult problem. As new syntactic
axioms are intruded, they should remain consistant with the existing
syntax elements. This poses ever increasing restraint on the evolution
of the language. New syntax elements appear less intuitive and more
arbitary in an attempt to fit in with the morass of ever increasing
restraints. If these restraints are not honnored, the language becomes
inconsistant. Eventually the language is guarenteed to become either
inconsistant or moribund as the number of interactions between
language elements overwhelms a language designers attempts understand
them.
The same is even more true of language semantics. The trouble lays in
finding initial axioms which can cleave large sections of future
concept space between them.
--
Julian Assange |If you want to build a ship, don't drum up people
|together to collect wood or assign them tasks and
proff@iq.org |work, but rather teach them to long for the endless
proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery
From kh0ndor@aeiou.pt Sun Jan 7 00:06:29 2001
From: kh0ndor@aeiou.pt (kh0ndor@aeiou.pt)
Date: Sun, 7 Jan 2001 00:06:29 GMT
Subject: (no subject)
Message-ID: <200101070006.AAA22676@xekmail.aeiou.pt>
which is the function in haskell that allows to generate us an amount
of aleatory numbers
I thank your help
__________________________________________________________
Mensagem enviada pelo Xekmail: webmail grátis do AEIOU
http://xekmail.aeiou.pt
From chak@cse.unsw.edu.au Sun Jan 7 09:13:45 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sun, 07 Jan 2001 20:13:45 +1100
Subject: (no subject)
In-Reply-To: <200101070006.AAA22676@xekmail.aeiou.pt>
References: <200101070006.AAA22676@xekmail.aeiou.pt>
Message-ID: <20010107201345R.chak@cse.unsw.edu.au>
kh0ndor@aeiou.pt wrote,
> which is the function in haskell that allows to generate us an amount
> of aleatory numbers
I guess, you want to generate random numbers. Check out
http://haskell.org/onlinelibrary/random.html
Cheers,
Manuel
From sebc@posse42.net Sun Jan 7 14:03:07 2001
From: sebc@posse42.net (Sebastien Carlier)
Date: Sun, 7 Jan 2001 15:03:07 +0100
Subject: Extending the do-notation
Message-ID: <20010107140312.09192FCF@www.haskell.org>
Sometimes I need to write code which looks like this:
> do x <- m1
> let y = unzip x
> ... -- never using x anymore
I thinks the following extension to do-notation would be useful:
> pat <- exp1 # exp2 ; exp3
would be rewritten as
> exp2 >>= ((\pat -> exp3) . exp1)
so that the above example could be rewritten more compactly:
> do y <- unzip # m1
I think the biggest problem with this extension is the choice
of a proper symbol.
Does this extension already exist ? (I only checked the Haskell 98
report).
From rje33@cam.ac.uk Sun Jan 7 14:41:48 2001
From: rje33@cam.ac.uk (Robert Ennals)
Date: Sun, 7 Jan 2001 14:41:48 +0000 (GMT)
Subject: Extending the do-notation
In-Reply-To: <20010107140312.09192FCF@www.haskell.org>
Message-ID:
On Sun, 7 Jan 2001, Sebastien Carlier wrote:
>
> Sometimes I need to write code which looks like this:
> > do x <- m1
> > let y = unzip x
> > ... -- never using x anymore
>
> I thinks the following extension to do-notation would be useful:
> > pat <- exp1 # exp2 ; exp3
> would be rewritten as
> > exp2 >>= ((\pat -> exp3) . exp1)
>
> so that the above example could be rewritten more compactly:
> > do y <- unzip # m1
>
> I think the biggest problem with this extension is the choice
> of a proper symbol.
Why not just use a user defined operator. eg:
infixr #
(#) :: Monad m => (a -> b) -> m a -> m b
f # p = p >>= (return . f)
Alternatively, define it to be "fmap", and be a bit more general.
-Rob
From qrczak@knm.org.pl Sun Jan 7 14:14:05 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 7 Jan 2001 14:14:05 GMT
Subject: Extending the do-notation
References: <20010107140312.09192FCF@www.haskell.org>
Message-ID:
Sun, 7 Jan 2001 15:03:07 +0100, Sebastien Carlier pisze:
> Does this extension already exist ?
Yes.
import Monad
...
do y <- liftM unzip m1
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From sebc@posse42.net Sun Jan 7 15:34:53 2001
From: sebc@posse42.net (Sebastien Carlier)
Date: Sun, 7 Jan 2001 16:34:53 +0100
Subject: Extending the do-notation
Message-ID: <20010107153452.E52BC1013@www.haskell.org>
> import Monad
> ...
> do y <- liftM unzip m1
Thanks.
I'm constantly amazed by the number of tricks one has
to know before he can write concise code using the
do-notation (among other things, I used to write
"x <- return $ m" instead of "let x = m").
Is there a paper demonstrating the most common
coding styles for do-notation ?
Another question concerning the do-notation: I noticed
that most parts of ghc do not use it. Is it because
the code was written before the notation was available,
because the do-notation is too weak to express these
parts, or for another fundamental reason ?
From R.Daniel@Europe.com Sun Jan 7 15:45:30 2001
From: R.Daniel@Europe.com (R.Daniel)
Date: Sun, 07 Jan 2001 15:45:30 +0000
Subject: Movement in a frictionless environment
Message-ID: <5.0.0.25.2.20010107154054.009f1a20@mail.ip.pt>
--=====================_1052009==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi, could anyone tell me where to find some info about generating movement
on a frictionless environment?
I need to put a ball running in a window, given an initial speed and then
let it run along with the rules of phisics....can anyone give me a hint on
where to find info, or on how to do that?
I would be most greatefull.
Thankx
----->R.Daniel
ICQ 28959546
--=====================_1052009==_.ALT
Content-Type: text/html; charset="us-ascii"
Hi, could anyone tell me where to find some info about generating
movement on a frictionless environment?
I need to put a ball running in a window, given an initial speed and then
let it run along with the rules of phisics....can anyone give me a hint
on where to find info, or on how to do that?
I would be most greatefull.
Thankx
----->R.Daniel
ICQ
28959546
--=====================_1052009==_.ALT--
From Sven.Panne@informatik.uni-muenchen.de Sun Jan 7 16:21:06 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Sun, 07 Jan 2001 17:21:06 +0100
Subject: Extending the do-notation
References: <20010107153452.E52BC1013@www.haskell.org>
Message-ID: <3A589772.8A84F4E8@informatik.uni-muenchen.de>
Sebastien Carlier wrote:
> I'm constantly amazed by the number of tricks one has
> to know before he can write concise code using the
> do-notation [...]
In my experience it is not the do-notation itself, but the mixture
of monadic actions and higher-order functions. But after a while
you´ll really like it. :-)
> Another question concerning the do-notation: I noticed
> that most parts of ghc do not use it. Is it because
> the code was written before the notation was available,
> because the do-notation is too weak to express these
> parts, or for another fundamental reason ?
It's only because of historical reasons, nothing more.
Cheers,
Sven
From Sven.Panne@informatik.uni-muenchen.de Sun Jan 7 16:24:19 2001
From: Sven.Panne@informatik.uni-muenchen.de (Sven Panne)
Date: Sun, 07 Jan 2001 17:24:19 +0100
Subject: Movement in a frictionless environment
References: <5.0.0.25.2.20010107154054.009f1a20@mail.ip.pt>
Message-ID: <3A589833.256726CF@informatik.uni-muenchen.de>
"R.Daniel" wrote:
> Hi, could anyone tell me where to find some info about generating
> movement on a frictionless environment? [...]
I'd recommend one of the game programming sites, they have tons of
useful stuff related to physics, too:
http://www.devgames.com/
http://www.gdmag.com/
http://www.gamasutra.com/
http://www.flipcode.com/
http://www.gamesdomain.co.uk/gamedev/gprog.html
http://www.3dgamedev.com/
Cheers,
Sven
From shlomif@vipe.technion.ac.il Sun Jan 7 18:00:51 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Sun, 7 Jan 2001 20:00:51 +0200 (IST)
Subject: A dictionary implementation in Hasekll
Message-ID:
Does anybody knows of an implementation for an efficient dictionary (such
as a hash, an AVL tree, a B-Tree etc. ) in Haskell? Can an array do that?
I'd like something that can map any type to any other type based on a
comparison function, and perhaps a hashing function.
TIA,
Shlomi Fish
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From jenglish@flightlab.com Sun Jan 7 19:08:32 2001
From: jenglish@flightlab.com (Joe English)
Date: Sun, 07 Jan 2001 11:08:32 -0800
Subject: Extending the do-notation
In-Reply-To: <20010107140312.09192FCF@www.haskell.org>
References: <20010107140312.09192FCF@www.haskell.org>
Message-ID: <200101071908.LAA00838@dragon.flightlab.com>
Sebastien Carlier wrote:
> Sometimes I need to write code which looks like this:
> > do x <- m1
> > let y = unzip x
> > ... -- never using x anymore
>
> I thinks the following extension to do-notation would be useful:
> > pat <- exp1 # exp2 ; exp3
> would be rewritten as
> > exp2 >>= ((\pat -> exp3) . exp1)
>
> so that the above example could be rewritten more compactly:
> > do y <- unzip # m1
This can be done in Haskell without any changes to the
'do' notation at all: just define
| f # m = m >>= (return . f)
and add an appropriate fixity declaration for '#'.
--Joe English
jenglish@flightlab.com
From qrczak@knm.org.pl Sun Jan 7 21:25:58 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 7 Jan 2001 21:25:58 GMT
Subject: A dictionary implementation in Hasekll
References:
Message-ID:
Sun, 7 Jan 2001 20:00:51 +0200 (IST), Shlomi Fish pisze:
> Does anybody knows of an implementation for an efficient dictionary
> (such as a hash, an AVL tree, a B-Tree etc. ) in Haskell?
ghc's library contains FiniteMap, implemented as a balanced binary tree
(not exactly AVL), over any comparable type as the key.
I haven't seen a hash table. It's harder to do in the functional
context. It would either have to be mutable, or provide bulk operations
on many elements at once to be efficient - or use a trick with hidden
mutations in place to obtain a modified value while substituting
a backward difference for the old value, to have the functional
interface and cheap access to newest versions.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From Tom.Pledger@peace.com Mon Jan 8 04:53:35 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Mon, 8 Jan 2001 17:53:35 +1300
Subject: Are fundeps the right model at all?
In-Reply-To:
References:
Message-ID: <14937.18383.904979.841600@waytogo.peace.co.nz>
Marcin 'Qrczak' Kowalczyk writes:
> Could somebody show an example which requires fundeps and cannot be
> expressed using a simpler model explained below - a model that I
> can even understand? Is the model self-consistent at all?
>
[a model which uses key constraints instead of functional dependencies]
Hi.
Try this:
class C a b c | b -> c
instance C t () t
Hugs rejects it.
If we try to express C with keys instead of fundeps, the key must
contain both a and b, which is equivalent to this:
class C a b c | a b -> c
instance C t () t
Hugs accepts this, but only because the constraint has been weakened
to something which can be expressed with keys.
It's quite a contrived example, and I'm not sure how it relates to
your later statement:
> Having types with type variables which are never instantiated nor
> constrained should be equivalent to having ground types!
Do you have any examples of such a type variable in an instance decl?
I'm having trouble imagining it, because I keep running into
unnecessary class parameters and overlapping instances.
Regards,
Tom
From ahey@iee.org Mon Jan 8 04:57:17 2001
From: ahey@iee.org (Adrian Hey)
Date: Mon, 8 Jan 2001 04:57:17 +0000 (GMT)
Subject: First Class Modules? was Re: Are anonymous type classes the right model at all?
In-Reply-To:
Message-ID:
Hello,
All this talk about Haskell classes, ML modules and improved record types
reminds me of the rumours of a "First Class Modules" system for Haskell,
but the only documentation I found was a fairly brief document that looked
like an application for a research grant. So...
Could somebody explain what a first class module is?
How does it differ from a record?
What could I do with a first class module (if Haskell provided them)?
Thanks
--
Adrian Hey
From ger@tzi.de Mon Jan 8 10:55:49 2001
From: ger@tzi.de (George Russell)
Date: Mon, 08 Jan 2001 11:55:49 +0100
Subject: Extending the do-notation
References: <20010107153452.E52BC1013@www.haskell.org>
Message-ID: <3A599CB5.8D3A7823@tzi.de>
Sebastien Carlier wrote:
>
> > import Monad
> > ...
> > do y <- liftM unzip m1
>
> Thanks.
>
> I'm constantly amazed by the number of tricks one has
> to know before he can write concise code using the
> do-notation (among other things, I used to write
> "x <- return $ m" instead of "let x = m").
[snip]
Why do you WANT to write concise code using the do-notation?
Has someone revived the Obfuscated Haskell Contest, or
do you find touch-typing difficult?
From ger@tzi.de Mon Jan 8 14:58:06 2001
From: ger@tzi.de (George Russell)
Date: Mon, 08 Jan 2001 15:58:06 +0100
Subject: Yet more on functional dependencies
Message-ID: <3A59D57E.6F5E0489@tzi.de>
I am finding functional dependencies confusing. (I suspect I am not alone.)
Should the following code work?
class HasConverter a b | a -> b where
convert :: a -> b
instance (HasConverter a b,Show b) => Show a where
show value = show (convert value)
From qrczak@knm.org.pl Mon Jan 8 17:21:52 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 8 Jan 2001 17:21:52 GMT
Subject: Are fundeps the right model at all?
References: <14937.18383.904979.841600@waytogo.peace.co.nz>
Message-ID:
Mon, 8 Jan 2001 17:53:35 +1300, Tom Pledger pisze:
> > Having types with type variables which are never instantiated nor
> > constrained should be equivalent to having ground types!
>
> Do you have any examples of such a type variable in an instance decl?
Not quite. When the type variable is never instantiated, like in ST
(ghc's and hbc's state threads), I don't see fundeps.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From Tom.Pledger@peace.com Mon Jan 8 20:15:10 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Tue, 9 Jan 2001 09:15:10 +1300
Subject: Yet more on functional dependencies
In-Reply-To: <3A59D57E.6F5E0489@tzi.de>
References: <3A59D57E.6F5E0489@tzi.de>
Message-ID: <14938.8142.601890.119998@waytogo.peace.co.nz>
George Russell writes:
> I am finding functional dependencies confusing. (I suspect I am not alone.)
> Should the following code work?
>
> class HasConverter a b | a -> b where
> convert :: a -> b
>
> instance (HasConverter a b,Show b) => Show a where
> show value = show (convert value)
Yes.
Let's assume that multi-parameter classes and overlapping instances
are enabled.
Without the functional dependency, the instance decl would be rejected
because the type variable b occurs in the context (HasConverter a b,
Show b) but not in the head (Show a). The compiler needs to generate
some code for `show value', but it's not allowed to make an arbitrary
substitution for b.
The functional dependency provides a way to determine b uniquely once
a is matched. So, the compiler can generate the code for `show value'
without being arbitrary.
Regards,
Tom
From Tom.Pledger@peace.com Mon Jan 8 21:30:52 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Tue, 9 Jan 2001 10:30:52 +1300
Subject: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
In-Reply-To:
References:
<3A42661E.7FCCAFFA@tzi.de>
<20001229003745.A11084@mark.ugcs.caltech.edu>
Message-ID: <14938.12684.532876.890748@waytogo.peace.co.nz>
Marcin 'Qrczak' Kowalczyk writes:
[...]
> My new record scheme proposal does not provide such lightweight
> extensibility, but fields can be added and deleted in a controlled
> way if the right types and instances are made.
Johan Nordlander must be on holiday or something, so I'll deputise for
him. :-)
O'Haskell also has add-a-field subtyping. Here's the coloured point
example (from http://www.cs.chalmers.se/~nordland/ohaskell/survey.html):
struct Point =
x,y :: Float
struct CPoint < Point =
color :: Color
Regards,
Tom
From nellardo@concentric.net Tue Jan 9 00:13:21 2001
From: nellardo@concentric.net (Brook Conner)
Date: Mon, 08 Jan 2001 19:13:21 -0500
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Message-ID: <3A5A57A1.6000609@concentric.net>
Inspired by the recent discussions of what kinds of books would
encourage the spread of Haskell, I whipped up a draft table of contents
for "Haskell in a Nutshell."
You can find it in PDF form at
http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts
embedded - OReilly uses a couple of oddballs) and in ASCII text at
http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt.
While there are page numbers attached, you should simply ignore those
for the moment :-) Rather, I'd be interested in feedback on the
structure etc. Oh, and please don't just rip it off and write it
yourself :-)
Like "Java in a Nutshell", the first part is a firehose description of
the language. As Haskell is somewhat different from what most OReilly
readers are used to, I've included a bit more about different ways you
can run Haskell (which, incidentally, points out that it runs *everywhere*).
Also like "Java in a Nutshell", the last part is a reference to common
packages.
The middle part is a bit different - a short "cookbook" of
semi-practical programs addressing fairly common programming tasks -
some of the kinds of things you'd typically do with Perl or C++. I think
it needs more "recipes" of course, but I'd like to know if the general
idea is working.
Brook
ps - for the curious, I have in fact written a textbook before
(object-oriented programming for a first-semester course, from 1994...).
And I'm using O'Reilly's FrameMaker templates, so the draft is
"camera-ready" (hence the page numbers - the TOC is automatically
generated).
From chak@cse.unsw.edu.au Tue Jan 9 02:43:59 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 09 Jan 2001 13:43:59 +1100
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
In-Reply-To: <3A5A57A1.6000609@concentric.net>
References: <3A5A57A1.6000609@concentric.net>
Message-ID: <20010109134359E.chak@cse.unsw.edu.au>
Brook Conner wrote,
> You can find it in PDF form at
> http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts
> embedded - OReilly uses a couple of oddballs) and in ASCII text at
> http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt.
Makes sense to me. However, I would move IO further to the
front. For any "real life" programming, IO is essential
and, I think, it is bad for the image of Haskell to treat it
as something dirty that is relegated to end of every (at
least, many) introduction of Haskell.
I have just given an Introduction to Computing course using
Haskell and written a set of lecture notes, which introduce
a couple of concepts (including IO) differently than
commonly done. The whole stuff is at
http://www.cse.unsw.edu.au/~cs1011/lectures/index.html
Feel free to get inspiration from the material (except Weeks
8 - 10, which weren't given by me). You will find IO in
Week 5. Note that I haven't used the word monad a single
time. IMHO, monads are an advanced concept, IO is not.
It's like you can introduce recursion without discussing
stacks. If you understand stacks, you can gain a deeper
understanding of recursion, but if you hear about recursion
for the first time, the mention of stacks will only distract
the average student.
> The middle part is a bit different - a short "cookbook" of
> semi-practical programs addressing fairly common programming tasks -
> some of the kinds of things you'd typically do with Perl or C++. I think
> it needs more "recipes" of course, but I'd like to know if the general
> idea is working.
I think, that this is a good idea.
Cheers,
Manuel
From bhalchin@hotmail.com Tue Jan 9 03:15:34 2001
From: bhalchin@hotmail.com (Bill Halchin)
Date: Tue, 09 Jan 2001 03:15:34
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Message-ID:
Yes! I agree with Manuel about the IO. It looks bad being towards
the end.
Regards,
Bill Halchin
>From: "Manuel M. T. Chakravarty"
>Reply-To: chak@cse.unsw.edu.au
>To: nellardo@concentric.net
>CC: haskell@haskell.org
>Subject: Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
>Date: Tue, 09 Jan 2001 13:43:59 +1100
>
>Brook Conner wrote,
>
> > You can find it in PDF form at
> > http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts
> > embedded - OReilly uses a couple of oddballs) and in ASCII text at
> > http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt.
>
>Makes sense to me. However, I would move IO further to the
>front. For any "real life" programming, IO is essential
>and, I think, it is bad for the image of Haskell to treat it
>as something dirty that is relegated to end of every (at
>least, many) introduction of Haskell.
>
>I have just given an Introduction to Computing course using
>Haskell and written a set of lecture notes, which introduce
>a couple of concepts (including IO) differently than
>commonly done. The whole stuff is at
>
> http://www.cse.unsw.edu.au/~cs1011/lectures/index.html
>
>Feel free to get inspiration from the material (except Weeks
>8 - 10, which weren't given by me). You will find IO in
>Week 5. Note that I haven't used the word monad a single
>time. IMHO, monads are an advanced concept, IO is not.
>It's like you can introduce recursion without discussing
>stacks. If you understand stacks, you can gain a deeper
>understanding of recursion, but if you hear about recursion
>for the first time, the mention of stacks will only distract
>the average student.
>
> > The middle part is a bit different - a short "cookbook" of
> > semi-practical programs addressing fairly common programming tasks -
> > some of the kinds of things you'd typically do with Perl or C++. I think
> > it needs more "recipes" of course, but I'd like to know if the general
> > idea is working.
>
>I think, that this is a good idea.
>
>Cheers,
>Manuel
>
>_______________________________________________
>Haskell mailing list
>Haskell@haskell.org
>http://www.haskell.org/mailman/listinfo/haskell
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
From ketil@ii.uib.no Tue Jan 9 06:39:47 2001
From: ketil@ii.uib.no (Ketil Malde)
Date: 09 Jan 2001 07:39:47 +0100
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
In-Reply-To: Brook Conner's message of "Mon, 08 Jan 2001 19:13:21 -0500"
References: <3A5A57A1.6000609@concentric.net>
Message-ID:
Brook Conner writes:
> Inspired by the recent discussions of what kinds of books would encourage the
> spread of Haskell, I whipped up a draft table of contents for "Haskell in a
> Nutshell."
Let's see. It all depends on what you put into the chapters, of
course, but you seem to jump directly from simple concepts into
Haskell for web servers. Wouldn't it be better to push this further
out, until at least some of the syntax has been explored?
From the headlines, one might get the impression that type
declarations are only important when the compiler can't figure it out
itself - I'm sure the actual text will give a different view, no?
The cookbook looks great, and it's certainly something I'd buy the
book for. I can, of course, think of many kinds of example programs
I'd like to see - how about a GUI oriented program, for instance?
Perhaps you could finish it off with a "real" application, say a GUIed
JPEG viewer, where you sort of string it all (the JPEG codec, a C
library interface for something or other, and GUI stuff, etc.)
together into a whole?
On the whole, I think it looks good. Best of luck!
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From joe@isun.informatik.uni-leipzig.de Tue Jan 9 08:00:27 2001
From: joe@isun.informatik.uni-leipzig.de (Johannes Waldmann)
Date: Tue, 9 Jan 2001 09:00:27 +0100 (MET)
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
In-Reply-To: <20010109134359E.chak@cse.unsw.edu.au> from "Manuel M. T. Chakravarty"
at "Jan 9, 2001 01:43:59 pm"
Message-ID: <200101090800.JAA19782@isun11.informatik.uni-leipzig.de>
> However, I would move IO further to the front.
> For any "real life" programming, IO is essential...
I am currently teaching a Functional Programming lecture (notes in German:
http://www.informatik.uni-leipzig.de/~joe/edu/ws00/praxis/skript/)
and I also used this approach: use the do-notation intuitively
(for text IO and graphics, using SOE book),
and explain monads later (with parser combinators and interpreters).
This could be driven to the extreme: not only hide the word "monad",
but also "functional". The title would be "Imperative programming in Haskell"
(as S. Peyton Jones says in Tackling the Awkward Squad:
"Haskell is the world's finest imperative programming language").
The students would start writing do-notated programs in the IO monad,
starting with putStrLn "Hello World";
and gradually the emphasis is shifted from sequencing (the "semicolon")
to "what can we do on the righthand side of let x = ... ",
thus introducing functional programming.
Not sure if this is really a good idea, though...
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From joe@isun.informatik.uni-leipzig.de Tue Jan 9 08:46:31 2001
From: joe@isun.informatik.uni-leipzig.de (Johannes Waldmann)
Date: Tue, 9 Jan 2001 09:46:31 +0100 (MET)
Subject: Defaults in datatype definitions
Message-ID: <200101090846.JAA19878@isun11.informatik.uni-leipzig.de>
Below are some suggestions for extensions to Haskell records.
These are just naive ideas.
Of course the extensions should integrate nicely
w.r.t. the existing syntax, type system, and module system.
Perhaps you can point me to opinions and research
on what has already been done, or to why it should not, or can not.
1) I would like to write down default values for record components
data Foo = Foo { x :: Bar; y :: Baz; x = some_expression }
We can do this for methods in type classes, so why not here.
2) With classes, we can do even more: in the default method,
we can access other methods.
This suggests that the above example should in fact read
data Foo = Foo { x :: Bar; y :: Baz; x = \ self -> some_expression }
where `self' might occur in some_expression. that is,
the default value of `me.x ' gets computed by applying a function to `me'.
3) I want to be able, in modules that use the type,
to add more components (with defaults) to the type:
This would avoid lengthy recomputations (at the cost of additional space).
Imagine the difference between
data Tree a = Node { key :: a, children :: [ Tree a ] }
size t = 1 + sum (map size (children t))
and
data Tree a = Node { key :: a, children :: [ Tree a ]
, size :: Integer
, size = \ self -> 1 + sum (map size (children self)) }
when you have one large tree and frequently need sizes of subtrees.
(by the way, what type does `size' have now -
do we write `Integer' or `Tree a -> Integer'?)
yes, I can do this manually, replacing `Node' by a smart constructor
that computes and stores the size. What I don't like about this
is that I have to know in advance (i. e. at the moment I define the type)
what functions I want to be "cached" this way.
Imagine `size' as some more complicated function,
only defined many modules later.
Of course I see that this would be difficult to implement
w.r.t. separate compilation. But I would be happy with a compiler
that ignores the "cache" specs during single-module compilations,
but honors them when doing a full rebuild of a set of modules.
I imagine that inter-module inlining behaves similar.
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From chak@cse.unsw.edu.au Tue Jan 9 09:41:05 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 09 Jan 2001 20:41:05 +1100
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
In-Reply-To: <200101090800.JAA19782@isun11.informatik.uni-leipzig.de>
References: <20010109134359E.chak@cse.unsw.edu.au>
<200101090800.JAA19782@isun11.informatik.uni-leipzig.de>
Message-ID: <20010109204105S.chak@cse.unsw.edu.au>
Johannes Waldmann wrote,
> > However, I would move IO further to the front.
> > For any "real life" programming, IO is essential...
>
> I am currently teaching a Functional Programming lecture (notes in German:
> http://www.informatik.uni-leipzig.de/~joe/edu/ws00/praxis/skript/)
> and I also used this approach: use the do-notation intuitively
> (for text IO and graphics, using SOE book),
> and explain monads later (with parser combinators and interpreters).
>
> This could be driven to the extreme: not only hide the word "monad",
> but also "functional". The title would be "Imperative programming in Haskell"
> (as S. Peyton Jones says in Tackling the Awkward Squad:
> "Haskell is the world's finest imperative programming language").
>
> The students would start writing do-notated programs in the IO monad,
> starting with putStrLn "Hello World";
> and gradually the emphasis is shifted from sequencing (the "semicolon")
> to "what can we do on the righthand side of let x = ... ",
> thus introducing functional programming.
Starting with
putStrLn "Hello World"
is a good idea and this would exactly be my approach when
teaching students who already know some programming language
(in the course I did last term, it was their first
programming experience; therefore, I waited until Week 5).
However, I don't think it is necessary (or desirable) to
hide "functional". With "monad" it is a different story, as
it is a complicated sounding word, which is not easily
explained (to non-mathematicians). And it is not necessary;
we are not starting on fixed point and domain theory either
when explaining recursive functions.
Actually, I did run a moderately detailed survey at the end
about what the students found interesting/boring and
difficult/easy etc (and with a good sample size, too: close
to 500 students filled in the survey). I am planing to
summarise the results and post them here sometime.
Cheers,
Manuel
From nellardo@concentric.net Tue Jan 9 16:55:11 2001
From: nellardo@concentric.net (Brook Conner)
Date: Tue, 09 Jan 2001 11:55:11 -0500
Subject: ANNOUNCE: Draft TOC of Haskell in a Nutshell
References: <3A5A57A1.6000609@concentric.net>
Message-ID: <3A5B426E.50009@concentric.net>
Ketil Malde wrote:
> Let's see. It all depends on what you put into the chapters, of
> course, but you seem to jump directly from simple concepts into
> Haskell for web servers. Wouldn't it be better to push this further
> out, until at least some of the syntax has been explored?
The second chapter is meant to be a brief overview of some of the ways
you can execute Haskell code. For a programmer familiar with some of the
more common languages (C++, Java, Perl is the kind I'm expecting),
showing them right off the bat that Haskell *can* be used in web servers
seemed like a good idea. It met two goals:
a) this list's objective in spreading the good word about how useful
Haskell is :-)
b) the objective of "Nutshell" books to let experienced people transfer
their existing skills as quickly as possible.
> >From the headlines, one might get the impression that type
> declarations are only important when the compiler can't figure it out
> itself - I'm sure the actual text will give a different view, no?
Of course - I have something of an informal writing tone when I'm
writing for education, and some of the headlines reflect that (I mean,
really, "hash"? :-) ) But part of what I was trying to do was to get
some key concepts across to two different audiences of programmers:
a) the Perl programmers, who have types but generally don't ever write
them down. These people will like type inferencing - it will seem more
natural to them.
b) the C++ and Java programmers. They'll be just fine declaring types -
showing them how to get strong typing without necessarily declaring the
types explicitly will seem nifty cool to them (it did to me, ten years
ago :-) )
I'm not about to get into any of the old arguments about static vs
dynamic typing or that stuff - been there, done that. Haskell is a
strongly typed language, and that will be apparent in the text.
> The cookbook looks great, and it's certainly something I'd buy the
Do you think the cookbook would be better as its own book?
> I can, of course, think of many kinds of example programs
> I'd like to see - how about a GUI oriented program, for instance?
Actually, last night after sending the announcement, I added exactly
that :-)
Years and years ago, Paul Haeberli of SGI implemented this cute little
hack of having a brush attached to the cursor with a spring - real
simple - moving the mouse changed the velocity vector of the brush, with
settable strength and inertia and such. It made it insanely easy to
produce a swooping, calligraphic stroke. Haeberli did it in C to OpenGL
- using Fran, it would be perhaps a one-liner.
Scott Snibbe, then of Brown University, did another cute hack that
showed up at SIGGRAPH later under the name "MotionPhone". He set up a
loop of screen buffers that ran at a constant frame rate. As you drew,
your mouse left behind moving streaks. Faster motion, longer streaks.
This would be another one-liner with Fran (Scott originally did it in C
to Pixrect, Sun's ancient direct screen access API).
I figured those kinds of examples showed off the power of Haskell.
> Perhaps you could finish it off with a "real" application, say a GUIed
> JPEG viewer, where you sort of string it all (the JPEG codec, a C
> library interface for something or other, and GUI stuff, etc.)
> together into a whole?
This morning I've been thinking about data visualization from an SQL DB....
> On the whole, I think it looks good. Best of luck!
Thanks!
Brook
From qrczak@knm.org.pl Tue Jan 9 18:52:11 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 9 Jan 2001 18:52:11 GMT
Subject: Are fundeps the right model at all?
References: <14937.18383.904979.841600@waytogo.peace.co.nz>
Message-ID:
Mon, 8 Jan 2001 17:53:35 +1300, Tom Pledger pisze:
> > Having types with type variables which are never instantiated nor
> > constrained should be equivalent to having ground types!
>
> Do you have any examples of such a type variable in an instance decl?
Now I have a practical example where fundeps don't work and keys
would work - but the type variable is later instantiated.
Let's take Parsec from ghc's libraries which includes the following
(this is cut down):
data TokenParser = TokenParser {
identifier :: Parser String,
reserved :: String -> Parser (),
operator :: Parser String,
reservedOp :: String -> Parser (),
parens :: forall a. Parser a -> Parser a}
makeTokenParser:: LanguageDef -> TokenParser
I would like to express this "first-class module" in my records
proposal, to make it extensible (there can be different types similar
to TokenParser with similar fields and used polymorphically together
with TokenParser).
Each record field in my proposal induces a class:
class Has_field r a | r -> a where
get_field :: r -> a
The fundep, or something which allows to find the instance from the
type of the record only, is required to make this practical. A type
which includes Has_field r a in its context, and includes r but not a
in its body, is legal.
For non-polymorphic fields it works great. But parens cause trouble:
instance Has_parens TokenParser (Parser a -> Parser a)
This instance is illegal because of the fundep. What it should mean is:
instance Has_parens TokenParser (forall a. Parser a -> Parser a)
but this is not possible either.
With keys instead of fundeps it works! The first instance is OK.
The record type is specified to be a key in all Has_field classes,
meaning that the record type alone is sufficient to determine which
instance of a field getter to use.
It is not always sufficient to determine the exact type of the field,
but this is not needed. For example here many types are good because
the instance is polymorphic wrt. a type variable used in the field's
type.
I want keys instead of fundeps! :-)
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From qrczak@knm.org.pl Tue Jan 9 18:37:03 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 9 Jan 2001 18:37:03 GMT
Subject: Defaults in datatype definitions
References: <200101090846.JAA19878@isun11.informatik.uni-leipzig.de>
Message-ID:
Tue, 9 Jan 2001 09:46:31 +0100 (MET), Johannes Waldmann pisze:
> 1) I would like to write down default values for record components
My proposal for remaking records ina more flexible way includes this.
> 2) With classes, we can do even more: in the default method,
> we can access other methods.
And this too.
> 3) I want to be able, in modules that use the type,
> to add more components (with defaults) to the type:
>
> This would avoid lengthy recomputations (at the cost of additional space).
> Imagine the difference between
>
> data Tree a = Node { key :: a, children :: [ Tree a ] }
> size t = 1 + sum (map size (children t))
>
> and
>
> data Tree a = Node { key :: a, children :: [ Tree a ]
> , size :: Integer
> , size = \ self -> 1 + sum (map size (children self)) }
>
> when you have one large tree and frequently need sizes of subtrees.
And this too, but it's a bit tricky because a field changes the
type covariantly.
data Tree a = record
key :: a
children :: [Tree a]
children = []
-- A function working on a tree must be prepared for extensions.
-- The following function does not actually refer to the above type,
-- but can be used on Tree Int.
isInTree:: (Eq a, tree.key :: a, tree.children :: [tree])
=> a -> tree -> Bool
isInTree a tree = a == tree.key || any (isInTree a) tree.children
-- Trees extended by size cache. The type below does not refer to
-- the type Tree because the type of children has changed. Otherwise
-- it could include Tree as a field and delegate key and children to
-- this field instead of defining them itself. Well, it could do it,
-- but it would have to store children as SizedTrees somewhere too.
-- I don't know yet if it can be solved more elegantly.
data SizedTree a = record
key :: a
children :: [SizedTree a]
size :: Int
children = []
size = 1 + sum (map (.size) children)
-- Creation of a tree is the same for both kinds. A different kind of
-- context is needed to create a record than to extract its fields.
-- This context includes the context used in isInTree (except Eq a)
-- in its superclasses.
flatTree:: (tree.record {key :: a; children :: [tree]})
=> a -> [a] -> tree
flatTree root leaves = record
key = root
children = [record key = leaf | leaf <- leaves]
I haven't written a complete description of the proposal yet, but
will do it in two weeks. I posted basic info here some time ago.
Some details changed since then.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From msk@post.tepkom.ru Tue Jan 9 21:10:46 2001
From: msk@post.tepkom.ru (Anton Moscal)
Date: Wed, 10 Jan 2001 00:10:46 +0300 (MSK)
Subject: Just for fun
Message-ID:
Hello!
This is well-known definition of the existential quantification through
universal:
(E x.P(x)) <=> A y.(A x.P (x) => y) => y
I try to translate in to Haskell. The following program can be compiled
by "ghc -fglasgow-exts ..." and works correctly:
----------------------------------------
import Char
type E a = forall t . (forall x . a x -> t) -> t
newtype Pair a b = MkPair (b, (b -> a))
newtype App a = MkApp (E (Pair a))
mk_app :: (a -> b) -> a -> App b
mk_app f v = MkApp (\g -> g (MkPair (v, f)))
app_s = mk_app Char.ord '1'
app_id = mk_app (\x->x) 239
eval :: App a -> a
eval (MkApp g) = g (\(MkPair (x, f)) -> f x)
main = print (map eval [mk_app (\x->x) 239, mk_app Char.ord '1'])
---------------------------------------
Regards,
Anton Moscal
From Tom.Pledger@peace.com Tue Jan 9 22:40:17 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Wed, 10 Jan 2001 11:40:17 +1300
Subject: Just for fun
In-Reply-To:
References:
Message-ID: <14939.37713.16403.320221@waytogo.peace.co.nz>
Anton Moscal writes:
> Hello!
>
> This is well-known definition of the existential quantification
> through universal:
>
> (E x.P(x)) <=> A y.(A x.P (x) => y) => y
>
> I try to translate in to Haskell. The following program can be
> compiled by "ghc -fglasgow-exts ..." and works correctly:
>
[...]
> main = print (map eval [mk_app (\x->x) 239, mk_app Char.ord '1'])
import Char(ord)
main = print (tail [error "I'm too lazy to be explicitly existential.",
(\x->x) 239,
ord '1'])
{- Regards, Tom :-}
From qrczak@knm.org.pl Tue Jan 9 23:10:40 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 9 Jan 2001 23:10:40 GMT
Subject: Haskell 98 (Library) Report: contradiction about fail :: String -> IO a
Message-ID: