&nbs=
p; =
; =20
CALL FOR PAPERS
&n=
bsp; =20
Submission Deadline: March 21, 2002
&n=
bsp;=20
The First ACM SIGPLAN/SIGSOFT Conference=20
on
&=
nbsp; =20
Generators and Components (GCSE/SAIG'02)
Supported by =
the=20
National Science Foundation=20
(NSF)
&nbs=
p; =20
Pittsburgh, PA, October 6-8, 2002.
http://www.cs.=
yale.edu/~taha/gcse-saig/cfp02.html
Invited Speakers:
* Neil Jones, University of Denmark
* Catuscia Palamidessi, Penn =
State=20
University
* Janos Sztipanovits, Vanderbilt University
Program generation has the prospect of being an integral part of =
a
wide=20
range of software development processes. Many recent =
studies
investigate=20
different aspects of program generation, including their
semantics, =
their=20
application, and their implementation. Existing
theories and systems =
address=20
both high-level (source) language and
low-level (machine) language=20
generation. A number of programming
languages now support program =
generation=20
and manipulation, with
different goals, implementation techniques, =
and=20
targeted at different
applications. The goal of this conference is to =
provide=20
a meeting
place for researchers and practitioners interested in this=20
topic.
A particular area of interest is component-based software=20
development,
which bears the promise of considerable productivity =
increases=20
to
software development comparable to the introduction of the=20
assembly
line in manufacturing. But due to the very same =
sophistication=20
that
makes components useful, their maintenance can be hard. =20
Generative
programming presents a promising approach to alleviating =
the=20
above
problems, as changes affecting components can now be more=20
effectively
managed during the generation process rather than at the=20
component
level.
The goal of this joint event is to foster further=20
cross-fertilization
between the software engineering research =
community on=20
the one hand,
and the programming languages community on the other, =
in=20
addition to
supporting the original research goals of both GCSE and=20
SAIG
communities. We seek papers both in software engineering=20
and
programming languages, and especially those that bridge the gap.=20
Being
accessible to both communities at the same time is also =
valued.
The conference solicits submissions related (but not limited) =
to:
* Generative Programming: Reuse, meta-programming, =
partial=20
evaluation,
multi-stage =
and=20
multi-level languages,
* Semantics, type systems, =
symbolic=20
computation, linking and =
explicit
=20
substitution, in-lining and macros, templates, program=20
transformation,
* Runtime code generation, compilation, =
active=20
libraries, synthesis from
=20
specifications, development methods, generation of non-code=20
artifacts,
formal =
methods. =20
Reflection.
* Component-Based Software Engineering: =
Reuse,=20
distributed platforms,
=
distributed=20
systems, evolution, analysis and design=20
patterns,
development =
methods,=20
formal methods
* Integration of Generative and =
Component-Based=20
Approaches
* Domain Engineering, analysis, and=20
languages
* Separation of Concerns: Aspect-Oriented =
Programming,=20
Intentional
* Programming, and Multi-Dimensional =
Separation of=20
Concerns
* Product Lines and generic architectures for =
that=20
purpose.
* Industrial Applications of Components and =
Generative=20
Programming
Reports on applications of these techniques to real-world problems=20
are
especially encouraged, as are submissions that relate ideas=20
and
concepts from several of these topics, or bridge the gap=20
between
theory and practice. The program committee is happy to advise =
on=20
the
appropriateness of a particular subject.
General Chair:
Walid Taha, Yale University, =
USA.
Program Chair (GCSE focus):
Don Batory, University of Texas at =
Austin,=20
USA.
Program Chair (SAIG focus):
Charles Consel, INRIA, LaBRI, =
France.
Program Committee (GCSE focus):
Jan Bosch , University of=20
Groningen
Greg Butler, Concordia=20
University
Prem Devanbu, University of =
California at Davis
Cristina Gacek, =
University=20
of Newcastle upon Tyne
Stan Jarzabek, =
National=20
University of Singapore
Kyo Kang, =
Pohang=20
University of Science and Technology
=
Peter=20
Knauber, Fraunhofer Institute
=
for=20
Experimental Software Engineering
=
Hausi=20
Muller, University of Victoria
Nenad=20
Medvidovic, University of Southern =
California
=20
Wolfgang Pree, University of Constance
=
Yannis=20
Smaragdakis, Georgia Institute of =
Technology
=20
Douglas R. Smith , Kestrel Institute
Program Committee (SAIG focus):
Craig Chambers, University of=20
Washington
Shigeru Chiba, Tokyo =
Institute of=20
Technology
Pierre Cointe, Ecole des =
Mines de=20
Nantes
Dawson Engler, Stanford=20
University
Siau cheng Khoo, National=20
University of Singapore
Gregor =
Kiczales,=20
University of British Columbia
Martin =
Odersky,=20
Ecole Polytechnique F=E9d=E9rale de =
Lausanne
=20
Calton Pu, Georgia Institute of =
Technology
=20
Peter Thiemann, Universit=E4t Freiburg
=
Andrew=20
Tolmach, Portland State University
Submission Details: Authors are invited to submit papers of at =
most
5000=20
words (excluding figures), in postscript format (letter or A4),
using =
the=20
electronic submission form by March 21st, 2002. This
deadline is =
firm. Both=20
position and technical papers are welcome
(Please indicate at time of =
submission.) Authors will be notified of
acceptance by May 14th, =
2002. =20
Final version of the papers must be
submitted by July 14, 2002.
Format: The three day conference will contain slots for =
technical
papers=20
(45 minutes) and position papers (30 minutes). Both times
include=20
discussion. Position papers are expected to describe
important =
future=20
directions, ongoing work, and survey previous
results. This category =
is best=20
thought of as one for "competitive
invited papers". Technical =
papers=20
are expected to contain novel
results. All papers will be =
reviewed by=20
the program committee for the
above-mentioned criteria, in addition =
to=20
correctness and clarity.
Simultaneous submission to other venues is =
not=20
allowed, as is
submission of previously published material. In =
addition,=20
there will
be time allocated for open discussions at the end of the=20
conference.
Proceedings will be published as an LNCS volume.
Special Note on Combined Event: While the Program Committee is=20
divided
into two focus areas corresponding the parent events (GCSE =
and=20
SAIG),
there will be one unified program committee meeting. At =
the time=20
of
submission, authors must indicate whether they intend the paper =
for
the=20
GCSE audience, SAIG audience, or BOTH. The last category is=20
the
default, and is strongly encouraged. Papers submitted =
explicitly=20
to
only one focus will be accepted or rejected by the respective=20
Program
Chair. For papers submitted to BOTH, it is enough that =
one of=20
the two
Program Chairs accepts the paper. All members of the PC =
will=20
allowed
to bid for and review all papers, and cross-bidding is=20
encouraged.
The conference itself will not be divided along focus=20
lines. Rather,
an attempt will be made to ensure that each =
session is=20
of interest to
both parent communities.
------=_NextPart_000_003C_01C1CE54.04C61670--
From gmh@Cs.Nott.AC.UK Mon Mar 18 14:27:51 2002
From: gmh@Cs.Nott.AC.UK (Graham Hutton)
Date: Mon, 18 Mar 2002 14:27:51 +0000
Subject: PhD studentship in Nottingham
Message-ID: <20020318142822.80CDF422222@www.haskell.org>
Dear all,
I'm seeking applicants for a PhD studentship in the area of functional
programming, to start on 1st October 2002 for a period of three years.
You will normally require a first-class Honours degree (or equivalent
qualification) in Computer Science and/or Mathematics, and some experience
of functional programming. If you are interested in the possibility of
such a PhD position, in the first instance please email your full CV,
including the results of all your university examinations to date.
Best wishes,
Graham
+---------------------------------------------------------------------+
| Dr Graham Hutton Email : gmh@cs.nott.ac.uk |
| Foundations of Programming Group Web : www.cs.nott.ac.uk/~gmh |
| School of Computer Science and IT |
| University of Nottingham |
| Jubilee Campus, Wollaton Road |
| Nottingham NG8 1BB Phone : +44 (0)115 951 4220 |
| United Kingdom Fax : +44 (0)115 951 4254 |
+---------------------------------------------------------------------+
From heringto@cs.unc.edu Mon Mar 18 17:37:12 2002
From: heringto@cs.unc.edu (Dean Herington)
Date: Mon, 18 Mar 2002 12:37:12 -0500
Subject: question about concurrency implementation
Message-ID: <3C9625C8.1E8FDCD8@cs.unc.edu>
I'm curious about the implementation of Concurrent Haskell in GHC and
Hugs. Does access to values possibly shared among threads cost the same
in Concurrent Haskell as in regular Haskell? I'm guessing the answer is
"yes", because Concurrent Haskell is provided by default in GHC. If the
costs are the same, does that rely on there being no true concurrency in
the current implementations? How would the cost change if true
concurrency were provided? Wouldn't thunk evaluation involve mutual
exclusion?
Dean Herington
From ajc99@aber.ac.uk Mon Mar 18 17:43:49 2002
From: ajc99@aber.ac.uk (Amanda Clare)
Date: Mon, 18 Mar 2002 17:43:49 +0000
Subject: using less stack
Message-ID: <3C962755.7080109@aber.ac.uk>
I have stack problems: my program uses too much stack. I suspect, from
removing bits of code, that it's due to a foldr in my program. If I use
foldr or foldl on a long list (eg >500 bulky elements for a 3M stack),
is this likely to be filling the stack? What is it that gets stored on
the stack? If so, is there an obvious refactoring of the fold to use?
Amanda
--
Amanda Clare http://users.aber.ac.uk/ajc99/
Tel: +44 (0)1970 621787 Fax: +44 (0)1970 622455
Dept. of Computer Science, University of Wales, Aberystwyth, SY23 3DB
From simonpj@microsoft.com Mon Mar 18 17:50:04 2002
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 18 Mar 2002 09:50:04 -0800
Subject: Haskell 98 report: March release
Message-ID: <1113DDB24D4A2841951BFDF86665EE1901041B5A@RED-MSG-10.redmond.corp.microsoft.com>
Folks
Before I get buried in ICFP submissions I thought I should
get out the H98 report draft.
It's in the usual place:
http://research.microsoft.com/~simonpj/haskell98-revised
Main changes since the Dec release are:
Much improved informal semantics of pattern matching (3.17).
Minor changes to the lexical syntax for white space (!).
Two extra productions for expressions, which makes the treatment
of sections align with the text in 3.5.
Add notes in three places about hard-to-parse constructs.=20
This is my eventual solution to some dark corners in the=20
grammar (Chapter 3).
Allow duplicates in the subordinate names of export lists (5.2).
Remark that Eq and Ord are strict in both arguments (Appendix
D.1).=20
plus quite a few other minor corrections.
As ever, your careful proofreading, esp of the new parts, would be
most helpful.
From simonmar@microsoft.com Mon Mar 18 17:50:10 2002
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 18 Mar 2002 17:50:10 -0000
Subject: question about concurrency implementation
Message-ID: <9584A4A864BD8548932F2F88EB30D1C608AA4458@TVP-MSG-01.europe.corp.microsoft.com>
> I'm curious about the implementation of Concurrent Haskell in GHC and
> Hugs. Does access to values possibly shared among threads=20
> cost the same
> in Concurrent Haskell as in regular Haskell? I'm guessing=20
> the answer is
> "yes", because Concurrent Haskell is provided by default in=20
> GHC.
"yes"
> If the costs are the same, does that rely on there being no true=20
> concurrency in
> the current implementations?
It depends what you mean by true concurrency: from the point of view of
the Haskell programmer, GHC's implementation of concurrency is "almost"
preemptive, because we can context-switch at any allocation. Most
computation does some allocation, but it's possible to write functions
that don't (although these tend to be on the trivial side - an optimised
nfib won't allocate, for example). We could artificially cause all
computation to do some allocation to avoid this problem, but we haven't
found it necessary so far.
But I suspect by "true concurrency" you're referring at the kind of
concurrent processes that can be executed on multiple CPUs
simultaneously. We did investigate doing this a while back, and found
that the locking required on thunks was very expensive (slowed down the
program by at least 2x on the bog-standard SMP machine we had here).
However there are some clever techniques that can be used to reduce the
cost - giving each process its own private allocation area and only
degrading to full locking for access to the shared portion of the heap
is one such technique we experimented with briefly but I don't have any
concrete benchmarks I'm afraid. Also you really need a multithreaded
garbage collector, which is a lot of work.
Cheers,
Simon
From ajc99@aber.ac.uk Mon Mar 18 17:59:07 2002
From: ajc99@aber.ac.uk (Amanda Clare)
Date: Mon, 18 Mar 2002 17:59:07 +0000
Subject: using less stack
References: <3C962755.7080109@aber.ac.uk>
Message-ID: <3C962AEB.9070505@aber.ac.uk>
Apologies for the typo: that should have been 50000 elements, not 500.
Amanda Clare wrote:
> I have stack problems: my program uses too much stack. I suspect, from
> removing bits of code, that it's due to a foldr in my program. If I use
> foldr or foldl on a long list (eg >500 bulky elements for a 3M stack),
> is this likely to be filling the stack? What is it that gets stored on
> the stack? If so, is there an obvious refactoring of the fold to use?
>
> Amanda
>
> --
> Amanda Clare http://users.aber.ac.uk/ajc99/
> Tel: +44 (0)1970 621787 Fax: +44 (0)1970 622455
> Dept. of Computer Science, University of Wales, Aberystwyth, SY23 3DB
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>
From Jon.Fairbairn@cl.cam.ac.uk Mon Mar 18 19:14:16 2002
From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn)
Date: Mon, 18 Mar 2002 19:14:16 +0000
Subject: using less stack
In-Reply-To: Your message of "Mon, 18 Mar 2002 17:59:07 GMT."
<3C962AEB.9070505@aber.ac.uk>
Message-ID: <29465.1016478856@cl.cam.ac.uk>
> Apologies for the typo: that should have been 50000 elements, not 500.
> =
> Amanda Clare wrote:
> > I have stack problems: my program uses too much stack. I suspect, fro=
m =
> > removing bits of code, that it's due to a foldr in my program. If I u=
se =
> > foldr or foldl on a long list (eg >500 bulky elements for a 3M stack)=
, =
> > is this likely to be filling the stack?
The fold itself won't be filling the stack. Without seeing
some of the code it's hard to tell, but the most common
cause of this sort of problem is a lack of strictness.
foldr (+) 0 [0..5000]
doesn't use up stack for the fold, but it builds a
suspension for all 5000 additions, and evaluating that
/does/ use stack unless the compiler has spotted that (+) is
strict. (What compiler/interpreter are you using?)
> > What is it that gets stored on =
> > the stack? If so, is there an obvious refactoring of the fold to use?=
The solution is to stick in $! judiciously and use foldr'
(which seems to have got dropped from the standard libraries
at some point, so you'll have to write your own) that uses
$!.
J=F3n
-- =
J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.u=
k
31 Chalmers Road jf@cl.cam.ac.uk
Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!)
From senganb@ia.nsc.com Mon Mar 18 19:19:21 2002
From: senganb@ia.nsc.com (senganb@ia.nsc.com)
Date: Mon, 18 Mar 2002 14:19:21 -0500
Subject: Haskell slicing tool?
Message-ID: <20020318141921.582b412f.senganb@ia.nsc.com>
Are there any tools to perform program slicing on Haskell?
I often find myself wanting to find all "fromJusts" invoked
from the current function, or all functions that use a
particular member of my monad's ADT.
Sengan
From reid@cs.utah.edu Mon Mar 18 20:47:26 2002
From: reid@cs.utah.edu (Alastair David Reid)
Date: 18 Mar 2002 20:47:26 +0000
Subject: question about concurrency implementation
In-Reply-To: <3C9625C8.1E8FDCD8@cs.unc.edu>
References: <3C9625C8.1E8FDCD8@cs.unc.edu>
Message-ID:
> I'm curious about the implementation of Concurrent Haskell in GHC
> and Hugs.
Hugs' implementation of concurrency is non-preemptive wherease GHC's
implementation is preemptive (or "almost preemptive") as described by
Simon.
> Does access to values possibly shared among threads cost the same in
> Concurrent Haskell as in regular Haskell? I'm guessing the answer
> is "yes", because Concurrent Haskell is provided by default in GHC.
The answer is yes for Hugs.
> If the costs are the same, does that rely on there being no true
> concurrency in the current implementations?
Just to be sure we agree on terminology: some people like to
distinguish between "parallelism" and "concurrency".
Parallelism is a way of going faster but doesn't change your
programming model. Implemented correctly, a parallel implementation
yields the same results as a sequential implementation - it just runs
faster. (This is ignoring the effects of interaction with the outside
world, of course - since that can also affect determinism.) Parallel
Haskell adds "par" and friends (operations which have no effect on the
semantics of your program).
Concurrency changes your programming model. A concurrent program is
allowed to give different results and interesting interactions
(including race conditions) between threads. A concurrent program may
run on a single processor. Concurrent Haskell adds forkIO,
killThread, MVars, etc (operations which affect not just the semantics
of your program but also the way the semantics are defined).
You might want to use different words for those concepts but I hope
the distinction is clear. (Note that the two concepts are rarely/never
separated in imperative languages. Arguably, Esterel is an exception.)
Using this terminology, I think what you're asking about is
"parallelism" and not "concurrency".
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From promos@motolev.com Mon Mar 18 20:57:28 2002
From: promos@motolev.com (promos@motolev.com)
Date: Mon, 18 Mar 2002 16:57:28 -0400
Subject: Hello
Message-ID: <200203182057.g2IKvS826553@server.angiesshowpalace.com>
We Welcome You
Angie's Show Palace
Your Private Virtual Date Awaits You.
Are you tired of those XXX sites that boast they have
10,000 photos and videos that are available on many other adult web sites? We are. Why not have hundreds of photos of our very sexy girls that you can take on your very own virtual dates.
We update our site every 3 days.We always have fresh new faces for you.
http://www.angiesxxx.com
Must be 18 years or older.
From cwitty@newtonlabs.com Tue Mar 19 00:07:41 2002
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 18 Mar 2002 16:07:41 -0800
Subject: Strictness!
In-Reply-To: Jay Cox's message of "Thu, 14 Mar 2002 22:23:32 -0600 (CST)"
References:
Message-ID:
Jay Cox writes:
> On Thu, 14 Mar 2002, Brian Huffman wrote:
>
> > In Haskell you can produce the desired behavior by using pattern guards.
> > Since the pattern guards always get evaluated before the result does, they
> > can be used to make things more strict. Here is the foldl example:
> >
> > strict x = seq x True
> >
> > foldl' :: (a -> b -> a) -> a -> [b] -> a
> > foldl' f z [] = z
> > foldl' f z (x:xs)
> > | strict z = foldl' f (f z x) xs
> >
> > You can make multiple arguments strict by using && or similar, e.g.:
> >
> > f x y | strict x && strict y = ...
> > f x y | all strict [x,y] = ...
> >
> > Of course, with the second example x and y must have the same type.
> > Hope this helps.
> >
> > - Brian Huffman
>
> Thanks! that looks like a great haskell idiom to use!
>
> Jay Cox
I also like this for trace:
f x y
| trace (show (x, y)) True
= ...
(Putting the trace on a separate line like that makes it easy to
comment out.)
Or, if you've got a function with a lot of cases, you can trace all of
them by adding:
f x y | trace (show (x, y)) False = undefined
above all the other cases.
Carl Witty
From heringto@cs.unc.edu Tue Mar 19 04:56:27 2002
From: heringto@cs.unc.edu (Dean Herington)
Date: Mon, 18 Mar 2002 23:56:27 -0500 (EST)
Subject: question about concurrency implementation
In-Reply-To:
Message-ID:
By "true concurrency" I meant "simultaneous execution of multiple threads
by multiple processors". This involves both concepts you define:
"concurrency" (to have multiple threads) and "parallelism" (to have them
execute possibly simultaneously when multiple processors are available).
>From Simon Marlow's reply, I gather that the current implementations of
Concurrent Haskell provide "concurrency" but not "parallelism", and that
provision of parallelism is not likely in the near term.
I've asked these questions in order to convince myself that multiple
threads can (and will) cooperate in lazily evaluating a value they share,
without need for any special programming. In particular, I plan to have
multiple threads share values whose computations involve uses of
`unsafePerformIO` (the safety of which my application's usage pattern
guarantees).
Thanks to you and others for your helpful replies.
Dean
On 18 Mar 2002, Alastair David Reid wrote:
>
> > I'm curious about the implementation of Concurrent Haskell in GHC
> > and Hugs.
>
> Hugs' implementation of concurrency is non-preemptive wherease GHC's
> implementation is preemptive (or "almost preemptive") as described by
> Simon.
>
> > Does access to values possibly shared among threads cost the same in
> > Concurrent Haskell as in regular Haskell? I'm guessing the answer
> > is "yes", because Concurrent Haskell is provided by default in GHC.
>
> The answer is yes for Hugs.
>
> > If the costs are the same, does that rely on there being no true
> > concurrency in the current implementations?
>
> Just to be sure we agree on terminology: some people like to
> distinguish between "parallelism" and "concurrency".
>
> Parallelism is a way of going faster but doesn't change your
> programming model. Implemented correctly, a parallel implementation
> yields the same results as a sequential implementation - it just runs
> faster. (This is ignoring the effects of interaction with the outside
> world, of course - since that can also affect determinism.) Parallel
> Haskell adds "par" and friends (operations which have no effect on the
> semantics of your program).
>
> Concurrency changes your programming model. A concurrent program is
> allowed to give different results and interesting interactions
> (including race conditions) between threads. A concurrent program may
> run on a single processor. Concurrent Haskell adds forkIO,
> killThread, MVars, etc (operations which affect not just the semantics
> of your program but also the way the semantics are defined).
>
> You might want to use different words for those concepts but I hope
> the distinction is clear. (Note that the two concepts are rarely/never
> separated in imperative languages. Arguably, Esterel is an exception.)
>
> Using this terminology, I think what you're asking about is
> "parallelism" and not "concurrency".
From ketil@ii.uib.no Tue Mar 19 07:56:40 2002
From: ketil@ii.uib.no (Ketil Z. Malde)
Date: 19 Mar 2002 08:56:40 +0100
Subject: question about concurrency implementation
In-Reply-To:
References:
Message-ID:
Dean Herington writes:
> From Simon Marlow's reply, I gather that the current implementations of
> Concurrent Haskell provide "concurrency" but not "parallelism", and that
> provision of parallelism is not likely in the near term.
Uh, GPH exists, doesn't it? So you can get "parallelism" if you're
after performance. The only implementation appears to be based on
PVM, so I expect some overhead on SMPs, although I haven't gotten
around to actually try it yet.
I don't know if or how you can mix the two paradigms.
There's also an implementation using threads for asynchronous calls to
Win32 libraries, if I understand things correctly. A full
thread-based parallel implementation might (or might not) be a logical
next step.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
From colin@cs.york.ac.uk Tue Mar 19 09:56:49 2002
From: colin@cs.york.ac.uk (Colin Runciman)
Date: Tue, 19 Mar 2002 09:56:49 +0000
Subject: Haskell slicing tool?
Message-ID:
> Are there any tools to perform program slicing on Haskell?
> I often find myself wanting to find all "fromJusts" invoked
> from the current function, or all functions that use a
> particular member of my monad's ADT.
Assuming that what you want to see are the applications of
these functions that occur at run-time, and the evaluation
contexts in which they arise, you could try the Hat
tracing tools (http://www.cs.york.ac.uk/fp/hat/).
Colin R
From ajc99@aber.ac.uk Tue Mar 19 11:15:28 2002
From: ajc99@aber.ac.uk (Amanda Clare)
Date: Tue, 19 Mar 2002 11:15:28 +0000
Subject: using less stack
References: <29465.1016478856@cl.cam.ac.uk>
Message-ID: <3C971DD0.1030002@aber.ac.uk>
Thanks for all the advice. In the end, I couldn't make $! work for me
(it always seems to be harder than I think it will be to use it, and $!
and deepSeq makes my code run slowly). But a continuation passing style
foldl worked wonderfully.
I now have:
> cpsfold f a [] = a
> cpsfold f a (x:xs) = f x a (\y -> cpsfold f y xs)
and f takes a continuation, Bob's my uncle, and I have a program that
runs quickly in constant space!
Amanda
--
Amanda Clare http://users.aber.ac.uk/ajc99/
Tel: +44 (0)1970 621787 Fax: +44 (0)1970 622455
Dept. of Computer Science, University of Wales, Aberystwyth, SY23 3DB
From dominic.j.steinitz@britishairways.com Tue Mar 19 11:33:11 2002
From: dominic.j.steinitz@britishairways.com (dominic.j.steinitz@britishairways.com)
Date: Tue, 19 Mar 2002 11:33:11 +0000
Subject: Gaussian Integers
Message-ID:
On holiday, I started reading about Gaussian integers (as you do) and I
thought this should be a piece of cake for Haskell. I get the following
error in Hugs:
ERROR "D:\Temp\comptst2.hs" (line 4): Cannot build superclass instance
*** Instance : Num (Gaussian a)
*** Context supplied : ()
*** Required superclass : Eq (Gaussian a)
and a similar one using GHCi:
Could not deduce `Eq b' from the context ()
Probable fix:
Add `Eq b' to the instance declaration context
arising from an instance declaration at comptst1.hs:4
I've already declared Gaussian a as being of class Eq so why does it need
to be told again?
data Integral a => Gaussian a = Gaussian a a
deriving (Eq, Show)
instance Num (Gaussian a) where
Gaussian a b - Gaussian a' b' = Gaussian (a-a') (b-b')
Gaussian a b + Gaussian a' b' = Gaussian (a+a') (b+b')
Gaussian a b * Gaussian a' b' = Gaussian (a*a' - b*b') (a*b' + b*a')
negate (Gaussian a b) = Gaussian (negate a) (negate b)
fromInteger a = Gaussian (fromIntegral a) 0
From voigt@orchid.inf.tu-dresden.de Tue Mar 19 11:46:43 2002
From: voigt@orchid.inf.tu-dresden.de (Janis Voigtlaender)
Date: Tue, 19 Mar 2002 12:46:43 +0100
Subject: Gaussian Integers
References:
Message-ID: <3C972523.A09DBE6A@tcs.inf.tu-dresden.de>
dominic.j.steinitz@britishairways.com wrote:
> I've already declared Gaussian a as being of class Eq so why does it need
> to be told again?
>
> data Integral a => Gaussian a = Gaussian a a
> deriving (Eq, Show)
>
> instance Num (Gaussian a) where
> Gaussian a b - Gaussian a' b' = Gaussian (a-a') (b-b')
> Gaussian a b + Gaussian a' b' = Gaussian (a+a') (b+b')
> Gaussian a b * Gaussian a' b' = Gaussian (a*a' - b*b') (a*b' + b*a')
> negate (Gaussian a b) = Gaussian (negate a) (negate b)
> fromInteger a = Gaussian (fromIntegral a) 0
You have only declared Gaussian a as being of class Eq (by deriving) if
"a" is of class Integral (as a context in the data declaration). Adding
Integral a to your instance should fix the problem:
instance Integral a => Num (Gaussian a) where
Gaussian a b - Gaussian a' b' = Gaussian (a-a') (b-b')
Gaussian a b + Gaussian a' b' = Gaussian (a+a') (b+b')
Gaussian a b * Gaussian a' b' = Gaussian (a*a' - b*b') (a*b' + b*a')
negate (Gaussian a b) = Gaussian (negate a) (negate b)
fromInteger a = Gaussian (fromIntegral a) 0
--
Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:voigt@tcs.inf.tu-dresden.de
From mechvel@math.botik.ru Tue Mar 19 12:05:03 2002
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Tue, 19 Mar 2002 15:05:03 +0300
Subject: Gaussian integers. Reply
Message-ID:
dominic.j.steinitz@britishairways.com writes
> On holiday, I started reading about Gaussian integers (as you do) and I
> thought this should be a piece of cake for Haskell. I get the following
> error in Hugs:
> [..]
>
> data Integral a => Gaussian a = Gaussian a a
> deriving (Eq, Show)
>
> instance Num (Gaussian a) where
> Gaussian a b - Gaussian a' b' = Gaussian (a-a') (b-b')
> Gaussian a b + Gaussian a' b' = Gaussian (a+a') (b+b')
> Gaussian a b * Gaussian a' b' = Gaussian (a*a' - b*b') (a*b' + b*a')
> negate (Gaussian a b) = Gaussian (negate a) (negate b)
> fromInteger a = Gaussian (fromIntegral a) 0
To my mind, it is not good to set `Integral a =>' to data declaration.
It is better to set such things in the instance declarations.
Try, say
data Gaussian a = Gau a a deriving (Eq, Show)
instance Integral a => Num (Gaussian a)
where
Gau a b - Gau a' b' = Gau (a-a') (b-b')
...
-------------------------------------------------
scico:~/t> ghci M.hs
... GHC Interactive, version 5.02.2, for Haskell 98.
...
M> Gau 1 1 * Gau 1 (-1)
Gau 2 0
-----------------
Serge Mechveliani
mechvel@botik.ru
From simonpj@microsoft.com Tue Mar 19 12:03:40 2002
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 19 Mar 2002 04:03:40 -0800
Subject: question about concurrency implementation
Message-ID: <1113DDB24D4A2841951BFDF86665EE1901041B68@RED-MSG-10.redmond.corp.microsoft.com>
Dean
| From Simon Marlow's reply, I gather that the current=20
| implementations of Concurrent Haskell provide "concurrency"=20
| but not "parallelism", and that provision of parallelism is=20
| not likely in the near term.
That's more or less right. The trouble is that for shared-memory
parallelism
- you take a performance hit for fine-grain locking
- so you need real parallelism to recover that performance
All the pieces are there in GHC, mostly implemented; but making
it all really work, really reliably, and somewhat portably, is a
non-trivial task... and the reward (as I say above) can be elusive.
| I've asked these questions in order to convince myself that=20
| multiple threads can (and will) cooperate in lazily=20
| evaluating a value they share, without need for any special=20
| programming. In particular, I plan to have multiple threads=20
| share values whose computations involve uses of=20
| `unsafePerformIO` (the safety of which my application's usage=20
| pattern guarantees).
Do make sure you understand Concurrent Haskell (I'm sure you do),
which is specifically about multiple threads each of which can perform
I/O. (See "Tackling the awkward squad" on my home page.) You are
on thin ice with unsafePerformIO, especially when concurrency is
involved.
Simon
From daan@cs.uu.nl Tue Mar 19 14:55:58 2002
From: daan@cs.uu.nl (Daan Leijen)
Date: Tue, 19 Mar 2002 15:55:58 +0100
Subject: Haskell puzzles!
Message-ID: <018401c1cf56$2e95f080$9650d383@ajam>
Hi all,
I have put together some interesting Haskell puzzles!
Not many people were able to solve all three puzzles
so don't be discouraged you don't know all the answers.
Have fun,
Daan.
-----------------------------------------------------
- All three puzzles are "Haskell 98"; you can solve
them using the Haskell 98 manual and they should be
implementation independent.
- "equal" means that two evaluated expression denote
the same semantical value; i.e. when typed on the
Hugs prompt, I will see the same answer.
- All the answers are at the end of this mail.
-----------------------------------------------------
1) Are e1 and e2 equal?
> f (x:xs) y = x
> g (x:xs) = \y -> x
>
> e1 = seq (f []) 1
> e2 = seq (g []) 1
-----------------------------------------------------
2) Are e1 and e2 equal?
Is one definition preferred over the other?
(And what about "h x = nfib 30" ?)
> f = const (nfib 30)
> g = \x -> nfib 30
>
> e1 = f 1 + f 2
> e2 = g 1 + g 2
-----------------------------------------------------
3) Are e1 and e2 equal?
And what if I typed them on the Hugs prompt?
> f = \x -> x + x
> g x = x + x
>
> e1 = f 1.0 + f 2.0
> e2 = g 1.0 + g 2.0
-----------------------------------------------------
Answers at the end of this email.....
Answers:
-----------------------------------------------------
1)
answer:
"e1" equals the value 1, while "e2" is undefined.
explanation:
This is due to the translation of pattern matching.
The functions are de sugared into:
> f x' y = case x' of (x:xs) -> x
> g x' = case x' of (x:xs) -> (\y -> x)
Now, the expression "f []" is a partial application
and thus in weak head normal form while "g []" is
evaluated and the pattern matching fails.
opinion:
I think that the pattern matching translation rules
are wrong here and we shouldn't push the "case" through
the lambda's. However, the current rules are potentially
more efficient since all arguments can be collected
before matching.
-----------------------------------------------------
2)
answer:
Yes, "e1" and "e2" are equal. However, the "f" definition
is preferred since it potentially shares the computation
of "nfib 30". ("e1" will be almost twice as fast as "e2"
on most systems).
explanation:
The Haskell language is only defined to be "non-strict".
This means that there are no guarantees about sharing. However,
all current Haskell systems use lazy semantics. This means
that both "f" and "g" are caf's. When "g" is evaluated, the
expression "\x -> nfib 30" is shared and on each call "nfib 30"
is re-evaluated. When "f" is evaluated, the application node
"const (nfib 30)" is shared and once it is applied it will be updated
and "nfib 30" is only evaluated once. Smart compilers like GHC
however, will inline definitions like "g" and after common expression
elimination we also end up with an efficient version. Same would
hold for a full laziness transformation.
Note that "h x = nfib 30" behaves exactly like "g" except that it's
type is more general due to the monomorphism restriction and
defaulting:
> f,g :: a -> Integer
> h :: Num b => a -> b
opinion:
I believe that the operational distinction between both definitions
is fundamentally important and should be expressible by the user.
-----------------------------------------------------
3)
answer:
Yes, "e1" and "e2" are equal (6.0). However, when "e1" and "e2"
are used outside the scope of "f" and "g", for example when typed
on the Hugs prompt, "e1" is not well-typed.
explanation:
The type of "g" is "Num a => a -> a". One would expect the same
type for "f" but unfortunately, the monomorphism restriction prevents
this and defaulting tries to resolve the instance. Based on the usage
of "f", it will default to "Double" and we get the type "Double -> Double"
for "f". However, if we would use it from the Hugs prompt, there is
no usage site of "f" and defaulting will resort to the "default defaulting"
rules and set the type of "f" to "Integer -> Integer" and the expression
"f 1.0" becomes ill typed -- that is, unless I use a "default" declaration
in the module, as in:
> default (Double)
opinion:
Clearly, as puzzle 2 shows, we want to have a distinction between
shared values and functions. So, we need at least to be warned when
the compiler would add a dictionary argument. I would say that an
"overloading warning" is more appropriate than a "monomorphism restriction".
Anyway, the real culprit here is the horrible defaulting mechanism.
I believe that defaulting has no place in Haskell modules and should
probably only be used on expressions in a top-level interpreter.
From jmaessen@alum.mit.edu Tue Mar 19 15:44:26 2002
From: jmaessen@alum.mit.edu (Jan-Willem Maessen)
Date: Tue, 19 Mar 2002 10:44:26 -0500
Subject: Haskell puzzles!
Message-ID: <200203191544.KAA00691@lauzeta.mit.edu>
Daan Leijen writes:
> 1) Are e1 and e2 equal?
>
> > f (x:xs) y = x
> > g (x:xs) = \y -> x
> >
> > e1 = seq (f []) 1
> > e2 = seq (g []) 1
> ...
> 1)
> answer:
> "e1" equals the value 1, while "e2" is undefined.
> ...
> opinion:
> I think that the pattern matching translation rules
> are wrong here and we shouldn't push the "case" through
> the lambda's. However, the current rules are potentially
> more efficient since all arguments can be collected
> before matching.
On the contrary, I far prefer the way things are now. Matching
arguments as they arrive makes programs far too eager about pattern
matching. Consider the following minor variation on your example
(which happily also avoids using "seq"):
Q) Are e1 and e2 both defined?
> f (x:xs) y z = x
> g (x:xs) = \y -> \z -> x
>
> e1 = f [] 1
> e2 = g [] 1
A) No, e1 is defined---pattern matching happens only when all the
arguments have arrived. This is nice and lazy---we don't do any work
until we know we have to. By contrast, e2 performs the matching as
soon as (g []) is applied to 1. We've matched eagerly, and our
program fails.
opinion:
In practice, pattern matches are much more complicated than f and g.
There is no easy and convenient way to get the behavior of e1 if
matching always works as in e2. Indeed, it's not even clear how to
do complex multiple-argument pattern matches if we proceed this way.
Meanwhile, there's a simple way to turn f into g if that's what is
desired.
-Jan-Willem Maessen
And I've implemented *Eager* Haskell, too.
From Sengan.Baring-Gould@nsc.com Tue Mar 19 18:20:39 2002
From: Sengan.Baring-Gould@nsc.com (Sengan.Baring-Gould@nsc.com)
Date: Tue, 19 Mar 2002 13:20:39 -0500
Subject: Haskell slicing tool?
In-Reply-To:
References:
Message-ID: <20020319132039.37e63d70.senganb@ia.nsc.com>
On Tue, 19 Mar 2002 09:56:49 +0000
"Colin Runciman" wrote:
> > Are there any tools to perform program slicing on Haskell?
> > I often find myself wanting to find all "fromJusts" invoked
> > from the current function, or all functions that use a
> > particular member of my monad's ADT.
>
> Assuming that what you want to see are the applications of
> these functions that occur at run-time, and the evaluation
> contexts in which they arise, you could try the Hat
> tracing tools (http://www.cs.york.ac.uk/fp/hat/).
Actually I was hoping for a static tool.
But now HAT works with GHC I'll be trying it out. Thanks.
Sengan
From ESEJournal@unisannio.it Tue Mar 19 23:56:07 2002
From: ESEJournal@unisannio.it (ESEJournal@unisannio.it)
Date: Wed, 20 Mar 2002 00:56:07 +0100 (CET)
Subject: Empirical Software Engineering: An International Journal - CALL FOR PAPERS
Message-ID: <200203192356.g2JNu7O05682@unisannio.it>
***********************************************************
Empirical Software Engineering: An International Journal
- CALL FOR PAPERS -
***********************************************************
http://www.kluweronline.com/issn/1382-3256
. Consider submitting papers on your latest experiments and field studies!
. The journal focuses on software measurement, quality and productivity
improvement, and technology evaluation
. Empirical studies addressing important software
development issues are reported, providing results and data
. Check the Journal Contents link for a sample of published articles
. Papers can be searched and downloaded on line!
. Individual subscription: USD $68 - subscribe on-line
Please forward the following to anybody who you think may be interested.
Our apologies if you received multiple copy of this message.
If you would like to be removed from our list please send an email to
ESEJournal@unisannio.it with REMOVE in the subject.
From Diego Yanivello"
This is a multi-part message in MIME format.
------=_NextPart_000_000E_01C1CF8C.3AAA60A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
hi, =20
is there (in Haskell) a function like =20
existFile :: FilePath -> IO (Bool) ?
Thanks!
------=_NextPart_000_000E_01C1CF8C.3AAA60A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
hi,
is there (in Haskell) a function=20
like
existFile :: FilePath =
-> IO=20
(Bool) ?
Thanks!
------=_NextPart_000_000E_01C1CF8C.3AAA60A0--
From lennart@augustsson.net Wed Mar 20 00:32:35 2002
From: lennart@augustsson.net (Lennart Augustsson)
Date: Wed, 20 Mar 2002 01:32:35 +0100
Subject: finding ....
References: <001101c1cfa5$6102a000$115633c8@s1i4m9>
Message-ID: <3C97D8A3.B8CA185@augustsson.net>
Using such a function is generally a bad idea because of race conditions.
-- Lennart
Diego Yanivello wrote:
> hi, is there (in Haskell) a function like existFile :: FilePath ->
> IO (Bool) ? Thanks!
From pixel@mandrakesoft.com Wed Mar 20 00:54:23 2002
From: pixel@mandrakesoft.com (Pixel)
Date: 20 Mar 2002 01:54:23 +0100
Subject: finding ....
In-Reply-To: <3C97D8A3.B8CA185@augustsson.net>
References: <001101c1cfa5$6102a000$115633c8@s1i4m9>
<3C97D8A3.B8CA185@augustsson.net>
Message-ID:
Lennart Augustsson writes:
> > Diego Yanivello wrote:
> >
> > > hi, is there (in Haskell) a function like existFile :: FilePath ->
> > > IO (Bool) ? Thanks!
>
> Using such a function is generally a bad idea because of race conditions.
however, real world programs use those tests since you don't need to care
*everytime* about race conditions. (of course using this existFile before
creating a temporary file is wrong, but existFile has *many* other
applications)
From hallgren@cse.ogi.edu Wed Mar 20 01:05:25 2002
From: hallgren@cse.ogi.edu (Thomas Hallgren)
Date: Tue, 19 Mar 2002 17:05:25 -0800
Subject: finding ....
References: <001101c1cfa5$6102a000$115633c8@s1i4m9> <3C97D8A3.B8CA185@augustsson.net>
Message-ID: <3C97E055.4030001@cse.ogi.edu>
Hi,
The standard library module Directory contains
doesFileExist :: FilePath -> IO Bool
See http://www.haskell.org/onlinelibrary/directory.html
Regards,
Thomas Hallgren
PS If using doesFileExist is a bad idea, then using some of the other
functions from the module Directory, e.g. getDirectoryContents, is
probablya bad idea too...
Lennart Augustsson wrote:
>Using such a function is generally a bad idea because of race conditions.
>
> -- Lennart
>
>Diego Yanivello wrote:
>
>>hi, is there (in Haskell) a function like existFile :: FilePath ->
>>IO (Bool) ? Thanks!
>>
From lennart@augustsson.net Wed Mar 20 01:18:05 2002
From: lennart@augustsson.net (Lennart Augustsson)
Date: Wed, 20 Mar 2002 02:18:05 +0100
Subject: finding ....
References: <001101c1cfa5$6102a000$115633c8@s1i4m9>
<3C97D8A3.B8CA185@augustsson.net>
Message-ID: <3C97E34D.81449C0C@augustsson.net>
Just because many applications use this doesn't make it safe or good.
Presumably you are testing for the existence of the file to do something
to it (read, create, delete...). It's better to do the operation you want to
do and have it fail if the file is missing (or existing if you create). You
then just have to handle the exception (that part is already in H98) or
proceed with the normal path. I claim the code simpler this way and you
avoid any race conditions.
-- Lennart
Pixel wrote:
> Lennart Augustsson writes:
>
> > > Diego Yanivello wrote:
> > >
> > > > hi, is there (in Haskell) a function like existFile :: FilePath ->
> > > > IO (Bool) ? Thanks!
> >
> > Using such a function is generally a bad idea because of race conditions.
>
> however, real world programs use those tests since you don't need to care
> *everytime* about race conditions. (of course using this existFile before
> creating a temporary file is wrong, but existFile has *many* other
> applications)
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From pixel@mandrakesoft.com Wed Mar 20 01:37:03 2002
From: pixel@mandrakesoft.com (Pixel)
Date: 20 Mar 2002 02:37:03 +0100
Subject: finding ....
In-Reply-To: <3C97E34D.81449C0C@augustsson.net>
References: <001101c1cfa5$6102a000$115633c8@s1i4m9>
<3C97D8A3.B8CA185@augustsson.net>
<3C97E34D.81449C0C@augustsson.net>
Message-ID:
Lennart Augustsson writes:
> Just because many applications use this doesn't make it safe or good.
> Presumably you are testing for the existence of the file to do something
> to it (read, create, delete...). It's better to do the operation you want to
> do and have it fail if the file is missing (or existing if you create). You
> then just have to handle the exception (that part is already in H98) or
> proceed with the normal path. I claim the code simpler this way and you
> avoid any race conditions.
I said real-world pbs ;p
WARNING, perl below!
- checking if devfs is mounted in /dev: -e "/dev/.devfsd"
- checking wether there is cdrom drive with devfs: -e "/dev/cdroms/cdrom0"
- looking for a file in a PATH-like:
if ($f !~ m|/|) { -e "$_/$f" and $f = "$_/$f", last foreach @icon_paths }
-
if (-e "$f.gz") {
# ... the wanted file is gzip'ed, doing whatever is needed
}
-
-x "/bin/sh" or die "cannot open shell - /bin/sh doesn't exist";
fork and return;
# doing things
# now, and only now exec'ing
exec "/bin/sh"
-
if (! -e '/usr/sbin/showmount') {
my $pkg = 'nfs-utils-clients';
$in->ask_okcancel('', _("The package %s needs to be installed. Do you want to install it?", $pkg), 1) or return;
$in->do_pkgs->install($pkg);
}
If you want some more, just ask ;)
From lennart@augustsson.net Wed Mar 20 01:42:02 2002
From: lennart@augustsson.net (Lennart Augustsson)
Date: Wed, 20 Mar 2002 02:42:02 +0100
Subject: finding ....
References: <001101c1cfa5$6102a000$115633c8@s1i4m9>
<3C97D8A3.B8CA185@augustsson.net>
<3C97E34D.81449C0C@augustsson.net>
Message-ID: <3C97E8EA.C0C8326A@augustsson.net>
Thank you for making my point. All these are indeed examples of broken code.
(Not because it's Perl. :)
-- Lennart
Pixel wrote:
> Lennart Augustsson writes:
>
> > Just because many applications use this doesn't make it safe or good.
> > Presumably you are testing for the existence of the file to do something
> > to it (read, create, delete...). It's better to do the operation you want to
> > do and have it fail if the file is missing (or existing if you create). You
> > then just have to handle the exception (that part is already in H98) or
> > proceed with the normal path. I claim the code simpler this way and you
> > avoid any race conditions.
>
> I said real-world pbs ;p
>
> WARNING, perl below!
>
> - checking if devfs is mounted in /dev: -e "/dev/.devfsd"
> - checking wether there is cdrom drive with devfs: -e "/dev/cdroms/cdrom0"
> - looking for a file in a PATH-like:
> if ($f !~ m|/|) { -e "$_/$f" and $f = "$_/$f", last foreach @icon_paths }
> -
> if (-e "$f.gz") {
> # ... the wanted file is gzip'ed, doing whatever is needed
> }
>
> -
> -x "/bin/sh" or die "cannot open shell - /bin/sh doesn't exist";
> fork and return;
> # doing things
> # now, and only now exec'ing
> exec "/bin/sh"
>
> -
> if (! -e '/usr/sbin/showmount') {
> my $pkg = 'nfs-utils-clients';
> $in->ask_okcancel('', _("The package %s needs to be installed. Do you want to install it?", $pkg), 1) or return;
> $in->do_pkgs->install($pkg);
> }
>
> If you want some more, just ask ;)
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From camio@yahoo.com Wed Mar 20 02:37:34 2002
From: camio@yahoo.com (David Sankel)
Date: Tue, 19 Mar 2002 18:37:34 -0800 (PST)
Subject: finding ....
In-Reply-To:
Message-ID: <20020320023734.29314.qmail@web13206.mail.yahoo.com>
--- Pixel wrote:
> Lennart Augustsson writes:
>
> > > Diego Yanivello wrote:
> > >
> > > > hi, is there (in Haskell) a function like
> existFile :: FilePath ->
> > > > IO (Bool) ? Thanks!
> >
> > Using such a function is generally a bad idea
> because of race conditions.
>
> however, real world programs use those tests since
> you don't need to care
> *everytime* about race conditions. (of course using
> this existFile before
> creating a temporary file is wrong, but existFile
> has *many* other
> applications)
Could someone post an example of the creation of a
temporary file where race conditions are important?
Thanks,
David J. Sankel
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
From juhp@01.246.ne.jp Wed Mar 20 06:00:32 2002
From: juhp@01.246.ne.jp (Jens Petersen)
Date: 20 Mar 2002 15:00:32 +0900
Subject: Bug in IO libraries when sending data through a pipe?
In-Reply-To:
References:
Message-ID:
Jens Petersen writes:
> > The problem is that the child process doesn't receive all the data which
> > the parent sends. It's as if "hPutStr vonh txt" sends the data lazily
> > somehow, and "hClose vonh" closes the pipe prematurely.
> >
> > It varies from run to run exactly which data gets through. If I cause the
> > child process to read all its input immediately, the problem doesn't
> > seem to occur. Normally, it does so gradually, which takes a few seconds.
> >
> > I'm using GHC 5.02.2
>
> Quite possibly could be a bug. Lazy IO is rather subtle I
> think, specially when done across pipes. I faced some
> similar problem with in POpen recently. You can see how I
> solved it (worked round it?) by comparing the latest release
> 1.00 with the previous one 0.00.1:
>
> http://www.01.246.ne.jp/~juhp/haskell/popenhs/
>
> In comparison Posix.runProcess allows attaching file handles
> to the in, out and error pipes, which can be written to and
> read from eagerly I suppose.
Also I just rediscovered Manuel Chakravarty's HPL (Haskell
Ports Library), which provides a rather elegant,
sophisticated approach.
http://www.cse.unsw.edu.au/~chak/haskell/ports/
It compiles fine under ghc-5.02.2, and using the BufferMode
patch included at the end output seems to be ok, but input
of more than 2048 bytes doesn't seem to be being handled
reliably.
Eg with the test program below:
% test-processes ping localhost
works (with the aforementioned patch below to Processes.hs), but
% cat 4096 | test-processes cat
[4096 is a file of 4096 chars]
mostly gives no output, but occasionally I see
Warning: Ports.listenToPort: Attempted to listen to a closed port!
Needs some debugging I guess. :)
Jens
-- ghc -o test-processes `ports-config --cflags --libs` test-processes.hs
module Main
where
import Processes
import Ports
import IO (openFile, hGetContents, IOMode(..), hSetBuffering, BufferMode(..))
import Monad (unless)
main :: IO()
main = do
inpt <- getContents
withPorts [] $ \ (cmd:args) ->
do
outpt <- newPort ' '
errpt <- newPort ' '
let p = proc cmd args
p inpt outpt errpt
putStrLn "output:"
out <- listenToPort outpt
mapM_ putStrLn $ lines out
putStrLn "error:"
errclosed <- isClosedPort errpt
unless errclosed $
do
err <- listenToPort errpt
putStr err
putStrLn "test finished"
Index: Processes.hs
===================================================================
RCS file: /home/chakcvs/cvs/ports/lib/Processes.hs,v
retrieving revision 1.7
diff -u -r1.7 Processes.hs
--- Processes.hs 2001/07/04 16:15:52 1.7
+++ Processes.hs 2002/03/20 05:28:33
@@ -145,6 +145,8 @@
stdoutWriteHandle <- fdToHandle stdoutWriteFD
stderrReadHandle <- fdToHandle stderrReadFD
stderrWriteHandle <- fdToHandle stderrWriteFD
+ hSetBuffering stdoutReadHandle LineBuffering
+ hSetBuffering stderrReadHandle LineBuffering
--
-- the child must close the pipe ends that it doesn't use (especially, the
-- write end)
From Jon.Fairbairn@cl.cam.ac.uk Wed Mar 20 10:18:56 2002
From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn)
Date: Wed, 20 Mar 2002 10:18:56 +0000
Subject: finding ....
In-Reply-To: Your message of "Tue, 19 Mar 2002 18:37:34 PST."
<20020320023734.29314.qmail@web13206.mail.yahoo.com>
Message-ID: <8240.1016619536@cl.cam.ac.uk>
> Could someone post an example of the creation of a
> temporary file where race conditions are important?
/any/ programme that does this on a multi-process system.
Between the test for existence and the creation, some other
process could have created a file of the same name. Then
the create fails because of insufficient permissions,
so the programme has to deal with failure anyway, or it
succeeds and stomps on the data belonging to the other
process.
do possible_handle <- try $ openFile "whatever" ReadMode
case possible_handle =
of (Right handle) -> do_things_to handle
(Left error) -> do whatever you would have done had
the existence test returned false
is no more complex than a version using an existence test,
but to create a file for writing, surely we need an
openNewFile primitive? Otherwise we might open on a file
that already exists and hit the "stomp" error mentioned
above.
J=F3n
-- =
J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.u=
k
31 Chalmers Road jf@cl.cam.ac.uk
Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!)
From dfeuer@cs.brown.edu Wed Mar 20 10:26:13 2002
From: dfeuer@cs.brown.edu (David Feuer)
Date: Wed, 20 Mar 2002 05:26:13 -0500
Subject: finding ....
In-Reply-To: <8240.1016619536@cl.cam.ac.uk>; from Jon.Fairbairn@cl.cam.ac.uk on Wed, Mar 20, 2002 at 10:18:56AM +0000
References: <20020320023734.29314.qmail@web13206.mail.yahoo.com> <8240.1016619536@cl.cam.ac.uk>
Message-ID: <20020320052612.B8025@cslab7e.cs.brown.edu>
On Wed, Mar 20, 2002, Jon Fairbairn wrote:
> > Could someone post an example of the creation of a
> > temporary file where race conditions are important?
>
> /any/ programme that does this on a multi-process system.
Occasionally, the presence or absence of a file (usually empty) of a
certain name in a certain directory is used for communication between
processes on a multi-process system.
David
From Jon.Fairbairn@cl.cam.ac.uk Wed Mar 20 10:31:28 2002
From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn)
Date: Wed, 20 Mar 2002 10:31:28 +0000
Subject: using less stack
In-Reply-To: Your message of "Tue, 19 Mar 2002 11:15:28 GMT."
<3C971DD0.1030002@aber.ac.uk>
Message-ID: <8291.1016620288@cl.cam.ac.uk>
> Thanks for all the advice. In the end, I couldn't make $! work for me =
> (it always seems to be harder than I think it will be to use it, and $!=
=
> and deepSeq makes my code run slowly). =
:-(
> But a continuation passing style foldl worked wonderfully.
As Jay Cox pointed out by email, my answer was rot because I
had confused foldl and foldr
> I now have:
> =
> > cpsfold f a [] =3D a
> > cpsfold f a (x:xs) =3D f x a (\y -> cpsfold f y xs)
> =
> and f takes a continuation, Bob's my uncle, and I have a program that =
> runs quickly in constant space!
Good. I'm curious to know from other readers whether
continuations like this are the only way of solving it,
though.
J=F3n
-- =
J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.u=
k
31 Chalmers Road jf@cl.cam.ac.uk
Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!)
From Jon.Fairbairn@cl.cam.ac.uk Wed Mar 20 10:33:17 2002
From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn)
Date: Wed, 20 Mar 2002 10:33:17 +0000
Subject: finding ....
In-Reply-To: Your message of "Wed, 20 Mar 2002 05:26:13 EST."
<20020320052612.B8025@cslab7e.cs.brown.edu>
Message-ID: <8314.1016620397@cl.cam.ac.uk>
> On Wed, Mar 20, 2002, Jon Fairbairn wrote:
> > > Could someone post an example of the creation of a
> > > temporary file where race conditions are important?
> > =
> > /any/ programme that does this on a multi-process system.
> =
> Occasionally, the presence or absence of a file (usually empty) of a
> certain name in a certain directory is used for communication between
> processes on a multi-process system.
Hence the need for an atomic openNewFile.
-- =
J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.u=
k
31 Chalmers Road jf@cl.cam.ac.uk
Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!)
From olaf@cs.york.ac.uk Wed Mar 20 10:42:15 2002
From: olaf@cs.york.ac.uk (Olaf Chitil)
Date: Wed, 20 Mar 2002 10:42:15 +0000
Subject: Haskell slicing tool?
References: <20020319132039.37e63d70.senganb@ia.nsc.com>
Message-ID: <3C986787.830C8F9B@cs.york.ac.uk>
Sengan.Baring-Gould@nsc.com wrote:
> > > Are there any tools to perform program slicing on Haskell?
> > > I often find myself wanting to find all "fromJusts" invoked
> > > from the current function, or all functions that use a
> > > particular member of my monad's ADT.
> Actually I was hoping for a static tool.
I'd be interested to learn for what purpose you want this kind of
information and also more precisely what you would like such a static
tool to do for you.
Olaf
--
OLAF CHITIL,
Dept. of Computer Science, The University of York, York YO10 5DD, UK.
URL: http://www.cs.york.ac.uk/~olaf/
Tel: +44 1904 434756; Fax: +44 1904 432767
From trinder@cee.hw.ac.uk Wed Mar 20 11:51:57 2002
From: trinder@cee.hw.ac.uk (Phil Trinder)
Date: Wed, 20 Mar 2002 11:51:57 +0000 (GMT Standard Time)
Subject: question about concurrency implementation
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C608AA4458@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Dean,
> > If the costs are the same, does that rely on there being no true
> > concurrency in
> > the current implementations?
>
> It depends what you mean by true concurrency: from the point of view of
> the Haskell programmer, GHC's implementation of concurrency is "almost"
> preemptive, because we can context-switch at any allocation. Most
> computation does some allocation, but it's possible to write functions
> that don't (although these tend to be on the trivial side - an optimised
> nfib won't allocate, for example). We could artificially cause all
> computation to do some allocation to avoid this problem, but we haven't
> found it necessary so far.
>
> But I suspect by "true concurrency" you're referring at the kind of
> concurrent processes that can be executed on multiple CPUs
> simultaneously. We did investigate doing this a while back, and found
> that the locking required on thunks was very expensive (slowed down the
> program by at least 2x on the bog-standard SMP machine we had here).
> However there are some clever techniques that can be used to reduce the
> cost - giving each process its own private allocation area and only
> degrading to full locking for access to the shared portion of the heap
> is one such technique we experimented with briefly but I don't have any
> concrete benchmarks I'm afraid. Also you really need a multithreaded
> garbage collector, which is a lot of work.
We've developed a Haskell extension that exhibit's "true concurrency" on
multiple CPUs, it's called Glasgow distributed Haskell (GdH). It's primarily
designed for distribution (i.e. multiple stateful threads on multiple
processors), but can be used to build parallel programs too. For more info see
http://www.cee.hw.ac.uk/~dsg/gdh/
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 C.Reinke@ukc.ac.uk Wed Mar 20 18:12:12 2002
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Wed, 20 Mar 2002 18:12:12 +0000
Subject: using less stack
In-Reply-To: Message from Jon Fairbairn
of "Wed, 20 Mar 2002 10:31:28 GMT." <8291.1016620288@cl.cam.ac.uk>
Message-ID:
> > > cpsfold f a [] ú
> > > cpsfold f a (x:xs) ÿ x a (\y -> cpsfold f y xs)
> >
> > and f takes a continuation, Bob's my uncle, and I have a program that
> > runs quickly in constant space!
>
> Good. I'm curious to know from other readers whether
> continuations like this are the only way of solving it,
> though.
Actually, and quite apart from it being cumbersome to use, I've got
my doubts about whether this cpsfold really does the job (is that
just me missing some point?-).
Also, I'm curious to know why the usual strict variant of foldl
doesn't help in this case?
foldl' f a [] = a
foldl' f a (x:xs) = (foldl' f $! f a x) xs
or, with the recently suggested idiom for strictness, tracing and
other annotations:-)
annotation = undefined
strict a = seq a False
foldl' f a l | strict a = annotation
foldl' f a [] = a
foldl' f a (x:xs) = foldl' f (f a x) xs
Claus
From hdaume@ISI.EDU Wed Mar 20 18:28:13 2002
From: hdaume@ISI.EDU (Hal Daume III)
Date: Wed, 20 Mar 2002 10:28:13 -0800 (PST)
Subject: using less stack
In-Reply-To:
Message-ID:
> strict a = seq a False
>
> foldl' f a l | strict a = annotation
> foldl' f a [] = a
> foldl' f a (x:xs) = foldl' f (f a x) xs
Or, perhaps
strict a = a `deepSeq` False
or
strict a = rnf a `seq` False
if you prefer the rnf notation instead.
depending on what you want...
\begin{rant}
I think the whole seq thing is very confusing for beginning/intermediate
haskell programmers. I was very confused for a long time as to why
> (unsafePerformIO (putStrLn "Hello")) `seq` 5
would print "Hello", but
> [unsafePerformIO (putStrLn "Hello")] `seq` 5
would not. this goes back to the earlier discussion of "does a haskell
programmer need to know how the compiler works." while you could argue
this isn't exactly a compiler issue and that the semantics of seq *are*
well defined outside any particular compiler, you do need to know
something about how the graph reduction happens, etc., in order to
understand exactly what is being evaluated on the left hand side of
`seq`. I would almost prefer if the semantics of `seq` were instead those
of rnf or deepSeq, so long as either (a) we were allowed to derive DeepSeq
or NFData, or (b) if the compiler would just do it itself. Yes, this
would cut down on the expressions which we could `seq`, but does that
really matter. I mean, how often are we going to say:
> (+) `seq` 5
What the heck is that supposed to mean? I would almost *prefer* if an
expression like that didn't typecheck.
Since seq isn't lambda definable anyway, I don't see any particular reason
the compiler couldn't just reduce to normal form instead of weak head
normal form for seqs. Perhaps artifically introduce an NFData instance
for everything so the above doesn't typecheck.
But that's just me :)
\end{rant}
From ajc99@aber.ac.uk Wed Mar 20 18:45:15 2002
From: ajc99@aber.ac.uk (Amanda Clare)
Date: Wed, 20 Mar 2002 18:45:15 +0000
Subject: using less stack
References:
Message-ID: <3C98D8BB.5060001@aber.ac.uk>
[cpsfold omitted]
> Actually, and quite apart from it being cumbersome to use, I've got
> my doubts about whether this cpsfold really does the job (is that
> just me missing some point?-).
It does the job for me! In practical terms I can see it works. I'm not
an expert - I may have this all wrong, but perhaps the point you're
looking for is that the arguments to f are brought to the very outside
of the expression, and hence available for evaluation. Imagine for
[x1,x2,x3,x4]
from foldr: f x1 (f x2 (f x3 (f x4 a)))
from foldl: f (f (f (f a x1) x2) x3) x4
Neither are available for immediate evaluation. In the case of foldr the
end of the list (x4) has to be reached before anything can be evaluated.
In the case of foldl the first function to be pulled upon is the
outermost f, which then can't do anything useful (in my case) without
evaluating its second argument, and so on.
with the cpsfold I get
f x1 a (\y1 -> f x2 y1 (\y2 -> f x3 y3 (\y3 -> f x4 y4 (\y4 -> y4)
so x1 and a are available immediately for f to use, and f x1 a is the
outermost expression so will be evaluated first.
See for yourself with the following (difference can be seen in ghc with
standard 1M stack):
> answer1 = foldr larger 0 [1..500000]
> answer2 = foldl larger 0 [1..500000]
> answer3 = cpsfold cpslarger 0 [1..500000]
> larger x y = if x > y then x else y
> cpslarger x y k = if x > y then k x else k y
> Also, I'm curious to know why the usual strict variant of foldl
> doesn't help in this case?
>
> foldl' f a [] = a
> foldl' f a (x:xs) = (foldl' f $! f a x) xs
Because $! and seq only evaluates enough to make sure the answer is not
bottom, and if my f is complex then it doesn't do enough.
Amanda
From olaf@cs.york.ac.uk Wed Mar 20 19:05:37 2002
From: olaf@cs.york.ac.uk (Olaf Chitil)
Date: Wed, 20 Mar 2002 19:05:37 +0000
Subject: using less stack
References: <3C98D8BB.5060001@aber.ac.uk>
Message-ID: <3C98DD81.6CE0CEE0@cs.york.ac.uk>
> with the cpsfold I get
>
> f x1 a (\y1 -> f x2 y1 (\y2 -> f x3 y3 (\y3 -> f x4 y4 (\y4 -> y4)
>
> so x1 and a are available immediately for f to use, and f x1 a is the
> outermost expression so will be evaluated first.
Yes, however, if f just calls its continuation without forcing the
evaluation of at least its second argument, e.g.
f x y k = k (g x y)
you get
f x1 a (\y1 -> f x2 y1 (\y2 -> f x3 y3 (\y3 -> f x4 y4 (\y4 -> y4))))
=> f x2 (g x1 a) (\y2 -> f x3 y3 (\y3 -> f x4 y4 (\y4 -> y4)))
=> f x3 (g x2 (g x1 a)) (\y3 -> f x4 y4 (\y4 -> y4)))
=> f x4 (g x3 (g x2 (g x1 a))) (\y4 -> y4)
=> g x4 (g x3 (g x2 (g x1 a)))
like the foldr.
> > larger x y = if x > y then x else y
> > cpslarger x y k = if x > y then k x else k y
Yes, with this definition of `cpslarger' no stack is used, because the
comparison forces evaluation.
With
cpslarger x y k = k (larger x y)
it does not work.
Still, if your definition of cpslarger is natural for your application,
it is a nice solution of the problem.
Ciao,
Olaf
--
OLAF CHITIL,
Dept. of Computer Science, The University of York, York YO10 5DD, UK.
URL: http://www.cs.york.ac.uk/~olaf/
Tel: +44 1904 434756; Fax: +44 1904 432767
From C.Reinke@ukc.ac.uk Wed Mar 20 20:32:19 2002
From: C.Reinke@ukc.ac.uk (C.Reinke)
Date: Wed, 20 Mar 2002 20:32:19 +0000
Subject: using less stack
In-Reply-To: Message from Amanda Clare
of "Wed, 20 Mar 2002 18:45:15 GMT." <3C98D8BB.5060001@aber.ac.uk>
Message-ID:
> > Actually, and quite apart from it being cumbersome to use, I've got
> > my doubts about whether this cpsfold really does the job (is that
> > just me missing some point?-).
>
> It does the job for me! In practical terms I can see it works.
..[explanation omitted]..
I didn't express myself well: I don't doubt that you solved your
problem by using cpsfold, but the cpsfold alone doesn't do the
trick. It just translates the implicit continuation (which uses
stack space) into an explicit continuation function (which uses
heap space). So there's something else going on.
As you explained, having the continuation explicit makes it easier
to get a handle on what happens next at every step, which is the
usual reason for using CPS style. And if neither the cautious
evaluate-to-weak-head-normal-form seq nor the all-out
evaluate-to-normal-form deepSeq do the job for you, I can well
imagine that CPS style permits you to fine-tune evaluation to the
needs of your application. But as Olaf has pointed out, having that
much control can be a bit of a fragile construction.
So I was just wondering about the specific use of fold in your
application, and how you've redefined your operator to make use of
your CPS version of fold (in order to solve the space problem).
Incidentally, cpsfold processes the list in reversed order, which
may or may not matter, depending on the operator passed to it.
Hugs session for:
Prelude.hs
R.hs
folds.hs
Main> foldr (-) 0 [1..4]
(1 - (2 - (3 - (4 - 0))))
Main> foldl (-) 0 [1..4]
((((0 - 1) - 2) - 3) - 4)
Main> cpsfold (\x y c-> c $ x - y) 0 [1..4]
(4 - (3 - (2 - (1 - 0))))
Claus
--
Research Opportunity: Refactoring Functional Programs (UKC)
Closing date: Friday 22 March 2002 <------- !!!
http://www.cs.ukc.ac.uk/vacancies_dir/r02-24.html
From post@volker-wysk.de Wed Mar 20 21:08:51 2002
From: post@volker-wysk.de (Volker Wysk)
Date: 20 Mar 2002 22:08:51 +0100
Subject: Bug in IO libraries when sending data through a pipe?
In-Reply-To:
References:
Message-ID: <1016658532.3061.43.camel@volker>
On Mit, 2002-03-20 at 07:00, Jens Petersen wrote:
> Jens Petersen writes:
>
> > > The problem is that the child process doesn't receive all the data which
> > > the parent sends. It's as if "hPutStr vonh txt" sends the data lazily
> > > somehow, and "hClose vonh" closes the pipe prematurely.
> > >
> > > It varies from run to run exactly which data gets through. If I cause the
> > > child process to read all its input immediately, the problem doesn't
> > > seem to occur. Normally, it does so gradually, which takes a few seconds.
> > >
> > > I'm using GHC 5.02.2
> >
> > Quite possibly could be a bug. Lazy IO is rather subtle I
> > think, specially when done across pipes. I faced some
> > similar problem with in POpen recently. You can see how I
> > solved it (worked round it?) by comparing the latest release
> > 1.00 with the previous one 0.00.1:
> >
> > http://www.01.246.ne.jp/~juhp/haskell/popenhs/
POpen-1.0.0 contains the same bug which I made. It doesn't ensure that
the values which are needed after the call of forkProcess, before that
of executeFile, are fully evaluated. So, if they are read lazily from a
stream, the newly spawned child process reads data from a stream which
it shares with its parent, making it disappear from the parent's input.
In this situation, this sure isn't intended.
Inserting the following lines just before the line "pid <- forkProcess",
in POpen.hs, would force the corresponding values to be evaluated, so no
data will be lost.
seq (length path) $ seq (sum (map length args)) $ return ()
when (isJust env) $ seq (sum (map (\(a,b) -> length a + length b)
(fromJust env))) $ return ()
when (isJust dir) $ seq (length (fromJust dir)) $ return ()
I'm also not sure what this part is supposed to do:
inr <- if (isJust inpt) then
do
(inr', inw) <- createPipe
hin <- fdToHandle inw
hPutStr hin $ fromJust inpt
hClose hin
return $ Just inr'
else
return Nothing
Doesn't it write the input data to a pipe which no process reads
from..??
Volker
From sohufm365sina@fm365.com Thu Mar 21 05:54:11 2002
From: sohufm365sina@fm365.com (sohufm365sina@fm365.com)
Date: Thu, 21 Mar 2002 05:54:11
Subject: ¹âÁÙÌøÎèÀ¼£¬ÓкñÀñÅÉËÍ------ÊýÂëÀñÆ·£¡
Message-ID: <200202180521.FAA27879@netpower>
ÌøÎèÀ¼¹ºÎïÉ̳Ç
| ¡¤ËùÓÐÌøÎèÀ¼Ð¡¢ÀÏÓû§¶¼½«Ãâ·Ñ»ñµÃ¼ÛÖµ10ÔªµÄÌøÎèȯ |
| ¡¤¹ºÎｫ°´"¹ºÎïÿ100ÔªËÍ5Ôª"µÄ·½Ê½»ñÔùÌøÎèȯ |
| ¡¤ÌøÎèÀ¼É̳ÇÌرðÔùËÍMP3»ú¡¢ÊÖ»úµÈÌرðÔùÆ· |
|
1999-2001°æȨËùÓÐ ÌøÎèÀ¼¹ºÎï³Ç
|
| °´ÕÕ¹ú¼Ê¹ßÀý£¬Ö»Òª±¾Óʼþ°üÀ¨¡°ÁªÏµÐÅÏ¢¡±ºÍ¡°ÒƳýÐÅÏ¢¡±£¬¾Í²»Ó¦±»¿´×öÀ¬»øÐżþ¡£Èç¹ûÄúÏëÎÒÃÇ´ÓÓʼþÁбíÖÐÒƳýÄúµÄÓʼþµØÖ·£¬ÇëÓÃÄúÏëÒƳýµÄÐÅÏäµã´Ë·¢ÐÅ£¬ÐżþÖ÷Ì⣺¡°Remove"£¬Èç¹û±¾Óʼþ¸øÄú´øÀ´Á˲»±ã£¬ÎÒÃÇÉî±íǸÒâ¡£ |
|
| Under Bill s.1618 Title III passed
by the 105th U.S. Congress this mail cannot be considered Spam as
long as we include contact information and a remove link for removal
from our mailing list. To be removed from our mailing list reply with
"remove" and include your "original email address/addresses" in the
subject heading send to here.
Include complete address/addresses and/or domain to be removed. We
will immediately update it accordingly. We apologize for the inconvenience
if any caused. |
|
From rakdver@hotmail.com Thu Mar 21 07:44:51 2002
From: rakdver@hotmail.com (Zdenek Dvorak)
Date: Thu, 21 Mar 2002 07:44:51 +0000
Subject: Haskell puzzles!
Message-ID:
Hello.
>- All the answers are at the end of this mail.
>
>-----------------------------------------------------
>1) Are e1 and e2 equal?
>
> > f (x:xs) y = x
> > g (x:xs) = \y -> x
> >
> > e1 = seq (f []) 1
> > e2 = seq (g []) 1
Should not these be
f (x:xs) y = y
g (x:xs) = \y -> y
?
Otherwise, both e1 and e2 are obviously undefined.
Zdenek Dvorak
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
From kyagrd@bawi.org Thu Mar 21 08:52:15 2002
From: kyagrd@bawi.org (Ahn Ki-yung)
Date: Thu, 21 Mar 2002 17:52:15 +0900
Subject: Hugs Bug !
Message-ID: <3C999F3F.97BF994D@bawi.org>
Prelude> f 1 where f x = x : f x
[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
,1,1,{Interrupted!}
Prelude> f 1 where f x = x : f x
====================
in unix/linux proper error msg comes out and back to interpreter.
ERROR - Control stack overflow
===========
but in windows 2000
Then suddnly interpreter fails and
the red (X) popup window pops up.
hugs.exe - application programm error
unknown software exception (0xc000fd) ... blabla
From rjmh@cs.chalmers.se Thu Mar 21 09:18:21 2002
From: rjmh@cs.chalmers.se (John Hughes)
Date: Thu, 21 Mar 2002 10:18:21 +0100 (MET)
Subject: using less stack
Message-ID: <200203210918.KAA02073@muppet30.cs.chalmers.se>
\begin{rant}
I think the whole seq thing is very confusing for beginning/intermediate
haskell programmers. I was very confused for a long time as to why
> (unsafePerformIO (putStrLn "Hello")) `seq` 5
would print "Hello", but
> [unsafePerformIO (putStrLn "Hello")] `seq` 5
would not. ... I would almost prefer if the semantics of `seq` were instead those
of rnf or deepSeq, so long as either (a) we were allowed to derive DeepSeq
or NFData, or (b) if the compiler would just do it itself. Yes, this
would cut down on the expressions which we could `seq`, but does that
really matter. ...
\end{rant}
Well, seq isn't there to enable sequencing of unsafe IO. It's there to enable
space optimisation. When heap profiling was first developed for Haskell, it
fairly soon became clear that fine control of evaluation order was often the
key to fixing space leaks. (Note: "fine control" includes making things lazier
at times via ~ patterns, but also making things stricter at times). Seq is
designed so that you can take ANY expression and move its evaluation where you
want. If we only had deepSeq, we could only move an expression together with
all of its subexpressions -- not good if a lazy list needs to be forced a
little earlier! As for putting seq in a class excluding functions, that would
mean that if you happened to use a function to represent an abstract data
type, you would suddenly be unable to control the evaluation order of programs
using that abstract data type -- and so potentially, unable to fix space leaks
in them. That would make functions a kind of second class citizen: you would
always know, when choosing a representation for an ADT, that if you chose a
function then that would have an impact on space debugging later...
If one is going to provide control of evaluation order (and it IS important),
why surround it with complex rules and restrictions, when seq provides it
simply for every single expression in the language?
Space debugging is a bit of a hobby horse of mine, and I know it is considered
by many to be something of a black art. It isn't so hard really: just run the
heap profiler, find the leaks, and often the fix involves changing evaluation
order. Use seq or ~ to do so. (There can be other fixes also, but these are a
good start). I can't emphasize too much how useful the heap profiler is for
building good intuitions about how programs are evaluated. I'd strongly advise
intermediate Haskell programmers to spend some time using it: one learns a
LOT!
John Hughes
From trinder@cee.hw.ac.uk Thu Mar 21 09:19:44 2002
From: trinder@cee.hw.ac.uk (Phil Trinder)
Date: Thu, 21 Mar 2002 09:19:44 +0000 (GMT Standard Time)
Subject: question about concurrency implementation
In-Reply-To:
Message-ID:
Dean,
Alastair Reid wrote:
> > Just to be sure we agree on terminology: some people like to
> > distinguish between "parallelism" and "concurrency".
> >
> > Parallelism is a way of going faster but doesn't change your
> > programming model. Implemented correctly, a parallel implementation
> > yields the same results as a sequential implementation - it just runs
> > faster. (This is ignoring the effects of interaction with the outside
> > world, of course - since that can also affect determinism.) Parallel
> > Haskell adds "par" and friends (operations which have no effect on the
> > semantics of your program).
> >
> > Concurrency changes your programming model. A concurrent program is
> > allowed to give different results and interesting interactions
> > (including race conditions) between threads. A concurrent program may
> > run on a single processor. Concurrent Haskell adds forkIO,
> > killThread, MVars, etc (operations which affect not just the semantics
> > of your program but also the way the semantics are defined).
We distinguish between parallel, concurrent and distributed depending on the
number of processors and whether threads are *stateful*, i.e. access stateful
objects like Mvars or Files, or *stateless*. That is:
Sequential, e.g. Haskell 98:
1 PE, 1 Stateful thread, 0 stateless threads
Concurrent, e.g. Concurrent Haskell:
1 PE, N Stateful thread, 0 stateless threads
Parallel, e.g. GpH:
N PEs, 1 Stateful thread, N stateless threads
Distributed, e.g. GdH:
N PEs, N Stateful thread, N stateless threads
In fact these languages form an inclusion hierarchy, e.g. GdH is a superset of
both GpH and Concurrent Haskell:
GdH
/ \
GpH Conc. Haskell
\ /
Haskell 98
Dean Herington wrote:
> I've asked these questions in order to convince myself that multiple
> threads can (and will) cooperate in lazily evaluating a value they share,
> without need for any special programming. In particular, I plan to have
> multiple threads share values whose computations involve uses of
> `unsafePerformIO` (the safety of which my application's usage pattern
> guarantees).
The key issue is whether the 'values' are stateful (e.g. Mvars or Files) or
stateless (e.g. a shared Haskell variable). Sharing stateless objects between
parallel, concurrent, or distributed threads preserves sequential semantics,
but sharing stateful objects can introduce non-determinism, unless you have
additional properties.
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 wflp2002@dimi.uniud.it Wed Mar 20 19:43:40 2002
From: wflp2002@dimi.uniud.it (WFLP2002 Organizing Committee)
Date: Wed, 20 Mar 2002 20:43:40 +0100
Subject: [E-CFP] WFLP2002 - deadline EXTENSION
Message-ID:
--============_-1195469066==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Dear Colleague
The submission deadline for the WFLP 2002 has been extended till
March 27, 2002
WFLP 2002 is the 11th international workshop on functional and
(constraint) logic programming. WFLP 2002 aims to bring together
researchers interested in functional programming, (constraint) logic
programming, as well as their integration. For further details about
the workshop please visit the web site
http://www.dimi.uniud.it/~wflp2002/
Papers are due by March 27, 2002. This is a firm deadline.
You can submit papers following the electronic submission process at:
http://www.dimi.uniud.it/~wflp2002/submit/
We hope that this "Call For Papers" will be useful for your work.
Please forward the following to anybody who you think may be
interested. Our apologies if you received multiple copy of this.
--
WFLP 2002 Organizing Committee
http://www.dimi.uniud.ut/~wflp2002/
--============_-1195469066==_ma============
Content-Type: text/html; charset="us-ascii"
[E-CFP] WFLP2002 - deadline
EXTENSION
Dear Colleague
The submission deadline for the WFLP 2002 has
been extended till
March 27,
2002
WFLP 2002 is the 11th international
workshop on functional and (constraint) logic programming.
WFLP 2002 aims to bring together researchers interested in functional
programming, (constraint) logic programming, as well as their
integration. For further details about the workshop please visit
the web site http://www.dimi.uniud.it/~wflp2002/
Papers are due by March 27, 2002. This is a firm
deadline.
You can submit papers following the electronic submission process
at:
http://www.dimi.uniud.it/~wflp2002/submit/
We hope that this "Call For Papers"
will be useful for your work.
Please forward the following to
anybody who you think may be
interested. Our apologies if you received multiple copy of
this.
--
WFLP 2002 Organizing Committee
http://www.dimi.uniud.ut/~wflp2002/
--============_-1195469066==_ma============--
From gmh@Cs.Nott.AC.UK Thu Mar 21 11:57:20 2002
From: gmh@Cs.Nott.AC.UK (Graham Hutton)
Date: Thu, 21 Mar 2002 11:57:20 +0000
Subject: using less stack
Message-ID: <20020321115730.2DA034223CC@www.haskell.org>
> In the case of foldr the end of the list has to be
> reached before anything can be evaluated.
This is perhaps a good time to point out the common missconception that
foldr can only be used to define functions that process the elements of
lists in right-to-left order. For a discussion of this point, see section
5 of my JFP tutorial paper on foldr, which (amonst other things) shows
how to sum a list of numbers in left-to-right order using foldr:
http://www.cs.nott.ac.uk/~gmh/fold.pdf
Graham
+----------------------------------------------------------------------------+
| Dr Graham Hutton Email : gmh@cs.nott.ac.uk |
| Foundations of Programming Group Web : http://www.cs.nott.ac.uk/~gmh |
| School of Computer Science and IT |
| University of Nottingham |
| Jubilee Campus, Wollaton Road |
| Nottingham NG8 1BB Phone : +44 (0)115 951 4220 |
| United Kingdom Fax : +44 (0)115 951 4254 |
+----------------------------------------------------------------------------+
From rjchaaft@cs.uu.nl Thu Mar 21 13:38:05 2002
From: rjchaaft@cs.uu.nl (Rijk J. C. van Haaften)
Date: Thu, 21 Mar 2002 14:38:05 +0100
Subject: Haskell puzzles!
In-Reply-To:
Message-ID: <4.3.0.20020321143034.00b30018@pop.students.cs.uu.nl>
Zdenek Dvorak wrote:
>>-----------------------------------------------------
>>1) Are e1 and e2 equal?
>>
>> > f (x:xs) y = x
>> > g (x:xs) = \y -> x
>> >
>> > e1 = seq (f []) 1
>> > e2 = seq (g []) 1
>
>Should not these be
>
>f (x:xs) y = y
>g (x:xs) = \y -> y
>?
>Otherwise, both e1 and e2 are obviously undefined.
That seems to be obvious, but e1 is NOT undefined!
That's the point Daan makes.
seq forces it's first argument and returns the second one.
However, because f is partially parametrized, seq doesn't
change anything in f and just returns 1. The right-hand-side
of f is not involved at all!
In e2 though, g is fully parametrized, so seq behaves as
you expect and the pattern match failes.
Rijk-Jan
From rjchaaft@cs.uu.nl Thu Mar 21 14:04:35 2002
From: rjchaaft@cs.uu.nl (Rijk J. C. van Haaften)
Date: Thu, 21 Mar 2002 15:04:35 +0100
Subject: Hugs Bug !
In-Reply-To: <3C999F3F.97BF994D@bawi.org>
Message-ID: <4.3.0.20020321150155.00b2cef8@pop.students.cs.uu.nl>
>but in windows 2000
>
>Then suddnly interpreter fails and
>the red (X) popup window pops up.
>
>hugs.exe - application programm error
>
> unknown software exception (0xc000fd) ... blabla
Are you sure you have the very very very latest download?
There have been some undocumented updates of the December
2001 release of Hugs.
Download the very latest release and try it again.
I tried you expression on Win2000, with Hugs Dec 2001,
downloaded last week, and it runs in constant space
for an unlimited time.
Rijk-Jan
From petersen@redhat.com Thu Mar 21 14:20:17 2002
From: petersen@redhat.com (Jens Petersen)
Date: 21 Mar 2002 23:20:17 +0900
Subject: Bug in IO libraries when sending data through a pipe?
In-Reply-To: <1016658532.3061.43.camel@volker>
References:
<1016658532.3061.43.camel@volker>
Message-ID:
Hi Volker,
Volker Wysk writes:
> On Mit, 2002-03-20 at 07:00, Jens Petersen wrote:
> > Jens Petersen writes:
> >
> > > > The problem is that the child process doesn't
> > > > receive all the data which the parent sends. It's as
> > > > if "hPutStr vonh txt" sends the data lazily somehow,
> > > > and "hClose vonh" closes the pipe prematurely.
> > > >
> > > > It varies from run to run exactly which data gets
> > > > through. If I cause the child process to read all
> > > > its input immediately, the problem doesn't seem to
> > > > occur. Normally, it does so gradually, which takes a
> > > > few seconds.
> > > >
> > > > I'm using GHC 5.02.2
> > >
> > > Quite possibly could be a bug. Lazy IO is rather subtle I
> > > think, specially when done across pipes. I faced some
> > > similar problem with in POpen recently. You can see how I
> > > solved it (worked round it?) by comparing the latest release
> > > 1.00 with the previous one 0.00.1:
> > >
> > > http://www.01.246.ne.jp/~juhp/haskell/popenhs/
>
> POpen-1.0.0 contains the same bug which I made. It doesn't ensure that
> the values which are needed after the call of forkProcess, before that
> of executeFile, are fully evaluated. So, if they are read lazily from a
> stream, the newly spawned child process reads data from a stream which
> it shares with its parent, making it disappear from the parent's input.
> In this situation, this sure isn't intended.
Perhaps you could give an explicit example?
> Inserting the following lines just before the line "pid <- forkProcess",
> in POpen.hs, would force the corresponding values to be evaluated, so no
> data will be lost.
>
> seq (length path) $ seq (sum (map length args)) $ return ()
> when (isJust env) $ seq (sum (map (\(a,b) -> length a + length b)
> (fromJust env))) $ return ()
> when (isJust dir) $ seq (length (fromJust dir)) $ return ()
Hmmm, I don't really see why this is necessary. Don't the
lazy values of "path", "env" and "dir" just get evaluated
when they're needed here as normal? (If what you say is
true though it would be simpler just to use "$!" or "!"s for
strict evaluation I guess.)
I would be more worried about the input stream string not
being complete when the input handle is closed.
> I'm also not sure what this part is supposed to do:
>
> inr <- if (isJust inpt) then
> do
> (inr', inw) <- createPipe
> hin <- fdToHandle inw
> hPutStr hin $ fromJust inpt
> hClose hin
> return $ Just inr'
> else
> return Nothing
It returns the output end of a pipe containing the input
string if one is given.
> Doesn't it write the input data to a pipe which no process reads
> from..??
Nope, "doTheBusiness" dup2's it to the stdin of the subprocess:
(outr, outw) <- createPipe
(errr, errw) <- createPipe
pid <- forkProcess
case pid of
Nothing -> doTheBusiness inr outw errw -- ***
Just p ->
do
-- close other end of pipes in here
when (isJust inr) $
fdClose $ fromJust inr
fdClose outw
fdClose errw
hout <- fdToHandle outr
outstrm <- hGetContents hout
herr <- fdToHandle errr
errstrm <- hGetContents herr
return (outstrm, errstrm , p)
where
doTheBusiness ::
Maybe Fd -- stdin
-> Fd -- stdout
-> Fd -- stderr
-> IO (String, String, ProcessID) -- (stdout, stderr)
doTheBusiness inr outw errw =
do
maybeChangeWorkingDirectory dir
when (isJust inr) $
dupTo (fromJust inr) stdInput -- ***
dupTo outw stdOutput
dupTo errw stdError
executeFile path True args env
-- for typing, should never actually run
error "executeFile failed!"
Jens
From anatoli@yahoo.com Thu Mar 21 16:35:27 2002
From: anatoli@yahoo.com (anatoli)
Date: Thu, 21 Mar 2002 08:35:27 -0800 (PST)
Subject: Lambda over types.
Message-ID: <20020321163527.92822.qmail@web14201.mail.yahoo.com>
I apologise in case this doesn't make any sense.
ghc -fglasgow-exts -fallow-undecidable-instances allows
constructs which amount to lambda abstraction over types.
I've written a small untyped lambda calculus interpreter
in the Haskell class/instance sublanguage, just to prove
this point. (The terms are Haskell *types*.)
Using this interpreter as a basis, and adapting it as
necessary, I can now write arbitrary "functions" [1] that take
types to types. But of course it's a pain to write them like
that.
Maybe, after all, it does make sense to have a dedicated
lambda-over-types Haskell extension which is convenient
to use?
[1] - I cannot produce an equivalent of
> type Foo a b c = a b c
but I can do an equivalent of this:
> fun :: T1 -> T2 -> T3 -> T1 T2 T3
--
anatoli
__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/
From anatoli@yahoo.com Thu Mar 21 17:37:46 2002
From: anatoli@yahoo.com (anatoli)
Date: Thu, 21 Mar 2002 09:37:46 -0800 (PST)
Subject: Lambda over types.
In-Reply-To:
Message-ID: <20020321173746.48681.qmail@web14202.mail.yahoo.com>
--0-681966285-1016732266=:42373
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hal Daume III wrote:
> I'd be interested in seeing how you do this. I attempted such a thing a
> while back but was unsuccessful.
Attached are two interpreters: one for untyped lambda calculus,
and one for an Unlambda-style language (combinators).
Of course pure lambda terms are not very useful Haskell types.
You may use your own types as primitive terms by defining
instances of Subst and/or Eval of them.
--
anatoli
__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/
--0-681966285-1016732266=:42373
Content-Type: application/x-unknown; name="lambda.lhs"
Content-Transfer-Encoding: base64
Content-Description: lambda.lhs
Content-Disposition: attachment; filename="lambda.lhs"
VGhlIGNsYXNzIG1ldGhvZHMsIGxhbWJkYVN1YnN0IGFuZCBsYW1iZGFFdmFs
LCBhcmUKZm9yIGRlYnVnZ2luZyBmcm9tIEh1Z3MvZ2hjaSBwcm9tcHQuClRv
IGV2YWx1YXRlIGEgdGVybSwgdHlwZToKCkxhbWJkYT46dCBsYW1iZGFFdmFs
IDx0ZXJtPgoKZm9yIGluc3RhbmNlCgpMYW1iZGE+OnQgbGFtYmRhRXZhbCAo
QSAoTCBYIFgpIChMIFkgWikpCkwgWSBaCkxhbWJkYT46dCBsYW1iZGFFdmFs
IChBIChMIFggKEEgWCBYKSkgKEwgWCAoQSBYIFgpKSkKPGRvZXMgbm90IHRl
cm1pbmF0ZT4KCj4gbW9kdWxlIExhbWJkYSB3aGVyZQoKVmFyaWFibGVzIAoK
PiBkYXRhIFggPSBYCj4gZGF0YSBZID0gWQo+IGRhdGEgWiA9IFoKPiBkYXRh
IFQgPSBUCgpMYW1iZGEgYWJzdHJhY3Rpb24gOiBceC0+eQoKPiBkYXRhIEwg
eCB5ID0gTCB4IHkKCkFwcGxpY2F0aW9uIDogeCB5Cgo+IGRhdGEgQSB4IHkg
PSBBIHggeQoKU3Vic3RpdHV0aW9uCgo+IGNsYXNzIFN1YnN0IHYgZSB0IHIg
fCB2IGUgdCAtPiByIHdoZXJlCj4gICBsYW1iZGFTdWJzdCA6OiB2IC0+IGUg
LT4gdCAtPiByCj4gICBsYW1iZGFTdWJzdCA9IHVuZGVmaW5lZAoKVHJpdmlh
bCBzdWJzdGl0dXRpb25zCgo+IGluc3RhbmNlIFN1YnN0IFggYSBYIGEKPiBp
bnN0YW5jZSBTdWJzdCBYIGEgWSBZCj4gaW5zdGFuY2UgU3Vic3QgWCBhIFog
Wgo+IGluc3RhbmNlIFN1YnN0IFggYSBUIFQKCj4gaW5zdGFuY2UgU3Vic3Qg
WSBhIFggWAo+IGluc3RhbmNlIFN1YnN0IFkgYSBZIGEKPiBpbnN0YW5jZSBT
dWJzdCBZIGEgWiBaCj4gaW5zdGFuY2UgU3Vic3QgWSBhIFQgVAoKPiBpbnN0
YW5jZSBTdWJzdCBaIGEgWCBYCj4gaW5zdGFuY2UgU3Vic3QgWiBhIFkgWQo+
IGluc3RhbmNlIFN1YnN0IFogYSBaIGEKPiBpbnN0YW5jZSBTdWJzdCBaIGEg
VCBUCgo+IGluc3RhbmNlIFN1YnN0IFQgYSBYIFgKPiBpbnN0YW5jZSBTdWJz
dCBUIGEgWSBZCj4gaW5zdGFuY2UgU3Vic3QgVCBhIFogWgo+IGluc3RhbmNl
IFN1YnN0IFQgYSBUIGEKClNjb3BlIHJ1bGVzCgo+IGluc3RhbmNlICAgICAg
ICAgICAgICAgICAgU3Vic3QgWCBhIChMIFggYikgKEwgWCBiKQo+IGluc3Rh
bmNlIFN1YnN0IFggYSBiIGMgPT4gU3Vic3QgWCBhIChMIFkgYikgKEwgWSBj
KQo+IGluc3RhbmNlIFN1YnN0IFggYSBiIGMgPT4gU3Vic3QgWCBhIChMIFog
YikgKEwgWiBjKQo+IGluc3RhbmNlIFN1YnN0IFggYSBiIGMgPT4gU3Vic3Qg
WCBhIChMIFQgYikgKEwgVCBjKQoKPiBpbnN0YW5jZSBTdWJzdCBZIGEgYiBj
ID0+IFN1YnN0IFkgYSAoTCBYIGIpIChMIFggYykKPiBpbnN0YW5jZSAgICAg
ICAgICAgICAgICAgIFN1YnN0IFkgYSAoTCBZIGIpIChMIFkgYikKPiBpbnN0
YW5jZSBTdWJzdCBZIGEgYiBjID0+IFN1YnN0IFkgYSAoTCBaIGIpIChMIFog
YykKPiBpbnN0YW5jZSBTdWJzdCBZIGEgYiBjID0+IFN1YnN0IFkgYSAoTCBU
IGIpIChMIFQgYykKCj4gaW5zdGFuY2UgU3Vic3QgWiBhIGIgYyA9PiBTdWJz
dCBaIGEgKEwgWCBiKSAoTCBYIGMpCj4gaW5zdGFuY2UgU3Vic3QgWiBhIGIg
YyA9PiBTdWJzdCBaIGEgKEwgWSBiKSAoTCBZIGMpCj4gaW5zdGFuY2UgICAg
ICAgICAgICAgICAgICBTdWJzdCBaIGEgKEwgWiBiKSAoTCBaIGIpCj4gaW5z
dGFuY2UgU3Vic3QgWiBhIGIgYyA9PiBTdWJzdCBaIGEgKEwgVCBiKSAoTCBU
IGMpCgo+IGluc3RhbmNlIFN1YnN0IFQgYSBiIGMgPT4gU3Vic3QgVCBhIChM
IFggYikgKEwgWCBjKQo+IGluc3RhbmNlIFN1YnN0IFQgYSBiIGMgPT4gU3Vi
c3QgVCBhIChMIFkgYikgKEwgWSBjKQo+IGluc3RhbmNlIFN1YnN0IFQgYSBi
IGMgPT4gU3Vic3QgVCBhIChMIFogYikgKEwgWiBjKQo+IGluc3RhbmNlICAg
ICAgICAgICAgICAgICAgU3Vic3QgVCBhIChMIFQgYikgKEwgVCBiKQoKQXBw
bGljYXRpb24gc3Vic3RpdHV0aW9uCgo+IGluc3RhbmNlIChTdWJzdCB2IGUg
dCByLCBTdWJzdCB2IGUgdCcgcicpID0+IFN1YnN0IHYgZSAoQSB0IHQnKSAo
QSByIHInKQoKRXZhbHVhdGlvbiBydWxlcwoKPiBjbGFzcyBFdmFsIGUgZScg
fCBlIC0+IGUnIHdoZXJlCj4gICBsYW1iZGFFdmFsIDo6IGUgLT4gZScKPiAg
IGxhbWJkYUV2YWwgPSB1bmRlZmluZWQKClZhcmlhYmxlcyBldmFsdWF0ZSB0
byB0aGVtc2VsdmVzCgo+IGluc3RhbmNlIEV2YWwgWCBYCj4gaW5zdGFuY2Ug
RXZhbCBZIFkKPiBpbnN0YW5jZSBFdmFsIFogWgo+IGluc3RhbmNlIEV2YWwg
VCBUCgpTbyBpcyBsYW1iZGEgYWJzdHJhY3Rpb24KCj4gaW5zdGFuY2UgRXZh
bCAoTCB2IGUpIChMIHYgZSkKCkFwcGxpY2F0aW9uIG9mIGxhbWJkYSBhYnN0
cmFjdGlvbiBpcyBldmFsdWF0ZWQgdmlhIHN1YnN0aXR1dGlvbgoKPiBpbnN0
YW5jZSAoU3Vic3QgdiBnIGUgciwgRXZhbCByIHInKSA9PiBFdmFsIChBIChM
IHYgZSkgZykgcicKCkFwcGxpY2F0aW9uIG9mIGFwcGxpY2F0aW9uOiBldmFs
dWF0ZSB0aGUgZnVuY3Rpb24gYW5kIHJldHJ5CkhlcmUgbGllcyB0aGUgdW5k
ZWNpZGFiaWxpdHkuCgo+IGluc3RhbmNlIChFdmFsIChBIGIgYykgZCwgRXZh
bCAoQSBkIGUpIGYpID0+IEV2YWwgKEEgKEEgYiBjKSBlKSBmCgo=
--0-681966285-1016732266=:42373
Content-Type: application/x-unknown; name="unlambda.lhs"
Content-Transfer-Encoding: base64
Content-Description: unlambda.lhs
Content-Disposition: attachment; filename="unlambda.lhs"
UXVhc2ktVW5sYW1iZGEgaW50ZXJwcmV0ZXIgaW4gSGFza2VsbCBjbGFzc2Vz
IQpTZWUgbGFtYmRhLmxocyBmb3IgaW5zaWdodC4KCj4gbW9kdWxlIFVubGFt
YmRhIHdoZXJlCgo+IGRhdGEgSyAgICAgICAgPSBLCj4gZGF0YSBLMSB4ICAg
ICA9IEsxIHgKCj4gZGF0YSBTICAgICAgICA9IFMKPiBkYXRhIFMxIHggICAg
ID0gUzEgeAo+IGRhdGEgUzIgeCB5ICAgPSBTMiB4IHkKCj4gZGF0YSBJICAg
ICAgICA9IEkKCj4gZGF0YSBWICAgICAgICA9IFYKCj4gZGF0YSBBcHAgZiBn
ICA9IEFwcCBmIGcKCj4gY2xhc3MgRXZhbCBmIGcgfCBmIC0+IGcgd2hlcmUK
PiAgIHVubGFtYmRhRXZhbCA6OiBmIC0+IGcKPiAgIHVubGFtYmRhRXZhbCA9
IHVuZGVmaW5lZAoKPiBjbGFzcyBBcHBseSBmIGcgaCB8IGYgZyAtPiBoIHdo
ZXJlCj4gICB1bmxhbWJkYUFwcGx5IDo6IGYgLT4gZyAtPiBoCj4gICB1bmxh
bWJkYUFwcGx5ID0gdW5kZWZpbmVkCgo+IGluc3RhbmNlIEV2YWwgSyBLCj4g
aW5zdGFuY2UgRXZhbCAoSzEgeCkgKEsxIHgpCj4gaW5zdGFuY2UgRXZhbCBT
IFMKPiBpbnN0YW5jZSBFdmFsIChTMSB4KSAoUzEgeCkKPiBpbnN0YW5jZSBF
dmFsIChTMiB4IHkpIChTMiB4IHkpCj4gaW5zdGFuY2UgRXZhbCBJIEkKPiBp
bnN0YW5jZSBFdmFsIFYgVgoKPiBpbnN0YW5jZSAoRXZhbCB4IHgnLCBFdmFs
IHkgeScsIEFwcGx5IHgnIHknIHopID0+IEV2YWwgKEFwcCB4IHkpIHoKCj4g
aW5zdGFuY2UgQXBwbHkgSyB4IChLMSB4KQo+IGluc3RhbmNlIEFwcGx5IChL
MSB4KSB5IHgKCj4gaW5zdGFuY2UgQXBwbHkgUyB4IChTMSB4KQo+IGluc3Rh
bmNlIEFwcGx5IChTMSB4KSB5IChTMiB4IHkpCgo+IGluc3RhbmNlIEFwcGx5
IEkgeCB4Cj4gaW5zdGFuY2UgQXBwbHkgViB4IFYKCj4gLS0gVGhlIHVuZGVj
aWRhYmxlIHBhcnQgCj4gaW5zdGFuY2UgRXZhbCAoQXBwIChBcHAgeCB6KSAo
QXBwIHkgeikpIHQgPT4gQXBwbHkgKFMyIHggeSkgeiB0Cgo=
--0-681966285-1016732266=:42373--
From icalp2002@informatica.uma.es Thu Mar 21 18:19:43 2002
From: icalp2002@informatica.uma.es (icalp2002@informatica.uma.es)
Date: Thu, 21 Mar 2002 19:19:43 +0100
Subject: ICALP2002: accepted papers and preliminary program
Message-ID:
This is a multi-part message in MIME format.
--------------9F1656E3A2720904ECEA2E70
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Dear Sir/Madam,
I'm sending you the following information:
-the list of accepted papers for ICALP'2002 (an HTML table
with two columns; authors and title)
-the preliminary program of ICALP'2002 is available on
http://sirius.lcc.uma.es/ICALP2002/PreliminarySchedule.html
(and on the "news" of ICALP2002 pages: http://www.lcc.uma.es/ICALP2002)
-the preliminary program of the satellite event "Global Computing"
(in the same link).
I consider that this conference can be of your interest.
The registration will be open in a few days.
Best regards,
Rafael Morales
--------------9F1656E3A2720904ECEA2E70
Content-Type: text/html; charset=us-ascii;
name="tableAceptICALP2002.htm"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="tableAceptICALP2002.htm"
Track A
|
Track A
|
|
|
Peter Hertling; |
A Banach-Mazur Computable but not Markov Computable Function on the Computable Real Numbers |
|
Seth Pettie; |
A Faster All-pairs Shortest Path Algorithm for Real-weighted Sparse Graphs |
|
Juhani Karhumäki; Leonid P. Lisovik; |
A surprising undecidability result: The equivalence problem for finite substitutions on $ab^*c$ |
|
Doerr Benjamin; |
Antirandomizing the Wrong Game |
|
Piotr Berman; Marek Karpinski; Yakov Nekrich; |
Approximating Huffman Codes in Parallel |
|
Marek Karpinski; Piotr Berman; |
Approximation Hardness of Bounded Degree MIN-CSP and MIN-BISECTION |
|
Nathan Segerlind; |
Bounded Depth Frege with Counting Principles Polynomially Simulates Nullstellensatz Refutations |
|
Rolf Fagerberg; Gerth Stølting Brodal; |
Cache Oblivious Distribution Sweeping |
|
Udo Adamy; |
Call Control in Rings |
|
Jurdzinski Tomasz; |
Church-Rosser Languages vs. UCFL |
|
Vincenzo Liberatore; |
Circular Arrangements |
|
Victor Dalmau; |
Constraint Satisfaction Problems in Non-Deterministic Logarithmic Space |
|
Joseph (Seffi) Naor; |
Control Message Aggregation in Group Communication Protocols |
|
John Hitchcock; |
Correspondence Principles for Effective Dimensions |
|
Aggelos Kiayias; Moti Yung; |
Cryptographic Hardness based on the Decoding of Reed-Solomon Codes |
|
Colin Stirling; |
Deciding DPDA equivalence is primitive recursive |
|
Yoshiharu Kohayakawa; Brendan Nagle; Vojtech Rodl; |
Efficient testing of hypergraphs |
|
Peter Sanders; Rene Beier; Naveen Sivadasan; Edgar Ramos; |
Energy Optimal Routing in Radio Networks Using Geometric Data Structures |
|
Dima Grigoriev; Edward A. Hirsch; Dmitrii V. Pasechnik; |
Exponential Lower Bound for Static Semi-Algebraic Proofs |
|
Rajeev Raman; |
Exponential structures for cache-oblivious algorithms |
|
Karhan Akcoglu; |
Fast Universalization of Investment Strategies with Provably Good Relative Returns |
|
Moses Charikar; Kevin Chen; Martin Farach-Colton; |
Finding Frequent Items in Data Streams |
|
Thore Husfeldt; |
Finding a Path of Superlogarithmic Length |
|
Xiaotie Deng; Guojun Li; Zimao Li; Bin ma; Lusheng Wang; |
Genetic Design of Drug without Side-effect |
|
Leszek Gasieniec; Andrzej Lingas; |
Gossiping with bounded size messages in unknown ad-hoc radio networks |
|
Elias Koutsoupias; Christos Papadimitriou; Alex Fabrikant; |
Heuristically Optimized Trade-offs: A New Paradigm for Power Laws in the Internet |
|
Martin Strauss; Sudipto Guha; Piotr Indyk; Muthu Muthukrishnan; |
Histogramming Data Streams with Fast Per-Item Processing |
|
Papazian Christophe; |
Hyperbolic Recognition by Cellular Automata |
|
Camil Demetrescu; Giuseppe F. Italiano; |
Improved Bounds and New Trade-Offs for Dynamic All Pairs Shortest Paths |
|
Jonas Holmerin; |
Improved Inapproximability Results for Vertex Cover on k-regular Hyper-graphs |
|
V.S. Anil Kumar Kumar; |
Improved Results for Stackelberg Scheduling Strategies |
|
Tomasz Radzik; |
Improving time bounds on maximum generalised flow computation |
|
Lars Engebretsen; Jonas Holmerin; Alexander Russell; |
Inapproximability Results for Equations Over Finite Groups |
|
Sebastian Bala; |
Intersection of Regular Language and Star Hierarchy |
|
Ryuhei Uehara; |
Linear Time Algorithms on Chordal Bipartite and Strongly Chordal Graphs |
|
Moses Charikar; Piotr Indyk; Rina Panigrahy; |
New Algorithms for Subset Query, Partial Match, Orthogonal Range Searching and Related Problems |
|
Steve Seiden; Leah Epstein; Rob van Stee; |
New Bounds for Variable-Sized and Resource Augmented Online Bin Packing |
|
Nicola Galesi; Juan Luis Esteban; Jochen Messner; |
On the Complexity of Resolution with Bounded Conjunctions |
|
Conrado Martinez; Amalia Duch; |
On the average performance of orthogonal range search in multidimensional data structures |
|
Sylvain Lombardy; |
On the construction of reversible automata for reversible languages |
|
Rasmus Pagh; Anna Östlin; |
One-Probe Search |
|
Xiaodong Wu; Danny Chen; |
Optimal Net Surface Problems with Applications |
|
Andreas Jakoby; Maciej Liskiewicz; |
Paths Problems in Symmetric Logarithmic Space |
|
Eyal Kushilevitz; Yuval Ishai; |
Perfect Constant-Round Secure Computation via Perfect Randomizing Polynomials |
|
Andrzej Lingas; Artur Czumaj; Hairong Zhao; |
Polynomial-Time Approximation Schemes for the Euclidean Survivable Network Design Problem |
|
Marek Chrobak; Leah Epstein; John Noga; Jiri Sgall; Rob van Stee; Tomas Tichy; Nodari Vakhania; |
Preemptive Scheduling in Overloaded Systems |
|
Amr Elmasry; |
Priority queues, pairing and adaptive sorting |
|
Chris Pollett; Farid Ablayev; Cris Moore; |
Quantum and Stochastic Branching Programs of Bounded Width |
|
Philippe Flajolet; |
Random Sampling from Boltzmann Principles |
|
Vasco Brattka; |
Random numbers and an incomplete immune recursive set |
|
Harald Räcke; Micah Adler; Naveen Sivadasan; Christian Sohler; Berthold Vöcking; |
Randomized Pursuit-Evasion in Graphs |
|
Kazuo Iwama; |
Removable On-Line Knapsack Problems |
|
Peter Damaschke; |
Scheduling search procedures |
|
Carlo Fantozzi; Andrea Pietracaprina; Geppino Pucci; |
Seamless Integration of Parallelism and Memory Hierarchy |
|
Gerth Stølting Brodal; Rune Bang Lyngsø; Anna Östlin; Christian N. S. Pedersen; |
Solving the String Statistics Problem in Time $O(n\log n)$ |
|
Ugo Vaccaro; Pavol Hell; Ladislav Stacho; Luisa Gargano; |
Spanning trees with bounded number of branch vertices |
|
Wolfgang Merkle; |
The Kolmogorov-Loveland stochastic sequences are not closed under selecting subsequences |
|
Robert A. Hearn; Erik D. Demaine; |
The Nondeterministic Constraint Logic Model of Computation: Reductions and Applications |
|
Ollinger Nicolas; |
The Quest for Small Universal Cellular Automata |
|
Dimitrios Fotakis; Spyros Kontogiannis; Elias Koutsoupias; Marios Mavronicolas; Paul Spirakis; |
The Structure and Complexity of Nash Equilibria for a Selfish Routing Game |
|
Noam Nisan; |
The communication complexity of approximate set packing and covering |
|
Mikolaj Bojanczyk; |
Two-Way Alternating Automata and Finite Models |
|
Mohamed Mosbah; Nicolas Bonichon; Bertrand Le Saec; |
Wagner's theorem on Realizers |
|
John Hitchcock; Jack Lutz; |
Why Computational Complexity Requires Stricter Martingales |
|
Track B |
|
|
Philippa Gardner; |
A Spatial Logic for Querying Graphs |
|
Rosu Grigore; |
A Total Approach to Partial Algebraic Specification |
|
Paul Gastin; |
An Elementary Expressively Complete Temporal Logic for Mazurkiewicz Traces |
|
Lohrey Markus; |
Axiomatising Divergence |
|
Marco Kick; |
Bialgebraic Modelling of Timed Processes |
|
Alex Simpson; |
Comparing functional paradigms for exact real-number computation |
|
Bharat Adsul; Milind Sohoni; |
Expressively Complete Tractable Linear Time Temporal Logics over Traces |
|
Luke Ong; |
Games Characterizing Levy-Longo Trees |
|
Zeitoun Marc; muscholl anca; genest blaise; seidl helmut; |
Infinite-state High-Level MSCs: Model-Checking and Realizability |
|
James Worrell; Keye Martin; Mike Mislove; |
Measuring the Probabilistic Powerdomain |
|
Michal Bielecki; Hidders Jan; Jan Paredaens; Jerzy Tyszkiewicz; Jan Van den Bussche; |
Navigating with a Browser |
|
Colcombet Thomas; |
On Families of Graphs Having a Decidable First Order Theory with Reachability |
|
Dietrich Kuske; Markus Lohrey; |
On the theory of one-step rewriting in trace monoids |
|
Jiri Srba; |
Strong Bisimilarity and Regularity of Basic Process Algebra is PSPACE-Hard |
|
Thierry Cachat; |
Symbolic Strategy Synthesis for Games on Pushdown Graphs |
|
Franck van Breugel; |
Testing Labelled Markov Processes |
|
J. B. Wells Wells; |
The Essence of Principal Typings |
|
Freddy Mang; Thomas A. Henzinger; Orna Kupferman; Sriram Krishnan; |
The Synthesis of Uninitialized Systems |
|
Klaus Wich; |
Universal Inherence of cycle-free context-free Ambiguity Functions |
--------------9F1656E3A2720904ECEA2E70--
From post@volker-wysk.de Thu Mar 21 23:31:35 2002
From: post@volker-wysk.de (Volker Wysk)
Date: Fri, 22 Mar 2002 00:31:35 +0100 (CET)
Subject: Bug in IO libraries when sending data through a pipe?
In-Reply-To:
Message-ID:
Hi
On 21 Mar 2002, Jens Petersen wrote:
> Volker Wysk writes:
> > POpen-1.0.0 contains the same bug which I made. It doesn't ensure that
> > the values which are needed after the call of forkProcess, before that
> > of executeFile, are fully evaluated. So, if they are read lazily from a
> > stream, the newly spawned child process reads data from a stream which
> > it shares with its parent, making it disappear from the parent's input.
> > In this situation, this sure isn't intended.
>
> Perhaps you could give an explicit example?
I haven't tried it, but it's exactly the same thing.
> > Inserting the following lines just before the line "pid <- forkProcess",
> > in POpen.hs, would force the corresponding values to be evaluated, so no
> > data will be lost.
> >
> > seq (length path) $ seq (sum (map length args)) $ return ()
> > when (isJust env) $ seq (sum (map (\(a,b) -> length a + length b)
> > (fromJust env))) $ return ()
> > when (isJust dir) $ seq (length (fromJust dir)) $ return ()
>
> Hmmm, I don't really see why this is necessary. Don't the
> lazy values of "path", "env" and "dir" just get evaluated
> when they're needed here as normal? (If what you say is
> true though it would be simpler just to use "$!" or "!"s for
> strict evaluation I guess.)
Yes, and that's *after* forkProcess. So when they are computed from
the lazily read contents of a stream, the newly spawned child will read
data from a stream which it shares with its parent.
> > I'm also not sure what this part is supposed to do:
> >
> > inr <- if (isJust inpt) then
> > do
> > (inr', inw) <- createPipe
> > hin <- fdToHandle inw
> > hPutStr hin $ fromJust inpt
> > hClose hin
> > return $ Just inr'
> > else
> > return Nothing
>
> It returns the output end of a pipe containing the input
> string if one is given.
>
> > Doesn't it write the input data to a pipe which no process reads
> > from..??
>
> Nope, "doTheBusiness" dup2's it to the stdin of the subprocess: [...]
But hPutStr, followed by hClose, won't complete until all the input string
has been written, while no process is listening.
Volker
From bhuffman@galois.com Fri Mar 22 00:21:43 2002
From: bhuffman@galois.com (Brian Huffman)
Date: Thu, 21 Mar 2002 16:21:43 -0800
Subject: catch (fail "...")
Message-ID: <200203220021.g2M0LiX09437@localhost.localdomain>
Hi,
Here is a problem I came across recently, revealing a difference between ghci
and Hugs:
hugs> catch (error "not ok") (\e -> putStrLn "ok")
Program error: not ok
ghci> catch (error "not ok") (\e -> putStrLn "ok")
*** Exception: not ok
hugs> catch (ioError (userError "not ok")) (\e -> putStrLn "ok")
ok
ghci> catch (ioError (userError "not ok")) (\e -> putStrLn "ok")
ok
hugs> catch (fail "not ok") (\e -> putStrLn "ok")
Program error: not ok
ghci> catch (fail "not ok") (\e -> putStrLn "ok")
ok
As I expected, neither of them can catch "error", and both of them can catch
"ioError". But only ghci can catch the "fail". It seems to me that ghc has
made a convenient choice here, because if I need to raise an IO exception, it
is easier to type "fail s" than "ioError (userError s)".
However, the online Haskell report says that for IO, fail s = error s, which
is what Hugs does.
(http://www.haskell.org/onlinereport/standard-prelude.html#$iMonad$$IO)
Does anyone know the reasoning behind the design choice made in the report,
or why the ghc implementation is different? I am mainly concerned about
portability issues: particularly, is it a good idea to use fail for raising
IO exceptions?
Thanks
- Brian Huffman
From senganb@ia.nsc.com Fri Mar 22 03:10:14 2002
From: senganb@ia.nsc.com (senganb@ia.nsc.com)
Date: Thu, 21 Mar 2002 22:10:14 -0500
Subject: Haskell slicing tool?
In-Reply-To: <3C986787.830C8F9B@cs.york.ac.uk>
References:
<20020319132039.37e63d70.senganb@ia.nsc.com>
<3C986787.830C8F9B@cs.york.ac.uk>
Message-ID: <20020321221014.6c7b7fdb.senganb@ia.nsc.com>
On Wed, 20 Mar 2002 10:42:15 +0000
"Olaf Chitil" wrote:
> Sengan.Baring-Gould@nsc.com wrote:
>
> > > > Are there any tools to perform program slicing on Haskell?
> > > > I often find myself wanting to find all "fromJusts" invoked
> > > > from the current function, or all functions that use a
> > > > particular member of my monad's ADT.
>
> > Actually I was hoping for a static tool.
>
> I'd be interested to learn for what purpose you want this kind of
> information and also more precisely what you would like such a static
> tool to do for you.
>
> Olaf
I looked at for what I use the "#" command in vim over the last 2 days,
and when it becomes insufficient:
* Upwards slicing:
- to see what parameters a function is actually given (can be quite a
long way from where the parameter is actually constructed, versus
simply passed around).
- to find dead code (function results that are never used)
* Downwards slicing
- to debug code (which head failed? One of those under function f, but
what are they?)
- which instance of (>>=) is it that I'm using here?
* Complex queries:
A := set of all functions refered to by f1's definition
B := set of all functions refered to by f2's definition
C := set of functions I'm interested in
D := intersection of A, B and C
D would then be the functions used both by A and B of the set I'm
interested in C.
In general the answer is to understand, debug and refactor code
in larger projects (my current project weighs 4500 lines of Haskell
for instance).
Sengan
From hallgren@cse.ogi.edu Fri Mar 22 04:09:25 2002
From: hallgren@cse.ogi.edu (Thomas Hallgren)
Date: Thu, 21 Mar 2002 20:09:25 -0800
Subject: stripcomments 1.0
References:
Message-ID: <3C9AAE75.1000508@cse.ogi.edu>
Hi,
There now is a program that strips comments and blank lines properly.
You can get the Haskell source code from:
http://www.cse.ogi.edu/~hallgren/stripcomments/
How hard it is to do a real job of course depends on what you start
from. I happened to have a lexer for Haskell, that was really easy to
reuse for this purpose!
Regards,
Thomas Hallgren
Nicholas Nethercote wrote:
>On Mon, 18 Mar 2002, Kevin Glynn wrote:
>
>> > Are there any programs to strip comments and blank lines from a Haskell
>> > source file, that work on normal and literate programs?
>>
>>Doing a real job is 'hard'
>>
>I'm surprised there aren't programs out there that do this properly.
>
From kyagrd@bawi.org Fri Mar 22 04:24:35 2002
From: kyagrd@bawi.org (Ahn Ki-yung)
Date: Fri, 22 Mar 2002 13:24:35 +0900
Subject: Typo: Hugs Bug ! >> it was +
References: <3C999F3F.97BF994D@bawi.org>
Message-ID: <3C9AB203.C6916529@bawi.org>
Prelude> f 1 where f x = x : f x
[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
,1,1,{Interrupted!}
Prelude> f 1 where f x = x + f x
====================
in unix/linux proper error msg comes out and back to interpreter.
ERROR - Control stack overflow
===========
but in windows 2000
Then suddnly interpreter fails and
the red (X) popup window pops up.
hugs.exe - application programm error
unknown software exception (0xc000fd) ... blabla
From petersen@redhat.com Fri Mar 22 05:37:00 2002
From: petersen@redhat.com (Jens Petersen)
Date: 22 Mar 2002 14:37:00 +0900
Subject: popen lazy args and input pipe
In-Reply-To:
References:
Message-ID:
Volker Wysk writes:
> On 21 Mar 2002, Jens Petersen wrote:
> > Volker Wysk writes:
> > > POpen-1.0.0 contains the same bug which I made. It doesn't ensure that
> > > the values which are needed after the call of forkProcess, before that
> > > of executeFile, are fully evaluated. So, if they are read lazily from a
> > > stream, the newly spawned child process reads data from a stream which
> > > it shares with its parent, making it disappear from the parent's input.
> > > In this situation, this sure isn't intended.
Ok, I agree this is a potential if unlikely problem. I
can't really think of any useful examples though.
I guess using "$!"s in the call to popen would solve this
part.
> > Perhaps you could give an explicit example?
>
> I haven't tried it, but it's exactly the same thing.
Well, an explicit example using your "pipeto" or popen would
be helpful.
> > > Inserting the following lines just before the line "pid <- forkProcess",
> > > in POpen.hs, would force the corresponding values to be evaluated, so no
> > > data will be lost.
> > >
> > > seq (length path) $ seq (sum (map length args)) $ return ()
> > > when (isJust env) $ seq (sum (map (\(a,b) -> length a + length b)
> > > (fromJust env))) $ return ()
> > > when (isJust dir) $ seq (length (fromJust dir)) $ return ()
I would prefer not to add strict evaluation to POpen unless
it's absolutely necessary. I guess I really need a testcase
for this problem. If you have one please send it to me. I
should really add some unit tests to popenhs.
> > Hmmm, I don't really see why this is necessary. Don't the
> > lazy values of "path", "env" and "dir" just get evaluated
> > when they're needed here as normal? (If what you say is
> > true though it would be simpler just to use "$!" or "!"s for
> > strict evaluation I guess.)
>
> Yes, and that's *after* forkProcess. So when they are computed from
> the lazily read contents of a stream, the newly spawned child will read
> data from a stream which it shares with its parent.
Btw I guess one can say that popen inherits this problem
from "Posix.runProcess".
But usually "path", "env" and "dir" are not streams, just
strings, right? Even for args I feel pushed to think of a
real example where it could be a problem. Something like
"xargs" taking a long stream of arguments from stdin, but
arguments instead?? (Most shells have restrictions on the
size of argv I think though.)
Are you're referring to these comments from Posix.lhs, or
you've rediscovered them?
-- ***NOTE***: make sure you completely force the evaluation of the path
-- and arguments to the child before calling runProcess. If you don't do
-- this *and* the arguments from runProcess are read in from a file lazily,
-- be prepared for some rather weird parent-child file I/O behaviour.
--
-- [If you don't force the args, consider the case where the
-- arguments emanate from a file that is read lazily, using
-- hGetContents or some such. Since a child of a fork()
-- inherits the opened files of the parent, the child can
-- force the evaluation of the arguments and read them off the
-- file without any problems. The problem is that while the
-- child share a file table with the parent, it has separate
-- buffers, so a child may fill up its (copy of) the buffer,
-- but only read it partially. When the *parent* tries to read
-- from the shared file again, the (shared) file offset will
-- have been stepped on by whatever number of chars that was
-- copied into the file buffer of the child. i.e., the unused
-- parts of the buffer will *not* be seen, resulting in
-- random/unpredicatable results.
--
-- Based on a true (, debugged :-) story.
-- ]
Reading this again I start to understand the problem you're
describing a little better. Perhaps something does need to
be done about it, as you say. ;-)
> But hPutStr, followed by hClose, won't complete until all
> the input string has been written, while no process is
> listening.
Oops, you're right! Indeed popen hangs on input greater
than 4kB on my system. Thank you very much for reporting
this.
Jens
From rjchaaft@cs.uu.nl Fri Mar 22 09:26:52 2002
From: rjchaaft@cs.uu.nl (Rijk J. C. van Haaften)
Date: Fri, 22 Mar 2002 10:26:52 +0100
Subject: Typo: Hugs Bug ! >> it was +
In-Reply-To: <3C9AB203.C6916529@bawi.org>
References: <3C999F3F.97BF994D@bawi.org>
Message-ID: <4.3.0.20020322102518.00b380b8@pop.students.cs.uu.nl>
Ahn Ki-yung wrote:
>Prelude> f 1 where f x = x : f x
>[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
>,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
>,1,1,{Interrupted!}
>
>Prelude> f 1 where f x = x + f x
--> Immediate (!) crash
Indeed, I could reproduce this on my computer
(Win2000; Hugs Dec 2001 of last week).
Rijk-Jan van Haaften
From Keith.Wansbrough@cl.cam.ac.uk Fri Mar 22 09:34:08 2002
From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough)
Date: Fri, 22 Mar 2002 09:34:08 +0000
Subject: Lambda over types.
In-Reply-To: Your message of "Thu, 21 Mar 2002 08:35:27 PST."
<20020321163527.92822.qmail@web14201.mail.yahoo.com>
Message-ID:
anatoli writes:
> ghc -fglasgow-exts -fallow-undecidable-instances allows =
> constructs which amount to lambda abstraction over types. =
> I've written a small untyped lambda calculus interpreter =
> in the Haskell class/instance sublanguage, just to prove
> this point. (The terms are Haskell *types*.)
Cool!
Some time ago I wrote a Turing machine evaluator in Haskell types with un=
decidable instances. It's described at
http://www.chttp://www.cl.cam.ac.uk/~kw217/research/misc/undec.html
Enjoy!
--KW 8-)
-- =
Keith Wansbrough
http://www.cl.cam.ac.uk/users/kw217/
University of Cambridge Computer Laboratory.
From simonpj@microsoft.com Fri Mar 22 10:29:22 2002
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 22 Mar 2002 02:29:22 -0800
Subject: catch (fail "...")
Message-ID: <1113DDB24D4A2841951BFDF86665EE1901041BD4@RED-MSG-10.redmond.corp.microsoft.com>
This is an inconsistency that was fixed in the revised Haskell98=20
report (Apr 2001). See
http://research.microsoft.com/~simonpj/haskell98-revised
In the bug list look for Page 90.
It looks as though Hugs hasn't quite caught up with this change.
Simon
| -----Original Message-----
| From: Brian Huffman [mailto:bhuffman@galois.com]=20
| Sent: 22 March 2002 00:22
| To: haskell@haskell.org
| Subject: catch (fail "...")
|=20
|=20
| Hi,
|=20
| Here is a problem I came across recently, revealing a=20
| difference between ghci=20
| and Hugs:
|=20
| hugs> catch (error "not ok") (\e -> putStrLn "ok")
| Program error: not ok
| ghci> catch (error "not ok") (\e -> putStrLn "ok")
| *** Exception: not ok
|=20
| hugs> catch (ioError (userError "not ok")) (\e -> putStrLn "ok")
| ok
| ghci> catch (ioError (userError "not ok")) (\e -> putStrLn "ok")
| ok
|=20
| hugs> catch (fail "not ok") (\e -> putStrLn "ok")
| Program error: not ok
| ghci> catch (fail "not ok") (\e -> putStrLn "ok")
| ok
|=20
| As I expected, neither of them can catch "error", and both of=20
| them can catch=20
| "ioError". But only ghci can catch the "fail". It seems to me=20
| that ghc has=20
| made a convenient choice here, because if I need to raise an=20
| IO exception, it=20
| is easier to type "fail s" than "ioError (userError s)".
|=20
| However, the online Haskell report says that for IO, fail=A0s=A0=3D=A0
| error=A0s, which=20
| is what Hugs does.=20
| (http://www.haskell.org/onlinereport/standard-prelude.html#$iM
onad$$IO)
Does anyone know the reasoning behind the design choice made in the =
report,=20
or why the ghc implementation is different? I am mainly concerned about=20
portability issues: particularly, is it a good idea to use fail for =
raising=20
IO exceptions?
Thanks
- Brian Huffman
_______________________________________________
Haskell mailing list
Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
From reid@cs.utah.edu Fri Mar 22 16:48:56 2002
From: reid@cs.utah.edu (Alastair Reid)
Date: 22 Mar 2002 16:48:56 +0000
Subject: Hugs Bug !
In-Reply-To: <3C999F3F.97BF994D@bawi.org>
References: <3C999F3F.97BF994D@bawi.org>
Message-ID:
Ahn Ki-yung reports:
> {Apparently inessential details of program supressed]
>
> in unix/linux proper error msg comes out and back to interpreter.
>
> ERROR - Control stack overflow
>
> ===========
> but in windows 2000
>
> Then suddnly interpreter fails and
> the red (X) popup window pops up.
>
> hugs.exe - application programm error
>
> unknown software exception (0xc000fd) ... blabla
This is a known problem in Hugs to do with overflows of the C stack.
The problem is:
- Hugs evaluation is done on the C stack and so some kinds of
evaluation can cause stack overflows.
- OSs and C are pretty poor at detecting or avoiding stack overflows.
The reason you didn't see this in Unix is:
- Unix apparently assigns a different stack-size limit to Hugs.
(I think you can tune stack size in Windows but forget how.)
- Hugs uses a 2nd stack 'the control stack' during evaluation.
This is a normal C array which Hugs knows the size of so it can
detect overflow in that stack.
Often, when you run out of C stack space, you were about to run out
of control stack space anyway and when you run out of control stack
space you were about to run out of C stack space. (In other words,
running out of either usually indicates a problem in your program
which will not be solved by tweaking stack sizes.)
Hope this helps.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From mark.wogahn@yale.edu Fri Mar 22 19:43:19 2002
From: mark.wogahn@yale.edu (Mark Wogahn)
Date: Fri, 22 Mar 2002 14:43:19 -0500
Subject: Haskell server switchover
Message-ID: <3C9B8957.5070901@yale.edu>
Hi All,
I will be bringing the haskell server down tomorrow morning (Sat Mar 23 )
between 08:00 and 8:30 to do some needed service. It should be back
online no later than 9:00. Sorry for any inconvenience.
-Mark
--
Mark Wogahn / mark.wogahn@yale.edu
Workstation Support Services (WSS)
Department of Computer Science
51 Prospect Street, New Haven, CT 06520
Phone: (203) 432-1264 Fax: (203) 432-0593
--------------------------------------------------------
"Nothing is static, everything is falling apart"
Chuck Palahniuk - "Fight Club"
From tom-list-haskell@moertel.com Fri Mar 22 23:38:00 2002
From: tom-list-haskell@moertel.com (Tom Moertel)
Date: Fri, 22 Mar 2002 18:38:00 -0500
Subject: ANNOUNCE: Red Hat RPMs of Haskell Mode for Emacs
Message-ID: <3C9BC058.F19E08DB@moertel.com>
I have packaged the Haskell Mode for Emacs at
http://www.haskell.org/haskell-mode/
into RPMs for Red Hat Linux 7.2 (and similar platforms). Once the
packages are installed, Haskell Mode is automatically enabled when you
start up Emacs. Integration with Hugs is the default, but a quick
change to your .emacs file will cause Haskell Mode to use GHCi instead.
You can find the RPMs here:
http://www.moertel.com/~thor/emacs-haskell-mode/
Cheers,
Tom
P.S. I have also made the RPM .spec file available. If somebody can
add it to the official haskell-mode tarball on haskell.org, people can
build RPMs directly from the tarball using "rpm -ta
haskell-mode-(VERS).tar.gz".
From gkamsteeg@freeler.nl Sat Mar 23 16:01:21 2002
From: gkamsteeg@freeler.nl (Gertjan Kamsteeg)
Date: Sat, 23 Mar 2002 17:01:21 +0100
Subject: using less stack
References: <3C98D8BB.5060001@aber.ac.uk>
Message-ID: <003c01c1d284$1a08e0b0$6e92153e@gertjan1>
You don't have to define cpsfold explicitly recursively since it can be
expressed in terms of foldr:
cpsfold f a xs = foldr (\x k y -> f x y k) id xs a
The following definition would even be better (but not equivalent):
cpsfold' f a xs = foldr (\x k y -> f y x k) id xs a
The list members are now 'consumed' left-to-right by f, with initial value
a.
So,
answer4 = foldr (\x k a -> if x > a then k x else k a) id [1..500000] 0
also works without a crash or insufficient stack space.
Gertjan
----- Original Message -----
From: "Amanda Clare"
To: "C.Reinke"
Cc:
Sent: Wednesday, March 20, 2002 7:45 PM
Subject: Re: using less stack
> [cpsfold omitted]
>
> > Actually, and quite apart from it being cumbersome to use, I've got
> > my doubts about whether this cpsfold really does the job (is that
> > just me missing some point?-).
>
> It does the job for me! In practical terms I can see it works. I'm not
> an expert - I may have this all wrong, but perhaps the point you're
> looking for is that the arguments to f are brought to the very outside
> of the expression, and hence available for evaluation. Imagine for
> [x1,x2,x3,x4]
> from foldr: f x1 (f x2 (f x3 (f x4 a)))
> from foldl: f (f (f (f a x1) x2) x3) x4
>
> Neither are available for immediate evaluation. In the case of foldr the
> end of the list (x4) has to be reached before anything can be evaluated.
> In the case of foldl the first function to be pulled upon is the
> outermost f, which then can't do anything useful (in my case) without
> evaluating its second argument, and so on.
>
> with the cpsfold I get
>
> f x1 a (\y1 -> f x2 y1 (\y2 -> f x3 y3 (\y3 -> f x4 y4 (\y4 -> y4)
>
> so x1 and a are available immediately for f to use, and f x1 a is the
> outermost expression so will be evaluated first.
>
> See for yourself with the following (difference can be seen in ghc with
> standard 1M stack):
>
> > answer1 = foldr larger 0 [1..500000]
> > answer2 = foldl larger 0 [1..500000]
> > answer3 = cpsfold cpslarger 0 [1..500000]
>
> > larger x y = if x > y then x else y
> > cpslarger x y k = if x > y then k x else k y
>
>
>
> > Also, I'm curious to know why the usual strict variant of foldl
> > doesn't help in this case?
> >
> > foldl' f a [] = a
> > foldl' f a (x:xs) = (foldl' f $! f a x) xs
>
> Because $! and seq only evaluates enough to make sure the answer is not
> bottom, and if my f is complex then it doesn't do enough.
>
> Amanda
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
From hdaume@ISI.EDU Sun Mar 24 00:35:18 2002
From: hdaume@ISI.EDU (Hal Daume III)
Date: Sat, 23 Mar 2002 16:35:18 -0800 (PST)
Subject: using less stack
In-Reply-To: <003c01c1d284$1a08e0b0$6e92153e@gertjan1>
Message-ID:
Hi,
> You don't have to define cpsfold explicitly recursively since it can be
> expressed in terms of foldr:
Is this generally considered good design? That is, is it generally
preferred to express functions in a nonrecursive style if that can be done
using standard library functions like foldr and map and filter,
etc? Okay, obviousloy everything *can* be done in that manner, so I guess
my question is why should we write something using foldr when, imo, the
explicitely recursive version is easier to parse (as a human).
- Hal
From reid@cs.utah.edu Sun Mar 24 02:58:49 2002
From: reid@cs.utah.edu (Alastair Reid)
Date: 24 Mar 2002 02:58:49 +0000
Subject: using less stack
In-Reply-To:
References:
Message-ID:
Gertjan Kamsteeg writes:
>> You don't have to define cpsfold explicitly recursively since it
>> can be expressed in terms of foldr:
Hal Daume III writes:
> Is this generally considered good design? [...]
Three different attempts at an answer:
As with all code-factoring it's in the eye of the beholder.
If what you want to do is trace execution in detail, the less factored
code is easier to understand.
If what you want to do is understand the difference between 5
different recursive traversals of a list, then isolating those
differences (by suppressing the invariant fact of recursion) is
better.
More concretely, some prefer to avoid the recursive formulations because:
1) It is trickier to reason about.
Functional programmers (especially Squiggol afficianados) have all
kinds of cunning ways to reason about programs written using
standard library functions such as foldr. The techniques for
reasoning directly about recursive functions are somewhat cruder
and harder.
2) The ability to recursivly invoke the function from _anywhere_ in
the function body has been compared (with some justification) to
the use of goto in unstructured programming. If you buy into this
line of reasoning then foldr, scanr, map, etc. are to functional
programming as while, repeat and for are to structured programming.
[These two points are connected!]
And, finally, my personal preference is:
- use explicit recursion when I don't understand what I'm doing well
enough to know which standard recursive pattern it fits into
(because it normally always fits a standard pattern).
- use higher-order functions when I know what I'm doing or where
setting up the infrastructure for the recursion costs more than
coding it directly.
--
Alastair Reid Reid Consulting (UK) Ltd
From Christine Hall Sun Mar 24 13:37:49 2002
From: Christine Hall (Christine Hall)
Date: Sun, 24 Mar 2002 21:37:49 +0800 (CST)
Subject: http://haskell.org
Message-ID: <37CR1000016979@emaserver.trafficmagnet.net>
--16881215.1016977069281.JavaMail.SYSTEM.emaserver
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi
I visited http://haskell.org, and noticed that you're not listed on some search engines! I think we can
offer you a service which can help you increase traffic and the number of visitors to your website.
I would like to introduce you to TrafficMagnet.net. We offer a unique technology that will submit your
website to over 300,000 search engines and directories every month.
You'll be surprised by the low cost, and by how effective this website promotion method can be.
To find out more about TrafficMagnet and the cost for submitting your website to over 300,000 search
engines and directories, visit www.TrafficMagnet.net.
I would love to hear from you.
Best Regards,
Christine Hall
Sales and Marketing
E-mail: christine@trafficmagnet.net
http://www.TrafficMagnet.net
This email was sent to haskell@haskell.org.
I understand that you may NOT wish to receive information from me by email.
To be removed from this and other offers, simply go to the link below:
http://emaserver.trafficmagnet.net/trafficmagnet/www/optoutredirect?UC=Lead&UI=199707
--16881215.1016977069281.JavaMail.SYSTEM.emaserver
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi
I visited http://haskell.org, and
noticed that you're not listed on some search engines! I think we can offer
you a service which can help you increase traffic and the number of visitors
to your website.
I would like to introduce you to TrafficMagnet.net. We offer a unique technology
that will submit your website to over 300,000 search engines and directories
every month.
You'll be surprised by the low cost, and by how effective this website promotion
method can be.
To find out more about TrafficMagnet and the cost for submitting your website
to over 300,000 search engines and directories, visit www.TrafficMagnet.net.
I would love to hear from you.
Best Regards,
Christine Hall
Sales and Marketing
E-mail: christine@trafficmagnet.net
http://www.TrafficMagnet.net
|
This email was sent to haskell@haskell.org.
I understand that you may NOT wish to receive information from me by email.
To be removed from this and other offers, simply click here.
|
--16881215.1016977069281.JavaMail.SYSTEM.emaserver--
From gkamsteeg@freeler.nl Sun Mar 24 13:38:44 2002
From: gkamsteeg@freeler.nl (Gertjan Kamsteeg)
Date: Sun, 24 Mar 2002 14:38:44 +0100
Subject: using less stack
References:
Message-ID: <002e01c1d339$582cc450$2797153e@gertjan1>
From: "Alastair Reid"
>
> Gertjan Kamsteeg writes:
> >> You don't have to define cpsfold explicitly recursively since it
> >> can be expressed in terms of foldr:
>
> Hal Daume III writes:
> > Is this generally considered good design? [...]
>
> Three different attempts at an answer:
>
> As with all code-factoring it's in the eye of the beholder.
>
> If what you want to do is trace execution in detail, the less factored
> code is easier to understand.
>
> If what you want to do is understand the difference between 5
> different recursive traversals of a list, then isolating those
> differences (by suppressing the invariant fact of recursion) is
> better.
>
I agree. However, although *functionally* every list traversing function
should be expressible in terms of foldr (because foldr represents the type
theoretical elimination rule for lists in most type systems with inductive
types (and without element depending types)), it's not just a matter of
taste. Execution clearly *does* depend on how things are defined. When I
said 'can be expressed', I meant extensionally equivalent, including
behavior w.r.t. reductions. For example, if, in the Prelude, foldr had been
defined in terms of foldl:
foldr f a xs = foldl (\h x y -> h (f x y)) id xs a
my definition of cpsfold in terms of foldr wouldn't go through. That is,
some stack would again overflow. What I wanted to say is that the fact that
Amanda's answer1 (maximum in terms of foldr) didn't work wasn't caused by
the definition of foldr in the Prelude.
Besides, (re)factoring is fun. So, here's another one (foldl in terms of
foldr):
foldl f a xs = foldr (\x h y -> h (f y x)) id xs a
BTW, there may be another reason for expressing list traversing functions in
terms of foldr: if one uses only functions representing 'standard'
elimination rules, it is guaranteed that all reduction sequences eventually
terminate.
Gertjan
From ru@river.org Sun Mar 24 20:23:23 2002
From: ru@river.org (Richard Uhtenwoldt)
Date: Sun, 24 Mar 2002 12:23:23 -0800
Subject: using less stack
In-Reply-To:
References: <003c01c1d284$1a08e0b0$6e92153e@gertjan1>
Message-ID:
Hal Daume III writes:
>> You don't have to define cpsfold explicitly recursively since it can be
>> expressed in terms of foldr:
>
>Is this generally considered good design? That is, is it generally
>preferred to express functions in a nonrecursive style if that can be done
>using standard library functions like foldr and map and filter,
>etc?
One answer that Alastair Reid did not mention is that the nonrecursive
style usually benefits from the deforestation optimization whereas
IIUC the explicitly recursive style never does in contemporary
compilers.
Another answer, which I give because the factor does not enter enough
into the thinking of academic language designers, is that the
nonrecursive style inhibits adoption of Haskell by making it slightly
more difficult for the average programmer or programmer-wannabe to
learn --"slightly" because with recursion, lists and monadic
interfaces Haskell already has a lot of significant learning barriers
to adoption, and the nonrecursive style of definition is easier to
learn (get used to) than any one of those last 3.
--
Richard Uhtenwoldt
From ru@river.org Sun Mar 24 20:59:50 2002
From: ru@river.org (Richard Uhtenwoldt)
Date: Sun, 24 Mar 2002 12:59:50 -0800
Subject: a survey of language popularity
In-Reply-To:
References: <003c01c1d284$1a08e0b0$6e92153e@gertjan1>
Message-ID:
So, how popular is Haskell compared to other languages?
Here are some Google search results that suggest how many web pages
are devoted to particular langauges. (Google tells you how many pages
match your query.) A better survey of language popularity would
include newsgroup and mailing list traffic, but no time, no time.
In this modest survey, Haskell is a little more popular than O'Caml, a
little less popular than Eiffel (an OOPL) 5 to 6 times less popular
than Smalltalk; 8 to 10 times less popular than Python, which is
itself at least 2 and a half or 3 times less popular than Perl.
On second thought, Eiffel and Smalltalk might be considerably more
popular than suggested by page counts because the other languages
surveyed have 100% open-source documentation. eg, in the GHC results
I saw lots of duplicates of essentially the same document. This is
characteristic of open-source-code-licensed content. In contrast,
Eiffel and Smalltalk have commercial vendors, whose documentation is
(I would think) underrepresented in this modest survey because of
having licenses that restrict copying.
perl 9,600,000
perl language OR program OR variable OR object 1,490,000.
python -monty -snake -venom 809,000
python program OR language OR variable OR object 630,000
smalltalk 361,000 (say 10% false hits. 325,000 real.)
lisp cmucl OR "common lisp" OR heap OR cdr OR cons OR lambda OR
closure OR scheme 188,000
eiffel object OR program OR variable OR string -tower 74,700
(I say there's a few false hits there. 71,000 real hits.)
ghc haskell OR compiler 63,100
ghc haskell OR compiler OR functional OR fp 66,800
haskell fp OR "programming" OR monad OR monadic OR functional OR lambda 63,600
haskell "programming" OR monad OR monadic OR functional OR lambda 55,500
(I say 63,000 is the most accurate)
caml 88,700 (I can see some false hits)
"objective caml" OR ocaml OR o'caml 41,700.
(42,000)
note that there is at least one open-source Linux package, unison, a
file sync utility, written in O'Caml. no Linux packages written in
Haskell except for Haskell compilers.
other info useful for measuring language popularity.
sloc in various RedHat 7.2 packages
lines of code in Debian
Counting Debian //
[E-Lang] popularity of programming languages among open source hackers // weak survey, of Sourceforge projects. see also Oct 2001 e-lang.
--
Richard Uhtenwoldt
From A.Simon@ukc.ac.uk Mon Mar 25 00:04:11 2002
From: A.Simon@ukc.ac.uk (Axel Simon)
Date: Mon, 25 Mar 2002 00:04:11 +0000 (GMT)
Subject: Announce: Gtk2Hs - A Haskell binding for Gtk2
Message-ID:
Note: This is not gtk+hs.
Gtk2Hs is a rewrite of gtk+hs. It is a binding to the recently released
version of Gtk2 with a couple of improvements over gtk+hs:
- Automatic memory management.
- Nearly complete coverage of widget functions and their signals,
including the new text and list widgets.
- The convenience wrapper MoGuL (Monad Gui Library) makes it possible to
create and lookup named widgets in a type safe way.
- Unicode support.
- Object-oriented calling convention for widget functions.
- Pragmatically uses both c2hs and hsc acquire information about the C
files. Automatically generates callback handlers and the widget type
hierarchy.
- Needs ghc version 5.00 or later, makes use of the --make flag and
complies quite quickly (12 mins).
I am currently only providing CVS access to the sources. Find them at:
https://sourceforge.net/cvs/?group_id=49207
At the moment it does not compile on Solaris due to the 4 parameter
restriction of GHC for dynamic callbacks.
Feedback is very welcome, a good place to send it to is:
gtk2hs-users@lists.sourceforge.net
Share and enjoy,
Axel.
From svb@doc.ic.ac.uk Mon Mar 25 13:28:15 2002
From: svb@doc.ic.ac.uk (Steffen van Bakel)
Date: Mon, 25 Mar 2002 13:28:15 +0000
Subject: ITRS'02 call for papers
Message-ID: <0203251328.AA157444@Schiele>
--PopOver-2.0.150-1017062895-3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
(Apologies for multiple copies)
(Second) Call for Papers
Workshop on
Intersection Types and Related Systems (ITRS '02)
Copenhagen, Denmark
Friday, July 26 2002
http://www.doc.ic.ac.uk/~itrs02/
Co-located with FLoC '02,
the third Federated Logic Conference
to be held in Copenhagen, Denmark
(July 22 to August 1 2002)
http://floc02.diku.dk/
IMPORTANT DATES/DEADLINES:
Submission of papers: Sunday, April 7 2002
Notification of acceptance: Thursday, April 25 2002
Workshop: Friday, July 26 2002
OVERALL TOPIC AND FORMAT OF WORKSHOP:
Intersection type disciplines originated in 1980 to overcome the
limitations of Curry's type assignment system and to provide a
characterisation of the strongly normalising terms of the Lambda
Calculus. Since then, intersection types disciplines were used
in a series of papers for characterising evaluation properties
and semantics.
Types also support reliable reasoning in many areas such as logic,
programming languages, linguistics, etc. A _polymorphic_ type
stands for some number of instance types, and the use of type
systems for non-trivial purposes generally requires polymorphic
types. In this context, roughly speaking, intersection types
could be seen as to provide type polymorphism by listing type
instances. This differs from the more widely used ("forall")
quantified types, which provide type polymorphism by giving a type
scheme that can be instantiated into various type instances.
(A similar relationship holds between union types and existential
types, the duals of intersection types and universal types.)
Although intersection types were initially intended for use in
analyzing and/or synthesizing lambda models as well as in analyzing
normalization properties, over the last twenty years the scope of
theoretical research on intersection types has broadened. Recently,
there have been a number of breakthroughs in the use of intersection
types (and similar technology) for practical purposes such as program
analysis.
The ITRS '02 workshop will be held to bring together researchers
working on both the theory and practice of systems with intersection
types and related systems (e.g., union types, refinement types,
etc.). The workshop will last one full day and will contain a long
talk by each invited speaker, a panel discussion, and a short
(approx. 25 minutes) talk for each accepted paper.
POSSIBLE TOPICS FOR SUBMITTED PAPERS:
Researchers are invited to submit original papers on topics in the
spirit of the workshop. Possible topics for submitted papers
include, but are not limited to:
* Formal properties of systems with intersection types: principal
typings, normalization properties (for normal forms, head-normal
forms, weak head-normal forms, etc.), type inference algorithms.
* Results for clearly related systems, e.g., systems with union
types, refinement types, or singleton types.
* Connections with not-so-clearly related approaches such as
abstract interpretation and constraints.
* Applications to lambda calculus and similar systems, e.g.,
denotational semantics, analysis/synthesis of lambda models
(domains), characterization of operational properties, etc.
* Applications for programming languages, e.g., program analysis
(flow, strictness, totality, etc.), accurate type error
messages, increased flexibility with static typing, separate
compilation and modularity, optimizing transformations, types
for objects, etc.
* Applications for other areas, e.g., database query languages,
program extraction from proofs, type systems for natural
languages.
INVITED SPEAKER (confirmed)
Frank Pfenning (Carnegie Mellon University, USA)
REGISTRATION FEE
50 Euro for the workshop; an additional 80 Euro will be charged
to participants who haven't registered for one of the main FLoC
conferences (but only once, not per workshop)
PROGRAM COMMITTEE:
Steffen van Bakel (Chair) (Imperial College, London, UK)
Franco Barbanera (Universita` di Catania, Italia)
Mario Coppo (Universita` di Torino, Italia)
Luca Roversi (Universita` di Torino, Italia)
Lyn Turbak (Wellesley College (MA) USA)
Pawel Urzyczyn (Uniwersytet Warszawski, Polska)
Joe Wells (Heriot-Watt University, Edinburgh,
Scotland)
SUBMISSION INSTRUCTIONS:
TOPIC: A submitted paper must describe work that does not
substantially overlap with work that has been previously published
or is currently being considered elsewhere (e.g., another
workshop, conference, or journal). Feel free to consult the
program chair on the appropriateness of a topic or the possibility
of conflict with another publication.
PRINTED APPEARANCE: The paper must be written in English. The paper
(including bibliography) should not exceed 15 pages. The paper
should a font size no smaller than 11pt and standard TeX spacing.
It is recommended to include full proofs of any theorems in
appendices if they will not fit in 15 pages. However, any
appendices beyond the 15-page limit should not be needed for
judging the paper and will not be included in the proceedings.
PAPER ELECTRONIC FORMAT: The paper should be in PostScript or PDF.
Every effort should be made to ensure that only portable
PostScript features are used (e.g., avoid using non-standard
built-in fonts). For other formats, ask the program chair well
in advance of the deadline.
For TeX, the class file itrspaper.cls is recommended for use
(available at http://www.doc.ic.ac.uk/~itrs02/itrspaper.cls).
ADMINISTRATIVE INFORMATION: The first page of the paper should include
(1) the title,
(2) the list of authors,
(3) a brief abstract (fewer than 200 words),
(4) a short list of key words/topics, and
(5) the name, e-mail address, and postal address of the corresponding
author.
This information should be repeated at the Paper Submission Page
available at the workshop's website =3D =
(http://www.doc.ic.ac.uk/~itrs02/).
SUBMISSION:
Papers can be submitted electronically via the Paper Submission Page
available at the workshop's website =3D =
(http://www.doc.ic.ac.uk/~itrs02/).
VENUE:
The workshop is colocated with the FLoC '02 conference, which will
be held in Copenhagen, Denmark.
CONTACT INFORMATION:
Web: http://www.doc.ic.ac.uk/~itrs02/
Program chair: Steffen van Bakel
e-mail: itrs02@doc.ic.ac..uk
telephone: +44 20 7495 8263
fax: +44 20 7581 8024
postal: Department of Computing
Imperial College
180 Queens's Gate
London SW7 2BZ, UK
--PopOver-2.0.150-1017062895-3
Content-Type: text/enriched; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Courier(Apologies for multiple copies)
(Second) Call for Papers
Workshop on
Intersection Types and Related Systems (ITRS '02)
Copenhagen, Denmark
Friday, July 26 2002
0000,0000,ffff=
http://www.doc.ic.ac.uk/~itrs02/
Co-located with FLoC '02,
the third Federated Logic Conference
to be held in Copenhagen, Denmark
(July 22 to August 1 2002)
0000,0000,ffff=
http://floc02.diku.dk/
IMPORTANT DATES/DEADLINES:
Submission of papers: Sunday, April 7 2002
Notification of acceptance: Thursday, April 25 2002
Workshop: Friday, July 26 2002
OVERALL TOPIC AND FORMAT OF WORKSHOP:
Intersection type disciplines originated in 1980 to overcome the
limitations of Curry's type assignment system and to provide a
characterisation of the strongly normalising terms of the Lambda
Calculus. Since then, intersection types disciplines were used
in a series of papers for characterising evaluation properties
and semantics.
Types also support reliable reasoning in many areas such as logic,
programming languages, linguistics, etc. A _polymorphic_ type
stands for some number of instance types, and the use of type
systems for non-trivial purposes generally requires polymorphic
types. In this context, roughly speaking, intersection types
could be seen as to provide type polymorphism by listing type
instances. This differs from the more widely used ("forall")
quantified types, which provide type polymorphism by giving a type
scheme that can be instantiated into various type instances.
(A similar relationship holds between union types and existential
types, the duals of intersection types and universal types.)
Although intersection types were initially intended for use in
analyzing and/or synthesizing lambda models as well as in analyzing
normalization properties, over the last twenty years the scope of
theoretical research on intersection types has broadened. Recently,
there have been a number of breakthroughs in the use of intersection
types (and similar technology) for practical purposes such as program
analysis.
The ITRS '02 workshop will be held to bring together researchers
working on both the theory and practice of systems with intersection
types and related systems (e.g., union types, refinement types,
etc.). The workshop will last one full day and will contain a long
talk by each invited speaker, a panel discussion, and a short
(approx. 25 minutes) talk for each accepted paper.
POSSIBLE TOPICS FOR SUBMITTED PAPERS:
Researchers are invited to submit original papers on topics in the
spirit of the workshop. Possible topics for submitted papers
include, but are not limited to:
* Formal properties of systems with intersection types: principal
typings, normalization properties (for normal forms, head-normal
forms, weak head-normal forms, etc.), type inference algorithms.
* Results for clearly related systems, e.g., systems with union
types, refinement types, or singleton types.
* Connections with not-so-clearly related approaches such as
abstract interpretation and constraints.
* Applications to lambda calculus and similar systems, e.g.,
denotational semantics, analysis/synthesis of lambda models
(domains), characterization of operational properties, etc.
* Applications for programming languages, e.g., program analysis
(flow, strictness, totality, etc.), accurate type error
messages, increased flexibility with static typing, separate
compilation and modularity, optimizing transformations, types
for objects, etc.
* Applications for other areas, e.g., database query languages,
program extraction from proofs, type systems for natural
languages.
INVITED SPEAKER (confirmed)
Frank Pfenning (Carnegie Mellon University, USA)
REGISTRATION FEE
50 Euro for the workshop; an additional 80 Euro will be charged
to participants who haven't registered for one of the main FLoC
conferences (but only once, not per workshop)
PROGRAM COMMITTEE:
Steffen van Bakel (Chair) (Imperial College, London, UK)
Franco Barbanera (Universita` di Catania, Italia)
Mario Coppo (Universita` di Torino, Italia)
Luca Roversi (Universita` di Torino, Italia)
Lyn Turbak (Wellesley College (MA) USA)
Pawel Urzyczyn (Uniwersytet Warszawski, Polska)
Joe Wells (Heriot-Watt University, Edinburgh,
Scotland)
SUBMISSION INSTRUCTIONS:
TOPIC: A submitted paper must describe work that does not
substantially overlap with work that has been previously published
or is currently being considered elsewhere (e.g., another
workshop, conference, or journal). Feel free to consult the
program chair on the appropriateness of a topic or the possibility
of conflict with another publication.
PRINTED APPEARANCE: The paper must be written in English. The paper
(including bibliography) should not exceed 15 pages. The paper
should a font size no smaller than 11pt and standard TeX spacing.
It is recommended to include full proofs of any theorems in
appendices if they will not fit in 15 pages. However, any
appendices beyond the 15-page limit should not be needed for
judging the paper and will not be included in the proceedings.
PAPER ELECTRONIC FORMAT: The paper should be in PostScript or PDF.
Every effort should be made to ensure that only portable
PostScript features are used (e.g., avoid using non-standard
built-in fonts). For other formats, ask the program chair well
in advance of the deadline.
For TeX, the class file itrspaper.cls is recommended for use
(available at 0000,0000,ffff=
http://www.doc.ic.ac.uk/~itrs02/itrspaper.cls).
ADMINISTRATIVE INFORMATION: The first page of the paper should include
(1) the title,
(2) the list of authors,
(3) a brief abstract (fewer than 200 words),
(4) a short list of key words/topics, and
(5) the name, e-mail address, and postal address of the corresponding
author.
This information should be repeated at the Paper Submission Page
available at the workshop's website =3D (=
0000,0000,ffff=
http://www.doc.ic.ac.uk/~itrs02/).
SUBMISSION:
Papers can be submitted electronically via the Paper Submission Page
available at the workshop's website =3D (=
0000,0000,ffff=
http://www.doc.ic.ac.uk/~itrs02/).
VENUE:
The workshop is colocated with the FLoC '02 conference, which will
be held in Copenhagen, Denmark.
CONTACT INFORMATION:
Web: 0000,0000,ffff=
http://www.doc.ic.ac.uk/~itrs02/
Program chair: Steffen van Bakel
e-mail: 0000,0000,ffff=
itrs02@doc.ic.ac..uk
telephone: +44 20 7495 8263
fax: +44 20 7581 8024
postal: Department of Computing
Imperial College
180 Queens's Gate
London SW7 2BZ, UK
--PopOver-2.0.150-1017062895-3--
From heringto@cs.unc.edu Mon Mar 25 20:00:58 2002
From: heringto@cs.unc.edu (Dean Herington)
Date: Mon, 25 Mar 2002 15:00:58 -0500
Subject: instance Read Dynamic ?
Message-ID: <3C9F81FA.833184A6@cs.unc.edu>
The type `Dynamic` is an instance of `Show` but not of `Read`. Is there
some reason `Dynamic` could not be made an instance of `Read`? Has
anyone extended `Dynamic` in that way?
Dean Herington
From bhuffman@galois.com Mon Mar 25 20:55:48 2002
From: bhuffman@galois.com (Brian Huffman)
Date: Mon, 25 Mar 2002 12:55:48 -0800
Subject: instance Read Dynamic ?
In-Reply-To: <3C9F81FA.833184A6@cs.unc.edu>
References: <3C9F81FA.833184A6@cs.unc.edu>
Message-ID: <200203252055.g2PKtmF02271@localhost.localdomain>
On Monday 25 March 2002 12:00 pm, Dean Herington wrote:
> The type `Dynamic` is an instance of `Show` but not of `Read`. Is there
> some reason `Dynamic` could not be made an instance of `Read`? Has
> anyone extended `Dynamic` in that way?
Here is a snippet of code from the GHC Dynamic library; you will notice that
Dynamic objects contain a TypeRep and a data object, but the data object is
ignored by show (as it must be, since the Obj could be anything, showable or
not):
data Dynamic = Dynamic TypeRep Obj
instance Show Dynamic where
-- the instance just prints the type representation.
showsPrec _ (Dynamic t _) =
showString "<<" .
showsPrec 0 t .
showString ">>"
It is impossible to make a matching Read instance, because you lose
information when you show a Dynamic object; there is no way a read function
can reconstruct the data object's value.
It probably wouldn't be too difficult to make a readable version of Dynamic,
but it would only be able to hold datatypes that were instances of Read and
Show. I'd be interested to see if anyone else has implemented anything like
this; it seems like it could be pretty useful.
- Brian Huffman
From ºÃÉÌÎñ Tue Mar 26 02:29:02 2002
From: ºÃÉÌÎñ (ºÃÉÌÎñ)
Date: Tue,26 Mar 2002 15:27:50 +0800
Subject: »¶Ó¹âÁÙ¡°ºÃÉÌÎñ¡±ÆóÒµÍø
Message-ID: <20020326072848.C2E6F4220CB@www.haskell.org>
------=_Mail_Part_PPP_SMTP_01C11A5B.CEFD965
Content-Type: multipart/alternative;
boundary="----=_Mail_Part_PPP_POP3_01C11A8E.4ECE36A0"
------=_Mail_Part_PPP_POP3_01C11A8E.4ECE36A0
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: 8bit
»¶ÓµÇ½
»¶ÓµÇ½¡°ºÃÉÌÎñ¡±ÆóÒµÍøÕ¾(www.good35.com)
×ð¾´µÄÅóÓÑ£º
ÄúºÃ£¡
¡°ºÃÉÌÎñ¡±ÆóÒµÍøÕ¾--ÖйúÆóÒµÉÌÎñÐÅÏ¢Íø¡£ÒÔ¡°ÎªÆóÒµ´´ÔìЧÒ桱Ϊ¾ÓªÀíÄ×ÅÁ¦ÓÚÆóÒµµÄÍøÉÏÐû´«¡¢ÓªÏúºÍ¹ÜÀíµÈ¹¤×÷µÄÈ«Ãæ·¢Õ¹¡£ËüÒÔ¸ü±ã½ÝµÄÐÅÏ¢¹µÍ¨£¬¸üµÍÁ®µÄ¼Û¸ñ£¬¸üÓÅÖʵķþÎñ£¬¸üÇ÷ÓÚ¸öÐÔ»¯µÄ¹ÜÀí£¬Á¦Õù³ÉΪÆóÒµÉÏÍøµÄÊ×ѡƽ̨¡£
¡°ºÃÉÌÎñ¡±ÎªÆóÒµÌṩ¶àÖÖ¼¼Êõ·þÎñºÍÈí¡¢Ó²¼þÖ§³Ö£¬ÎªÆóÒµÌṩ¶àÖÖµÄÍøÕ¾Éè¼ÆÄ£°å£¬Ìṩ¶àÀàÃâ·ÑCGI³ÌÐò£¬¿ÉÉêÇëÃâ·Ñ¶þ¼¶ÓòÃû£¬ÀûÓÃ×ÔÖúÍøÕ¾Éú³Éϵͳ£¬Ê¹ÆóÒµ½¨Õ¾¸üÇáËÉ¡£¡°ºÃÉÌÎñ¡±ÒÀÍеçÐŹ«ÓÃÊý¾ÝͨÐÅƽ̨£¬ÎªÆóÒµ¿Í»§ÌṩÊý¾ÝÏß·¡¢ÍøÂç½ÓÈëºÍÍøÂçÓ¦ÓõȶàÖÖ·þÎñ¡£¡°ºÃÉÌÎñ¡±ÖصãÍ»³öÍøÉÏÓªÏú£¬Í¨¹ýÐÂƷչʾ¡¢¾«Æ·ÈÈÂô¡¢ÍøÉϳ¬ÊС¢ÍøÉÏרÂôµê¡¢¹©ÇóÐÅÏ¢·¢²¼ÒÔ¼°ÏîÄ¿ÕÐͶ±ê¡¢ÕÐÉÌÒý×Ê¡¢È˲ÅÊг¡µÈÀ¸Ä¿µÄÍƳö£¬Ê¹ÍøÂçÓªÏú¸ü¾«²Ê¡£
¡°ºÃÉÌÎñ¡±µÄÒ»Çлù±¾¹¦Äܶ¼½«Ãâ·ÑΪÄú¿ª·Å£¬Ï£ÍûÄܽ衰ºÃÉÌÎñ¡±×¨ÒµÉÌÎñƽ̨£¬Îª¹ó¹«Ë¾µÄ·¢Õ¹ÖúÒ»±ÛÖ®Á¦¡£µ±È»£¬ÄúÒ²¿ÉÒÔÑ¡Óá°ºÃÉÌÎñ¡±µÄÇ¿´óÑÓÉì·þÎñ£¬¹¦ÄܸüÈ«£¬¼Û¸ñ¸üÓÅ¡£¡°ºÃÉÌÎñ¡±£¬ÎªÆóÒµ´´ÔìЧÒæ¡£
ÎÒÃdzÏÖ¿µØÑûÇë¹ó¹«Ë¾¼ÓÃË¡°ºÃÉÌÎñ¡±£¬ÇëµÇ½www.good35.com£¬ÉêÇëÄãµÄÕʺźͿռ䡣Ը¹ó¹«Ë¾ÔÚ¡°ºÃÉÌÎñ¡±µÄÐÖúÏ£¬Äܹ»ÔÚÍøÉÏÓªÏúÁìÓò´óÕ¹ºêͼ¡£
ºÃÉÌÎñ£¬ÆóÒµµÄºÃ°ïÊÖ£¡
¡¡
¡¡
¡¡
¡¡
------=_Mail_Part_PPP_POP3_01C11A8E.4ECE36A0--
------=_Mail_Part_PPP_SMTP_01C11A5B.CEFD965--
From ºÃÉÌÎñ Tue Mar 26 02:29:02 2002
From: ºÃÉÌÎñ (ºÃÉÌÎñ)
Date: Tue,26 Mar 2002 15:27:50 +0800
Subject: »¶Ó¹âÁÙ¡°ºÃÉÌÎñ¡±ÆóÒµÍø
Message-ID: <20020326072851.DB86C42223A@www.haskell.org>
------=_Mail_Part_PPP_SMTP_01C11A5B.CEFD965
Content-Type: multipart/alternative;
boundary="----=_Mail_Part_PPP_POP3_01C11A8E.4ECE36A0"
------=_Mail_Part_PPP_POP3_01C11A8E.4ECE36A0
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: 8bit
»¶ÓµÇ½
»¶ÓµÇ½¡°ºÃÉÌÎñ¡±ÆóÒµÍøÕ¾(www.good35.com)
×ð¾´µÄÅóÓÑ£º
ÄúºÃ£¡
¡°ºÃÉÌÎñ¡±ÆóÒµÍøÕ¾--ÖйúÆóÒµÉÌÎñÐÅÏ¢Íø¡£ÒÔ¡°ÎªÆóÒµ´´ÔìЧÒ桱Ϊ¾ÓªÀíÄ×ÅÁ¦ÓÚÆóÒµµÄÍøÉÏÐû´«¡¢ÓªÏúºÍ¹ÜÀíµÈ¹¤×÷µÄÈ«Ãæ·¢Õ¹¡£ËüÒÔ¸ü±ã½ÝµÄÐÅÏ¢¹µÍ¨£¬¸üµÍÁ®µÄ¼Û¸ñ£¬¸üÓÅÖʵķþÎñ£¬¸üÇ÷ÓÚ¸öÐÔ»¯µÄ¹ÜÀí£¬Á¦Õù³ÉΪÆóÒµÉÏÍøµÄÊ×ѡƽ̨¡£
¡°ºÃÉÌÎñ¡±ÎªÆóÒµÌṩ¶àÖÖ¼¼Êõ·þÎñºÍÈí¡¢Ó²¼þÖ§³Ö£¬ÎªÆóÒµÌṩ¶àÖÖµÄÍøÕ¾Éè¼ÆÄ£°å£¬Ìṩ¶àÀàÃâ·ÑCGI³ÌÐò£¬¿ÉÉêÇëÃâ·Ñ¶þ¼¶ÓòÃû£¬ÀûÓÃ×ÔÖúÍøÕ¾Éú³Éϵͳ£¬Ê¹ÆóÒµ½¨Õ¾¸üÇáËÉ¡£¡°ºÃÉÌÎñ¡±ÒÀÍеçÐŹ«ÓÃÊý¾ÝͨÐÅƽ̨£¬ÎªÆóÒµ¿Í»§ÌṩÊý¾ÝÏß·¡¢ÍøÂç½ÓÈëºÍÍøÂçÓ¦ÓõȶàÖÖ·þÎñ¡£¡°ºÃÉÌÎñ¡±ÖصãÍ»³öÍøÉÏÓªÏú£¬Í¨¹ýÐÂƷչʾ¡¢¾«Æ·ÈÈÂô¡¢ÍøÉϳ¬ÊС¢ÍøÉÏרÂôµê¡¢¹©ÇóÐÅÏ¢·¢²¼ÒÔ¼°ÏîÄ¿ÕÐͶ±ê¡¢ÕÐÉÌÒý×Ê¡¢È˲ÅÊг¡µÈÀ¸Ä¿µÄÍƳö£¬Ê¹ÍøÂçÓªÏú¸ü¾«²Ê¡£
¡°ºÃÉÌÎñ¡±µÄÒ»Çлù±¾¹¦Äܶ¼½«Ãâ·ÑΪÄú¿ª·Å£¬Ï£ÍûÄܽ衰ºÃÉÌÎñ¡±×¨ÒµÉÌÎñƽ̨£¬Îª¹ó¹«Ë¾µÄ·¢Õ¹ÖúÒ»±ÛÖ®Á¦¡£µ±È»£¬ÄúÒ²¿ÉÒÔÑ¡Óá°ºÃÉÌÎñ¡±µÄÇ¿´óÑÓÉì·þÎñ£¬¹¦ÄܸüÈ«£¬¼Û¸ñ¸üÓÅ¡£¡°ºÃÉÌÎñ¡±£¬ÎªÆóÒµ´´ÔìЧÒæ¡£
ÎÒÃdzÏÖ¿µØÑûÇë¹ó¹«Ë¾¼ÓÃË¡°ºÃÉÌÎñ¡±£¬ÇëµÇ½www.good35.com£¬ÉêÇëÄãµÄÕʺźͿռ䡣Ը¹ó¹«Ë¾ÔÚ¡°ºÃÉÌÎñ¡±µÄÐÖúÏ£¬Äܹ»ÔÚÍøÉÏÓªÏúÁìÓò´óÕ¹ºêͼ¡£
ºÃÉÌÎñ£¬ÆóÒµµÄºÃ°ïÊÖ£¡
¡¡
¡¡
¡¡
¡¡
------=_Mail_Part_PPP_POP3_01C11A8E.4ECE36A0--
------=_Mail_Part_PPP_SMTP_01C11A5B.CEFD965--
From bahadirsevinc@firat.edu.tr Tue Mar 26 10:44:35 2002
From: bahadirsevinc@firat.edu.tr (=?iso-8859-9?B?QmFoYWT9ciBTRVbdTsc=?=)
Date: Tue, 26 Mar 2002 12:44:35 +0200
Subject: Little problem
Message-ID:
Hello
I have little problem. I want to solve this equation
f(n-1) = f(n)+n
f(6)=6 => f(2)=?
Can anybody help me please ?
Best regards..
Bahadýr SEVÝNÇ
From bahadirsevinc@firat.edu.tr Tue Mar 26 13:51:21 2002
From: bahadirsevinc@firat.edu.tr (=?iso-8859-9?B?QmFoYWT9ciBTRVbdTsc=?=)
Date: Tue, 26 Mar 2002 15:51:21 +0200
Subject: I need some help
Message-ID:
Hello
I am writing a whole program which is analyz a elegtromagnetic wave. This
is ok but in the program I use a lot of constant for example pi,epsilon etc.
I want to ask that
how I use a constant in Haskell ?
However the user of the program give some argument then program is starting.
And I want to use this arguments for example at the end of the program. What
will I do.
Thanks
Baha
Electrical & Electronics Engineer
Bahadýr SEVÝNÇ
Fýrat University
Informatics Department & Computer Center
Elazýð / Türkiye
23169
Tlf: +90 424 2370000-5011
From jadrian@mat.uc.pt Tue Mar 26 15:46:13 2002
From: jadrian@mat.uc.pt (Jorge Adriano)
Date: Tue, 26 Mar 2002 15:46:13 +0000
Subject: I need some help
In-Reply-To:
References:
Message-ID: <20020326154911.A7B2A422221@www.haskell.org>
[Obs: moving to haskell cafe]
[beware, huge answer follows]
> Hello
> I am writing a whole program which is analyz a elegtromagnetic wave. This
> is ok but in the program I use a lot of constant for example pi,epsilon
> etc. I want to ask that
> how I use a constant in Haskell ?
Defining constants it's easy, examples.
-- with no type signature
epsilon = 3.1
-- with explicit type signature
epsilon2 :: Double
epsilon2 = 3.1
-- specifying the type but no type signature
epsilon3 = 3.1 :: Double
(by the way, wouldn't it make sense not to get a warning about missing type
signature in this last case. I know there is no signature there but still...)
> However the user of the program give some argument then program is
> starting. And I want to use this arguments for example at the end of the
> program. What will I do.
Good question. I've had a bad time with this, some in this list proably got
tired of me saying the same thing over and over again... those of you might
want to skip the rest of my mail :-)
If you want the user to be able to chose those values, then they are NOT
constants, period. Yes their values won't chnage during the rest of the
algorithm, but that doesn't makes it constants, so you can't declare them
that way.
What *can* you do.
1. One *awfull* option is to pass thos values as arguments to all your
functions. Yes signatures will get monstruous, it will complicate the
developing process etc,
2. Instead of passing all those variables, group them in a record - data type
with named fields - and pass that record arround.
(http://www.haskell.org/onlinereport/exps.html#sect3.15)
Signatures will get better. It's kind of weird though, to always have to pass
around that record. Things can get quite messy, IMO.
-- foo
f :: Double -> Double -> Double
f x y = eta*x - epsilon^2*y
-- foo2
f :: Options -> Double -> Double -> Double
f opt x y = (eta opt)* (epsilon opt)^2*y
And this is just a very simple example, it can get much worst.
3. Implicit parameters. (At least in Ghc, what about others?)
Now this is the closest to an elegant solution.
*Read both*:
http://citeseer.nj.nec.com/246042.html
http://www.cs.chalmers.se/~rjmh/Globals.ps
f :: (?eta::Double, ?epsilon::Double)=> Double -> Double -> Double
f x y = ?eta*x - ?epsilon^2*y
Now you don't have to specify eta and epsilon in the type signature itself,
but in the context - no passing around extra (not natural) parameters. It
makes an huge diference IMO when developing your algorithms.
Still signatures wil get even bigger than if you just passed them as
parameters, you can't even type the context like: (?eta, ?epsilon::Double)
So that is just awfull!
Once again records will help.
f :: (?opt::Options)=> Double -> Double -> Double
f x y = (eta ?opt) *x - (epsilon ?opt)^2*y
It still lokes quite bad. I *hate* the field projection functions, and I hate
the '?'!! So you could simply rename you data opt fields and declare,
eta :: (?opt:: Options) => Double
eta = etaF ?opt
epsilon :: (?opt:: Options) => Double
epsilon = epsilonF ?opt
Now f could be written like:
f :: (?opt::Options)=> Double -> Double -> Double
f x y = eta*x - epsilon^2*y
Which differs from the first f function only in the context.
It is *almost* good enough for me :-)
"Why the almost?" you ask...
Well, implicit parameters are not only non-standard features, but also
experimental features (right?), so you they can change anytime.
--------------------------------------------------------------------------------------
NOTE: some of you might wanna quit reading here, I keep complaining about
this stuff, you are probably tired of it :-)
--------------------------------------------------------------------------------------
In a couple of days you will also want to use more than one record, because
grouping certain constants together doesn't feel right, and contexts will get
bigger.
Also, you will want to use global variables and instead of a record you will
use an STRef to a record, and very small signatures will have in they're
context something like: (?opt :: STRef s Opt). And then you will need to
update some option fields, and you will want to use modifySTRef, and you will
need to create an applyField function to every damn field of the record...
So you will start asking
1. (when) will we have implicit contexts available?
2. wouldn't it be good to have, besides the data projection functions, some
update and apply field functions, automaticly derived when declaring the
data type? [yes am actually *asking* if *anyone agrees* with me? haven't had
any feedback on this one, so I don't no wether it is a good or just plain
dumb idea]
IMVHO, it is of extreme importance and *urgent* to get implicit parameters
right. This question about how to use this 'user difined constants' is a
*simple* question and should have a *very simple* and standard answer.
The same goes to global variables. We need them in certain situations and it
is supposed to be, and it can be from my experience, *simple*.
J.A.
From feuer@his.com Tue Mar 26 17:31:44 2002
From: feuer@his.com (Feuer)
Date: Tue, 26 Mar 2002 12:31:44 -0500
Subject: first-class modules
Message-ID: <3CA0B080.F9E26CB9@his.com>
A number of people have discussed the use of implicit parameters to
mimic global variables in Haskell. I am wondering if any have done the
same for a first-class module system such as that proposed by Shields
and Jones. It seems to make a tremendous amount of sense to do it that
way:
1. semi-constant values: Things that are calculated or input at the
beginning of the program could be handled by Main.main, which would pass
the results to the Second module, whose main function it could then
call. This seems much more natural than the implicit parameter approach
for this purpose.
2. others: whenever a group of functions are likely to share a
particular argument, they can be grouped in a module for greater
convenience. For example, a library of mathematical functions that
should all share a certain precision indicator could be grouped in a
module: the user of the module could instantiate it once with the right
precision and then use all the functions at that precision.
David Feuer
(please reply to dfeuer@cs.brown.edu)
From Jon.Fairbairn@cl.cam.ac.uk Tue Mar 26 18:07:36 2002
From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn)
Date: Tue, 26 Mar 2002 18:07:36 +0000
Subject: first-class modules
In-Reply-To: Your message of "Tue, 26 Mar 2002 12:31:44 EST."
<3CA0B080.F9E26CB9@his.com>
Message-ID: <19893.1017166056@cl.cam.ac.uk>
David Feuer wrote:
> A number of people have discussed the use of implicit parameters to
> mimic global variables in Haskell. I am wondering if any have done the=
> same for a first-class module system such as that proposed by Shields
> and Jones. It seems to make a tremendous amount of sense to do it that=
> way:
> =
> 1. semi-constant values: Things that are calculated
aren't a problem unless they depend on something that's
input at run-time.
> or input at the beginning of the program could be handled
> by Main.main, which would pass the results to the Second
> module, whose main function it could then call. This
> seems much more natural than the implicit parameter
> approach for this purpose.
This approach could also solve the "here document" question.
If we allow modules that define a value rather than names
and are in a range of different syntaxes, we can import the
value at the point of use. Having foreign values in files
would allow things such as the import of a font metric file
as a constant, which would be much nicer than reading it
from a file and having to pass it around.
J=F3n
From lmp@di.fct.unl.pt Tue Mar 26 18:00:02 2002
From: lmp@di.fct.unl.pt (Luis Moniz Pereira)
Date: Tue, 26 Mar 2002 18:00:02 +0000
Subject: Postdoc positions at CENTRIA
Message-ID: <3CA0B722.3C22958B@di.fct.unl.pt>
Please post
The Research Center for Artificial Intelligence (CENTRIA) at the
Universidade Nova de Lisboa (UNL) offers as of now several
post-doctoral research positions, in the areas of:
Machine Learning.
Neural Networks.
Data Mining.
Text Mining.
each for nine months to a year (yearly extensions possible), starting
immediately or within the next few months.
Candidates must hold a doctoral degree and may apply by sending us their
CV and other relevant information, namely regarding availability date
and duration of stay AS SOON AS POSSIBLE. Salaries are negotiable,
starting at 1,500 Euros net per month, up to 2,000 Euros.
Further information at: http://centria.di.fct.unl.pt/~nmm/PostDoc/
--
Professor Luis Moniz Pereira http://centria.di.fct.unl.pt/~lmp/
Director AI Centre CENTRIA http://centria.fct.unl.pt/
Departamento de Informatica Ph (+351) 21 294 8533 Fax 21 294 8541
Universidade Nova de Lisboa Secretary: (+351) 21 294 8536
2829-516 Caparica, Portugal Email: lmp@di.fct.unl.pt
From jadrian@mat.uc.pt Tue Mar 26 20:02:59 2002
From: jadrian@mat.uc.pt (Jorge Adriano)
Date: Tue, 26 Mar 2002 20:02:59 +0000
Subject: first-class modules
In-Reply-To: <3CA0B080.F9E26CB9@his.com>
References: <3CA0B080.F9E26CB9@his.com>
Message-ID: <20020326200610.AD2844220B5@www.haskell.org>
> On Tuesday 26 March 2002 17:31, you wrote:
> A number of people have discussed the use of implicit parameters to
> mimic global variables in Haskell. I am wondering if any have done the
> same for a first-class module system such as that proposed by Shields
> and Jones. It seems to make a tremendous amount of sense to do it that
> way:
>
> 1. semi-constant values: Things that are calculated or input at the
> beginning of the program could be handled by Main.main, which would pass
> the results to the Second module, whose main function it could then
> call. This seems much more natural than the implicit parameter approach
> for this purpose.
It seems nice for that *specific* purpose. What I like about implicit
parameters is the fact that they are a more general approach, and that is IMO
very important.
You, might for instance, decide that maybe it would be a good idea to, under
certain specific conditions, change one of those "semi-constant" values.
Imagine some AI algortithm, you iterate some learning function 'learnF' over
and over again. Now you realize that under certain conditions maybe the
learning rate (used in learnF) should be changed.
Chaging your implementation would be easy with implicit parameters.
J.A.
From mpool02@multiparadigm.org Wed Mar 27 07:07:29 2002
From: mpool02@multiparadigm.org (MPOOL 2002)
Date: Wed, 27 Mar 2002 08:07:29 +0100
Subject: MPOOL 2002 - FINAL CALL FOR PAPERS
Message-ID: <3CA16FB1.52B0189E@multiparadigm.org>
We apologize if you have received this CfP multiple times.
--------------------------------------------------------------------
CALL FOR PARTICIPATION
Workshop on
MULTIPARADIGM PROGRAMMING WITH OO LANGUAGES
(MPOOL 2002, June 11)
at the
EUROPEAN CONFERENCE ON OBJECT-ORIENTED PROGRAMMING
(ECOOP 2002, Malaga, Spain, June 10-14)
While OO has become ubiquitously employed for design, implementation,
and even conceptualization, many practitioners recognize the concomitant
need for other programming paradigms according to problem domain. We seek
answers to the question of how to address the need for other programming
paradigms in the general context of OO languages.
Specific areas of interest include, but are not limited to:
* non-OO programming with OO languages;
* merging functional/logic/OO/other programs (language crossbinding);
* non-OO programming at the meta level (e.g. template metaprogramming)
* module systems vs. object systems
* OO design patterns and their relation to functional patterns
* type system relationships across languages
* theoretical foundations of multiparadigm programming with OO languages
The deadline for the submission of a 5+ pages abstract is
8 April 2002
Prospective authors are invited to submit abstracts in PDF or postscript.
Any common encoding (MIME or uuencode) or compression (zip, gzip) is
acceptable.
Authors of accepted papers are responsible for submitting the final
version using the Springer LNCS LaTeX template
(http://www.springer.de/comp/lncs/authors.html) by May 2, to ensure
prompt printing of the proceedings.
Submission and email correspondence to mpool02@multiparadigm.org.
ORGANIZATION
This workshop is a joint organization by the John von Neumann Institute for
Computing (NIC) at Research Centre Juelich, Los Alamos National Laboratory,
and the Georgia Institute of Technology.
PROGRAM COMMITTEE
Gerald Baumgartner (Ohio State University, Ohio, USA)
Kei Davis (Los Alamos National Laboratory, New Mexico, USA)
Jaakko Jaervi (Indiana University, Indiana, USA)
Peter Van Roy (Universite catholique de Louvain, Belgium)
Yannis Smaragdakis (Georgia Institute of Technology, Georgia, USA)
Joerg Striegnitz (John von Neumann Institute for Computing, Germany)
FURTHER INFORMATION
MPOOL'2002: http://www.multiparadigm.org/mpool2002
ECOOP'2002: http://ecoop2002.lcc.uma.es
From romildo@uber.com.br Wed Mar 27 15:30:05 2002
From: romildo@uber.com.br (=?iso-8859-1?Q?Jos=E9?= Romildo Malaquias)
Date: Wed, 27 Mar 2002 12:30:05 -0300
Subject: Mutable arrays in Haskell 98
Message-ID: <20020327153005.GA14181@darling.home.br>
Hello.
I would like to use muttable arrays in Haskell 98, with the GHC
_and_ NHC98 compilers. By muttable arrays I mean arrays with
in-place updates, as with the MArray arrays (which are not
Haskell 98 conformant) found in GHC. Is such array implmentation
available?
Regards.
Romildo
--
Prof. José Romildo Malaquias Departamento de Computação
http://iceb.ufop.br/~romildo Universidade Federal de Ouro Preto
romildo@iceb.ufop.br Brasil
romildo@uber.com.br
From Malcolm.Wallace@cs.york.ac.uk Wed Mar 27 15:58:46 2002
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Wed, 27 Mar 2002 15:58:46 +0000
Subject: Mutable arrays in Haskell 98
In-Reply-To: <20020327153005.GA14181@darling.home.br>
References: <20020327153005.GA14181@darling.home.br>
Message-ID: <20020327155846.247487df.Malcolm.Wallace@cs.york.ac.uk>
José Romildo Malaquias writes:
> I would like to use muttable arrays in Haskell 98, with the GHC
> _and_ NHC98 compilers. By muttable arrays I mean arrays with
> in-place updates, as with the MArray arrays (which are not
> Haskell 98 conformant) found in GHC. Is such array implmentation
> available?
Both compilers have libraries supporting the `IOArray' type,
implemented with in-place update, although obviously the operations
must be threaded through the IO monad.
module IOExtras -- called IOExts in ghc
( ...
, IOArray -- data IOArray ix elt -- mutable arrays
, newIOArray -- :: Ix ix => (ix,ix) -> elt -> IO (IOArray ix elt)
, boundsIOArray -- :: Ix ix => IOArray ix elt -> (ix, ix)
, readIOArray -- :: Ix ix => IOArray ix elt -> ix -> IO elt
, writeIOArray -- :: Ix ix => IOArray ix elt -> ix -> elt -> IO ()
, freezeIOArray -- :: Ix ix => IOArray ix elt -> IO (Array ix elt)
, module Ix -- re-export Ix for the benefit of IOArrays
-- instance Eq (IOArray ix elt)
)
Regards,
Malcolm
From jadrian@mat.uc.pt Wed Mar 27 16:29:59 2002
From: jadrian@mat.uc.pt (Jorge Adriano)
Date: Wed, 27 Mar 2002 16:29:59 +0000
Subject: Little problem
In-Reply-To:
References:
Message-ID: <20020327163346.0ABEA42221A@www.haskell.org>
[moving to haskell-cafe]
> Hello
> I have little problem. I want to solve this equation
>
> f(n-1) = f(n)+n
> f(6)=6
This is a simple recursive definition..
By the way, are you sure you didn't meant:
f(n-1)=f(n)+(n-1)
> => f(2)=?
Not exactly sure what you're after here. You could simply do:
f(2)
=f(3)+3
=f(4)+4+3
=f(5)+5+4+3
=f(6)+6+5+4+3
=6+6+5+4+3
=24
anyway it's simple to see, or even prove by induction, that
f(n) = (\sum_{i=n+1}^{7} i) -1 = (n+8)(7-n)/2 - 1
If I'm rigth and you're formula is suposed to be
f(n-1) = f(n)+n
it is even easier.
J.A.
From romildo@uber.com.br Wed Mar 27 23:16:44 2002
From: romildo@uber.com.br (=?iso-8859-1?Q?Jos=E9?= Romildo Malaquias)
Date: Wed, 27 Mar 2002 20:16:44 -0300
Subject: Mutable arrays in Haskell 98
In-Reply-To: <20020327155846.247487df.Malcolm.Wallace@cs.york.ac.uk>
References: <20020327153005.GA14181@darling.home.br> <20020327155846.247487df.Malcolm.Wallace@cs.york.ac.uk>
Message-ID: <20020327231644.GA8755@darling.home.br>
On Wed, Mar 27, 2002 at 03:58:46PM +0000, Malcolm Wallace wrote:
> José Romildo Malaquias writes:
>
> > I would like to use muttable arrays in Haskell 98, with the GHC
> > _and_ NHC98 compilers. By muttable arrays I mean arrays with
> > in-place updates, as with the MArray arrays (which are not
> > Haskell 98 conformant) found in GHC. Is such array implmentation
> > available?
>
> Both compilers have libraries supporting the `IOArray' type,
> implemented with in-place update, although obviously the operations
> must be threaded through the IO monad.
>
> module IOExtras -- called IOExts in ghc
> ( ...
> , IOArray -- data IOArray ix elt -- mutable arrays
> , newIOArray -- :: Ix ix => (ix,ix) -> elt -> IO (IOArray ix elt)
> , boundsIOArray -- :: Ix ix => IOArray ix elt -> (ix, ix)
> , readIOArray -- :: Ix ix => IOArray ix elt -> ix -> IO elt
> , writeIOArray -- :: Ix ix => IOArray ix elt -> ix -> elt -> IO ()
> , freezeIOArray -- :: Ix ix => IOArray ix elt -> IO (Array ix elt)
>
> , module Ix -- re-export Ix for the benefit of IOArrays
> -- instance Eq (IOArray ix elt)
> )
I am having difficults in defining a map function over an IOArray object.
My attempt was
mapIOArray :: Ix ix => (a -> b) -> IOArray ix a -> IO (IOArray ix b)
mapIOArray f v = do w <- newIOArray bounds ????????????
mapping w (range bounds)
where
bounds = boundsIOArray v
mapping w (i:is) = do x <- readIOArray v i
writeIOArray w i (f x)
mapping w is
mapping w [] = return w
But I do not know what to use to replace the ????????????. Is there
a polymorphic value in Haskell that can be of any type?
Is it indeed possible to have such function without resorting to
another intermediate data structure (like a list)?
Regards,
Romildo
--
Prof. José Romildo Malaquias Departamento de Computação
http://iceb.ufop.br/~romildo Universidade Federal de Ouro Preto
romildo@iceb.ufop.br Brasil
romildo@uber.com.br
From mtullsen@cse.ogi.edu Wed Mar 27 23:41:52 2002
From: mtullsen@cse.ogi.edu (Mark Tullsen)
Date: Wed, 27 Mar 2002 15:41:52 -0800
Subject: Mutable arrays in Haskell 98
References: <20020327153005.GA14181@darling.home.br> <20020327155846.247487df.Malcolm.Wallace@cs.york.ac.uk> <20020327231644.GA8755@darling.home.br>
Message-ID: <3CA258C0.9E53EBF6@cse.ogi.edu>
José Romildo Malaquias wrote:
> ...
> My attempt was
>
> mapIOArray :: Ix ix => (a -> b) -> IOArray ix a -> IO (IOArray ix b)
> mapIOArray f v = do w <- newIOArray bounds ????????????
> mapping w (range bounds)
> where
> bounds = boundsIOArray v
> mapping w (i:is) = do x <- readIOArray v i
> writeIOArray w i (f x)
> mapping w is
> mapping w [] = return w
>
> But I do not know what to use to replace the ????????????. Is there
> a polymorphic value in Haskell that can be of any type?
>
Yes, use "undefined" from the Prelude:
undefined :: a
undefined | False = undefined
- Mark
From sas02@clip.dia.fi.upm.es Thu Mar 28 01:30:07 2002
From: sas02@clip.dia.fi.upm.es (sas02@clip.dia.fi.upm.es)
Date: Thu, 28 Mar 2002 02:30:07 +0100
Subject: 2002 Static Analysis Symposium (SAS'02) Call for Papers
Message-ID: <200203280130.g2S1U7B30799@clip.dia.fi.upm.es>
(Apologies for multiple postings)
----------------------------------------------------------------------
CALL FOR PAPERS (SAS'02)
The 9th International Static Analysis Symposium
September 17 - 20 2002, Madrid, Spain
http://clip.dia.fi.upm.es/SAS02
Submission deadline: May 5, 2002
----------------------------------------------------------------------
Static Analysis is increasingly recognized as a fundamental tool
for high performance implementations and verification systems of
high-level programming languages. The series of Static Analysis
Symposia has served as the primary venue for presentation of
theoretical, practical, and application advances in the area.
The Ninth International Static Analysis Symposium (SAS'02) will be
held at the Technical University of Madrid, do-located with
Logic-based Program Development and Transformation (LOPSTR'02) and the
APPIA-GULP-PRODE Joint Conference on Declarative Programming
(AGP'02). Previous symposia were held in Paris, Santa Barbara, Venice,
Pisa, Paris, Aachen, Glasgow and Namur.
The technical program for SAS'02 will consist of invited lectures,
tutorials, panels, presentations of refereed papers, and software
demonstrations. Contributions are welcome on all aspects of Static
Analysis, including, but not limited to:
* abstract interpretation, * data flow analysis,
* verification systems, * program specialization,
* abstract domains, * optimizing compilers,
* theoretical frameworks, * type inference,
* abstract model checking, * complexity analysis,
* abstract testing, * security analysis.
Submissions can address any programming paradigm, including
concurrent, constraint, functional, imperative, logic and
object-oriented programming. Survey papers that present some aspect
of the above topics with a new coherence are also welcome.
Papers must describe original work, be written and presented in
English, and must not substantially overlap with papers that have been
published or that are simultaneously submitted to a journal or a
conference with refereed proceedings.
Submission Instructions
-----------------------
All submissions must be performed electronically at
http://clip.dia.fi.upm.es/SAS02/submission.html. Submitted papers
should be at most 15 pages excluding bibliography and well-marked
appendices. Program committee members are not required to read the
appendices, and thus papers should be intelligible without them. The
proceedings will be published by Springer-Verlag in the Lecture Notes
in Computer Science series (see
http://www.springer.de/comp/lncs/authors.html for the LNCS author
instructions). Thus, adhering to that style already in the submission
is strongly encouraged. Papers should be submitted either in
PostScript or PDF format and they should be interpretable by
Ghostscript or Acrobat Reader. Papers must be printable on either A4
paper or US letter, and preferably on both.
Important Dates
---------------
May 5, 2002 Submission deadline
June 10, 2002 Notification
June 30, 2002 Final version
Sept 17-20, 2002 SAS'02
Program Committee
-----------------
Manuel Hermenegildo (Chair) Technical University of Madrid, Spain
German Puebla (Co-chair) Technical University of Madrid, Spain
Radhia Cousot Ecole Polytechnique, France
Saumya Debray The University of Arizona, USA
Manuel Fahndrich Microsoft Research, USA
Roberto Giacobazzi Univerity of Verona, Italy
Chris Hankin Imperial College, UK
Giorgio Levi Univerity of Pisa, Italy
Kim Marriott Monash University, Australia
Alan Mycroft Cambridge University, United Kingdom
Ganesan Ramalingam IBM T.J. Watson Research Center, USA
Martin Rinard Massachusetts Institute of Technology, USA
Shmuel Sagiv Tel-Aviv Univerisity, Israel
Reinhard Wilhelm Universitat des Saarlandes, Germany
Contact Info
------------
Email: sas02@clip.dia.fi.upm.es
Fax: + 34 91 352 4819
Phone: + 34 91 336 7448
Post:
Manuel Hermenegildo (Ref.: SAS'02)
Facultad de Informatica
Universidad Politecnica de Madrid
28660 Boadilla del Monte
Madrid, Spain
----------------------------------------------------------------------
--
From whitejbiii@ornl.gov Thu Mar 28 15:37:48 2002
From: whitejbiii@ornl.gov (James B. White III (Trey))
Date: Thu, 28 Mar 2002 10:37:48 -0500
Subject: ">>" and "do" notation
Message-ID: <3CA338CD.D807BA87@ornl.gov>
I recently discovered that Hugs converts "do" notation as follows.
do {e;stmts} = e >>= \_ -> do {stmts}
To me, this is inconsistent with the definition given in the Haskell 98 Report.
do {e;stmts} = e >> do {stmts}
It "hard wires" the default definition of ">>" into "do" notation.
If you provide your own definition of ">>", which is completely legal in
Haskell, the "do" translation in Hugs disagrees with the definition in
the Report. In other words, the following two statements produce
different results.
do {e;stmts} = e >>= \_ -> do {stmts}
do {e;stmts} = e >> do {stmts}
When I reported this as a bug, I got responses stating that the
definition of "do {e;stmts}" in the Report is merely a suggestion, and
that the default definition of ">>" in the "Monad" class is a law of
Monads and should not be redefined in instances.
I strongly disagree with these responses. I think the default definition
of ">>" is just that, a default, and not a law. This view is consistent
with every other default definition in a class; it is there for
convenience but may be redefined. If it is a law, why are users given
the power to change it!
Also, I think that the Report *specifies* the translation of "do" to
">>", not merely suggests it.
This is the only interpretation that makes sense to me. The above
claims---that the contents of the Report are mere suggestions and that
default definitions are laws---baffle me. I beg the community to
reassure me or enlighten me.
If my thoughts are wrong, then I assert that the Report needs revision.
">>" should no longer be a class function with a default value that can
be changed; it should be syntactic sugar built into Haskell, like "do"
notation.
Let me just restate my argument for emphasis: a Monad instance should be
able to define its own ">>" operator, and "do" notation should honor
this redefinition!
--
James B. White III (Trey)
Center for Computational Sciences
Oak Ridge National Laboratory
whitejbiii@ornl.gov
From simonpj@microsoft.com Thu Mar 28 15:28:46 2002
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 28 Mar 2002 07:28:46 -0800
Subject: Do-notation
Message-ID: <1113DDB24D4A2841951BFDF86665EE1901041C4F@RED-MSG-10.redmond.corp.microsoft.com>
James White has noticed that the draft Haskell 98 report
gives the following translation for do-notation:
do {e} =3D e
do {e;stmts} =3D e >> do {stmts}=20
do {p <- e; stmts} =3D let ok p =3D do {stmts}
ok _ =3D fail "..."
in e >>=3D ok =20
On the face of it, that makes do-notation depend on the definitions of
both (>>) and (>>=3D) in the monad. This makes a difference if someone
defines an instance of the Monad class in which (>>) is not defined to
be (\x y -> x >>=3D \_ -> y).
I am certain that was not the intention of the authors. So one
possibility is to change the second line to read
do {e;stmts} =3D e >>=3D (\ _ -> do {stmts})
and that is what I *propose* to do. =20
However, James implies that in his monad (>>) has a different meaning
than its usual one, and Haskell 98 allows that because (>>) is one of
the class operations (not a good design choice I think). I'm quite
reluctant to make the meaning of do-notation dependent on such
differences. James, can you convince us that doing so would be a good
idea?
Simon
=20
From whitejbiii@ornl.gov Thu Mar 28 16:20:50 2002
From: whitejbiii@ornl.gov (James B. White III (Trey))
Date: Thu, 28 Mar 2002 11:20:50 -0500
Subject: Do-notation
References: <1113DDB24D4A2841951BFDF86665EE1901041C4F@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <3CA342E4.DDECC8E9@ornl.gov>
Simon Peyton-Jones wrote:
> However, James implies that in his monad (>>) has a different meaning
> than its usual one, and Haskell 98 allows that because (>>) is one of
> the class operations (not a good design choice I think). I'm quite
> reluctant to make the meaning of do-notation dependent on such
> differences. James, can you convince us that doing so would be a good
> idea?
I didn't see this before sending off my previous rant. My apologies.
Having separate definitions for ">>=" and ">>" is more flexible. With
the definition of a default for ">>" in the Monad class, having them
separate is no less convenient. More flexible, no less
convenient---where is the design flaw? I thought it was a design
triumph, fully in the spirit of elegance I associate with Haskell.
Are there Monad laws that this breaks? If not, why impose an unnecessary constraint?
Let me describe my practical motivation for a separate definition for
">>". I am experimenting with using Haskell to build program generators
for embedded domain-specific languages. The goal is to generate
high-performance Fortran codes from high-level specifications.
I am using a Monad to hold the state of the generation. One thing
maintained in the state is a list of declared variables and a list of
busy, or in-scope, variables. The generator automatically adds variable
declarations as needed.
By differentiating between monadic statements that return an argument
(>>=) and those that don't (>>), the generator can easily determine when
variables go out of scope. Within the definition of ">>", it can free
these variables (in a logical, not physical, sense) to be reused. This
is critical because it allows me to generate code using large temporary
arrays efficiently.
As far as I can tell, this use of ">>" breaks no monad laws.
In Hugs, it works fine if I use ">>" directly instead of "do". For the
aesthetic acceptance of my user base, I need it to work with "do" notation.
--
James B. White III (Trey)
Center for Computational Sciences
Oak Ridge National Laboratory
whitejbiii@ornl.gov
From olaf@cs.york.ac.uk Thu Mar 28 16:27:19 2002
From: olaf@cs.york.ac.uk (Olaf Chitil)
Date: Thu, 28 Mar 2002 16:27:19 +0000
Subject: Do-notation
References: <1113DDB24D4A2841951BFDF86665EE1901041C4F@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <3CA34467.24B420F9@cs.york.ac.uk>
> I am certain that was not the intention of the authors. So one
> possibility is to change the second line to read
>
> do {e;stmts} = e >>= (\ _ -> do {stmts})
>
> and that is what I *propose* to do.
>
> However, James implies that in his monad (>>) has a different meaning
> than its usual one, and Haskell 98 allows that because (>>) is one of
> the class operations (not a good design choice I think). I'm quite
> reluctant to make the meaning of do-notation dependent on such
> differences.
I disagree. Hugs should be changed, not the report. In my opinion (>>)
is a class operation, because there may be more efficient
implementations of (>>) than the default one (\x y -> x >>= \_ -> y).
The do notation should profit from a more efficient implementation.
I do think that James steps on very dangerous ground if his
implementation of (>>) is semantically different from (\x y -> x >>= \_
-> y). This semantic equality is a law of the monad class, that users
expect to hold. However, the language (implementation) cannot enforce
it; in particular, compilers cannot use such laws for optimisations. The
programmer has the freedom to break such laws.
The situation is similar with classes such as Eq and Ord. You expect x
/= y == not (x == y), but it is not enforced.
Actually, the report currently doesn't say that the given default
definitions are laws which are expected to hold (except where a comment
says otherwise, see class Enum). I think such a statement should be
added to the report.
Happy Easter,
Olaf
--
OLAF CHITIL,
Dept. of Computer Science, The University of York, York YO10 5DD, UK.
URL: http://www.cs.york.ac.uk/~olaf/
Tel: +44 1904 434756; Fax: +44 1904 432767
From nilsson@cs.yale.edu Thu Mar 28 16:48:25 2002
From: nilsson@cs.yale.edu (nilsson@cs.yale.edu)
Date: Thu, 28 Mar 2002 11:48:25 -0500
Subject: Do-notation
References: <1113DDB24D4A2841951BFDF86665EE1901041C4F@RED-MSG-10.redmond.corp.microsoft.com> <3CA34467.24B420F9@cs.york.ac.uk>
Message-ID: <3CA34959.81A5C949@cs.yale.edu>
Olaf Chitil wrote:
> > I am certain that was not the intention of the authors. So one
> > possibility is to change the second line to read
> >
> > do {e;stmts} = e >>= (\ _ -> do {stmts})
> >
> > and that is what I *propose* to do.
> >
> > However, James implies that in his monad (>>) has a different meaning
> > than its usual one, and Haskell 98 allows that because (>>) is one of
> > the class operations (not a good design choice I think). I'm quite
> > reluctant to make the meaning of do-notation dependent on such
> > differences.
>
> I disagree. Hugs should be changed, not the report. In my opinion (>>)
> is a class operation, because there may be more efficient
> implementations of (>>) than the default one (\x y -> x >>= \_ -> y).
> The do notation should profit from a more efficient implementation.
I agree with Olaf (and James).
Incidentally, similar concerns occur in the context of the arrows framework.
Ross Paterson, in response to a request from us at Yale, recently changed
some derived arrow combinators into default methods of the arrow classes in
his implementation of the framework to allow more efficient, instance
specific, implementations of these combinators. Our request was prompted
by our work of (A)FRP, an embedded language.
/Henrik
--
Henrik Nilsson
Yale University
Department of Computer Science
nilsson@cs.yale.edu
From sof@galois.com Thu Mar 28 17:46:59 2002
From: sof@galois.com (Sigbjorn Finne)
Date: Thu, 28 Mar 2002 09:46:59 -0800
Subject: catch (fail "...")
Message-ID: <010b01c1d680$8f6ce180$8132a8c0@sofxp>
Simon Peyton-Jones simonpj@microsoft.com writes:
>
> This is an inconsistency that was fixed in the revised Haskell98=20
> report (Apr 2001). See
> http://research.microsoft.com/~simonpj/haskell98-revised
>
> In the bug list look for Page 90.
>
> It looks as though Hugs hasn't quite caught up with this change.
Yes, the Feb 2001 release (which Brian was/is using) unfortunately
didn't foresee the future change to the Report :-)
The current release, Dec 2001, does the prescribed thing.
--sigbjorn
From ross@soi.city.ac.uk Thu Mar 28 18:44:39 2002
From: ross@soi.city.ac.uk (Ross Paterson)
Date: Thu, 28 Mar 2002 18:44:39 +0000
Subject: Do-notation
In-Reply-To: <3CA34959.81A5C949@cs.yale.edu>
References: <1113DDB24D4A2841951BFDF86665EE1901041C4F@RED-MSG-10.redmond.corp.microsoft.com> <3CA34467.24B420F9@cs.york.ac.uk> <3CA34959.81A5C949@cs.yale.edu>
Message-ID: <20020328184438.GA2702@soi.city.ac.uk>
On Thu, Mar 28, 2002 at 11:48:25AM -0500, nilsson@cs.yale.edu wrote:
> Incidentally, similar concerns occur in the context of the arrows framework.
> Ross Paterson, in response to a request from us at Yale, recently changed
> some derived arrow combinators into default methods of the arrow classes in
> his implementation of the framework to allow more efficient, instance
> specific, implementations of these combinators. Our request was prompted
> by our work of (A)FRP, an embedded language.
Yes, but in that case the specific implementations are required to be
denotationally equal to the default versions. And surely that was
the original intention here. Section 6.3.6 of the Report needs an
additional equation:
m >> k = m >>= \_ -> k
Then Hugs and GHC would be correct but suboptimal.
There's a similar glitch in the claim in section 3.5 of the Report that
(+ (- exp)) is a substitute for (\x -> x - exp), which is true only if
x - y = x + negate y
In that case the claim could be simply dropped.
From olaf@cs.york.ac.uk Thu Mar 28 19:10:54 2002
From: olaf@cs.york.ac.uk (Olaf Chitil)
Date: Thu, 28 Mar 2002 19:10:54 +0000
Subject: Do-notation
References: <1113DDB24D4A2841951BFDF86665EE1901041C4F@RED-MSG-10.redmond.corp.microsoft.com> <3CA34467.24B420F9@cs.york.ac.uk> <3CA34959.81A5C949@cs.yale.edu> <20020328184438.GA2702@soi.city.ac.uk>
Message-ID: <3CA36ABE.B5D61A5F@cs.york.ac.uk>
Ross Paterson wrote:
> Yes, but in that case the specific implementations are required to be
> denotationally equal to the default versions. And surely that was
> the original intention here. Section 6.3.6 of the Report needs an
> additional equation:
>
> m >> k = m >>= \_ -> k
>
> Then Hugs and GHC would be correct but suboptimal.
I agree that this equation should be in the report, but note that there
is no *requirement* that the monad laws hold for user defined instances.
The report merely states that they *should* hold. Maybe we should be
more clear what this word *should* means. I understand it as meaning
that the term "monad" suggests that these laws hold, that a programmer
should have very good reasons for breaking any of them and if a law is
broken a big warning should be attached to the code, because any user of
a monad expects it to fulfill the laws. However, because the laws cannot
be checked by an implementation, no implementation is allowed to make
use of them. In particular, the laws may accidentally have been broken
and if an implementation makes use of the laws, then the behaviour of
the resulting computation may be completely incomprehensible. (Just to
make clear that I don't advocate breaking these laws; but then I'm not a
fan of monads anyway...)
Olaf
--
OLAF CHITIL,
Dept. of Computer Science, The University of York, York YO10 5DD, UK.
URL: http://www.cs.york.ac.uk/~olaf/
Tel: +44 1904 434756; Fax: +44 1904 432767
From nilsson@cs.yale.edu Thu Mar 28 19:15:20 2002
From: nilsson@cs.yale.edu (nilsson@cs.yale.edu)
Date: Thu, 28 Mar 2002 14:15:20 -0500
Subject: Do-notation
References: <1113DDB24D4A2841951BFDF86665EE1901041C4F@RED-MSG-10.redmond.corp.microsoft.com> <3CA34467.24B420F9@cs.york.ac.uk> <3CA34959.81A5C949@cs.yale.edu> <20020328184438.GA2702@soi.city.ac.uk>
Message-ID: <3CA36BC8.FE6C8B7F@cs.yale.edu>
> Yes, but in that case the specific implementations are required to be
> denotationally equal to the default versions.
Yes, obviously. My only point was that I believe (>>) should remain
a class operation.
/Henrik
--
Henrik Nilsson
Yale University
Department of Computer Science
nilsson@cs.yale.edu
From hdaume@ISI.EDU Thu Mar 28 21:27:42 2002
From: hdaume@ISI.EDU (Hal Daume III)
Date: Thu, 28 Mar 2002 13:27:42 -0800 (PST)
Subject: Z_n in Haskell
Message-ID:
Suppose I want to define integers modulo n, I could do this something
like:
data Zn = Zn Integer Integer -- modulus, number
instance Num Zn where
(Zn m1 n1) + (Zn m2 n2)
| m1 == m2 = Zn m1 (n1 + n2 `mod` m1)
| otherwise= error "differing moduli"
...etc...
However, I'd really like it if, say, addition on Zn-s of different
"n" values were caught by the typechecker and disallowed. One solution to
this problem would be to do something like:
class Modulus m where modulus :: T m -> Integer
data Zn m = Zn (T m) Integer
instance Modulus m => Num (Zn m) where
(Zn m1 n1) + (Zn m2 n2) =
(Zn m1 ((n1 + n2) `mod` (modulus m1)))
data T a = T
data Mod5
data Mod7
instance Modulus (Mod5) where modulus _ = 5
instance Modulus (Mod7) where modulus _ = 7
then we get:
Modulus> (Zn (T :: T Mod5) 3) + (Zn (T :: T Mod5) 4)
2
but it fails when the moduli are different:
Modulus> (Zn (T :: T Mod5) 3) + (Zn (T :: T Mod7) 4)
Ambiguous type variable(s) `a' in the constraint `Show a'
arising from use of `print' at
In a 'do' expression pattern binding: print it
:1:
Couldn't match `Mod7' against `Mod5'
Expected type: T Mod7
Inferred type: T Mod5
In an expression with a type signature: T :: T Mod7
In the first argument of `Zn', namely `(T :: T Mod7)'
Unfortunately, this solution isn't very pretty. We have to define a new
datatype for each modulus and make it an instance of Modulus. Is there a
better way to do this?
- Hal
--
Hal Daume III
"Computer science is no more about computers | hdaume@isi.edu
than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
From ken@digitas.harvard.edu Thu Mar 28 21:43:59 2002
From: ken@digitas.harvard.edu (Ken Shan)
Date: Thu, 28 Mar 2002 13:43:59 -0800
Subject: Z_n in Haskell
In-Reply-To:
References:
Message-ID: <20020328214359.GB2215@ccshan.stanford.edu>
--SkvwRMAIpAhPCcCJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2002-03-28T13:27:42-0800, Hal Daume III wrote:
> Suppose I want to define integers modulo n, I could do this something
Check out the message "Modular arithmetic" earlier on haskell-cafe
(http://www.haskell.org/pipermail/haskell-cafe/2001-August/002132.html)
and its followup...
--=20
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Dyer Honeycutt
3192 Anchor Drive
Southside, AL 35907-0866
--SkvwRMAIpAhPCcCJ
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8o46ezjAc4f+uuBURAvKwAJ9Dv6zigbDbu9B3eOoTwoi7msW9MACgj+l2
POwnhFy8vC7jJuXpLFQ+MU0=
=9+XM
-----END PGP SIGNATURE-----
--SkvwRMAIpAhPCcCJ--
From wolfgang@jeltsch.net Thu Mar 28 23:19:14 2002
From: wolfgang@jeltsch.net (Wolfgang Jeltsch)
Date: Fri, 29 Mar 2002 00:19:14 +0100
Subject: ">>" and "do" notation
In-Reply-To: =?iso-8859-1?Q?=3C20020329000911=2EA1832?=
=?iso-8859-1?Q?=40localhost=3E=3B_from_wolfgang=40jeltsch=2Enet_on_Fre=2C?=
=?iso-8859-1?Q?_M=E4r?= 29, 2002 at 00:09:11 +0100
References: <3CA338CD.D807BA87@ornl.gov> <20020329000911.A1832@localhost>
Message-ID: <20020329001914.C1832@localhost>
On Thursday, March 28, 2002, 16:37 CET James B. White III wrote:
> [...]
> I think the default definition of ">>" is just that, a default, and not a
> law.
I suppose, a >> b = a >>= \_ -> b is intended to be a law. This would mean
that every redefined (>>) would have to obey this law.
> [...]
> If it is a law, why are users given the power to change it!
For performance reasons, I would suppose.
> Also, I think that the Report *specifies* the translation of "do" to ">>",
> not merely suggests it.
The report specifies certain identities and suggests to use these identities
for translations into the kernel. If it is also a law that a >> b and a >>=
\_ -> b are identical even with respect to laziness then, I think, a
conforming Haskell implementation could use the latter instead of the former
to realize do expressions. But I would prefer implementations using (>>).
> [...]
> ">>" should no longer be a class function with a default value that can be
> changed; it should be syntactic sugar built into Haskell, like "do"
> notation.
It shouldn't be syntactic suger but at most an operator which does not belong
to the monad class. One could define (>>) just as an ordinary function
instead of a class member.
> [...]
By the way, why uses the report the complicated looking \_ -> b instead of
just const b.
Wolfgang
From oleg@pobox.com Fri Mar 29 04:28:28 2002
From: oleg@pobox.com (oleg@pobox.com)
Date: Thu, 28 Mar 2002 20:28:28 -0800 (PST)
Subject: Z_n in Haskell
Message-ID: <200203290428.UAA89829@adric.cs.nps.navy.mil>
The Z_n problem doesn't seem to be different from the problem of
arrays or bitvectors of a statically-checkable size.
If you prefer a decimal specification of the modulus, you may find the
following articles relevant.
Implementation of fixed-precision decimal types:
Main> BV D1 0
Bitvector of width 1 and value 0
Main> BV (D1,D2) 123
Bitvector of width 12 and value 123
Main> BV (D5,D7,D9) 31415
Bitvector of width 579 and value 31415
It appears that modulus in the Z_n problem plays the same role as the
bitvector width in the bitvector problem.
An attempt to perform an operation on bitvectors of different sizes results
in a compiler error:
Main> (BV (D1,D0) 10) `b_and` (BV (D1,D1) 7)
ERROR - Type error in application
*** Expression : b_and (BV (D1,D0) 10) (BV (D1,D1) 7)
*** Term : BV (D1,D0) 10
*** Type : BitVector (D1,D0)
*** Does not match : BitVector (D1,D1)
http://groups.google.com/groups?selm=7eb8ac3e.0202201753.473a5cb2%40posting.google.com
Arbitrary precision decimal types, e.g.:
Main> BV (D1 $ D2 $ D3 $ D4 $ D5 $ D6 $ D7 $ D8 $ D9 $ D0 $ D9 $ D8 $
D7 $ D6 $ D5 $ D4 $ D3 $ D2 $ D1 $ Dim) 1234567879
Bitvector of width 1234567890987654321 and value 1234567879
which are slightly more general and less convenient, are described in:
http://groups.google.com/groups?selm=7eb8ac3e.0202230221.62d98db8%40posting.google.com
Both implementations work in any Haskell-98 system. Multi-parameter
classes, existential types or other extensions are not needed.
From Jon.Fairbairn@cl.cam.ac.uk Fri Mar 29 10:28:34 2002
From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn)
Date: Fri, 29 Mar 2002 10:28:34 +0000
Subject: ">>" and "do" notation
In-Reply-To: Your message of "Fri, 29 Mar 2002 00:19:14 +0100."
<20020329001914.C1832@localhost>
Message-ID: <8102.1017397714@cl.cam.ac.uk>
Wolfgang Jeltsch wrote:
> It shouldn't be syntactic suger but at most an operator which does not =
belong
> to the monad class. One could define (>>) just as an ordinary function
> instead of a class member.
That sounds to me like the best idea so far. =
If (as a human reader of a programme) I see
do a <- thing1
and I notice (perhaps after some modifications) that a is
not present in , then I /really/ don't want a
change to
do thing1
to change the meaning of the programme.
J=F3n
From rjljr2@yahoo.com Fri Mar 29 13:43:40 2002
From: rjljr2@yahoo.com (Ronald Legere)
Date: Fri, 29 Mar 2002 05:43:40 -0800 (PST)
Subject: Type extensions
Message-ID: <20020329134340.69879.qmail@web10005.mail.yahoo.com>
Greetings.
I have decided to try and understand the type
system of haskell with extensions. As far as I
can tell, the following set of extensions has
been included, for example in ghc:
multiparameter type classes
constructor classes
existential types
explicit universal quantification
scoped type signatures
funtional dep?? Etc
There is probably some overlap, and
probably missed a few, as i do not understand
what all these things do! !
My question:
How do you get started learning all this? which of
these is the most important? Is there
a paper out there that explains most or all of these
extensions and why you would want them and HOW the
heck they work together?
Ron Legere
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/
From wolfgang@jeltsch.net Fri Mar 29 16:25:13 2002
From: wolfgang@jeltsch.net (Wolfgang Jeltsch)
Date: Fri, 29 Mar 2002 17:25:13 +0100
Subject: Type extensions
In-Reply-To: =?iso-8859-1?Q?=3C20020329134340=2E69879?=
=?iso-8859-1?Q?=2Eqmail=40web10005=2Email=2Eyahoo=2Ecom=3E=3B_from_rjljr2?=
=?iso-8859-1?Q?=40yahoo=2Ecom_on_Fre=2C_M=E4r?= 29, 2002 at 14:43:40 +0100
References: <20020329134340.69879.qmail@web10005.mail.yahoo.com>
Message-ID: <20020329172513.A2308@localhost>
On Friday, March 29, 2002, 14:43 CET Ronald Legere wrote:
> [...]
> As far as I can tell, the following set of extensions has been included,
> for example in ghc:
> multiparameter type classes
> constructor classes
Type classes can be seen as a specific kind of constructor classes because a
type can be seen as a type constructor with zero arguments. So the
constructor class concept is more general than the type class concept.
Constructor classes aren't an extension but belong to the Haskell 98
standard. They didn't belong to some older versions of the standard, however.
Normally, a type or constructor class has one parameter --- a type or a type
constructor respectively. The multi-parameter type class concept extends the
ordinary *type* class concept such that classes can have multiple parameters
but these arguments have to be types. The multi-parameter constructor class
concept allows mulitple class parameters which may be arbitrary type
constructors.
I think GHC used to implement only multi-parameter type classes while Hugs
implemented multi-parameter constructor classes. The newer GHC versions
implement multi-parameter constructor classes as well.
> [...]
> Is there a paper out there that explains most or all of these extensions
> and why you would want them and HOW the heck they work together?
I don't know of such a paper. There is several information distributed over
several documents. Concerning (single-parameter) constructor classes, you may
consult some Haskell 98 document, for instance the Gentle introduction to
Haskell or the Haskell report. Concerning the other things, you may, for
example, have a look at Simon Peyton Jones' Haskell stuff, referenced on
http://research.microsoft.com/users/simonpj/.
> [...]
Wolfgang
From whitejbiii@ornl.gov Sat Mar 30 05:39:59 2002
From: whitejbiii@ornl.gov (James B. White III (Trey))
Date: Sat, 30 Mar 2002 00:39:59 -0500
Subject: Unbind ">>"! (was Do-notation)
Message-ID: <3CA3CD21@webmail>
Here's my short manifesto on ">>" and "do" notation. It is based on the
precedent set with "negate", a precedent that I also support.
">>" should be a member of the "Monad" class, just as "negate" is a
member of the "Num" class!
Users should have the power to override the default definition of ">>", just
as they have the power to override the default definition of "negate"!
Haskell compilers should honor user definitions for ">>" and not
hard-wire ">>= \_ ->", just as they should honor user definitions for
"negate" and do not hardwire "0 - x"!
I have fixed the December 2001 release of Hugs to follow these principles
for ">>". (I haven't tested the fix exhaustively. It works on my programs.
Corrections appreciated!)
Here are the "diffs", before the fix followed by after:
connect.h:
74c74
< extern Name nameReturn, nameBind; /* for translating monad comps
*/
---
> extern Name nameReturn, nameBind, nameSequence; /* for
translating monad comps */
type.c:
85c85
< Name nameReturn, nameBind; /* for translating monad comps
*/
---
> Name nameReturn, nameBind, nameSequence; /* for
translating monad comps */
3267a3268
> nameSequence = linkName(">>");
compiler.c:
397c397
< * do { e; qs } => LETREC _h _ = [ e | qs ] in bind m exp _h
---
> * do { e; qs } => sequence m e qs
433,442c433,436
< case DOQUAL : { Cell hVar = inventVar();
< Cell ld = cons(pair(singleton(WILDCARD),
< transDo(m,e,qs1)),
< NIL);
< return ap(LETREC,
< pair(singleton(pair(hVar,ld)),
< ap(ap(ap(nameBind,
< m),
< translate(snd(q))),
< hVar)));
---
> case DOQUAL : {
> return ap(ap(ap(nameSequence, m),
> translate(snd(q))),
> transDo(m,e,qs1));
---
James B. White III (Trey)
Center for Computational Sciences
Oak Ridge National Laboratory
whitejbiii@ornl.gov
From ru@river.org Sun Mar 31 07:34:05 2002
From: ru@river.org (Richard Uhtenwoldt)
Date: Sat, 30 Mar 2002 23:34:05 -0800
Subject: ">>" and "do" notation
In-Reply-To: <8102.1017397714@cl.cam.ac.uk>
References: <20020329001914.C1832@localhost>
<8102.1017397714@cl.cam.ac.uk>
Message-ID:
>If (as a human reader of a programme) I see
>
>do a <- thing1
>
>
>and I notice (perhaps after some modifications) that a is
>not present in , then I /really/ don't want a
>change to
>
>do thing1
> ![](3D"http://www.weaver.com.cn/images/mail/weaver_log=)
![](3D"http://www.weaver.com.cn/images/mail/weaver_bot=)
