From simonpj@microsoft.com Thu Mar 1 11:21:54 2001
Date: Thu, 1 Mar 2001 03:21:54 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: FW: Pattern guards vs. case (was, unfortunately :Re: interesting
example of laziness/ghc optimisation)
| * * * Ketil Malde <ketil@ii.uib.no> wrote:
|
| > ut - the converse is not true, is it? I can write
| >
| > ... = case foo of
| > (Foo f) -> ...
| > (Bar b) -> ...
| >
| > ut I can't express that as a pattern-guarded expression, can I?
Check out http://research.microsoft.com/~simonpj/Haskell/guards.html
which is implemented in GHC. Thus
f x | Foo a <- x = ...
| Bar b <- x = ...
Simon
From ralf@cs.uu.nl Thu Mar 1 13:39:32 2001
Date: Thu, 01 Mar 2001 14:39:32 +0100
From: Ralf Hinze ralf@cs.uu.nl
Subject: Literate Programming in Haskell?
Patrik Jansson wrote:
> A tool I am using is Ralf Hinze's
>
> http://www.informatik.uni-bonn.de/~ralf/Literate.tar.gz
>
> http://www.informatik.uni-bonn.de/~ralf/Guide.ps.gz
>
> It transforms .lhs files (with some formatting commands in LaTeX-style
> comments) to LaTeX. Development based on this idea is something I would be
> willing to participate in as I already have a fair amount of Haskell
> code/articles (read: my PhD thesis;-) in this format.
>
> Maybe Ralf can say something about his views on further development of
> lhs2tex (copyright etc.) by other people (us?).
[Sorry for the delay.]
In principle, everyone can use and/or modify the program to adjust it to
her needs.
However, since I use lhs2text almost daily, I am willing to maintain the
program.
So if you have suggestions, proposals etc please let me know.
Cheers, Ralf
From conal@microsoft.com Thu Mar 1 23:15:17 2001
Date: Thu, 1 Mar 2001 15:15:17 -0800
From: Conal Elliott conal@microsoft.com
Subject: Literate Programming in Haskell?
Has anyone gotten Ralf's lhs2tex to work under Windows? I compiled it up
with GHC 4.08.1 and then GHC 4.08.2, on Windows 2k pro, and it appears to
fail in all of its file reads. Haven't yet isolated a small bug example to
report.
- Conal
-----Original Message-----
From: Ralf Hinze [mailto:ralf@cs.uu.nl]
Sent: Thursday, March 01, 2001 5:40 AM
To: Patrik Jansson
Cc: haskell-cafe@haskell.org
Subject: Re: Literate Programming in Haskell?
Patrik Jansson wrote:
> A tool I am using is Ralf Hinze's
>
> http://www.informatik.uni-bonn.de/~ralf/Literate.tar.gz
>
> http://www.informatik.uni-bonn.de/~ralf/Guide.ps.gz
>
> It transforms .lhs files (with some formatting commands in LaTeX-style
> comments) to LaTeX. Development based on this idea is something I would be
> willing to participate in as I already have a fair amount of Haskell
> code/articles (read: my PhD thesis;-) in this format.
>
> Maybe Ralf can say something about his views on further development of
> lhs2tex (copyright etc.) by other people (us?).
[Sorry for the delay.]
In principle, everyone can use and/or modify the program to adjust it to
her needs.
However, since I use lhs2text almost daily, I am willing to maintain the
program.
So if you have suggestions, proposals etc please let me know.
Cheers, Ralf
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
From dpt@math.harvard.edu Fri Mar 2 17:29:09 2001
Date: Fri, 2 Mar 2001 12:29:09 -0500
From: Dylan Thurston dpt@math.harvard.edu
Subject: Literate Programming in Haskell?
On Thu, Mar 01, 2001 at 02:39:32PM +0100, Ralf Hinze wrote:
> In principle, everyone can use and/or modify the program to adjust
> it to her needs. However, since I use lhs2text almost daily, I am
> willing to maintain the program. So if you have suggestions,
> proposals etc please let me know.
>From my cursory glance, it looked quite interesting, but I was
disturbed by the changes required in the TeX source that didn't refer
to Haskell at all. Is there any way to improve that situation?
Best,
Dylan Thurston
From wohlstad@cs.ucdavis.edu Thu Mar 8 05:29:30 2001
Date: Wed, 7 Mar 2001 21:29:30 -0800 (PST)
From: Eric Allen Wohlstadter wohlstad@cs.ucdavis.edu
Subject: Summer School on Functional Programming?
I was wondering if anyone knew if there was going to be a summer school on
functional programming this year. Also, where would I find information
about it? Thanks.
Eric Wohlstadter
UCDavis Software Engineering
From johanj@cs.uu.nl Thu Mar 8 10:46:09 2001
Date: Thu, 08 Mar 2001 11:46:09 +0100
From: Johan Jeuring johanj@cs.uu.nl
Subject: Summer School on Functional Programming?
>I was wondering if anyone knew if there was going to be a summer school on
>functional programming this year. Also, where would I find information
>about it? Thanks.
I don't think a summer school on advanced functional programming will be
organised this year. Maybe next year, but as far as I know nothing
has been decided yet. I will try to start up something (which doesn't mean
I will organise it!) soon.
-- Johan Jeuring
From wohlstad@cs.ucdavis.edu Fri Mar 9 02:18:46 2001
Date: Thu, 8 Mar 2001 18:18:46 -0800 (PST)
From: Eric Allen Wohlstadter wohlstad@cs.ucdavis.edu
Subject: zips and maps
I find myself very often needing to use this function and was wondering if
there was already a way to do this using zip,maps, and folds.
zipMap::[a->b]->[a]->[b]
zipMap [] _ = []
zipMap _ [] = []
zipMap (f:fs) (x:xs) = (f x):(zipMap fs xs)
Alternatively I can get the same affect like this:
fstOnSnd::(a->b,a)->b
fstOnSnd (f,x) = f x
zipMap::[a->b]->[a]->[b]
zipMap fs xs = map fstOnSnd (zip fs xs)
Both require me to invent some new function (or use a lambda) which I am
trying to avoid. If it is unavoidable then can someone think of a better
name then zipMap?
Eric Wohlstadter
UCDavis Software Engineering
From elf@sandburst.com Fri Mar 9 02:29:51 2001
Date: Thu, 08 Mar 2001 21:29:51 -0500
From: Mieszko Lis elf@sandburst.com
Subject: zips and maps
Eric Allen Wohlstadter wrote:
>
> I find myself very often needing to use this function and was wondering if
> there was already a way to do this using zip,maps, and folds.
Do you mind using zipWith? How about
zipMap = zipWith ($)
..?
-- Mieszko
From timd@macquarie.com.au Fri Mar 9 02:31:24 2001
Date: Fri, 9 Mar 2001 13:31:24 +1100 (EST)
From: Timothy Docker timd@macquarie.com.au
Subject: zips and maps
Eric Allen Wohlstadter writes:
> I find myself very often needing to use this function and was wondering if
> there was already a way to do this using zip,maps, and folds.
>
> zipMap::[a->b]->[a]->[b]
> zipMap [] _ = []
> zipMap _ [] = []
> zipMap (f:fs) (x:xs) = (f x):(zipMap fs xs)
>
....
> Both require me to invent some new function (or use a lambda) which I am
> trying to avoid. If it is unavoidable then can someone think of a better
> name then zipMap?
The following is more concise, and probably how I would do it:
zipMap :: [a->b] -> [a] -> [b]
zipMap = zipWith ($)
Cheers,
Tim
From conal@microsoft.com Fri Mar 9 02:36:26 2001
Date: Thu, 8 Mar 2001 18:36:26 -0800
From: Conal Elliott conal@microsoft.com
Subject: zips and maps
How about zipMap = zipWith ($)
- Conal
-----Original Message-----
From: Eric Allen Wohlstadter [mailto:wohlstad@cs.ucdavis.edu]
Sent: Thursday, March 08, 2001 6:19 PM
To: haskell-cafe@haskell.org
Subject: zips and maps
I find myself very often needing to use this function and was wondering if
there was already a way to do this using zip,maps, and folds.
zipMap::[a->b]->[a]->[b]
zipMap [] _ = []
zipMap _ [] = []
zipMap (f:fs) (x:xs) = (f x):(zipMap fs xs)
Alternatively I can get the same affect like this:
fstOnSnd::(a->b,a)->b
fstOnSnd (f,x) = f x
zipMap::[a->b]->[a]->[b]
zipMap fs xs = map fstOnSnd (zip fs xs)
Both require me to invent some new function (or use a lambda) which I am
trying to avoid. If it is unavoidable then can someone think of a better
name then zipMap?
Eric Wohlstadter
UCDavis Software Engineering
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
From conal@microsoft.com Fri Mar 9 15:07:55 2001
Date: Fri, 9 Mar 2001 07:07:55 -0800
From: Conal Elliott conal@microsoft.com
Subject: zips and maps
Note also that zipMap is the classic S combinatory if you think of lists as
functions over the natural numbers, so there's something especially
compelling about it. Similarly, repeat is K. From zipMap & repeat, you can
easily define map, zip, zipWith, zipWith3, etc.
s = zipWith ($)
k = repeat
mapT f xs = s (k f) xs
zipWithT f as bs = s (mapT f as) bs
zipT = zipWithT (,)
zipWith3T f as bs cs = s (zipWithT f as bs) cs
- Conal
-----Original Message-----
From: Mieszko Lis [mailto:elf@sandburst.com]
Sent: Thursday, March 08, 2001 6:30 PM
To: Eric Allen Wohlstadter
Cc: haskell-cafe@haskell.org
Subject: Re: zips and maps
Eric Allen Wohlstadter wrote:
>
> I find myself very often needing to use this function and was wondering if
> there was already a way to do this using zip,maps, and folds.
Do you mind using zipWith? How about
zipMap = zipWith ($)
..?
-- Mieszko
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
From sievers@ips.cs.tu-bs.de Fri Mar 9 15:50:30 2001
Date: Fri, 9 Mar 2001 16:50:30 +0100 (MET)
From: Christian Sievers sievers@ips.cs.tu-bs.de
Subject: zips and maps
Mieszko Lis (and others) wrote:
> zipMap = zipWith ($)
which is even in the report (end of section 6.2).
Interestingly, there is also a shorter, though rather unreadable
definition:
zipMap = zipWith id
Christian Sievers
From v-julsew@microsoft.com Mon Mar 12 11:46:31 2001
Date: Mon, 12 Mar 2001 03:46:31 -0800
From: Julian Seward (Intl Vendor) v-julsew@microsoft.com
Subject: GHC HQ are looking for a Linux-IA64 box
[Apologies if you get multiple copies of this msg.]
Folks,
Following a recent discussion about future development directions
for GHC, it seems one thing we want to start thinking about is
support for the IA64 architecture.
Does any kind person have an IA64 box, running Linux, on which we could
have an account? The extent of the work would be to make GHC's
runtime-support system work again on a 64-bit platform (it used to),
and possibly to build an IA64 native code generator. This work would
be spread across a couple of months, I imagine.
Basic requirements are:
* IA64 Linux box, with development tools (gcc, perl, autoconf, gdb,
etc -- all the usual Linux/Unix stuff).
* As many spare processor cycles as possible. GHC building/debugging
tends to CPU intensive. Also, probably at least 256MB of memory would
be necessary to keep us out of trouble.
* At a bare minimum, 300 MB of free disk space; 1 GB would be
preferable, since it would allow more thorough testing of the
system.
* Decent, permanent, reliable internet connection from so that we can=20
work remotely (obviously) and so that we can talk to our CVS server.
I'd say at a bare minimum a 128 kb/sec connection. Preferably
as few as possible network hops from Cambridge, UK.
This work is likely to be on-and-off (not all the time) over a couple
of months, I'd guess. We probably won't be ready to start on it for=20
at least a month, so some time around the start of May would be when=20
we'd really want to start moving on this.
Availability of such a machine would be a useful contribution to
the GHC development effort, so we'd be grateful if any of you could
point us in the right direction.
J
(speaking for the GHC crew as a whole)
From fjh@cs.mu.oz.au Mon Mar 12 16:28:38 2001
Date: Tue, 13 Mar 2001 03:28:38 +1100
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: GHC HQ are looking for a Linux-IA64 box
On 12-Mar-2001, Julian Seward (Intl Vendor) <v-julsew@microsoft.com> wrote:
>
> Does any kind person have an IA64 box, running Linux, on which we could
> have an account?
You might want to check out SourceForge: <http://ia-64.sourceforge.net/>.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From usmoeliu@mcs.drexel.edu Wed Mar 14 01:55:56 2001
Date: Tue, 13 Mar 2001 19:55:56 -0600
From: Samuel E. Moelius III usmoeliu@mcs.drexel.edu
Subject: Linearity Requirement for Patterns
What is the reasoning for the requirement that patterns be linear? Am I
correct to say that if non-linear patterns were allowed, it would require
equality to be defined for all data types? Is this the reason, or are there
others?
Sam Moelius
From brian@boutel.co.nz Sat Mar 17 02:49:15 2001
Date: Sat, 17 Mar 2001 15:49:15 +1300
From: Brian Boutel brian@boutel.co.nz
Subject: Linearity Requirement for Patterns
"Samuel E. Moelius III" wrote:
>
> What is the reasoning for the requirement that patterns be linear? Am I
> correct to say that if non-linear patterns were allowed, it would require
> equality to be defined for all data types? Is this the reason, or are there
> others?
>
If that were the reason, then to be consistent, there would be no
literals in patterns, as these are tested using equality.
Here is a reason. Some people believe that the equations that form a
function definition should be disjoint. A good reason for this view is
that fold/unfold transformations can be then performed without reference
to the other cases in the definition - if it matches, it is correct to
use it. Although Haskell does not require disjoint cases, and defines
the semantics in terms of a top-to-bottom testing order, the rejection
of non-linear patterns was largely because it is not generally possible
to specify, as a pattern, the complement of the set of values that match
a non-linear pattern, and so not possible to write a set of disjoint
case equations if non-linear patterns occur.
In any case, the same effect can be obtained using guards, where the
extra power of expression syntax solves the problem. Instead of
f x x = e1
f (illegal pattern) = e2
...
you can write the single equation
f x y | x == y = e1
| x /= y = e2
--brian
From dpt@math.harvard.edu Sat Mar 17 04:14:17 2001
Date: Fri, 16 Mar 2001 23:14:17 -0500
From: Dylan Thurston dpt@math.harvard.edu
Subject: Linearity Requirement for Patterns
On Sat, Mar 17, 2001 at 03:49:15PM +1300, Brian Boutel wrote:
> "Samuel E. Moelius III" wrote:
> >
> > What is the reasoning for the requirement that patterns be linear? Am I
> > correct to say that if non-linear patterns were allowed, it would require
> > equality to be defined for all data types? Is this the reason, or are there
> > others?
>
> If that were the reason, then to be consistent, there would be no
> literals in patterns, as these are tested using equality.
Only numeric literals actually use the '==' operator, correct? (As
opposed to built-in equality for data constructors and characters.)
--Dylan Thurston
From mc991008@pgc.edu Sat Mar 17 07:23:55 2001
Date: Sat, 17 Mar 2001 12:23:55 +0500
From: mc991008 mc991008@pgc.edu
Subject: (no subject)
hello, i'm a student of computer science in a known university of
pakistan. in this
semester i'm doing a course on "programming methodology". in this
course i had
given a project on learning haskell, a functional language and to give
a comparison on
haskell with prolog. if u plz kindly guide me and help me out, i'll be
very thankful to u.
looking forward soon from u
bye
amara hussain
mc991008@pgc.edu
From qrczak@knm.org.pl Sat Mar 17 07:43:10 2001
Date: 17 Mar 2001 07:43:10 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Linearity Requirement for Patterns
Fri, 16 Mar 2001 23:14:17 -0500, Dylan Thurston <dpt@math.harvard.edu> pisze:
> > If that were the reason, then to be consistent, there would be no
> > literals in patterns, as these are tested using equality.
>
> Only numeric literals actually use the '==' operator, correct?
Yes. This is a hack which allows viewing numeric types as algebraic
types with many constructors, assuming that (==) definition is sane.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From brian@boutel.co.nz Sat Mar 17 09:22:46 2001
Date: Sat, 17 Mar 2001 22:22:46 +1300
From: Brian Boutel brian@boutel.co.nz
Subject: Linearity Requirement for Patterns
Dylan Thurston wrote:
>
>
>
> Only numeric literals actually use the '==' operator, correct?
> (As opposed to built-in equality for data constructors and characters.)
>
I should have been more specific. Not that it affects the point being
made, and I didn't want to lose that in the detail.
Pattern matching for numeric literals uses whatever (==) has been
defined for the type, except, of course for the literals in n+k patterns
where (>=) is used.
The Character type is treated as a set of data constructors. Data
constructors match if they are the same constructor, and fail to match
otherwise. This is not the same as equality, where you are free to
define any result when comparing values, but it is the same as the
equality that would be derived for a type that consisted of a set of
nullary constructors.
String literals are lists of characters. Consequently, string matching
will use constructor matching for the List constructors and for the
characters.
So, yes, (==) is used when matching most numeric literals, and not used
for other literals.
--brian
From biotechinfo2004@yahoo.com Sun Mar 18 01:02:09 2001
Date: Sun, 18 Mar 2001 01:02:09
From: biotechinfo2004@yahoo.com biotechinfo2004@yahoo.com
Subject: FREE Biotech Stock Info! 298
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Do you want to capitalize on the Biotech Revolution</title>
</head>
<body>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto" align="center"><img border="0" src="http://www.geocities.com/mailtestbox2001/Kiloh_logo.gif" width="204" height="170"></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">Do
you want to capitalize on the Biotech Revolution? Would you like to add
groundbreaking biotech, pharmaceutical and medical device companies to your
portfolio mix? Does hearing about exciting IPO and private placement offerings
from life sciences companies interest you?</span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">The
exclusive <b>Ruddy-Carlisle Biotech Infoline</b> service keeps you abreast of
investment opportunities in the life sciences space. Just sign up for it once
and get important information instantly delivered to study at your leisure. Our
service is <b><u>100% FREE</u></b>! <b><span style="color:blue"><a href="mailto:biotechsubscribe2@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:#003366">Ruddy-Carlisle
Biotech Infoline:</span></i></b></p>
<ul type="disc">
<li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Instantly
delivers key life sciences investment information directly to you! </span></i></b><o:p>
</o:p>
</li>
<li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Learn
about biotech, pharmaceutical & medical device investment opportunities
before others! </span></i></b><o:p>
</o:p>
</li>
<li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Includes
IPO & private placement information! </span></i></b><o:p>
</o:p>
</li>
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:
11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:#003366">100%
FREE!</span></i></b></li>
</ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">For
the entire last decade there were only three profitable biotech companies. At
the end of this year, ten are projected. At the end of 2003, <u>over forty</u>
are projected! The genomic promise is about to be delivered and investors know
it. The <b>Ruddy-Carlisle Biotech Infoline </b>provides you with critical,
decision-making, information that aids the chance of investment success in this
lucrative space. <b><span style="color:blue"><a href="mailto:biotechsubscribe2@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:Arial">Please
Note-</span></b><span style="font-family:Arial"> Your information will only be
shared with companies that are in the life sciences space <u>and</u> pass our
rigorous inspection. Only the best opportunities will come to you.
Ruddy-Carlisle respects your privacy. <b><span style="color:blue"><a href="mailto:biotechsubscribe2@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p>
<b><span style="font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;
mso-fareast-font-family:"Times New Roman";mso-ansi-language:EN-US;mso-fareast-language:
EN-US;mso-bidi-language:AR-SA">
</p>
</p>List Removal Instructions</span></b><span style="font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;mso-fareast-font-family:
"Times New Roman";mso-ansi-language:EN-US;mso-fareast-language:EN-US;
mso-bidi-language:AR-SA">- Simply click here: <b><span style="color:blue"><a href="mailto:remobiotech2@yahoo.com">remove</a></span></b>
to be instantly and permanently removed from our list. Send the blank email to
the address specified. Please do not try to reply to this message.</span>
</body>
</html>
From shlomif@vipe.technion.ac.il Sun Mar 18 08:43:56 2001
Date: Sun, 18 Mar 2001 10:43:56 +0200 (IST)
From: Shlomi Fish shlomif@vipe.technion.ac.il
Subject: (no subject)
On Sat, 17 Mar 2001, mc991008 wrote:
> hello, i'm a student of computer science in a known university of
> pakistan. in this
> semester i'm doing a course on "programming methodology". in this
> course i had
> given a project on learning haskell, a functional language and to give
> a comparison on
> haskell with prolog. if u plz kindly guide me and help me out, i'll be
> very thankful to u.
> looking forward soon from u
Read http://www.haskell.org/tutorial/ in order to learn Haskell. Can't
tell you about Prolog because I don't know it yet.
Regards,
Shlomi Fish
> bye
> amara hussain
> mc991008@pgc.edu
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From mh@informatik.uni-kiel.de Mon Mar 19 08:38:36 2001
Date: Mon, 19 Mar 2001 09:38:36 +0100 (MET)
From: Michael Hanus mh@informatik.uni-kiel.de
Subject: Linearity Requirement for Patterns
Brian Boutel wrote:
> In any case, the same effect can be obtained using guards, where the
> extra power of expression syntax solves the problem. Instead of
> f x x = e1
> f (illegal pattern) = e2
> ...
>
> you can write the single equation
>
> f x y | x == y = e1
> | x /= y = e2
It depends on the meaning of pattern matching wrt. non-linear
patterns. The standard notion (e.g., term rewriting) matches
a pattern by finding a substitution for the pattern variables
so that the instantiated pattern is identical to the function
call. In this case, it can also match partially defined
functions in contrast to your transformation. For instance,
consider the definitions
g z = 1 + g z
f x x = 0
Then a call like (f (g 0) (g 0)) is reducible to 0
(wrt. standard notion of pattern matching using the instantiation
{x |-> (g 0)}) whereas it is undefined if we transform this definition to
f x y | x==y = 0
(which requires the evaluation of both arguments).
Thus, I would say that non-linear patterns gives you
extra power.
Michael
From brian@boutel.co.nz Mon Mar 19 11:04:50 2001
Date: Mon, 19 Mar 2001 23:04:50 +1200
From: brian boutel brian@boutel.co.nz
Subject: Linearity Requirement for Patterns
Michael Hanus wrote:
>
> Brian Boutel wrote:
> > In any case, the same effect can be obtained using guards, where the
> > extra power of expression syntax solves the problem. Instead of
> > f x x = e1
> > f (illegal pattern) = e2
> > ...
> >
> > you can write the single equation
> >
> > f x y | x == y = e1
> > | x /= y = e2
>
> It depends on the meaning of pattern matching wrt. non-linear
> patterns. The standard notion (e.g., term rewriting) matches
> a pattern by finding a substitution for the pattern variables
> so that the instantiated pattern is identical to the function
> call. In this case, it can also match partially defined
> functions in contrast to your transformation. For instance,
> consider the definitions
>
> g z = 1 + g z
> f x x = 0
>
> Then a call like (f (g 0) (g 0)) is reducible to 0
> (wrt. standard notion of pattern matching using the instantiation
> {x |-> (g 0)}) whereas it is undefined if we transform this definition to
>
> f x y | x==y = 0
>
> (which requires the evaluation of both arguments).
> Thus, I would say that non-linear patterns gives you
> extra power.
>
I don't think so.
Haskell is not a term rewriting system, and lacks the notion of
syntactic identity of expressions that would be required for your
scheme. If non-linear patterns were to be added, I do not think this
would change, and there would be no increase in power.
Moreover, sometimes your scheme would be less powerful. Consider
f x x = 0
f x y = f x (y+1)
and call f (factorial 5) (15 * 8)
This will be undefined unless you evaluate both arguments before
matching - which you say above that you wish to avoid. And if you do not
eveluate both, you lose referential transparency, for if I substutute
the argument values, and write f 120 120, you would then match the first
case and get 0 instead of bottom.
--brian
From lennart@augustsson.net Mon Mar 19 11:19:57 2001
Date: Mon, 19 Mar 2001 12:19:57 +0100
From: Lennart Augustsson lennart@augustsson.net
Subject: Linearity Requirement for Patterns
Michael Hanus wrote:
> g z = 1 + g z
> f x x = 0
>
> Then a call like (f (g 0) (g 0)) is reducible to 0
> (wrt. standard notion of pattern matching using the instantiation
> {x |-> (g 0)}) whereas it is undefined if we transform this definition to
>
> f x y | x==y = 0
>
> (which requires the evaluation of both arguments).
> Thus, I would say that non-linear patterns gives you
> extra power.
Yes, your definition of non-linear patterns would give you extra
power. It would also destroy the nice semantics of Haskell!
By using this facility you can now observe intensional properties
of the term, and the clean denotational semantics crumbles.
E.g., in Haskell you can always replace equals by equals without
changing the meaning of a program. In your example `g 0' is equal
to bottom so it should be possible to replace it by any other bottom
without any change in meaning. But if I define
h x = h x
and evaluate `f (g 0) (h 0)' I will no longer get 0.
So this definitions of non-linear patterns is not an option for a
language that claims to be "referentially transparent" (whatever that means :).
--
-- Lennart
From mh@informatik.uni-kiel.de Mon Mar 19 14:10:24 2001
Date: Mon, 19 Mar 2001 15:10:24 +0100 (MET)
From: Michael Hanus mh@informatik.uni-kiel.de
Subject: Linearity Requirement for Patterns
Lennart Augustsson wrote:
> Yes, your definition of non-linear patterns would give you extra
> power. It would also destroy the nice semantics of Haskell!
> By using this facility you can now observe intensional properties
> of the term, and the clean denotational semantics crumbles.
>
> E.g., in Haskell you can always replace equals by equals without
> changing the meaning of a program. In your example `g 0' is equal
> to bottom so it should be possible to replace it by any other bottom
> without any change in meaning. But if I define
> h x = h x
> and evaluate `f (g 0) (h 0)' I will no longer get 0.
>
> So this definitions of non-linear patterns is not an option for a
> language that claims to be "referentially transparent" (whatever that means :).
I agree and the question is about "whatever that means"...
Term rewriting systems (TRS) are based on replacing equals by equals
and that could be also considered as "referentially transparent".
Nevertheless, TRSs usually allow non-linear left-hand sides
(but often come with other restrictions like termination).
BTW, (g 0) and (h 0) are not considered as equal since
there are no rules/equations to transform one into the other.
However, I agree that there are good reasons (mainly, operational
simplicity) to allow only linear patterns and constructor-based
rules in a real programming language, since non-linear patterns
or non-constructor-based rules require other and more advanced
operational principles. I only wanted to remark that there is
no simple way to translate non-linear pattterns into linear
patterns in the general case.
Michael
From lennart@augustsson.net Mon Mar 19 14:55:33 2001
Date: Mon, 19 Mar 2001 15:55:33 +0100
From: Lennart Augustsson lennart@augustsson.net
Subject: Linearity Requirement for Patterns
Michael Hanus wrote:
> > E.g., in Haskell you can always replace equals by equals without
> > changing the meaning of a program. In your example `g 0' is equal
> > to bottom so it should be possible to replace it by any other bottom
> > without any change in meaning. But if I define
> > h x = h x
> > and evaluate `f (g 0) (h 0)' I will no longer get 0.
> >
> > So this definitions of non-linear patterns is not an option for a
> > language that claims to be "referentially transparent" (whatever that means :).
>
> I agree and the question is about "whatever that means"...
>
> Term rewriting systems (TRS) are based on replacing equals by equals
> and that could be also considered as "referentially transparent".
Yes, but a TRS has a different semantics than Haskell. In TRS you
manipulate terms, in Haskell you manipulate (the extension) of
functions (OK, OK, there's stuff that looks like constructors, but
it's all encodable as lambda terms).
> Nevertheless, TRSs usually allow non-linear left-hand sides
> (but often come with other restrictions like termination).
> BTW, (g 0) and (h 0) are not considered as equal since
> there are no rules/equations to transform one into the other.
But in Haskell they are equal since their denotations are equal.
> However, I agree that there are good reasons (mainly, operational
> simplicity) to allow only linear patterns and constructor-based
> rules in a real programming language, since non-linear patterns
> or non-constructor-based rules require other and more advanced
> operational principles. I only wanted to remark that there is
> no simple way to translate non-linear pattterns into linear
> patterns in the general case.
I think we are in agreement, I just wanted to point out that if you've
decided on the particular "functional style" semantics that Haskell
has, then you cannot have the kind of non-linear patterns that you
exemplified.
--
-- Lennart
From gruenbacher-lists@geoinfo.tuwien.ac.at Mon Mar 19 16:59:59 2001
Date: Mon, 19 Mar 2001 17:59:59 +0100 (CET)
From: Andreas Gruenbacher gruenbacher-lists@geoinfo.tuwien.ac.at
Subject: Coroutines
Hello,
has anybody thought about how to implement Simula style coroutines in
Haskell? What I have in mind is several "procedures" that communicate via
message passing in a co-operative way. That would give clear and intuitive
code for things like simulations...
Thanks,
Andreas.
------------------------------------------------------------------------
Andreas Gruenbacher gruenbacher@geoinfo.tuwien.ac.at
Research Assistant Phone +43(1)58801-12723
Institute for Geoinformation Fax +43(1)58801-12799
Technical University of Vienna Cell phone +43(664)4064789
From gruenbacher-lists@geoinfo.tuwien.ac.at Mon Mar 19 17:43:55 2001
Date: Mon, 19 Mar 2001 18:43:55 +0100 (CET)
From: Andreas Gruenbacher gruenbacher-lists@geoinfo.tuwien.ac.at
Subject: Coroutines
On Mon, 19 Mar 2001, Simon Peyton-Jones wrote:
> Lazy evaluation *is* coroutines, in a way.
What I had in mind was something like the following (pseudocode), which
could easily be implemented on top of coroutines:
class Channel c t where
send :: t -> c -> IO ()
receive :: c -> IO t
sender :: Int -> Channel -> ...
sender n receiver = do send n receiver
return (sender (n+1) receiver)
receiver :: Channel -> ...
receiver sender = do i <- receive sender
return (receiver sender)
c :: Channel Int
c = ...
main = run_them [ sender 1 c, receiver c ]
Maybe there is also a way to achieve something similar using higher order
functions---I just don't see how.
> Or you may be interested in Concurrent Haskell
> See section 4 of "Tackling the awkward squad"
> http://research.microsoft.com/~simonpj/papers/marktoberdorf.htm
Thanks, I'm chewing on this paper of yours since a couple of days already.
I particularly like the introduction to monads---it's the best I have seen
so far.
--Andreas.
From simonpj@microsoft.com Mon Mar 19 17:14:09 2001
Date: Mon, 19 Mar 2001 09:14:09 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Coroutines
Lazy evaluation *is* coroutines, in a way.
Or you may be interested in Concurrent Haskell
See section 4 of "Tackling the awkward squad"
http://research.microsoft.com/~simonpj/papers/marktoberdorf.htm
Simon
| -----Original Message-----
| From: Andreas Gruenbacher [mailto:gruenbacher@geoinfo.tuwien.ac.at]
| Sent: 19 March 2001 17:00
| To: haskell-cafe@haskell.org
| Subject: Coroutines
|=20
|=20
| Hello,
|=20
| has anybody thought about how to implement Simula style coroutines in
| Haskell? What I have in mind is several "procedures" that=20
| communicate via
| message passing in a co-operative way. That would give clear=20
| and intuitive
| code for things like simulations...
|=20
| Thanks,
| Andreas.
|=20
| --------------------------------------------------------------
| ----------
| Andreas Gruenbacher gruenbacher@geoinfo.tuwien.ac.at
| Research Assistant Phone +43(1)58801-12723
| Institute for Geoinformation Fax +43(1)58801-12799
| Technical University of Vienna Cell phone +43(664)4064789
|=20
|=20
| _______________________________________________
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
|=20
From simonpj@microsoft.com Mon Mar 19 17:45:28 2001
Date: Mon, 19 Mar 2001 09:45:28 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Coroutines
| What I had in mind was something like the following=20
| (pseudocode), which
| could easily be implemented on top of coroutines:
Concurrent Haskell provides exactly this Channel stuff.
Simon
|=20
| class Channel c t where
| send :: t -> c -> IO ()
| receive :: c -> IO t
|=20
| sender :: Int -> Channel -> ...
| sender n receiver =3D do send n receiver
| return (sender (n+1) receiver)
|=20
| receiver :: Channel -> ...
| receiver sender =3D do i <- receive sender
| return (receiver sender)
|=20
| c :: Channel Int
| c =3D ...
|=20
| main =3D run_them [ sender 1 c, receiver c ]
|=20
|=20
| Maybe there is also a way to achieve something similar using=20
| higher order
| functions---I just don't see how.
|=20
|=20
| > Or you may be interested in Concurrent Haskell
| > See section 4 of "Tackling the awkward squad"
| > http://research.microsoft.com/~simonpj/papers/marktoberdorf.htm
|=20
| Thanks, I'm chewing on this paper of yours since a couple of=20
| days already.
| I particularly like the introduction to monads---it's the=20
| best I have seen
| so far.
|=20
|=20
| --Andreas.
|=20
|=20
From uk1o@rz.uni-karlsruhe.de Mon Mar 19 21:56:48 2001
Date: Mon, 19 Mar 2001 22:56:48 +0100
From: Hannah Schroeter uk1o@rz.uni-karlsruhe.de
Subject: Coroutines
Hello!
On Mon, Mar 19, 2001 at 06:43:55PM +0100, Andreas Gruenbacher wrote:
> On Mon, 19 Mar 2001, Simon Peyton-Jones wrote:
> > Lazy evaluation *is* coroutines, in a way.
> What I had in mind was something like the following (pseudocode), which
> could easily be implemented on top of coroutines:
> class Channel c t where
> send :: t -> c -> IO ()
> receive :: c -> IO t
> sender :: Int -> Channel -> ...
> sender n receiver = do send n receiver
> return (sender (n+1) receiver)
> receiver :: Channel -> ...
> receiver sender = do i <- receive sender
> return (receiver sender)
> c :: Channel Int
> c = ...
> main = run_them [ sender 1 c, receiver c ]
Now, you can do this:
sender :: Int -> [Int]
sender n = n:(sender (n+1))
receiver :: [Int] -> ()
receiver (x:xs) = receiver xs
main =
let
sent_stuff = sender 1
receiver_result = receiver sent_stuff
in
receiver_result `seq` return ()
I.e. lazy lists work like coroutine channels often enough.
You can do that a bit more abstractly:
send :: a -> [a] -> [a]
send = (:)
receive :: (a -> [a] -> result) -> [a] -> result
receive f (x:xs) = f x xs
sender n = send n $ sender (n+1)
receiver = receive $ \received_thing -> receiver
main = (as above)
Note that the definition of sender now looks not too unsimilar to
your monadic things:
sender n = send n >> sender (n+1)
===
sender n = do
send n
sender (n+1) -- your 'return' above is redundant
receiver = receive >>= \received_thing -> receiver
===
receiver = do
received_thing <- receive
receiver
Now, in fact, you could achieve this effect with a continuation+state monad
quite well (state for input, continuation as *one* way for lazy output).
> [...]
Kind regards,
Hannah.
From karczma@info.unicaen.fr Tue Mar 20 11:20:19 2001
Date: Tue, 20 Mar 2001 11:20:19 +0000
From: Jerzy Karczmarczuk karczma@info.unicaen.fr
Subject: Linearity Requirement for Patterns
Michael Hanus wrote:
>
> Lennart Augustsson wrote:
> > Yes, your definition of non-linear patterns would give you extra
> > power. It would also destroy the nice semantics of Haskell!
> > By using this facility you can now observe intensional properties
> > of the term, and the clean denotational semantics crumbles.
...
> > So this definitions of non-linear patterns is not an option for a
> > language that claims to be "referentially transparent" (whatever
> > that means :).
...
> However, I agree that there are good reasons (mainly, operational
> simplicity) to allow only linear patterns and constructor-based
> rules in a real programming language, since non-linear patterns
> or non-constructor-based rules require other and more advanced
> operational principles. I only wanted to remark that there is
> no simple way to translate non-linear pattterns into linear
> patterns in the general case.
>
> Michael
Logic languages which allow for nonlinear patterns use unification,
which is usually much more costly than simple pattern compiling.
Now, I wonder whether in FP where there is no place for "logical
variable" concept one needs or doesn't need the classical unification,
with all the substitutions of variables.
"Read-only" patterns are manipulated more efficiently, but in presence
of laziness, of ~patterns etc., I feel - for the moment - rather
lost.
What is the status of the referential transparency of Prolog or
Mercury?
Anybody, with a clever comment on that?
Jerzy Karczmarczuk
Caen, France
From rejj@cs.mu.OZ.AU Tue Mar 20 12:47:31 2001
Date: Tue, 20 Mar 2001 23:47:31 +1100
From: Robert Jeschofnik rejj@cs.mu.OZ.AU
Subject: ANNOUNCE: HasChorus - some modules for Haskore
On 20-Mar-2001, Martin Schwenke <martin@meltin.net> wrote:
> HasChorus:
>
> A set of Haskell (http://haskell.org/) modules written on top of
> Haskore (http://haskell.org/haskore/) to make it easier to sequence
> simple, repetitive music.
Even without having had a look at the code yet, I am led to wonder...
> BubbleSort.lhs: An implementation of bubble sort.
> Used by HasGroove.lhs.
(I reformatted the quote so it wouldn't wrap over 80 chars)
-Why- bubblesort?
Rob
From mh@informatik.uni-kiel.de Tue Mar 20 12:53:54 2001
Date: Tue, 20 Mar 2001 13:53:54 +0100 (MET)
From: Michael Hanus mh@informatik.uni-kiel.de
Subject: Linearity Requirement for Patterns
Jerzy Karczmarczuk wrote:
> Logic languages which allow for nonlinear patterns use unification,
> which is usually much more costly than simple pattern compiling.
> Now, I wonder whether in FP where there is no place for "logical
> variable" concept one needs or doesn't need the classical unification,
> with all the substitutions of variables.
> "Read-only" patterns are manipulated more efficiently, but in presence
> of laziness, of ~patterns etc., I feel - for the moment - rather
> lost.
>
> What is the status of the referential transparency of Prolog or
> Mercury?
Prolog isn't referential transparent due to predefined predicates
with side effects. However, logic programming ("pure Prolog")
is referentially transparent if one considers a "non-deterministic"
semantics where an expression is reduced to a disjunction of
expressions (Prolog systems explore this disjunction in a
left-to-right manner by backtracking). Actually, one can
extend Haskell by "logical variables" in a conservative manner.
This is the idea of the functional logic language Curry
(http://www.informatik.uni-kiel.de/~curry/) where the pattern
matching process is slightly extended so that the operational
behavior is identical to Haskell (i.e., not more costly)
for programs without occurrences of logical variables
and, if a logical variable occurs during pattern matching,
it is (non-deterministically) bound to some pattern.
However, in order to support infinite data structures and
laziness, linear patterns are also required. Non-linear patterns
must be transformed into linear patterns by introducing
a unification constraint in the condition part, i.e., all
non-linearities must be made explicit in the program
(so that pattern matching can be efficiently performed).
Thus, I think that linearity is a natural requirement
even for logic languages that support laziness.
Michael
From lisper@it.kth.se Tue Mar 20 14:01:50 2001
Date: Tue, 20 Mar 2001 15:01:50 +0100 (MET)
From: Bjorn Lisper lisper@it.kth.se
Subject: Linearity Requirement for Patterns
Michael Hanus:
>Thus, I think that linearity is a natural requirement
>even for logic languages that support laziness.
Yes. Further evidence for this is that non-left-linear term rewriting systems
typically don't have sequential normalizing evaluation strategies. A
normalizing evaluation strategy might thus be very expensive for a rewrite
system with such rules.
Also, many nice results about confluence do not hold if there are
non-left-linear rules.
Björn Lisper
From loogen@Mathematik.Uni-Marburg.de Tue Mar 20 15:45:52 2001
Date: Tue, 20 Mar 2001 16:45:52 +0100
From: Rita Loogen loogen@Mathematik.Uni-Marburg.de
Subject: Coroutines
Eden (http://www.mathematik.uni-marburg.de/inf/eden) is a parallel
extension of Haskell that provides processes which communicate via
streams (lazy lists).
In Eden, your pseudocode would look like:
sender :: Int -> Process () [Int]
sender n = process () -> [n,n+1..]
receiver :: Process [Int] [Results]
receiver = process xs -> consume xs
where consume :: [Int] -> [Results]
main = print (receiver # (sender # ()))
The type Process a b belongs to a process abstraction which defines a
process consuming input of type a and producing output of type b.
# :: Process a b -> a -> b applies a process abstraction to input. This
leads to the creation of the process and its interconnecting channels.
Regards
Rita
--
Rita Loogen
Fachbereich Mathematik und Informatik, Philipps-Universitaet Marburg,
Germany
http://www.mathematik.uni-marburg.de/~loogen
--
From gruenbacher-lists@geoinfo.tuwien.ac.at Tue Mar 20 17:07:25 2001
Date: Tue, 20 Mar 2001 18:07:25 +0100 (CET)
From: Andreas Gruenbacher gruenbacher-lists@geoinfo.tuwien.ac.at
Subject: Coroutines
On Mon, 19 Mar 2001, Hannah Schroeter wrote:
> Hello!
>
> On Mon, Mar 19, 2001 at 06:43:55PM +0100, Andreas Gruenbacher wrote:
>
> > On Mon, 19 Mar 2001, Simon Peyton-Jones wrote:
> >
> > > Lazy evaluation *is* coroutines, in a way.
> >
> > What I had in mind was something like the following (pseudocode), which
> > could easily be implemented on top of coroutines:
> >
> > class Channel c t where
> > send :: t -> c -> IO ()
> > receive :: c -> IO t
> >
> > sender :: Int -> Channel -> ...
> > sender n receiver = do send n receiver
> > return (sender (n+1) receiver)
> >
> > receiver :: Channel -> ...
> > receiver sender = do i <- receive sender
> > return (receiver sender)
> >
> > c :: Channel Int
> > c = ...
> >
> > main = run_them [ sender 1 c, receiver c ]
>
> Now, you can do this:
>
> sender :: Int -> [Int]
> sender n = n:(sender (n+1))
>
> receiver :: [Int] -> ()
> receiver (x:xs) = receiver xs
>
> main =
> let
> sent_stuff = sender 1
> receiver_result = receiver sent_stuff
> in
> receiver_result `seq` return ()
>
> I.e. lazy lists work like coroutine channels often enough.
I see your point, and I must admit that this approach has its charm. It's
not what I had in mind, though. Simon's MVars (in the Awkward Squad)
come pretty close, but they're still not the sort of (cooperative)
multitasking that I'm thinking of. I'm not looking for a process or thread
model of concurrency. That's too expensive for simulations due to the
frequency of task switches. (And thanks Rita, for the Eden reference.
That's comparable to Concurrent Haskell.)
The sort of lazy evaluation employed in your solution is in a way similar
to coroutines, with the following restrictions (correct me if I'm wrong):
* It is not possible to implement cyclic communication.
* It is not possible to implement processes with multiple asynchronous
output channels.
I really would like to preserve the elegance of simulations in Simula, but
with all the advantages Haskell offers. I believe that in current Haskell
implementations all the components needed for "proper" coroutines are more
or less there (because lazy evaluation is pretty close).
Any more ideas?
Thanks,
--Andreas.
From qrczak@knm.org.pl Tue Mar 20 17:42:09 2001
Date: 20 Mar 2001 17:42:09 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Coroutines
Tue, 20 Mar 2001 18:07:25 +0100 (CET), Andreas Gruenbacher <gruenbacher@geoinfo.tuwien.ac.at> pisze:
> The sort of lazy evaluation employed in your solution is in a way similar
> to coroutines, with the following restrictions (correct me if I'm wrong):
>
> * It is not possible to implement cyclic communication.
I see no problem in this.
In fact laziness is really about the ability to cycle anything.
> * It is not possible to implement processes with multiple asynchronous
> output channels.
Again I see no problem:
splitEvenOdd:: [a] -> ([a], [a])
splitEvenOdd [] = ([], [])
splitEvenOdd (x:xs) = (x:ys, zs) where (ys, zs) = splitOddEven xs
splitOddEven:: [a] -> ([a], [a])
splitOddEven [] = ([], [])
splitOddEven (x:xs) = (ys, x:zs) where (ys, zs) = splitEvenOdd xs
What it cannot do is to multiplex input. Code is purely functional
and thus the result cannot depend on the order in which inputs become
available.
Concurrent Haskell provides nondeterministic merge from lazy lists
(mergeIO and nmergeIO in module Concurrent).
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From simonpj@microsoft.com Tue Mar 20 17:45:50 2001
Date: Tue, 20 Mar 2001 09:45:50 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Coroutines
| I see your point, and I must admit that this approach has its=20
| charm. It's
| not what I had in mind, though. Simon's MVars (in the Awkward Squad)
| come pretty close, but they're still not the sort of (cooperative)
| multitasking that I'm thinking of. I'm not looking for a=20
| process or thread
| model of concurrency. That's too expensive for simulations due to the
| frequency of task switches.
Could you try it and see? GHC's threads are implemented in GHC's
runtime system; thread switching is much much much cheaper than
switching between OS threads. It's designed to support thousands or
hundreds of thousands of threads.
Give it a whirl!
Simon=20
From ross@soi.city.ac.uk Tue Mar 20 18:06:48 2001
Date: Tue, 20 Mar 2001 18:06:48 +0000
From: Ross Paterson ross@soi.city.ac.uk
Subject: Coroutines
On Tue, Mar 20, 2001 at 06:07:25PM +0100, Andreas Gruenbacher wrote:
> The sort of lazy evaluation employed in [Hannah's] solution is in a
> way similar to coroutines, with the following restrictions (correct
> me if I'm wrong):
>
> * It is not possible to implement cyclic communication.
It certainly is, and that seems to me a neat way to do process-driven
simulation: a process generates a list of future events, which a controller
merges into its pool, from which it selects the next event to simulate,
starting the next process, and so on. You could use a monad to hide the
event output if required.
> * It is not possible to implement processes with multiple asynchronous
> output channels.
Again, should be no problem, but what do you need these for?
> I really would like to preserve the elegance of simulations in Simula, but
> with all the advantages Haskell offers. I believe that in current Haskell
> implementations all the components needed for "proper" coroutines are more
> or less there (because lazy evaluation is pretty close).
Indeed, you may be able to do all the simulation primitives in pure
Haskell, if you take a step back from the channel view.
From Martin Schwenke" >>>>> "Robert" == Robert Jeschofnik <rejj@cs.mu.OZ.AU> writes:
Robert> Even without having had a look at the code yet, I am led
Robert> to wonder...
>> BubbleSort.lhs: An implementation of bubble sort.
>> Used by HasGroove.lhs.
Robert> (I reformatted the quote so it wouldn't wrap over 80 chars)
Robert> -Why- bubblesort?
That's what I initially thought when a colleague asked why I wasn't
using bubblesort!
The groove function takes a Haskore performance and rearranges it a
bit according to some parameters and normal distributions. The idea
is to loosen things up a bit. The performance is a very long list,
but is still roughly in order (otherwise I would just generate random
music to start with :-). That is, nothing moves very far, but the
next stage in Haskore (conversion to MIDI) requires everything to be
in order.
My implementation of bubblesort iterates over the list until the list
is sorted and then stops. Since the list is only a little bit out of
order, this doesn't take too many iterations.
My implementation is very declarative. I could make it less so, but
my experiments have shown that the performance gain is minimal. I'd
rather keep the code beautiful! :-)
I tried things like quicksort and mergesort, but I couldn't minimize
the space requirements enough to make them work well. I even
implemented a "window sort" algorithm that sorted within a window that
I "moved" along the list. This worked quite well, but was a gross
hack. I can't remember exactly, but I think bubblesort out-performed
it anyway!
Bubblesort rules! ... within a very limited domain... :-)
peace & happiness,
martin
From fjh@cs.mu.oz.au Thu Mar 22 01:07:09 2001
Date: Thu, 22 Mar 2001 12:07:09 +1100
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: Linearity Requirement for Patterns
On 20-Mar-2001, Michael Hanus <mh@informatik.uni-kiel.de> wrote:
> Jerzy Karczmarczuk wrote:
> > Logic languages which allow for nonlinear patterns use unification,
> > which is usually much more costly than simple pattern compiling.
> > Now, I wonder whether in FP where there is no place for "logical
> > variable" concept one needs or doesn't need the classical unification,
> > with all the substitutions of variables.
> > "Read-only" patterns are manipulated more efficiently, but in presence
> > of laziness, of ~patterns etc., I feel - for the moment - rather
> > lost.
> >
> > What is the status of the referential transparency of Prolog or
> > Mercury?
>
> Prolog isn't referential transparent due to predefined predicates
> with side effects. However, logic programming ("pure Prolog")
> is referentially transparent if one considers a "non-deterministic"
> semantics where an expression is reduced to a disjunction of
> expressions (Prolog systems explore this disjunction in a
> left-to-right manner by backtracking).
I would talk about disjunctions of "goals" rather than disjunctions of
"expressions". This is perhaps a pedantic distinction, but when
you start talking about referential transparency it is important
to be very precise, because often the distinctions are a matter
of terminology.
> Actually, one can
> extend Haskell by "logical variables" in a conservative manner.
> This is the idea of the functional logic language Curry
My understanding, from talking with Michael Hanus a few years ago, is
that Curry is not referentially transparent, in the sense that you can't
replace equals with equals, because it permits nondeterministic functions.
In particular, `let x = f y in g x x' is not the same as `g (f y) (f y)'
in Curry.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From fjh@cs.mu.oz.au Thu Mar 22 01:31:35 2001
Date: Thu, 22 Mar 2001 12:31:35 +1100
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: Linearity Requirement for Patterns
On 20-Mar-2001, Jerzy Karczmarczuk <karczma@info.unicaen.fr> wrote:
>
> Logic languages which allow for nonlinear patterns use unification,
> which is usually much more costly than simple pattern compiling.
That's true, but the exceptions are important.
If you have sufficient compile-time mode information, then unification
need not be more costly than simple pattern matching.
> What is the status of the referential transparency of Prolog or
> Mercury?
As Michael Hanus said, Prolog is not referentially transparent because
it has a large variety of builtins that violate referential transparency.
For Mercury, the short answer is that yes, Mercury is referentially
transparent.
Still, I guess you want the long answer ;-)
Mercury's declarative semantics are referentially transparent.
Modifying some Mercury program by replacing equals with equals always
preserves the program's declarative semantics. However, such
transformations do not necessarily preserve the operational semantics;
the transformed program may not terminate when the original does,
or may compute the set of solutions in a different order.
The same is true for pure Prolog.
Haskell's denotational semantics is referentially transparent. AFAIK
Haskell doesn't have a standard operational semantics, but the typical
operational semantics used are also referentially transparent. However,
if you use a more detailed operational semantics, e.g. one which takes
into account the fact that machines have finite memory, then the same
kind of thing applies to Haskell too: replacing equals with equals may
not preserve the operational semantics, because the transformed program
may run out of memory when the original didn't.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From mh@informatik.uni-kiel.de Thu Mar 22 08:46:26 2001
Date: Thu, 22 Mar 2001 09:46:26 +0100 (MET)
From: Michael Hanus mh@informatik.uni-kiel.de
Subject: Linearity Requirement for Patterns
Fergus Henderson wrote:
> My understanding, from talking with Michael Hanus a few years ago, is
> that Curry is not referentially transparent, in the sense that you can't
> replace equals with equals, because it permits nondeterministic functions.
> In particular, `let x = f y in g x x' is not the same as `g (f y) (f y)'
> in Curry.
Of course, as you already mentioned, one has te be very precise
when talking about referential transparency. In particular, one
has to say what "equals" mean. Otherwise, one could also argue
that Haskell is not referential transparent: if a Haskell program
has a defining equation "f 1 = 1", the expressions "(f 1)" and "1"
might not be identical (if there is another equation like "f x = 0"
before).
In Curry, each defining equation contributes to the semantics
of a function independently of the other equations for the same
function, and the overall goal is to compute all values of
an expression (plus possible substitutions for free variables)
which can be derived from this equational reading of all rules.
In this sense, Curry is refentially transparent (although I have
no formal definition of this notion but only soundness, completeness
and optimality results). Your "counter example" comes from a
misunderstanding of the "let" in Curry. Since the kernel language
is based lazy evaluation w.r.t. a set of constructor-based rewrite
rules, the "let" is considered as syntactic sugar for abbreviating
some function argument. For instance, the meaning of the definition
h = let x = f y in g x x
is defined as an abbreviation for the rules
h = aux (f y)
aux x = g x x
W.r.t. this semantics, there is no problem even with non-deterministic
functions.
If you have a precise definition of "referentially transparent"
at hand so that you can make your statement more precise, I would
be very interested to read it. As you have seen, the slogan
"replacing equals by equals" is still to fuzzy since just looking
for equality symbols in a language is not sufficient.
Michael
From lisper@it.kth.se Thu Mar 22 10:26:59 2001
Date: Thu, 22 Mar 2001 11:26:59 +0100 (MET)
From: Bjorn Lisper lisper@it.kth.se
Subject: Linearity Requirement for Patterns
Michael Hanus:
>In Curry, each defining equation contributes to the semantics
>of a function independently of the other equations for the same
>function, and the overall goal is to compute all values of
>an expression (plus possible substitutions for free variables)
>which can be derived from this equational reading of all rules.
>In this sense, Curry is refentially transparent (although I have
>no formal definition of this notion but only soundness, completeness
>and optimality results). Your "counter example" comes from a
>misunderstanding of the "let" in Curry. Since the kernel language
>is based lazy evaluation w.r.t. a set of constructor-based rewrite
>rules, the "let" is considered as syntactic sugar for abbreviating
>some function argument. For instance, the meaning of the definition
>
> h = let x = f y in g x x
>
>is defined as an abbreviation for the rules
>
> h = aux (f y)
> aux x = g x x
>
>W.r.t. this semantics, there is no problem even with non-deterministic
>functions.
How does sharing work here? I assume the "let x = ..." is intended to mean
sharing of "...". Does the same hold for function calls in Curry, so
"aux x = g x x" implies sharing of x when evaluating g? In that case I
suspect you might have problems if, for instance, you inline aux naively
into g (f y) (f y) and f is nondeterministic. (Inlining should typically
work for a referentially transparent language.) The problem can be fixed
though: if you have this sharing, then "aux x = g x x" is really shorthand
for "aux x = let y = x in g y y". If this definition is inlined and the let
is kept (to preserve the sharing), then the transformation should work even
if f is nondeterministic.
If, on the other hand, Curry has a call-by-name semantics, then the direct
inlining should work.
>If you have a precise definition of "referentially transparent"
>at hand so that you can make your statement more precise, I would
>be very interested to read it. As you have seen, the slogan
>"replacing equals by equals" is still to fuzzy since just looking
>for equality symbols in a language is not sufficient.
Referential transparency is defined w.r.t. some notion of equality on terms,
and cannot be precise unless this notion is made precise. If the language at
hand has a denotational semantics, then equality on terms can be derived
from their denotations. But referential transparency can also be defined
w.r.t. other semantics. An interesting case is term rewrite semantics: a
confluent term rewrite system defines a notion of equality through its
convertibility relation (the transitive-reflexive-symmetric closure of the
reduction relation). A notion of referential transparency can be based on this
equivalence relation (which is an equality relation, due to closedness of
the reduction relation under substitutions and taking of contexts).
A restricted notion of referential transparency carries over to nonconfluent
(and thus nondeterministic) rewrite systems. If the rewrite system can be
partitioned into a confluent and a nonconfluent part, then the
convertibility relation for the confluent part can be taken as an equality
relation upon which the referential transparency can be defined. Under
certain (not so strong) technical conditions, the set of possible normal
forms will be the same for terms that are equal w.r.t. this convertibility
relation. This holds also if the concept of normal form is extended to cover
infinite and possibly diverging computations.
I don't know how much of this applies directly to Curry, since the above is
for pure term rewriting and I suspect Curry has unification in its
evaluation mechanism (right?) which then makes the evaluation more
complex. But maybe the above can provide some ideas how to formally define
referential transparency for Curry?
Björn Lisper
PS. I have a paper on this. There is also a paper by Søndergaard and Sestoft
that has an interesting discussion about referential transparency and
nondeterminism. Bibtex entries are given below.
@STRING{tcs = "Theoret.\ Comput.\ Sci."}
@ARTICLE{Lisper-TCS,
AUTHOR = {Bj{\"o}rn Lisper},
TITLE = {Computing in Unpredictable Environments: Semantics, Reduction Strategies, and Program Transformations},
JOURNAL = tcs,
YEAR = {1998},
VOLUME = {190},
NUMBER = {1},
PAGES = {61--85},
MONTH = jan
}
@ARTICLE{SonSes-reftrans-unfold,
AUTHOR = {Harald S{\o}ndergaard and Peter Sestoft},
TITLE = {Referential Transparency, Definiteness and Unfoldability},
JOURNAL = {Acta Informatica},
YEAR = {1990},
VOLUME = {27},
PAGES = {505--517}
}
From koen@cs.chalmers.se Thu Mar 22 12:04:51 2001
Date: Thu, 22 Mar 2001 13:04:51 +0100 (MET)
From: Koen Claessen koen@cs.chalmers.se
Subject: Linearity Requirement for Patterns
Michael Hanus wrote:
| For instance, the meaning of the definition
|
| h = let x = f y in g x x
|
| is defined as an abbreviation for the rules
|
| h = aux (f y)
| aux x = g x x
|
| W.r.t. this semantics, there is no problem even with
| non-deterministic functions.
In ML, the meaning of the expression:
let x = e1 in e2
is defined as an abbreviation for the expression
mdo x <- e1; e2
W.r.t. this semantics, there is no problem even with
side-effecting functions.
/Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
From mh@informatik.uni-kiel.de Thu Mar 22 12:53:20 2001
Date: Thu, 22 Mar 2001 13:53:20 +0100 (MET)
From: Michael Hanus mh@informatik.uni-kiel.de
Subject: Linearity Requirement for Patterns
Bjorn Lisper wrote:
> >some function argument. For instance, the meaning of the definition
> >
> > h = let x = f y in g x x
> >
> >is defined as an abbreviation for the rules
> >
> > h = aux (f y)
> > aux x = g x x
> >
> >W.r.t. this semantics, there is no problem even with non-deterministic
> >functions.
>
> How does sharing work here? I assume the "let x = ..." is intended to mean
> sharing of "...". Does the same hold for function calls in Curry, so
> "aux x = g x x" implies sharing of x when evaluating g? In that case I
Yes. Since Curry is based on a lazy and (for a particular subclass,
namely inductively sequential rules) also optimal evaluation strategy,
sharing of function arguments is required and essential.
> suspect you might have problems if, for instance, you inline aux naively
> into g (f y) (f y) and f is nondeterministic. (Inlining should typically
> work for a referentially transparent language.) The problem can be fixed
> though: if you have this sharing, then "aux x = g x x" is really shorthand
> for "aux x = let y = x in g y y". If this definition is inlined and the let
> is kept (to preserve the sharing), then the transformation should work even
> if f is nondeterministic.
In the presence of nondeterministic functions (i.e., nonconfluent
rules), one has several options for the semantics. For parameter
passing, one can use either the call-time choice or run-time choice
semantics. Curry is based on the former since there is a well-defined
semantical framework for this in the presence of non-strict functions
(Gonzalez-Moreno et al., Journal of Logic Programming, Vol. 40, 1999).
Semantically, the call-time choice means that rewrite rules can
only be applied if the arguments are constructor terms, i.e.,
totally evaluated. This does not necessarily imply a strict semantics
since it can be implemented by lazy reduction provided that
function arguments are shared. Thus, this sharing must be
somehow represented in an intermediate language for executing
the programs and on this level inlining is preserved, as you have
remarked. Naive inlining (i.e., without lets but possibly
duplicating function calls) does only work for deterministic
functions (which is no restriction from a Haskell point of view
since Haskell allows only deterministic functions).
> I don't know how much of this applies directly to Curry, since the above is
> for pure term rewriting and I suspect Curry has unification in its
> evaluation mechanism (right?) which then makes the evaluation more
> complex. But maybe the above can provide some ideas how to formally define
> referential transparency for Curry?
The paper mentioned above defines a proof calculus, model theory
and operational semantics for this language where the denotation
of functions distinguish between deterministic and non-deterministic
functions which seems to be conform to your remarks. Although
it does not explicitly define referential transparancy, it shows
the equivalence of all three notions which I think is enough
for reasoning about Curry programs. Nevertheless, many thanks
for your hints.
Michael
From fjh@cs.mu.oz.au Thu Mar 22 23:39:15 2001
Date: Fri, 23 Mar 2001 10:39:15 +1100
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: Linearity Requirement for Patterns
On 22-Mar-2001, Koen Claessen <koen@cs.chalmers.se> wrote:
> Michael Hanus wrote:
>
> | For instance, the meaning of the definition
> |
> | h = let x = f y in g x x
> |
> | is defined as an abbreviation for the rules
> |
> | h = aux (f y)
> | aux x = g x x
> |
> | W.r.t. this semantics, there is no problem even with
> | non-deterministic functions.
>
> In ML, the meaning of the expression:
>
> let x = e1 in e2
>
> is defined as an abbreviation for the expression
>
> mdo x <- e1; e2
>
> W.r.t. this semantics, there is no problem even with
> side-effecting functions.
Referential transparency is a *syntactic* property of a language. You can
define two languages with very similar semantics, and a well-defined
translation that maps one to the other (and vice versa), the only difference
being some syntactic sugar, and yet one can be referentially transparent and
the other not.
So I don't think it is reasonable to say that either of those languages are
referentially transparent by virtue of the existence of some transformation or
some rules for how to expand syntactic sugar for which the result of the
transformation is referentially transparent. In general such transformations
don't necessarily preserve referential transparency.
On the other hand, another conclusion that you could draw from this is that
referential transparency is not such an important property; it's a means, not
an end. Really what we care about is whether the languages that we use
are easy to understand, have a simple semantics, and are easy to transform.
Languages which are referentially transparent *tend* to have those properties,
but this is not necessarily the case.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From koen@cs.chalmers.se Tue Mar 27 09:42:15 2001
Date: Tue, 27 Mar 2001 11:42:15 +0200 (MET DST)
From: Koen Claessen koen@cs.chalmers.se
Subject: the constant functor
(moved reply to haskell-cafe)
Hi Tobias,
| data ConstInt a = Const Int
|
| Any ideas how to make 'ConstInt' an instance of class
| Functor?
What is wrong with:
class Functor ConstInt where
map f (Const n) = Const n
?
/Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
From Tom.Pledger@peace.com Tue Mar 27 20:46:08 2001
Date: Wed, 28 Mar 2001 08:46:08 +1200
From: Tom Pledger Tom.Pledger@peace.com
Subject: the constant functor
Tobias Haeberlein writes:
|
| > What is wrong with:
| >
| > class Functor ConstInt where
| > map f (Const n) = Const n
|
| Ups - absolutely nothing.
| I actually tried it with
|
| data ConstInt a = Int
This version doesn't refer to the type Int. Instead, it introduces a
new nullary data constructor called Int, which you could use like
this:
instance Functor ConstInt where
fmap f Int = Int
...but I don't think that's what you were after. If you use a type
alias (type ConstInt a = Int) instead of declaring a data type, it
will refer to the type Int. However, then you'd need to use ConstInt
partially applied in the instance declaration, which Haskell doesn't
allow. I think Gofer has a more liberal type system which does allow
it.
| and didnt manage to make this an instance of
| class Functor. Sorry for giving the wrong
| example.
From ate2882@yahoo.com Tue Mar 27 23:32:30 2001
Date: Tue, 27 Mar 2001 15:32:30 -0800 (PST)
From: Atenea Azcue ate2882@yahoo.com
Subject: (no subject)
--0-1558094891-985735950=:95280
Content-Type: text/plain; charset=us-ascii
Hello
My name is Atenea : I´m what to ask you who can I make a program in haskell like une program that say hello word
---------------------------------
Do You Yahoo!?
Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! Mail.
--0-1558094891-985735950=:95280
Content-Type: text/html; charset=us-ascii
<P>Hello </P>
<P>My name is Atenea : I´m what to ask you who can I make a program in haskell like une program that say hello word </P><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://personal.mail.yahoo.com/?.refer=mailiyfoot">Yahoo! Mail Personal Address</a> -
Get email at your own domain with Yahoo! Mail.
--0-1558094891-985735950=:95280--
From ate2882@yahoo.com Tue Mar 27 23:36:03 2001
Date: Tue, 27 Mar 2001 15:36:03 -0800 (PST)
From: Atenea Azcue ate2882@yahoo.com
Subject: (no subject)
--0-1194470999-985736163=:38095
Content-Type: text/plain; charset=us-ascii
Hello
My name is Atenea . I just want to ask you that how can i Creat a program that just say "hello word" and another that can add a "matrix" if you can help me I would really going to apreciate please. Thank you for your listening
---------------------------------
Do You Yahoo!?
Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! Mail.
--0-1194470999-985736163=:38095
Content-Type: text/html; charset=us-ascii
<P>Hello </P>
<P>My name is Atenea . I just want to ask you that how can i Creat a program that just say "hello word" and another that can add a "matrix" if you can help me I would really going to apreciate please. Thank you for your listening </P><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://personal.mail.yahoo.com/?.refer=mailiyfoot">Yahoo! Mail Personal Address</a> -
Get email at your own domain with Yahoo! Mail.
--0-1194470999-985736163=:38095--
From shlomif@vipe.technion.ac.il Wed Mar 28 04:23:27 2001
Date: Wed, 28 Mar 2001 06:23:27 +0200 (IST)
From: Shlomi Fish shlomif@vipe.technion.ac.il
Subject: (no subject)
On Tue, 27 Mar 2001, Atenea Azcue wrote:
>=20
> Hello=20
>=20
> My name is Atenea : I=B4m what to ask you who can I make a program in ha=
skell=20
> like une program that say hello word=20
>=20
main =3D putStr "Hello, World!"
Regards,
=09Shlomi Fish
>=20
>=20
> ---------------------------------
> Do You Yahoo!?
> Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! M=
ail.
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il=20
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of=20
converting any statement that follows it into a true one.
From shlomif@vipe.technion.ac.il Wed Mar 28 04:36:14 2001
Date: Wed, 28 Mar 2001 06:36:14 +0200 (IST)
From: Shlomi Fish shlomif@vipe.technion.ac.il
Subject: (no subject)
On Tue, 27 Mar 2001, Atenea Azcue wrote:
>
> Hello
>
> My name is Atenea . I just want to ask you that how can i Creat a program
> that just say "hello word" and another that can add a "matrix" if you
> can
>help me I would really going to apreciate please. Thank you for your
> listening
>
It depends if your matrix is represented as a list of lists or a
two-dimensional array. For lists it is something like that:
plus (a,b) = a+b
plus_vec ([],[]) = []
plus_vec (a:as,b:bs) = (plus (a,b)):(plus_vec (as,bs))
vector_add a b = (map plus (zip a b))
matrix_add a b = (map plus_vec (zip a b))
It can be done a bit better using classes, but then it will be less easy
to understand.
For 2-D arrays, I believe there is an example in the tutorial that shows
matrix _mulitplication_, so addition should be quite trivial after
understanding that.
Check out: http://www.haskell.org/tutorial/
Regards,
Shlomi Fish
>
>
> ---------------------------------
> Do You Yahoo!?
> Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! Mail.
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From mark@chaos.x-philes.com Wed Mar 28 18:05:46 2001
Date: Wed, 28 Mar 2001 13:05:46 -0500 (EST)
From: Mark Carroll mark@chaos.x-philes.com
Subject: Printed Haskell 98 Report
I don't suppose it's possible to get a reasonable printed copy of the
Haskell 98 Report and Haskell 98 Library Report at a sensible price, is
it? Just wondering, before I go pricing printing and binding. Thanks.
-- Mark
From Malcolm.Wallace@cs.york.ac.uk Thu Mar 29 09:21:18 2001
Date: Thu, 29 Mar 2001 10:21:18 +0100
From: Malcolm Wallace Malcolm.Wallace@cs.york.ac.uk
Subject: Printed Haskell 98 Report
> I don't suppose it's possible to get a reasonable printed copy of the
> Haskell 98 Report and Haskell 98 Library Report at a sensible price, is
> it? Just wondering, before I go pricing printing and binding. Thanks.
The Haskell Reports are freely re-distributable, so I'm not aware
of anyone offering to sell them.
However, they aren't very long, so the cost of printing and binding
should not be excessive. 120 pages double-sided, I reckon should
be less than 10 UKP (15 USD) per copy cost-price.
One caution however. Simon PJ has been promising to issue a new,
corrected edition of the Reports (essentially to incorporate the
accumulated errata). Before you print a hundred copies, you might like
to check how soon the corrected version will be publically available.
Regards,
Malcolm
From ingo@ele.kth.se Thu Mar 29 15:10:10 2001
Date: Thu, 29 Mar 2001 17:10:10 +0200 (MET DST)
From: Ingo Sander ingo@ele.kth.se
Subject: Instances of Read and Show
I have a question concerning the Read and Show classes.
I have read the Haskell 98 report (section 6.3.3 The Read and Show
Classes), but I still do not figure out how to make instances.
I have a simple data type:
data TVal a = Abst
| Prst a
I managed to define the function show, so that I can use it with the data
type TVal
instance (Show a) => Show (TVal a) where
show Abst = "_"
show (Prst x) = show x
Signals> [Prst 1, Abst, Prst 2]
[1,_,2] :: [TVal Integer]
which is what I want to have.
But how do I make a Read instance?
I still do not understand the meaning of 'readsPrec' and
'readList' (and not of 'showPrec' and 'showList') either.
Can somebody explain to me or give me a good reference so that I can make
TVal an instance of the classes Read and Show.
Thanks in advance for your help!
Ingo Sander
From fruehr@willamette.edu Fri Mar 30 00:36:54 2001
Date: Thu, 29 Mar 2001 16:36:54 -0800 (PST)
From: Fritz K Ruehr fruehr@willamette.edu
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
Forgive me if the following links were announced here and I just missed
them. I found them through the O'Reilley Meerkat "Open Wire Service",
in the "Lambda" channel of the "Lang" category (see:
<http://www.oreillynet.com/meerkat/index.php?&c=4623&t=ALL>
). The first link is the "Lambda Dance" page, presumably inspired by
the infamous "Hamster Dance" (if you don't know the latter, you are
better off for it, so don't ask):
<http://lambdadance.spacebar.org/>
"Beta-reduce the night away", as the site says!
The second link is a little polemic entitled "Why People Aren't Using
Haskell", which I presume would be of interest to readers of this
list (the author is Dejan Jelovic, whom I don't recognize as a regular
contributor here):
<http://www.jelovic.com/articles/why_people_arent_using_haskell.htm>
There are several other interesting looking links on the Meerkat
site ("Moving FP from Academia", "Object Functional Patterns", etc.),
but I will let you investigate on your own. Enjoy ...
-- Fritz Ruehr, still humming to the lambda dance
From karczma@info.unicaen.fr Fri Mar 30 10:28:01 2001
Date: Fri, 30 Mar 2001 11:28:01 +0100
From: Jerzy Karczmarczuk karczma@info.unicaen.fr
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
Fritz K Ruehr wrote:
...
> The second link is a little polemic entitled "Why People Aren't Using
> Haskell", which I presume would be of interest to readers of this
> list (the author is Dejan Jelovic, whom I don't recognize as a regular
> contributor here):
>
> <http://www.jelovic.com/articles/why_people_arent_using_haskell.htm>
If you didn't verify this site, forget it. There is NOTHING serious
there.
Over and over again the same silly song, by a person who - visibly -
had never anything to do with functional languages, who thinks now
about hiring some C and java programmers living in Belgrade, but who
writes such silly, incompetent things as:
> And there is an air of staleness: where new versions of these other
> languages appear frequently, the Haskell community is offering you
> Hugs98.
Delovic points out that some languages became "immensely" popular,
as e.g. Ruby, and that Haskell is marginal. Hm. this extremely
orthodox Japanese essence of O-O programming may have some practical
merits, especially those which come from shameless borrowing from
Eiffel, Sather, Clu and Common Lisp, but calling Haskell "marginal"
or "obscure" informs us not what is Haskell, but who is Jelovic.
He accuses the Haskell community of not providing libraries...
==
Perhaps there is *one* point worth mentioning: the necessity to
publish papers about Haskell far from such journals as JFP or HOSC,
but to try to reach DrDobbs etc. I would add: Software: Practice
and experience, and journals on numerical software where one could
show some non-trivial implementations of practical, numerical
algorithms.
Jerzy Karczmarczuk
Caen, France
PS. What is "hamster dance", anyway?
From alex@shop.com Fri Mar 30 14:28:43 2001
Date: Fri, 30 Mar 2001 09:28:43 -0500 (Eastern Standard Time)
From: S. Alexander Jacobson alex@shop.com
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
Jerszy,
Although I think Haskell is a beautiful language, Jelovic is right on his
core points, Haskell implementations don't meet the needs of the working
programmer.
A user can download Python or Perl to his windows or linux computer,
install, and very quickly be up and running writing code that calls system
libraries, talks to mysql databases, retrieves XML content from the web and parses
it, etc.
Moreover, if the default libraries don't meet his/her needs, it is easy
to find additional libraries on the web, and when found, there is a high
likelyhood that they will work as advertised with the installed system.
Contrast the above with Haskell, which doesn't immediately, easily and
reliably install on all platforms (perhaps aside from Hugs), is still
figuring out core language features,and does not even have a consistent
set of libraries for simple stuff like filesystem access!
There are, perhaps good reasons for all these failures, but please
recognize them for what they are: failures to meet the needs of the
working programmer who just wants to get something done (whether he/she
lives in YU, FR, JP, or US)
I would love to be using Haskell for day to day programming work but I
can't at this time. Unless the community recognizes what is required and
gets it done, I never will.
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
On Fri, 30 Mar 2001, Jerzy Karczmarczuk wrote:
> Fritz K Ruehr wrote:
>
> ...
>
> > The second link is a little polemic entitled "Why People Aren't Using
> > Haskell", which I presume would be of interest to readers of this
> > list (the author is Dejan Jelovic, whom I don't recognize as a regular
> > contributor here):
> >
> > <http://www.jelovic.com/articles/why_people_arent_using_haskell.htm>
>
> If you didn't verify this site, forget it. There is NOTHING serious
> there.
>
> Over and over again the same silly song, by a person who - visibly -
> had never anything to do with functional languages, who thinks now
> about hiring some C and java programmers living in Belgrade, but who
> writes such silly, incompetent things as:
>
> > And there is an air of staleness: where new versions of these other
> > languages appear frequently, the Haskell community is offering you
> > Hugs98.
>
>
> Delovic points out that some languages became "immensely" popular,
> as e.g. Ruby, and that Haskell is marginal. Hm. this extremely
> orthodox Japanese essence of O-O programming may have some practical
> merits, especially those which come from shameless borrowing from
> Eiffel, Sather, Clu and Common Lisp, but calling Haskell "marginal"
> or "obscure" informs us not what is Haskell, but who is Jelovic.
> He accuses the Haskell community of not providing libraries...
>
> ==
>
> Perhaps there is *one* point worth mentioning: the necessity to
> publish papers about Haskell far from such journals as JFP or HOSC,
> but to try to reach DrDobbs etc. I would add: Software: Practice
> and experience, and journals on numerical software where one could
> show some non-trivial implementations of practical, numerical
> algorithms.
>
> Jerzy Karczmarczuk
> Caen, France
>
>
> PS. What is "hamster dance", anyway?
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From simonmar@microsoft.com Fri Mar 30 15:22:56 2001
Date: Fri, 30 Mar 2001 16:22:56 +0100
From: Simon Marlow simonmar@microsoft.com
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
> There are, perhaps good reasons for all these failures, but please
> recognize them for what they are: failures to meet the needs of the
> working programmer who just wants to get something done=20
> (whether he/she
> lives in YU, FR, JP, or US)
>=20
> I would love to be using Haskell for day to day programming work but I
> can't at this time. Unless the community recognizes what is=20
> required and
> gets it done, I never will.
There is one good reason that Haskell fails in these areas, and that's
shortage of effort.
We in the GHC team are actively trying to encourage our users to
contribute: with an open CVS source tree, open development mailing
lists, etc. We've had some good results (thanks to our developers!),
but we need more. GHC is a large and complex system, and with trying to
be all things to all people - a research vehicle / experimentation
platform / production compiler, our developer resources are stretched a
bit thin. I'm sure this goes for the other Haskell systems too.
I see libraries as the biggest missing piece in the Haskell language.
Let's face it, Joe Programmer isn't going to pass Haskell by just
because it doesn't support a particular flavour of overlapping instance
declarations. But he might if it doesn't have a networking library, or
unicode support, or an XML parser. Please, join libraries@haskell.org.
</rant>
Cheers,
Simon
From heringto@cs.unc.edu Fri Mar 30 15:28:15 2001
Date: Fri, 30 Mar 2001 10:28:15 -0500
From: Dean Herington heringto@cs.unc.edu
Subject: Instances of Read and Show
--------------74E5E9480E30AA4DD6791F2C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ingo Sander wrote:
> I have a question concerning the Read and Show classes.
>
> I have read the Haskell 98 report (section 6.3.3 The Read and Show
> Classes), but I still do not figure out how to make instances.
>
> I have a simple data type:
>
> data TVal a = Abst
> | Prst a
>
> I managed to define the function show, so that I can use it with the data
> type TVal
>
> instance (Show a) => Show (TVal a) where
> show Abst = "_"
> show (Prst x) = show x
>
> Signals> [Prst 1, Abst, Prst 2]
> [1,_,2] :: [TVal Integer]
>
> which is what I want to have.
>
> But how do I make a Read instance?
>
> I still do not understand the meaning of 'readsPrec' and
> 'readList' (and not of 'showPrec' and 'showList') either.
>
> Can somebody explain to me or give me a good reference so that I can make
> TVal an instance of the classes Read and Show.
>
> Thanks in advance for your help!
>
> Ingo Sander
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
I might do it this way:
> data TVal a = Abst | Prst a
> instance (Show a) => Show (TVal a) where
> showsPrec p Abst = ('_' :)
> showsPrec p (Prst x) = showsPrec p x
> instance (Read a) => Read (TVal a) where
> readsPrec p s = case s' of ('_':t) -> (Abst,t) : readsA
> _ -> readsA
> where s' = dropWhile isSpace s
> readsA = map (\(a,t)-> (Prst a,t)) (readsPrec p s')
See section D.4 of the Haskell report for information on 'readsPrec',
'readList', 'showPrec', and 'showList'.
Dean Herington
--------------74E5E9480E30AA4DD6791F2C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Ingo Sander wrote:
<blockquote TYPE=CITE>I have a question concerning the Read and Show classes.
<p>I have read the Haskell 98 report (section 6.3.3 The Read and Show
<br>Classes), but I still do not figure out how to make instances.
<p>I have a simple data type:
<p>data TVal a = Abst
<br>
| Prst a
<p>I managed to define the function show, so that I can use it with the
data
<br>type TVal
<p>instance (Show a) => Show (TVal a) where
<br> show Abst
= "_"
<br> show (Prst x) = show
x
<p>Signals> [Prst 1, Abst, Prst 2]
<br>[1,_,2] :: [TVal Integer]
<p>which is what I want to have.
<p>But how do I make a Read instance?
<p>I still do not understand the meaning of 'readsPrec' and
<br>'readList' (and not of 'showPrec' and 'showList') either.
<p>Can somebody explain to me or give me a good reference so that I can
make
<br>TVal an instance of the classes Read and Show.
<p>Thanks in advance for your help!
<p>Ingo Sander
<p>_______________________________________________
<br>Haskell-Cafe mailing list
<br>Haskell-Cafe@haskell.org
<br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a></blockquote>
<p><br>I might do it this way:
<p><tt>> data TVal a = Abst | Prst a</tt>
<br><tt> </tt>
<br><tt>> instance (Show a) => Show (TVal a) where</tt>
<br><tt>> showsPrec p Abst = ('_' :)</tt>
<br><tt>> showsPrec p (Prst x) = showsPrec p x</tt><tt></tt>
<p><tt>> instance (Read a) => Read (TVal a) where</tt>
<br><tt>> readsPrec p s = case s' of ('_':t) ->
(Abst,t) : readsA</tt>
<br><tt>>
_ -> readsA</tt>
<br><tt>> where s' = dropWhile isSpace
s</tt>
<br><tt>>
readsA = map (\(a,t)-> (Prst a,t)) (readsPrec p s')</tt>
<p>See section D.4 of the Haskell report for information on 'readsPrec',
'readList', 'showPrec', and 'showList'.
<p>Dean Herington</html>
--------------74E5E9480E30AA4DD6791F2C--
From Tom.Pledger@peace.com Sat Mar 31 04:41:50 2001
Date: Sat, 31 Mar 2001 16:41:50 +1200
From: Tom Pledger Tom.Pledger@peace.com
Subject: constants and functions without arguments
Andreas Leitner writes:
:
| The classic examlple for this is class POINT, which has an interface
| like that:
| --
| POINT
| -- group 1
| x: DOUBLE
| y: DOUBLE
| -- group 2
| rho: DOUBLE
| abs: DOUBLE
| --
| Now, you can choose to either implement group 1 as attributes, or
| group 2 and calculate the other one. With the uniform access
| principle, which says that accessing attributes and functions with no
| arguments happen in the same syntactic way, you can change the
| implementaion without notice. No user of this class needs to know.
|
| I am to new to FP to say whether this is equaly important in
| FP-languages, since the semantics are different (constants vs.
| attributes and immutable values vs. objects), but for now I am just
| currious wether it is possible theoretically.
That uniformity of access can certainly be achieved in Haskell.
Here's the Point example. I've done it with two constructors so as to
get fewer floating point imprecisions, but some other possible
representations (e.g. one with only the Polar constructor) would look
identical outside the module.
module Point(Point, cartesian, polar, x, y, r, theta) where
-- data type with hidden constructors
data Point = Cartesian Double Double -- corresponds to group 1
| Polar Double Double -- corresponds to group 2
-- proxy constructor functions
cartesian x y = Cartesian x y
polar r theta = Polar r theta
-- attribute extraction functions
x (Cartesian x y) = x
x (Polar r theta) = r * cos theta
y (Cartesian x y) = y
y (Polar r theta) = r * sin theta
r (Cartesian x y) = sqrt (x*x + y*y)
r (Polar r theta) = r
theta (Cartesian x y) = atan2 y x
theta (Polar r theta) = theta
From simonpj@microsoft.com Thu Mar 1 11:21:54 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 1 Mar 2001 03:21:54 -0800
Subject: FW: Pattern guards vs. case (was, unfortunately :Re: interesting
example of laziness/ghc optimisation)
Message-ID: <37DA476A2BC9F64C95379BF66BA2690260DBB3@red-msg-09.redmond.corp.microsoft.com>
| * * * Ketil Malde wrote:
|
| > ut - the converse is not true, is it? I can write
| >
| > ... = case foo of
| > (Foo f) -> ...
| > (Bar b) -> ...
| >
| > ut I can't express that as a pattern-guarded expression, can I?
Check out http://research.microsoft.com/~simonpj/Haskell/guards.html
which is implemented in GHC. Thus
f x | Foo a <- x = ...
| Bar b <- x = ...
Simon
From ralf@cs.uu.nl Thu Mar 1 13:39:32 2001
From: ralf@cs.uu.nl (Ralf Hinze)
Date: Thu, 01 Mar 2001 14:39:32 +0100
Subject: Literate Programming in Haskell?
References:
Message-ID: <3A9E5114.363543A1@cs.uu.nl>
Patrik Jansson wrote:
> A tool I am using is Ralf Hinze's
>
> http://www.informatik.uni-bonn.de/~ralf/Literate.tar.gz
>
> http://www.informatik.uni-bonn.de/~ralf/Guide.ps.gz
>
> It transforms .lhs files (with some formatting commands in LaTeX-style
> comments) to LaTeX. Development based on this idea is something I would be
> willing to participate in as I already have a fair amount of Haskell
> code/articles (read: my PhD thesis;-) in this format.
>
> Maybe Ralf can say something about his views on further development of
> lhs2tex (copyright etc.) by other people (us?).
[Sorry for the delay.]
In principle, everyone can use and/or modify the program to adjust it to
her needs.
However, since I use lhs2text almost daily, I am willing to maintain the
program.
So if you have suggestions, proposals etc please let me know.
Cheers, Ralf
From conal@microsoft.com Thu Mar 1 23:15:17 2001
From: conal@microsoft.com (Conal Elliott)
Date: Thu, 1 Mar 2001 15:15:17 -0800
Subject: Literate Programming in Haskell?
Message-ID:
Has anyone gotten Ralf's lhs2tex to work under Windows? I compiled it up
with GHC 4.08.1 and then GHC 4.08.2, on Windows 2k pro, and it appears to
fail in all of its file reads. Haven't yet isolated a small bug example to
report.
- Conal
-----Original Message-----
From: Ralf Hinze [mailto:ralf@cs.uu.nl]
Sent: Thursday, March 01, 2001 5:40 AM
To: Patrik Jansson
Cc: haskell-cafe@haskell.org
Subject: Re: Literate Programming in Haskell?
Patrik Jansson wrote:
> A tool I am using is Ralf Hinze's
>
> http://www.informatik.uni-bonn.de/~ralf/Literate.tar.gz
>
> http://www.informatik.uni-bonn.de/~ralf/Guide.ps.gz
>
> It transforms .lhs files (with some formatting commands in LaTeX-style
> comments) to LaTeX. Development based on this idea is something I would be
> willing to participate in as I already have a fair amount of Haskell
> code/articles (read: my PhD thesis;-) in this format.
>
> Maybe Ralf can say something about his views on further development of
> lhs2tex (copyright etc.) by other people (us?).
[Sorry for the delay.]
In principle, everyone can use and/or modify the program to adjust it to
her needs.
However, since I use lhs2text almost daily, I am willing to maintain the
program.
So if you have suggestions, proposals etc please let me know.
Cheers, Ralf
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
From dpt@math.harvard.edu Fri Mar 2 17:29:09 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Fri, 2 Mar 2001 12:29:09 -0500
Subject: Literate Programming in Haskell?
In-Reply-To: <3A9E5114.363543A1@cs.uu.nl>; from ralf@cs.uu.nl on Thu, Mar 01, 2001 at 02:39:32PM +0100
References: <3A9E5114.363543A1@cs.uu.nl>
Message-ID: <20010302122909.C15005@math.harvard.edu>
On Thu, Mar 01, 2001 at 02:39:32PM +0100, Ralf Hinze wrote:
> In principle, everyone can use and/or modify the program to adjust
> it to her needs. However, since I use lhs2text almost daily, I am
> willing to maintain the program. So if you have suggestions,
> proposals etc please let me know.
From my cursory glance, it looked quite interesting, but I was
disturbed by the changes required in the TeX source that didn't refer
to Haskell at all. Is there any way to improve that situation?
Best,
Dylan Thurston
From wohlstad@cs.ucdavis.edu Thu Mar 8 05:29:30 2001
From: wohlstad@cs.ucdavis.edu (Eric Allen Wohlstadter)
Date: Wed, 7 Mar 2001 21:29:30 -0800 (PST)
Subject: Summer School on Functional Programming?
Message-ID:
I was wondering if anyone knew if there was going to be a summer school on
functional programming this year. Also, where would I find information
about it? Thanks.
Eric Wohlstadter
UCDavis Software Engineering
From johanj@cs.uu.nl Thu Mar 8 10:46:09 2001
From: johanj@cs.uu.nl (Johan Jeuring)
Date: Thu, 08 Mar 2001 11:46:09 +0100
Subject: Summer School on Functional Programming?
In-Reply-To:
Message-ID: <20010308104610.09CA4453F@mail.cs.uu.nl>
>I was wondering if anyone knew if there was going to be a summer school on
>functional programming this year. Also, where would I find information
>about it? Thanks.
I don't think a summer school on advanced functional programming will be
organised this year. Maybe next year, but as far as I know nothing
has been decided yet. I will try to start up something (which doesn't mean
I will organise it!) soon.
-- Johan Jeuring
From wohlstad@cs.ucdavis.edu Fri Mar 9 02:18:46 2001
From: wohlstad@cs.ucdavis.edu (Eric Allen Wohlstadter)
Date: Thu, 8 Mar 2001 18:18:46 -0800 (PST)
Subject: zips and maps
Message-ID:
I find myself very often needing to use this function and was wondering if
there was already a way to do this using zip,maps, and folds.
zipMap::[a->b]->[a]->[b]
zipMap [] _ = []
zipMap _ [] = []
zipMap (f:fs) (x:xs) = (f x):(zipMap fs xs)
Alternatively I can get the same affect like this:
fstOnSnd::(a->b,a)->b
fstOnSnd (f,x) = f x
zipMap::[a->b]->[a]->[b]
zipMap fs xs = map fstOnSnd (zip fs xs)
Both require me to invent some new function (or use a lambda) which I am
trying to avoid. If it is unavoidable then can someone think of a better
name then zipMap?
Eric Wohlstadter
UCDavis Software Engineering
From elf@sandburst.com Fri Mar 9 02:29:51 2001
From: elf@sandburst.com (Mieszko Lis)
Date: Thu, 08 Mar 2001 21:29:51 -0500
Subject: zips and maps
References:
Message-ID: <3AA8401F.6CFE7431@sandburst.com>
Eric Allen Wohlstadter wrote:
>
> I find myself very often needing to use this function and was wondering if
> there was already a way to do this using zip,maps, and folds.
Do you mind using zipWith? How about
zipMap = zipWith ($)
..?
-- Mieszko
From timd@macquarie.com.au Fri Mar 9 02:31:24 2001
From: timd@macquarie.com.au (Timothy Docker)
Date: Fri, 9 Mar 2001 13:31:24 +1100 (EST)
Subject: zips and maps
In-Reply-To:
References:
Message-ID: <15016.16356.929529.112635@tcc2>
Eric Allen Wohlstadter writes:
> I find myself very often needing to use this function and was wondering if
> there was already a way to do this using zip,maps, and folds.
>
> zipMap::[a->b]->[a]->[b]
> zipMap [] _ = []
> zipMap _ [] = []
> zipMap (f:fs) (x:xs) = (f x):(zipMap fs xs)
>
....
> Both require me to invent some new function (or use a lambda) which I am
> trying to avoid. If it is unavoidable then can someone think of a better
> name then zipMap?
The following is more concise, and probably how I would do it:
zipMap :: [a->b] -> [a] -> [b]
zipMap = zipWith ($)
Cheers,
Tim
From conal@microsoft.com Fri Mar 9 02:36:26 2001
From: conal@microsoft.com (Conal Elliott)
Date: Thu, 8 Mar 2001 18:36:26 -0800
Subject: zips and maps
Message-ID:
How about zipMap = zipWith ($)
- Conal
-----Original Message-----
From: Eric Allen Wohlstadter [mailto:wohlstad@cs.ucdavis.edu]
Sent: Thursday, March 08, 2001 6:19 PM
To: haskell-cafe@haskell.org
Subject: zips and maps
I find myself very often needing to use this function and was wondering if
there was already a way to do this using zip,maps, and folds.
zipMap::[a->b]->[a]->[b]
zipMap [] _ = []
zipMap _ [] = []
zipMap (f:fs) (x:xs) = (f x):(zipMap fs xs)
Alternatively I can get the same affect like this:
fstOnSnd::(a->b,a)->b
fstOnSnd (f,x) = f x
zipMap::[a->b]->[a]->[b]
zipMap fs xs = map fstOnSnd (zip fs xs)
Both require me to invent some new function (or use a lambda) which I am
trying to avoid. If it is unavoidable then can someone think of a better
name then zipMap?
Eric Wohlstadter
UCDavis Software Engineering
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
From conal@microsoft.com Fri Mar 9 15:07:55 2001
From: conal@microsoft.com (Conal Elliott)
Date: Fri, 9 Mar 2001 07:07:55 -0800
Subject: zips and maps
Message-ID:
Note also that zipMap is the classic S combinatory if you think of lists as
functions over the natural numbers, so there's something especially
compelling about it. Similarly, repeat is K. From zipMap & repeat, you can
easily define map, zip, zipWith, zipWith3, etc.
s = zipWith ($)
k = repeat
mapT f xs = s (k f) xs
zipWithT f as bs = s (mapT f as) bs
zipT = zipWithT (,)
zipWith3T f as bs cs = s (zipWithT f as bs) cs
- Conal
-----Original Message-----
From: Mieszko Lis [mailto:elf@sandburst.com]
Sent: Thursday, March 08, 2001 6:30 PM
To: Eric Allen Wohlstadter
Cc: haskell-cafe@haskell.org
Subject: Re: zips and maps
Eric Allen Wohlstadter wrote:
>
> I find myself very often needing to use this function and was wondering if
> there was already a way to do this using zip,maps, and folds.
Do you mind using zipWith? How about
zipMap = zipWith ($)
..?
-- Mieszko
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
From sievers@ips.cs.tu-bs.de Fri Mar 9 15:50:30 2001
From: sievers@ips.cs.tu-bs.de (Christian Sievers)
Date: Fri, 9 Mar 2001 16:50:30 +0100 (MET)
Subject: zips and maps
In-Reply-To: <3AA8401F.6CFE7431@sandburst.com>
References:
<3AA8401F.6CFE7431@sandburst.com>
Message-ID: <15016.64193.306830.744513@infbsps3.ips.cs.tu-bs.de>
Mieszko Lis (and others) wrote:
> zipMap = zipWith ($)
which is even in the report (end of section 6.2).
Interestingly, there is also a shorter, though rather unreadable
definition:
zipMap = zipWith id
Christian Sievers
From v-julsew@microsoft.com Mon Mar 12 11:46:31 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Mon, 12 Mar 2001 03:46:31 -0800
Subject: GHC HQ are looking for a Linux-IA64 box
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F22EF@red-msg-06.redmond.corp.microsoft.com>
[Apologies if you get multiple copies of this msg.]
Folks,
Following a recent discussion about future development directions
for GHC, it seems one thing we want to start thinking about is
support for the IA64 architecture.
Does any kind person have an IA64 box, running Linux, on which we could
have an account? The extent of the work would be to make GHC's
runtime-support system work again on a 64-bit platform (it used to),
and possibly to build an IA64 native code generator. This work would
be spread across a couple of months, I imagine.
Basic requirements are:
* IA64 Linux box, with development tools (gcc, perl, autoconf, gdb,
etc -- all the usual Linux/Unix stuff).
* As many spare processor cycles as possible. GHC building/debugging
tends to CPU intensive. Also, probably at least 256MB of memory would
be necessary to keep us out of trouble.
* At a bare minimum, 300 MB of free disk space; 1 GB would be
preferable, since it would allow more thorough testing of the
system.
* Decent, permanent, reliable internet connection from so that we can=20
work remotely (obviously) and so that we can talk to our CVS server.
I'd say at a bare minimum a 128 kb/sec connection. Preferably
as few as possible network hops from Cambridge, UK.
This work is likely to be on-and-off (not all the time) over a couple
of months, I'd guess. We probably won't be ready to start on it for=20
at least a month, so some time around the start of May would be when=20
we'd really want to start moving on this.
Availability of such a machine would be a useful contribution to
the GHC development effort, so we'd be grateful if any of you could
point us in the right direction.
J
(speaking for the GHC crew as a whole)
From fjh@cs.mu.oz.au Mon Mar 12 16:28:38 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Tue, 13 Mar 2001 03:28:38 +1100
Subject: GHC HQ are looking for a Linux-IA64 box
In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60F22EF@red-msg-06.redmond.corp.microsoft.com>; from Julian Seward (Intl Vendor) on Mon, Mar 12, 2001 at 03:46:31AM -0800
References: <68B95AA1648D1840AB0083CC63E57AD60F22EF@red-msg-06.redmond.corp.microsoft.com>
Message-ID: <20010313032838.A22945@murlibobo.cs.mu.OZ.AU>
On 12-Mar-2001, Julian Seward (Intl Vendor) wrote:
>
> Does any kind person have an IA64 box, running Linux, on which we could
> have an account?
You might want to check out SourceForge: .
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From usmoeliu@mcs.drexel.edu Wed Mar 14 01:55:56 2001
From: usmoeliu@mcs.drexel.edu (Samuel E. Moelius III)
Date: Tue, 13 Mar 2001 19:55:56 -0600
Subject: Linearity Requirement for Patterns
Message-ID:
What is the reasoning for the requirement that patterns be linear? Am I
correct to say that if non-linear patterns were allowed, it would require
equality to be defined for all data types? Is this the reason, or are there
others?
Sam Moelius
From brian@boutel.co.nz Sat Mar 17 02:49:15 2001
From: brian@boutel.co.nz (Brian Boutel)
Date: Sat, 17 Mar 2001 15:49:15 +1300
Subject: Linearity Requirement for Patterns
References:
Message-ID: <3AB2D0AB.7E083590@boutel.co.nz>
"Samuel E. Moelius III" wrote:
>
> What is the reasoning for the requirement that patterns be linear? Am I
> correct to say that if non-linear patterns were allowed, it would require
> equality to be defined for all data types? Is this the reason, or are there
> others?
>
If that were the reason, then to be consistent, there would be no
literals in patterns, as these are tested using equality.
Here is a reason. Some people believe that the equations that form a
function definition should be disjoint. A good reason for this view is
that fold/unfold transformations can be then performed without reference
to the other cases in the definition - if it matches, it is correct to
use it. Although Haskell does not require disjoint cases, and defines
the semantics in terms of a top-to-bottom testing order, the rejection
of non-linear patterns was largely because it is not generally possible
to specify, as a pattern, the complement of the set of values that match
a non-linear pattern, and so not possible to write a set of disjoint
case equations if non-linear patterns occur.
In any case, the same effect can be obtained using guards, where the
extra power of expression syntax solves the problem. Instead of
f x x = e1
f (illegal pattern) = e2
...
you can write the single equation
f x y | x == y = e1
| x /= y = e2
--brian
From dpt@math.harvard.edu Sat Mar 17 04:14:17 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Fri, 16 Mar 2001 23:14:17 -0500
Subject: Linearity Requirement for Patterns
In-Reply-To: <3AB2D0AB.7E083590@boutel.co.nz>; from brian@boutel.co.nz on Sat, Mar 17, 2001 at 03:49:15PM +1300
References: <3AB2D0AB.7E083590@boutel.co.nz>
Message-ID: <20010316231417.A26366@abel.math.harvard.edu>
On Sat, Mar 17, 2001 at 03:49:15PM +1300, Brian Boutel wrote:
> "Samuel E. Moelius III" wrote:
> >
> > What is the reasoning for the requirement that patterns be linear? Am I
> > correct to say that if non-linear patterns were allowed, it would require
> > equality to be defined for all data types? Is this the reason, or are there
> > others?
>
> If that were the reason, then to be consistent, there would be no
> literals in patterns, as these are tested using equality.
Only numeric literals actually use the '==' operator, correct? (As
opposed to built-in equality for data constructors and characters.)
--Dylan Thurston
From mc991008@pgc.edu Sat Mar 17 07:23:55 2001
From: mc991008@pgc.edu (mc991008)
Date: Sat, 17 Mar 2001 12:23:55 +0500
Subject: (no subject)
Message-ID: <200103170724.f2H7OqS10969@isb.comsats.net.pk>
hello, i'm a student of computer science in a known university of
pakistan. in this
semester i'm doing a course on "programming methodology". in this
course i had
given a project on learning haskell, a functional language and to give
a comparison on
haskell with prolog. if u plz kindly guide me and help me out, i'll be
very thankful to u.
looking forward soon from u
bye
amara hussain
mc991008@pgc.edu
From qrczak@knm.org.pl Sat Mar 17 07:43:10 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 17 Mar 2001 07:43:10 GMT
Subject: Linearity Requirement for Patterns
References: <3AB2D0AB.7E083590@boutel.co.nz> <20010316231417.A26366@abel.math.harvard.edu>
Message-ID:
Fri, 16 Mar 2001 23:14:17 -0500, Dylan Thurston pisze:
> > If that were the reason, then to be consistent, there would be no
> > literals in patterns, as these are tested using equality.
>
> Only numeric literals actually use the '==' operator, correct?
Yes. This is a hack which allows viewing numeric types as algebraic
types with many constructors, assuming that (==) definition is sane.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From brian@boutel.co.nz Sat Mar 17 09:22:46 2001
From: brian@boutel.co.nz (Brian Boutel)
Date: Sat, 17 Mar 2001 22:22:46 +1300
Subject: Linearity Requirement for Patterns
References: <3AB2D0AB.7E083590@boutel.co.nz> <20010316231417.A26366@abel.math.harvard.edu>
Message-ID: <3AB32CE6.BB6077C2@boutel.co.nz>
Dylan Thurston wrote:
>
>
>
> Only numeric literals actually use the '==' operator, correct?
> (As opposed to built-in equality for data constructors and characters.)
>
I should have been more specific. Not that it affects the point being
made, and I didn't want to lose that in the detail.
Pattern matching for numeric literals uses whatever (==) has been
defined for the type, except, of course for the literals in n+k patterns
where (>=) is used.
The Character type is treated as a set of data constructors. Data
constructors match if they are the same constructor, and fail to match
otherwise. This is not the same as equality, where you are free to
define any result when comparing values, but it is the same as the
equality that would be derived for a type that consisted of a set of
nullary constructors.
String literals are lists of characters. Consequently, string matching
will use constructor matching for the List constructors and for the
characters.
So, yes, (==) is used when matching most numeric literals, and not used
for other literals.
--brian
From biotechinfo2004@yahoo.com Sun Mar 18 01:02:09 2001
From: biotechinfo2004@yahoo.com (biotechinfo2004@yahoo.com)
Date: Sun, 18 Mar 2001 01:02:09
Subject: FREE Biotech Stock Info! 298
Message-ID: <708.315785.863814@excite.com>
Do you want to capitalize on the Biotech Revolution
Do
you want to capitalize on the Biotech Revolution? Would you like to add
groundbreaking biotech, pharmaceutical and medical device companies to your
portfolio mix? Does hearing about exciting IPO and private placement offerings
from life sciences companies interest you?
The
exclusive Ruddy-Carlisle Biotech Infoline service keeps you abreast of
investment opportunities in the life sciences space. Just sign up for it once
and get important information instantly delivered to study at your leisure. Our
service is 100% FREE! Sign
up!
Ruddy-Carlisle
Biotech Infoline:
- Instantly
delivers key life sciences investment information directly to you!
- Learn
about biotech, pharmaceutical & medical device investment opportunities
before others!
- Includes
IPO & private placement information!
- 100%
FREE!
For
the entire last decade there were only three profitable biotech companies. At
the end of this year, ten are projected. At the end of 2003, over forty
are projected! The genomic promise is about to be delivered and investors know
it. The Ruddy-Carlisle Biotech Infoline provides you with critical,
decision-making, information that aids the chance of investment success in this
lucrative space. Sign
up!
Please
Note- Your information will only be
shared with companies that are in the life sciences space and pass our
rigorous inspection. Only the best opportunities will come to you.
Ruddy-Carlisle respects your privacy. Sign
up!
List Removal Instructions- Simply click here: remove
to be instantly and permanently removed from our list. Send the blank email to
the address specified. Please do not try to reply to this message.
From shlomif@vipe.technion.ac.il Sun Mar 18 08:43:56 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Sun, 18 Mar 2001 10:43:56 +0200 (IST)
Subject: (no subject)
In-Reply-To: <200103170724.f2H7OqS10969@isb.comsats.net.pk>
Message-ID:
On Sat, 17 Mar 2001, mc991008 wrote:
> hello, i'm a student of computer science in a known university of
> pakistan. in this
> semester i'm doing a course on "programming methodology". in this
> course i had
> given a project on learning haskell, a functional language and to give
> a comparison on
> haskell with prolog. if u plz kindly guide me and help me out, i'll be
> very thankful to u.
> looking forward soon from u
Read http://www.haskell.org/tutorial/ in order to learn Haskell. Can't
tell you about Prolog because I don't know it yet.
Regards,
Shlomi Fish
> bye
> amara hussain
> mc991008@pgc.edu
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From mh@informatik.uni-kiel.de Mon Mar 19 08:38:36 2001
From: mh@informatik.uni-kiel.de (Michael Hanus)
Date: Mon, 19 Mar 2001 09:38:36 +0100 (MET)
Subject: Linearity Requirement for Patterns
In-Reply-To: Brian Boutel's message of March 17 (15:49)
References:
<3AB2D0AB.7E083590@boutel.co.nz>
Message-ID: <15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
Brian Boutel wrote:
> In any case, the same effect can be obtained using guards, where the
> extra power of expression syntax solves the problem. Instead of
> f x x = e1
> f (illegal pattern) = e2
> ...
>
> you can write the single equation
>
> f x y | x == y = e1
> | x /= y = e2
It depends on the meaning of pattern matching wrt. non-linear
patterns. The standard notion (e.g., term rewriting) matches
a pattern by finding a substitution for the pattern variables
so that the instantiated pattern is identical to the function
call. In this case, it can also match partially defined
functions in contrast to your transformation. For instance,
consider the definitions
g z = 1 + g z
f x x = 0
Then a call like (f (g 0) (g 0)) is reducible to 0
(wrt. standard notion of pattern matching using the instantiation
{x |-> (g 0)}) whereas it is undefined if we transform this definition to
f x y | x==y = 0
(which requires the evaluation of both arguments).
Thus, I would say that non-linear patterns gives you
extra power.
Michael
From brian@boutel.co.nz Mon Mar 19 11:04:50 2001
From: brian@boutel.co.nz (brian boutel)
Date: Mon, 19 Mar 2001 23:04:50 +1200
Subject: Linearity Requirement for Patterns
References:
<3AB2D0AB.7E083590@boutel.co.nz> <15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
Message-ID: <3AB5E7D2.D0713569@boutel.co.nz>
Michael Hanus wrote:
>
> Brian Boutel wrote:
> > In any case, the same effect can be obtained using guards, where the
> > extra power of expression syntax solves the problem. Instead of
> > f x x = e1
> > f (illegal pattern) = e2
> > ...
> >
> > you can write the single equation
> >
> > f x y | x == y = e1
> > | x /= y = e2
>
> It depends on the meaning of pattern matching wrt. non-linear
> patterns. The standard notion (e.g., term rewriting) matches
> a pattern by finding a substitution for the pattern variables
> so that the instantiated pattern is identical to the function
> call. In this case, it can also match partially defined
> functions in contrast to your transformation. For instance,
> consider the definitions
>
> g z = 1 + g z
> f x x = 0
>
> Then a call like (f (g 0) (g 0)) is reducible to 0
> (wrt. standard notion of pattern matching using the instantiation
> {x |-> (g 0)}) whereas it is undefined if we transform this definition to
>
> f x y | x==y = 0
>
> (which requires the evaluation of both arguments).
> Thus, I would say that non-linear patterns gives you
> extra power.
>
I don't think so.
Haskell is not a term rewriting system, and lacks the notion of
syntactic identity of expressions that would be required for your
scheme. If non-linear patterns were to be added, I do not think this
would change, and there would be no increase in power.
Moreover, sometimes your scheme would be less powerful. Consider
f x x = 0
f x y = f x (y+1)
and call f (factorial 5) (15 * 8)
This will be undefined unless you evaluate both arguments before
matching - which you say above that you wish to avoid. And if you do not
eveluate both, you lose referential transparency, for if I substutute
the argument values, and write f 120 120, you would then match the first
case and get 0 instead of bottom.
--brian
From lennart@augustsson.net Mon Mar 19 11:19:57 2001
From: lennart@augustsson.net (Lennart Augustsson)
Date: Mon, 19 Mar 2001 12:19:57 +0100
Subject: Linearity Requirement for Patterns
References:
<3AB2D0AB.7E083590@boutel.co.nz> <15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
Message-ID: <3AB5EB5D.9BE24B7A@augustsson.net>
Michael Hanus wrote:
> g z = 1 + g z
> f x x = 0
>
> Then a call like (f (g 0) (g 0)) is reducible to 0
> (wrt. standard notion of pattern matching using the instantiation
> {x |-> (g 0)}) whereas it is undefined if we transform this definition to
>
> f x y | x==y = 0
>
> (which requires the evaluation of both arguments).
> Thus, I would say that non-linear patterns gives you
> extra power.
Yes, your definition of non-linear patterns would give you extra
power. It would also destroy the nice semantics of Haskell!
By using this facility you can now observe intensional properties
of the term, and the clean denotational semantics crumbles.
E.g., in Haskell you can always replace equals by equals without
changing the meaning of a program. In your example `g 0' is equal
to bottom so it should be possible to replace it by any other bottom
without any change in meaning. But if I define
h x = h x
and evaluate `f (g 0) (h 0)' I will no longer get 0.
So this definitions of non-linear patterns is not an option for a
language that claims to be "referentially transparent" (whatever that means :).
--
-- Lennart
From mh@informatik.uni-kiel.de Mon Mar 19 14:10:24 2001
From: mh@informatik.uni-kiel.de (Michael Hanus)
Date: Mon, 19 Mar 2001 15:10:24 +0100 (MET)
Subject: Linearity Requirement for Patterns
In-Reply-To: Lennart Augustsson's message of March 19 (12:19)
References:
<3AB2D0AB.7E083590@boutel.co.nz>
<15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
<3AB5EB5D.9BE24B7A@augustsson.net>
Message-ID: <15030.4944.608707.884030@petrus.informatik.uni-kiel.de>
Lennart Augustsson wrote:
> Yes, your definition of non-linear patterns would give you extra
> power. It would also destroy the nice semantics of Haskell!
> By using this facility you can now observe intensional properties
> of the term, and the clean denotational semantics crumbles.
>
> E.g., in Haskell you can always replace equals by equals without
> changing the meaning of a program. In your example `g 0' is equal
> to bottom so it should be possible to replace it by any other bottom
> without any change in meaning. But if I define
> h x = h x
> and evaluate `f (g 0) (h 0)' I will no longer get 0.
>
> So this definitions of non-linear patterns is not an option for a
> language that claims to be "referentially transparent" (whatever that means :).
I agree and the question is about "whatever that means"...
Term rewriting systems (TRS) are based on replacing equals by equals
and that could be also considered as "referentially transparent".
Nevertheless, TRSs usually allow non-linear left-hand sides
(but often come with other restrictions like termination).
BTW, (g 0) and (h 0) are not considered as equal since
there are no rules/equations to transform one into the other.
However, I agree that there are good reasons (mainly, operational
simplicity) to allow only linear patterns and constructor-based
rules in a real programming language, since non-linear patterns
or non-constructor-based rules require other and more advanced
operational principles. I only wanted to remark that there is
no simple way to translate non-linear pattterns into linear
patterns in the general case.
Michael
From lennart@augustsson.net Mon Mar 19 14:55:33 2001
From: lennart@augustsson.net (Lennart Augustsson)
Date: Mon, 19 Mar 2001 15:55:33 +0100
Subject: Linearity Requirement for Patterns
References:
<3AB2D0AB.7E083590@boutel.co.nz>
<15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
<3AB5EB5D.9BE24B7A@augustsson.net> <15030.4944.608707.884030@petrus.informatik.uni-kiel.de>
Message-ID: <3AB61DE5.3FEECF39@augustsson.net>
Michael Hanus wrote:
> > E.g., in Haskell you can always replace equals by equals without
> > changing the meaning of a program. In your example `g 0' is equal
> > to bottom so it should be possible to replace it by any other bottom
> > without any change in meaning. But if I define
> > h x = h x
> > and evaluate `f (g 0) (h 0)' I will no longer get 0.
> >
> > So this definitions of non-linear patterns is not an option for a
> > language that claims to be "referentially transparent" (whatever that means :).
>
> I agree and the question is about "whatever that means"...
>
> Term rewriting systems (TRS) are based on replacing equals by equals
> and that could be also considered as "referentially transparent".
Yes, but a TRS has a different semantics than Haskell. In TRS you
manipulate terms, in Haskell you manipulate (the extension) of
functions (OK, OK, there's stuff that looks like constructors, but
it's all encodable as lambda terms).
> Nevertheless, TRSs usually allow non-linear left-hand sides
> (but often come with other restrictions like termination).
> BTW, (g 0) and (h 0) are not considered as equal since
> there are no rules/equations to transform one into the other.
But in Haskell they are equal since their denotations are equal.
> However, I agree that there are good reasons (mainly, operational
> simplicity) to allow only linear patterns and constructor-based
> rules in a real programming language, since non-linear patterns
> or non-constructor-based rules require other and more advanced
> operational principles. I only wanted to remark that there is
> no simple way to translate non-linear pattterns into linear
> patterns in the general case.
I think we are in agreement, I just wanted to point out that if you've
decided on the particular "functional style" semantics that Haskell
has, then you cannot have the kind of non-linear patterns that you
exemplified.
--
-- Lennart
From gruenbacher-lists@geoinfo.tuwien.ac.at Mon Mar 19 16:59:59 2001
From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher)
Date: Mon, 19 Mar 2001 17:59:59 +0100 (CET)
Subject: Coroutines
Message-ID:
Hello,
has anybody thought about how to implement Simula style coroutines in
Haskell? What I have in mind is several "procedures" that communicate via
message passing in a co-operative way. That would give clear and intuitive
code for things like simulations...
Thanks,
Andreas.
------------------------------------------------------------------------
Andreas Gruenbacher gruenbacher@geoinfo.tuwien.ac.at
Research Assistant Phone +43(1)58801-12723
Institute for Geoinformation Fax +43(1)58801-12799
Technical University of Vienna Cell phone +43(664)4064789
From gruenbacher-lists@geoinfo.tuwien.ac.at Mon Mar 19 17:43:55 2001
From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher)
Date: Mon, 19 Mar 2001 18:43:55 +0100 (CET)
Subject: Coroutines
In-Reply-To: <37DA476A2BC9F64C95379BF66BA2690260DC84@red-msg-09.redmond.corp.microsoft.com>
Message-ID:
On Mon, 19 Mar 2001, Simon Peyton-Jones wrote:
> Lazy evaluation *is* coroutines, in a way.
What I had in mind was something like the following (pseudocode), which
could easily be implemented on top of coroutines:
class Channel c t where
send :: t -> c -> IO ()
receive :: c -> IO t
sender :: Int -> Channel -> ...
sender n receiver = do send n receiver
return (sender (n+1) receiver)
receiver :: Channel -> ...
receiver sender = do i <- receive sender
return (receiver sender)
c :: Channel Int
c = ...
main = run_them [ sender 1 c, receiver c ]
Maybe there is also a way to achieve something similar using higher order
functions---I just don't see how.
> Or you may be interested in Concurrent Haskell
> See section 4 of "Tackling the awkward squad"
> http://research.microsoft.com/~simonpj/papers/marktoberdorf.htm
Thanks, I'm chewing on this paper of yours since a couple of days already.
I particularly like the introduction to monads---it's the best I have seen
so far.
--Andreas.
From simonpj@microsoft.com Mon Mar 19 17:14:09 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 19 Mar 2001 09:14:09 -0800
Subject: Coroutines
Message-ID: <37DA476A2BC9F64C95379BF66BA2690260DC84@red-msg-09.redmond.corp.microsoft.com>
Lazy evaluation *is* coroutines, in a way.
Or you may be interested in Concurrent Haskell
See section 4 of "Tackling the awkward squad"
http://research.microsoft.com/~simonpj/papers/marktoberdorf.htm
Simon
| -----Original Message-----
| From: Andreas Gruenbacher [mailto:gruenbacher@geoinfo.tuwien.ac.at]
| Sent: 19 March 2001 17:00
| To: haskell-cafe@haskell.org
| Subject: Coroutines
|=20
|=20
| Hello,
|=20
| has anybody thought about how to implement Simula style coroutines in
| Haskell? What I have in mind is several "procedures" that=20
| communicate via
| message passing in a co-operative way. That would give clear=20
| and intuitive
| code for things like simulations...
|=20
| Thanks,
| Andreas.
|=20
| --------------------------------------------------------------
| ----------
| Andreas Gruenbacher gruenbacher@geoinfo.tuwien.ac.at
| Research Assistant Phone +43(1)58801-12723
| Institute for Geoinformation Fax +43(1)58801-12799
| Technical University of Vienna Cell phone +43(664)4064789
|=20
|=20
| _______________________________________________
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
|=20
From simonpj@microsoft.com Mon Mar 19 17:45:28 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 19 Mar 2001 09:45:28 -0800
Subject: Coroutines
Message-ID: <37DA476A2BC9F64C95379BF66BA2690260DC88@red-msg-09.redmond.corp.microsoft.com>
| What I had in mind was something like the following=20
| (pseudocode), which
| could easily be implemented on top of coroutines:
Concurrent Haskell provides exactly this Channel stuff.
Simon
|=20
| class Channel c t where
| send :: t -> c -> IO ()
| receive :: c -> IO t
|=20
| sender :: Int -> Channel -> ...
| sender n receiver =3D do send n receiver
| return (sender (n+1) receiver)
|=20
| receiver :: Channel -> ...
| receiver sender =3D do i <- receive sender
| return (receiver sender)
|=20
| c :: Channel Int
| c =3D ...
|=20
| main =3D run_them [ sender 1 c, receiver c ]
|=20
|=20
| Maybe there is also a way to achieve something similar using=20
| higher order
| functions---I just don't see how.
|=20
|=20
| > Or you may be interested in Concurrent Haskell
| > See section 4 of "Tackling the awkward squad"
| > http://research.microsoft.com/~simonpj/papers/marktoberdorf.htm
|=20
| Thanks, I'm chewing on this paper of yours since a couple of=20
| days already.
| I particularly like the introduction to monads---it's the=20
| best I have seen
| so far.
|=20
|=20
| --Andreas.
|=20
|=20
From uk1o@rz.uni-karlsruhe.de Mon Mar 19 21:56:48 2001
From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter)
Date: Mon, 19 Mar 2001 22:56:48 +0100
Subject: Coroutines
In-Reply-To: ; from gruenbacher@geoinfo.tuwien.ac.at on Mon, Mar 19, 2001 at 06:43:55PM +0100
References: <37DA476A2BC9F64C95379BF66BA2690260DC84@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <20010319225645.A25257@rz.uni-karlsruhe.de>
Hello!
On Mon, Mar 19, 2001 at 06:43:55PM +0100, Andreas Gruenbacher wrote:
> On Mon, 19 Mar 2001, Simon Peyton-Jones wrote:
> > Lazy evaluation *is* coroutines, in a way.
> What I had in mind was something like the following (pseudocode), which
> could easily be implemented on top of coroutines:
> class Channel c t where
> send :: t -> c -> IO ()
> receive :: c -> IO t
> sender :: Int -> Channel -> ...
> sender n receiver = do send n receiver
> return (sender (n+1) receiver)
> receiver :: Channel -> ...
> receiver sender = do i <- receive sender
> return (receiver sender)
> c :: Channel Int
> c = ...
> main = run_them [ sender 1 c, receiver c ]
Now, you can do this:
sender :: Int -> [Int]
sender n = n:(sender (n+1))
receiver :: [Int] -> ()
receiver (x:xs) = receiver xs
main =
let
sent_stuff = sender 1
receiver_result = receiver sent_stuff
in
receiver_result `seq` return ()
I.e. lazy lists work like coroutine channels often enough.
You can do that a bit more abstractly:
send :: a -> [a] -> [a]
send = (:)
receive :: (a -> [a] -> result) -> [a] -> result
receive f (x:xs) = f x xs
sender n = send n $ sender (n+1)
receiver = receive $ \received_thing -> receiver
main = (as above)
Note that the definition of sender now looks not too unsimilar to
your monadic things:
sender n = send n >> sender (n+1)
===
sender n = do
send n
sender (n+1) -- your 'return' above is redundant
receiver = receive >>= \received_thing -> receiver
===
receiver = do
received_thing <- receive
receiver
Now, in fact, you could achieve this effect with a continuation+state monad
quite well (state for input, continuation as *one* way for lazy output).
> [...]
Kind regards,
Hannah.
From karczma@info.unicaen.fr Tue Mar 20 11:20:19 2001
From: karczma@info.unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 20 Mar 2001 11:20:19 +0000
Subject: Linearity Requirement for Patterns
References:
<3AB2D0AB.7E083590@boutel.co.nz>
<15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
<3AB5EB5D.9BE24B7A@augustsson.net> <15030.4944.608707.884030@petrus.informatik.uni-kiel.de>
Message-ID: <3AB73CF3.C6A812@info.unicaen.fr>
Michael Hanus wrote:
>
> Lennart Augustsson wrote:
> > Yes, your definition of non-linear patterns would give you extra
> > power. It would also destroy the nice semantics of Haskell!
> > By using this facility you can now observe intensional properties
> > of the term, and the clean denotational semantics crumbles.
...
> > So this definitions of non-linear patterns is not an option for a
> > language that claims to be "referentially transparent" (whatever
> > that means :).
...
> However, I agree that there are good reasons (mainly, operational
> simplicity) to allow only linear patterns and constructor-based
> rules in a real programming language, since non-linear patterns
> or non-constructor-based rules require other and more advanced
> operational principles. I only wanted to remark that there is
> no simple way to translate non-linear pattterns into linear
> patterns in the general case.
>
> Michael
Logic languages which allow for nonlinear patterns use unification,
which is usually much more costly than simple pattern compiling.
Now, I wonder whether in FP where there is no place for "logical
variable" concept one needs or doesn't need the classical unification,
with all the substitutions of variables.
"Read-only" patterns are manipulated more efficiently, but in presence
of laziness, of ~patterns etc., I feel - for the moment - rather
lost.
What is the status of the referential transparency of Prolog or
Mercury?
Anybody, with a clever comment on that?
Jerzy Karczmarczuk
Caen, France
From rejj@cs.mu.OZ.AU Tue Mar 20 12:47:31 2001
From: rejj@cs.mu.OZ.AU (Robert Jeschofnik)
Date: Tue, 20 Mar 2001 23:47:31 +1100
Subject: ANNOUNCE: HasChorus - some modules for Haskore
In-Reply-To: <20010320041040.69A3C659859@au2.samba.org>; from Martin Schwenke on Tue, Mar 20, 2001 at 03:25:45PM +1100
References: <20010320041040.69A3C659859@au2.samba.org>
Message-ID: <20010320234731.A16708@cs.mu.oz.au>
On 20-Mar-2001, Martin Schwenke wrote:
> HasChorus:
>
> A set of Haskell (http://haskell.org/) modules written on top of
> Haskore (http://haskell.org/haskore/) to make it easier to sequence
> simple, repetitive music.
Even without having had a look at the code yet, I am led to wonder...
> BubbleSort.lhs: An implementation of bubble sort.
> Used by HasGroove.lhs.
(I reformatted the quote so it wouldn't wrap over 80 chars)
-Why- bubblesort?
Rob
From mh@informatik.uni-kiel.de Tue Mar 20 12:53:54 2001
From: mh@informatik.uni-kiel.de (Michael Hanus)
Date: Tue, 20 Mar 2001 13:53:54 +0100 (MET)
Subject: Linearity Requirement for Patterns
In-Reply-To: Jerzy Karczmarczuk's message of March 20 (11:20)
References:
<3AB2D0AB.7E083590@boutel.co.nz>
<15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
<3AB5EB5D.9BE24B7A@augustsson.net>
<15030.4944.608707.884030@petrus.informatik.uni-kiel.de>
<3AB73CF3.C6A812@info.unicaen.fr>
Message-ID: <15031.21218.290464.30769@petrus.informatik.uni-kiel.de>
Jerzy Karczmarczuk wrote:
> Logic languages which allow for nonlinear patterns use unification,
> which is usually much more costly than simple pattern compiling.
> Now, I wonder whether in FP where there is no place for "logical
> variable" concept one needs or doesn't need the classical unification,
> with all the substitutions of variables.
> "Read-only" patterns are manipulated more efficiently, but in presence
> of laziness, of ~patterns etc., I feel - for the moment - rather
> lost.
>
> What is the status of the referential transparency of Prolog or
> Mercury?
Prolog isn't referential transparent due to predefined predicates
with side effects. However, logic programming ("pure Prolog")
is referentially transparent if one considers a "non-deterministic"
semantics where an expression is reduced to a disjunction of
expressions (Prolog systems explore this disjunction in a
left-to-right manner by backtracking). Actually, one can
extend Haskell by "logical variables" in a conservative manner.
This is the idea of the functional logic language Curry
(http://www.informatik.uni-kiel.de/~curry/) where the pattern
matching process is slightly extended so that the operational
behavior is identical to Haskell (i.e., not more costly)
for programs without occurrences of logical variables
and, if a logical variable occurs during pattern matching,
it is (non-deterministically) bound to some pattern.
However, in order to support infinite data structures and
laziness, linear patterns are also required. Non-linear patterns
must be transformed into linear patterns by introducing
a unification constraint in the condition part, i.e., all
non-linearities must be made explicit in the program
(so that pattern matching can be efficiently performed).
Thus, I think that linearity is a natural requirement
even for logic languages that support laziness.
Michael
From lisper@it.kth.se Tue Mar 20 14:01:50 2001
From: lisper@it.kth.se (Bjorn Lisper)
Date: Tue, 20 Mar 2001 15:01:50 +0100 (MET)
Subject: Linearity Requirement for Patterns
In-Reply-To: <15031.21218.290464.30769@petrus.informatik.uni-kiel.de> (message
from Michael Hanus on Tue, 20 Mar 2001 13:53:54 +0100 (MET))
References:
<3AB2D0AB.7E083590@boutel.co.nz>
<15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
<3AB5EB5D.9BE24B7A@augustsson.net>
<15030.4944.608707.884030@petrus.informatik.uni-kiel.de>
<3AB73CF3.C6A812@info.unicaen.fr> <15031.21218.290464.30769@petrus.informatik.uni-kiel.de>
Message-ID: <200103201401.PAA04044@cuchulain.it.kth.se>
Michael Hanus:
>Thus, I think that linearity is a natural requirement
>even for logic languages that support laziness.
Yes. Further evidence for this is that non-left-linear term rewriting systems
typically don't have sequential normalizing evaluation strategies. A
normalizing evaluation strategy might thus be very expensive for a rewrite
system with such rules.
Also, many nice results about confluence do not hold if there are
non-left-linear rules.
Björn Lisper
From loogen@Mathematik.Uni-Marburg.de Tue Mar 20 15:45:52 2001
From: loogen@Mathematik.Uni-Marburg.de (Rita Loogen)
Date: Tue, 20 Mar 2001 16:45:52 +0100
Subject: Coroutines
References:
Message-ID: <3AB77B30.9260A3B4@mathematik.uni-marburg.de>
Eden (http://www.mathematik.uni-marburg.de/inf/eden) is a parallel
extension of Haskell that provides processes which communicate via
streams (lazy lists).
In Eden, your pseudocode would look like:
sender :: Int -> Process () [Int]
sender n = process () -> [n,n+1..]
receiver :: Process [Int] [Results]
receiver = process xs -> consume xs
where consume :: [Int] -> [Results]
main = print (receiver # (sender # ()))
The type Process a b belongs to a process abstraction which defines a
process consuming input of type a and producing output of type b.
# :: Process a b -> a -> b applies a process abstraction to input. This
leads to the creation of the process and its interconnecting channels.
Regards
Rita
--
Rita Loogen
Fachbereich Mathematik und Informatik, Philipps-Universitaet Marburg,
Germany
http://www.mathematik.uni-marburg.de/~loogen
--
From gruenbacher-lists@geoinfo.tuwien.ac.at Tue Mar 20 17:07:25 2001
From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher)
Date: Tue, 20 Mar 2001 18:07:25 +0100 (CET)
Subject: Coroutines
In-Reply-To: <20010319225645.A25257@rz.uni-karlsruhe.de>
Message-ID:
On Mon, 19 Mar 2001, Hannah Schroeter wrote:
> Hello!
>
> On Mon, Mar 19, 2001 at 06:43:55PM +0100, Andreas Gruenbacher wrote:
>
> > On Mon, 19 Mar 2001, Simon Peyton-Jones wrote:
> >
> > > Lazy evaluation *is* coroutines, in a way.
> >
> > What I had in mind was something like the following (pseudocode), which
> > could easily be implemented on top of coroutines:
> >
> > class Channel c t where
> > send :: t -> c -> IO ()
> > receive :: c -> IO t
> >
> > sender :: Int -> Channel -> ...
> > sender n receiver = do send n receiver
> > return (sender (n+1) receiver)
> >
> > receiver :: Channel -> ...
> > receiver sender = do i <- receive sender
> > return (receiver sender)
> >
> > c :: Channel Int
> > c = ...
> >
> > main = run_them [ sender 1 c, receiver c ]
>
> Now, you can do this:
>
> sender :: Int -> [Int]
> sender n = n:(sender (n+1))
>
> receiver :: [Int] -> ()
> receiver (x:xs) = receiver xs
>
> main =
> let
> sent_stuff = sender 1
> receiver_result = receiver sent_stuff
> in
> receiver_result `seq` return ()
>
> I.e. lazy lists work like coroutine channels often enough.
I see your point, and I must admit that this approach has its charm. It's
not what I had in mind, though. Simon's MVars (in the Awkward Squad)
come pretty close, but they're still not the sort of (cooperative)
multitasking that I'm thinking of. I'm not looking for a process or thread
model of concurrency. That's too expensive for simulations due to the
frequency of task switches. (And thanks Rita, for the Eden reference.
That's comparable to Concurrent Haskell.)
The sort of lazy evaluation employed in your solution is in a way similar
to coroutines, with the following restrictions (correct me if I'm wrong):
* It is not possible to implement cyclic communication.
* It is not possible to implement processes with multiple asynchronous
output channels.
I really would like to preserve the elegance of simulations in Simula, but
with all the advantages Haskell offers. I believe that in current Haskell
implementations all the components needed for "proper" coroutines are more
or less there (because lazy evaluation is pretty close).
Any more ideas?
Thanks,
--Andreas.
From qrczak@knm.org.pl Tue Mar 20 17:42:09 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 20 Mar 2001 17:42:09 GMT
Subject: Coroutines
References:
Message-ID:
Tue, 20 Mar 2001 18:07:25 +0100 (CET), Andreas Gruenbacher pisze:
> The sort of lazy evaluation employed in your solution is in a way similar
> to coroutines, with the following restrictions (correct me if I'm wrong):
>
> * It is not possible to implement cyclic communication.
I see no problem in this.
In fact laziness is really about the ability to cycle anything.
> * It is not possible to implement processes with multiple asynchronous
> output channels.
Again I see no problem:
splitEvenOdd:: [a] -> ([a], [a])
splitEvenOdd [] = ([], [])
splitEvenOdd (x:xs) = (x:ys, zs) where (ys, zs) = splitOddEven xs
splitOddEven:: [a] -> ([a], [a])
splitOddEven [] = ([], [])
splitOddEven (x:xs) = (ys, x:zs) where (ys, zs) = splitEvenOdd xs
What it cannot do is to multiplex input. Code is purely functional
and thus the result cannot depend on the order in which inputs become
available.
Concurrent Haskell provides nondeterministic merge from lazy lists
(mergeIO and nmergeIO in module Concurrent).
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
From simonpj@microsoft.com Tue Mar 20 17:45:50 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 20 Mar 2001 09:45:50 -0800
Subject: Coroutines
Message-ID: <37DA476A2BC9F64C95379BF66BA2690260D90A@red-msg-09.redmond.corp.microsoft.com>
| I see your point, and I must admit that this approach has its=20
| charm. It's
| not what I had in mind, though. Simon's MVars (in the Awkward Squad)
| come pretty close, but they're still not the sort of (cooperative)
| multitasking that I'm thinking of. I'm not looking for a=20
| process or thread
| model of concurrency. That's too expensive for simulations due to the
| frequency of task switches.
Could you try it and see? GHC's threads are implemented in GHC's
runtime system; thread switching is much much much cheaper than
switching between OS threads. It's designed to support thousands or
hundreds of thousands of threads.
Give it a whirl!
Simon=20
From ross@soi.city.ac.uk Tue Mar 20 18:06:48 2001
From: ross@soi.city.ac.uk (Ross Paterson)
Date: Tue, 20 Mar 2001 18:06:48 +0000
Subject: Coroutines
In-Reply-To: ; from gruenbacher@geoinfo.tuwien.ac.at on Tue, Mar 20, 2001 at 06:07:25PM +0100
References: <20010319225645.A25257@rz.uni-karlsruhe.de>
Message-ID: <20010320180648.A21471@soi.city.ac.uk>
On Tue, Mar 20, 2001 at 06:07:25PM +0100, Andreas Gruenbacher wrote:
> The sort of lazy evaluation employed in [Hannah's] solution is in a
> way similar to coroutines, with the following restrictions (correct
> me if I'm wrong):
>
> * It is not possible to implement cyclic communication.
It certainly is, and that seems to me a neat way to do process-driven
simulation: a process generates a list of future events, which a controller
merges into its pool, from which it selects the next event to simulate,
starting the next process, and so on. You could use a monad to hide the
event output if required.
> * It is not possible to implement processes with multiple asynchronous
> output channels.
Again, should be no problem, but what do you need these for?
> I really would like to preserve the elegance of simulations in Simula, but
> with all the advantages Haskell offers. I believe that in current Haskell
> implementations all the components needed for "proper" coroutines are more
> or less there (because lazy evaluation is pretty close).
Indeed, you may be able to do all the simulation primitives in pure
Haskell, if you take a step back from the channel view.
From Martin Schwenke"
References: <20010320041040.69A3C659859@au2.samba.org>
<20010320234731.A16708@cs.mu.oz.au>
Message-ID: <20010320233434.67E8C659859@au2.samba.org>
>>>>> "Robert" == Robert Jeschofnik writes:
Robert> Even without having had a look at the code yet, I am led
Robert> to wonder...
>> BubbleSort.lhs: An implementation of bubble sort.
>> Used by HasGroove.lhs.
Robert> (I reformatted the quote so it wouldn't wrap over 80 chars)
Robert> -Why- bubblesort?
That's what I initially thought when a colleague asked why I wasn't
using bubblesort!
The groove function takes a Haskore performance and rearranges it a
bit according to some parameters and normal distributions. The idea
is to loosen things up a bit. The performance is a very long list,
but is still roughly in order (otherwise I would just generate random
music to start with :-). That is, nothing moves very far, but the
next stage in Haskore (conversion to MIDI) requires everything to be
in order.
My implementation of bubblesort iterates over the list until the list
is sorted and then stops. Since the list is only a little bit out of
order, this doesn't take too many iterations.
My implementation is very declarative. I could make it less so, but
my experiments have shown that the performance gain is minimal. I'd
rather keep the code beautiful! :-)
I tried things like quicksort and mergesort, but I couldn't minimize
the space requirements enough to make them work well. I even
implemented a "window sort" algorithm that sorted within a window that
I "moved" along the list. This worked quite well, but was a gross
hack. I can't remember exactly, but I think bubblesort out-performed
it anyway!
Bubblesort rules! ... within a very limited domain... :-)
peace & happiness,
martin
From fjh@cs.mu.oz.au Thu Mar 22 01:07:09 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Thu, 22 Mar 2001 12:07:09 +1100
Subject: Linearity Requirement for Patterns
In-Reply-To: <15031.21218.290464.30769@petrus.informatik.uni-kiel.de>
References: <3AB2D0AB.7E083590@boutel.co.nz> <15029.50572.458644.381258@petrus.informatik.uni-kiel.de> <3AB5EB5D.9BE24B7A@augustsson.net> <15030.4944.608707.884030@petrus.informatik.uni-kiel.de> <3AB73CF3.C6A812@info.unicaen.fr> <15031.21218.290464.30769@petrus.informatik.uni-kiel.de>
Message-ID: <20010322120709.A15339@hg.cs.mu.oz.au>
On 20-Mar-2001, Michael Hanus wrote:
> Jerzy Karczmarczuk wrote:
> > Logic languages which allow for nonlinear patterns use unification,
> > which is usually much more costly than simple pattern compiling.
> > Now, I wonder whether in FP where there is no place for "logical
> > variable" concept one needs or doesn't need the classical unification,
> > with all the substitutions of variables.
> > "Read-only" patterns are manipulated more efficiently, but in presence
> > of laziness, of ~patterns etc., I feel - for the moment - rather
> > lost.
> >
> > What is the status of the referential transparency of Prolog or
> > Mercury?
>
> Prolog isn't referential transparent due to predefined predicates
> with side effects. However, logic programming ("pure Prolog")
> is referentially transparent if one considers a "non-deterministic"
> semantics where an expression is reduced to a disjunction of
> expressions (Prolog systems explore this disjunction in a
> left-to-right manner by backtracking).
I would talk about disjunctions of "goals" rather than disjunctions of
"expressions". This is perhaps a pedantic distinction, but when
you start talking about referential transparency it is important
to be very precise, because often the distinctions are a matter
of terminology.
> Actually, one can
> extend Haskell by "logical variables" in a conservative manner.
> This is the idea of the functional logic language Curry
My understanding, from talking with Michael Hanus a few years ago, is
that Curry is not referentially transparent, in the sense that you can't
replace equals with equals, because it permits nondeterministic functions.
In particular, `let x = f y in g x x' is not the same as `g (f y) (f y)'
in Curry.
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From fjh@cs.mu.oz.au Thu Mar 22 01:31:35 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Thu, 22 Mar 2001 12:31:35 +1100
Subject: Linearity Requirement for Patterns
In-Reply-To: <3AB73CF3.C6A812@info.unicaen.fr>
References: <3AB2D0AB.7E083590@boutel.co.nz> <15029.50572.458644.381258@petrus.informatik.uni-kiel.de> <3AB5EB5D.9BE24B7A@augustsson.net> <15030.4944.608707.884030@petrus.informatik.uni-kiel.de> <3AB73CF3.C6A812@info.unicaen.fr>
Message-ID: <20010322123135.B15339@hg.cs.mu.oz.au>
On 20-Mar-2001, Jerzy Karczmarczuk wrote:
>
> Logic languages which allow for nonlinear patterns use unification,
> which is usually much more costly than simple pattern compiling.
That's true, but the exceptions are important.
If you have sufficient compile-time mode information, then unification
need not be more costly than simple pattern matching.
> What is the status of the referential transparency of Prolog or
> Mercury?
As Michael Hanus said, Prolog is not referentially transparent because
it has a large variety of builtins that violate referential transparency.
For Mercury, the short answer is that yes, Mercury is referentially
transparent.
Still, I guess you want the long answer ;-)
Mercury's declarative semantics are referentially transparent.
Modifying some Mercury program by replacing equals with equals always
preserves the program's declarative semantics. However, such
transformations do not necessarily preserve the operational semantics;
the transformed program may not terminate when the original does,
or may compute the set of solutions in a different order.
The same is true for pure Prolog.
Haskell's denotational semantics is referentially transparent. AFAIK
Haskell doesn't have a standard operational semantics, but the typical
operational semantics used are also referentially transparent. However,
if you use a more detailed operational semantics, e.g. one which takes
into account the fact that machines have finite memory, then the same
kind of thing applies to Haskell too: replacing equals with equals may
not preserve the operational semantics, because the transformed program
may run out of memory when the original didn't.
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From mh@informatik.uni-kiel.de Thu Mar 22 08:46:26 2001
From: mh@informatik.uni-kiel.de (Michael Hanus)
Date: Thu, 22 Mar 2001 09:46:26 +0100 (MET)
Subject: Linearity Requirement for Patterns
In-Reply-To: Fergus Henderson's message of March 22 (12:07)
References:
<3AB2D0AB.7E083590@boutel.co.nz>
<15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
<3AB5EB5D.9BE24B7A@augustsson.net>
<15030.4944.608707.884030@petrus.informatik.uni-kiel.de>
<3AB73CF3.C6A812@info.unicaen.fr>
<15031.21218.290464.30769@petrus.informatik.uni-kiel.de>
<20010322120709.A15339@hg.cs.mu.oz.au>
Message-ID: <15033.48098.588306.455140@petrus.informatik.uni-kiel.de>
Fergus Henderson wrote:
> My understanding, from talking with Michael Hanus a few years ago, is
> that Curry is not referentially transparent, in the sense that you can't
> replace equals with equals, because it permits nondeterministic functions.
> In particular, `let x = f y in g x x' is not the same as `g (f y) (f y)'
> in Curry.
Of course, as you already mentioned, one has te be very precise
when talking about referential transparency. In particular, one
has to say what "equals" mean. Otherwise, one could also argue
that Haskell is not referential transparent: if a Haskell program
has a defining equation "f 1 = 1", the expressions "(f 1)" and "1"
might not be identical (if there is another equation like "f x = 0"
before).
In Curry, each defining equation contributes to the semantics
of a function independently of the other equations for the same
function, and the overall goal is to compute all values of
an expression (plus possible substitutions for free variables)
which can be derived from this equational reading of all rules.
In this sense, Curry is refentially transparent (although I have
no formal definition of this notion but only soundness, completeness
and optimality results). Your "counter example" comes from a
misunderstanding of the "let" in Curry. Since the kernel language
is based lazy evaluation w.r.t. a set of constructor-based rewrite
rules, the "let" is considered as syntactic sugar for abbreviating
some function argument. For instance, the meaning of the definition
h = let x = f y in g x x
is defined as an abbreviation for the rules
h = aux (f y)
aux x = g x x
W.r.t. this semantics, there is no problem even with non-deterministic
functions.
If you have a precise definition of "referentially transparent"
at hand so that you can make your statement more precise, I would
be very interested to read it. As you have seen, the slogan
"replacing equals by equals" is still to fuzzy since just looking
for equality symbols in a language is not sufficient.
Michael
From lisper@it.kth.se Thu Mar 22 10:26:59 2001
From: lisper@it.kth.se (Bjorn Lisper)
Date: Thu, 22 Mar 2001 11:26:59 +0100 (MET)
Subject: Linearity Requirement for Patterns
In-Reply-To: <15033.48098.588306.455140@petrus.informatik.uni-kiel.de>
(message from Michael Hanus on Thu, 22 Mar 2001 09:46:26 +0100 (MET))
References:
<3AB2D0AB.7E083590@boutel.co.nz>
<15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
<3AB5EB5D.9BE24B7A@augustsson.net>
<15030.4944.608707.884030@petrus.informatik.uni-kiel.de>
<3AB73CF3.C6A812@info.unicaen.fr>
<15031.21218.290464.30769@petrus.informatik.uni-kiel.de>
<20010322120709.A15339@hg.cs.mu.oz.au> <15033.48098.588306.455140@petrus.informatik.uni-kiel.de>
Message-ID: <200103221026.LAA07217@cuchulain.it.kth.se>
Michael Hanus:
>In Curry, each defining equation contributes to the semantics
>of a function independently of the other equations for the same
>function, and the overall goal is to compute all values of
>an expression (plus possible substitutions for free variables)
>which can be derived from this equational reading of all rules.
>In this sense, Curry is refentially transparent (although I have
>no formal definition of this notion but only soundness, completeness
>and optimality results). Your "counter example" comes from a
>misunderstanding of the "let" in Curry. Since the kernel language
>is based lazy evaluation w.r.t. a set of constructor-based rewrite
>rules, the "let" is considered as syntactic sugar for abbreviating
>some function argument. For instance, the meaning of the definition
>
> h = let x = f y in g x x
>
>is defined as an abbreviation for the rules
>
> h = aux (f y)
> aux x = g x x
>
>W.r.t. this semantics, there is no problem even with non-deterministic
>functions.
How does sharing work here? I assume the "let x = ..." is intended to mean
sharing of "...". Does the same hold for function calls in Curry, so
"aux x = g x x" implies sharing of x when evaluating g? In that case I
suspect you might have problems if, for instance, you inline aux naively
into g (f y) (f y) and f is nondeterministic. (Inlining should typically
work for a referentially transparent language.) The problem can be fixed
though: if you have this sharing, then "aux x = g x x" is really shorthand
for "aux x = let y = x in g y y". If this definition is inlined and the let
is kept (to preserve the sharing), then the transformation should work even
if f is nondeterministic.
If, on the other hand, Curry has a call-by-name semantics, then the direct
inlining should work.
>If you have a precise definition of "referentially transparent"
>at hand so that you can make your statement more precise, I would
>be very interested to read it. As you have seen, the slogan
>"replacing equals by equals" is still to fuzzy since just looking
>for equality symbols in a language is not sufficient.
Referential transparency is defined w.r.t. some notion of equality on terms,
and cannot be precise unless this notion is made precise. If the language at
hand has a denotational semantics, then equality on terms can be derived
from their denotations. But referential transparency can also be defined
w.r.t. other semantics. An interesting case is term rewrite semantics: a
confluent term rewrite system defines a notion of equality through its
convertibility relation (the transitive-reflexive-symmetric closure of the
reduction relation). A notion of referential transparency can be based on this
equivalence relation (which is an equality relation, due to closedness of
the reduction relation under substitutions and taking of contexts).
A restricted notion of referential transparency carries over to nonconfluent
(and thus nondeterministic) rewrite systems. If the rewrite system can be
partitioned into a confluent and a nonconfluent part, then the
convertibility relation for the confluent part can be taken as an equality
relation upon which the referential transparency can be defined. Under
certain (not so strong) technical conditions, the set of possible normal
forms will be the same for terms that are equal w.r.t. this convertibility
relation. This holds also if the concept of normal form is extended to cover
infinite and possibly diverging computations.
I don't know how much of this applies directly to Curry, since the above is
for pure term rewriting and I suspect Curry has unification in its
evaluation mechanism (right?) which then makes the evaluation more
complex. But maybe the above can provide some ideas how to formally define
referential transparency for Curry?
Björn Lisper
PS. I have a paper on this. There is also a paper by Søndergaard and Sestoft
that has an interesting discussion about referential transparency and
nondeterminism. Bibtex entries are given below.
@STRING{tcs = "Theoret.\ Comput.\ Sci."}
@ARTICLE{Lisper-TCS,
AUTHOR = {Bj{\"o}rn Lisper},
TITLE = {Computing in Unpredictable Environments: Semantics, Reduction Strategies, and Program Transformations},
JOURNAL = tcs,
YEAR = {1998},
VOLUME = {190},
NUMBER = {1},
PAGES = {61--85},
MONTH = jan
}
@ARTICLE{SonSes-reftrans-unfold,
AUTHOR = {Harald S{\o}ndergaard and Peter Sestoft},
TITLE = {Referential Transparency, Definiteness and Unfoldability},
JOURNAL = {Acta Informatica},
YEAR = {1990},
VOLUME = {27},
PAGES = {505--517}
}
From koen@cs.chalmers.se Thu Mar 22 12:04:51 2001
From: koen@cs.chalmers.se (Koen Claessen)
Date: Thu, 22 Mar 2001 13:04:51 +0100 (MET)
Subject: Linearity Requirement for Patterns
In-Reply-To: <15033.48098.588306.455140@petrus.informatik.uni-kiel.de>
Message-ID:
Michael Hanus wrote:
| For instance, the meaning of the definition
|
| h = let x = f y in g x x
|
| is defined as an abbreviation for the rules
|
| h = aux (f y)
| aux x = g x x
|
| W.r.t. this semantics, there is no problem even with
| non-deterministic functions.
In ML, the meaning of the expression:
let x = e1 in e2
is defined as an abbreviation for the expression
mdo x <- e1; e2
W.r.t. this semantics, there is no problem even with
side-effecting functions.
/Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
From mh@informatik.uni-kiel.de Thu Mar 22 12:53:20 2001
From: mh@informatik.uni-kiel.de (Michael Hanus)
Date: Thu, 22 Mar 2001 13:53:20 +0100 (MET)
Subject: Linearity Requirement for Patterns
In-Reply-To: Bjorn Lisper's message of March 22 (11:26)
References:
<3AB2D0AB.7E083590@boutel.co.nz>
<15029.50572.458644.381258@petrus.informatik.uni-kiel.de>
<3AB5EB5D.9BE24B7A@augustsson.net>
<15030.4944.608707.884030@petrus.informatik.uni-kiel.de>
<3AB73CF3.C6A812@info.unicaen.fr>
<15031.21218.290464.30769@petrus.informatik.uni-kiel.de>
<20010322120709.A15339@hg.cs.mu.oz.au>
<15033.48098.588306.455140@petrus.informatik.uni-kiel.de>
<200103221026.LAA07217@cuchulain.it.kth.se>
Message-ID: <15033.62912.228361.909956@petrus.informatik.uni-kiel.de>
Bjorn Lisper wrote:
> >some function argument. For instance, the meaning of the definition
> >
> > h = let x = f y in g x x
> >
> >is defined as an abbreviation for the rules
> >
> > h = aux (f y)
> > aux x = g x x
> >
> >W.r.t. this semantics, there is no problem even with non-deterministic
> >functions.
>
> How does sharing work here? I assume the "let x = ..." is intended to mean
> sharing of "...". Does the same hold for function calls in Curry, so
> "aux x = g x x" implies sharing of x when evaluating g? In that case I
Yes. Since Curry is based on a lazy and (for a particular subclass,
namely inductively sequential rules) also optimal evaluation strategy,
sharing of function arguments is required and essential.
> suspect you might have problems if, for instance, you inline aux naively
> into g (f y) (f y) and f is nondeterministic. (Inlining should typically
> work for a referentially transparent language.) The problem can be fixed
> though: if you have this sharing, then "aux x = g x x" is really shorthand
> for "aux x = let y = x in g y y". If this definition is inlined and the let
> is kept (to preserve the sharing), then the transformation should work even
> if f is nondeterministic.
In the presence of nondeterministic functions (i.e., nonconfluent
rules), one has several options for the semantics. For parameter
passing, one can use either the call-time choice or run-time choice
semantics. Curry is based on the former since there is a well-defined
semantical framework for this in the presence of non-strict functions
(Gonzalez-Moreno et al., Journal of Logic Programming, Vol. 40, 1999).
Semantically, the call-time choice means that rewrite rules can
only be applied if the arguments are constructor terms, i.e.,
totally evaluated. This does not necessarily imply a strict semantics
since it can be implemented by lazy reduction provided that
function arguments are shared. Thus, this sharing must be
somehow represented in an intermediate language for executing
the programs and on this level inlining is preserved, as you have
remarked. Naive inlining (i.e., without lets but possibly
duplicating function calls) does only work for deterministic
functions (which is no restriction from a Haskell point of view
since Haskell allows only deterministic functions).
> I don't know how much of this applies directly to Curry, since the above is
> for pure term rewriting and I suspect Curry has unification in its
> evaluation mechanism (right?) which then makes the evaluation more
> complex. But maybe the above can provide some ideas how to formally define
> referential transparency for Curry?
The paper mentioned above defines a proof calculus, model theory
and operational semantics for this language where the denotation
of functions distinguish between deterministic and non-deterministic
functions which seems to be conform to your remarks. Although
it does not explicitly define referential transparancy, it shows
the equivalence of all three notions which I think is enough
for reasoning about Curry programs. Nevertheless, many thanks
for your hints.
Michael
From fjh@cs.mu.oz.au Thu Mar 22 23:39:15 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Fri, 23 Mar 2001 10:39:15 +1100
Subject: Linearity Requirement for Patterns
In-Reply-To:
References: <15033.48098.588306.455140@petrus.informatik.uni-kiel.de>
Message-ID: <20010323103915.A13545@hg.cs.mu.oz.au>
On 22-Mar-2001, Koen Claessen wrote:
> Michael Hanus wrote:
>
> | For instance, the meaning of the definition
> |
> | h = let x = f y in g x x
> |
> | is defined as an abbreviation for the rules
> |
> | h = aux (f y)
> | aux x = g x x
> |
> | W.r.t. this semantics, there is no problem even with
> | non-deterministic functions.
>
> In ML, the meaning of the expression:
>
> let x = e1 in e2
>
> is defined as an abbreviation for the expression
>
> mdo x <- e1; e2
>
> W.r.t. this semantics, there is no problem even with
> side-effecting functions.
Referential transparency is a *syntactic* property of a language. You can
define two languages with very similar semantics, and a well-defined
translation that maps one to the other (and vice versa), the only difference
being some syntactic sugar, and yet one can be referentially transparent and
the other not.
So I don't think it is reasonable to say that either of those languages are
referentially transparent by virtue of the existence of some transformation or
some rules for how to expand syntactic sugar for which the result of the
transformation is referentially transparent. In general such transformations
don't necessarily preserve referential transparency.
On the other hand, another conclusion that you could draw from this is that
referential transparency is not such an important property; it's a means, not
an end. Really what we care about is whether the languages that we use
are easy to understand, have a simple semantics, and are easy to transform.
Languages which are referentially transparent *tend* to have those properties,
but this is not necessarily the case.
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From koen@cs.chalmers.se Tue Mar 27 09:42:15 2001
From: koen@cs.chalmers.se (Koen Claessen)
Date: Tue, 27 Mar 2001 11:42:15 +0200 (MET DST)
Subject: the constant functor
In-Reply-To: <24765.985685935@www18.gmx.net>
Message-ID:
(moved reply to haskell-cafe)
Hi Tobias,
| data ConstInt a = Const Int
|
| Any ideas how to make 'ConstInt' an instance of class
| Functor?
What is wrong with:
class Functor ConstInt where
map f (Const n) = Const n
?
/Koen.
--
Koen Claessen http://www.cs.chalmers.se/~koen
phone:+46-31-772 5424 mailto:koen@cs.chalmers.se
-----------------------------------------------------
Chalmers University of Technology, Gothenburg, Sweden
From Tom.Pledger@peace.com Tue Mar 27 20:46:08 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Wed, 28 Mar 2001 08:46:08 +1200
Subject: the constant functor
In-Reply-To: <16008.985687799@www18.gmx.net>
References:
<16008.985687799@www18.gmx.net>
Message-ID: <15040.64528.177920.229331@waytogo.peace.co.nz>
Tobias Haeberlein writes:
|
| > What is wrong with:
| >
| > class Functor ConstInt where
| > map f (Const n) = Const n
|
| Ups - absolutely nothing.
| I actually tried it with
|
| data ConstInt a = Int
This version doesn't refer to the type Int. Instead, it introduces a
new nullary data constructor called Int, which you could use like
this:
instance Functor ConstInt where
fmap f Int = Int
...but I don't think that's what you were after. If you use a type
alias (type ConstInt a = Int) instead of declaring a data type, it
will refer to the type Int. However, then you'd need to use ConstInt
partially applied in the instance declaration, which Haskell doesn't
allow. I think Gofer has a more liberal type system which does allow
it.
| and didnt manage to make this an instance of
| class Functor. Sorry for giving the wrong
| example.
From ate2882@yahoo.com Tue Mar 27 23:32:30 2001
From: ate2882@yahoo.com (Atenea Azcue)
Date: Tue, 27 Mar 2001 15:32:30 -0800 (PST)
Subject: (no subject)
Message-ID: <20010327233230.95334.qmail@web9204.mail.yahoo.com>
--0-1558094891-985735950=:95280
Content-Type: text/plain; charset=us-ascii
Hello
My name is Atenea : I´m what to ask you who can I make a program in haskell like une program that say hello word
---------------------------------
Do You Yahoo!?
Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! Mail.
--0-1558094891-985735950=:95280
Content-Type: text/html; charset=us-ascii
Hello
My name is Atenea : I´m what to ask you who can I make a program in haskell like une program that say hello word
Do You Yahoo!?
Yahoo! Mail Personal Address -
Get email at your own domain with Yahoo! Mail.
--0-1558094891-985735950=:95280--
From ate2882@yahoo.com Tue Mar 27 23:36:03 2001
From: ate2882@yahoo.com (Atenea Azcue)
Date: Tue, 27 Mar 2001 15:36:03 -0800 (PST)
Subject: (no subject)
Message-ID: <20010327233603.39612.qmail@web9205.mail.yahoo.com>
--0-1194470999-985736163=:38095
Content-Type: text/plain; charset=us-ascii
Hello
My name is Atenea . I just want to ask you that how can i Creat a program that just say "hello word" and another that can add a "matrix" if you can help me I would really going to apreciate please. Thank you for your listening
---------------------------------
Do You Yahoo!?
Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! Mail.
--0-1194470999-985736163=:38095
Content-Type: text/html; charset=us-ascii
Hello
My name is Atenea . I just want to ask you that how can i Creat a program that just say "hello word" and another that can add a "matrix" if you can help me I would really going to apreciate please. Thank you for your listening
Do You Yahoo!?
Yahoo! Mail Personal Address -
Get email at your own domain with Yahoo! Mail.
--0-1194470999-985736163=:38095--
From shlomif@vipe.technion.ac.il Wed Mar 28 04:23:27 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Wed, 28 Mar 2001 06:23:27 +0200 (IST)
Subject: (no subject)
In-Reply-To: <20010327233230.95334.qmail@web9204.mail.yahoo.com>
Message-ID:
On Tue, 27 Mar 2001, Atenea Azcue wrote:
>=20
> Hello=20
>=20
> My name is Atenea : I=B4m what to ask you who can I make a program in ha=
skell=20
> like une program that say hello word=20
>=20
main =3D putStr "Hello, World!"
Regards,
=09Shlomi Fish
>=20
>=20
> ---------------------------------
> Do You Yahoo!?
> Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! M=
ail.
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il=20
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of=20
converting any statement that follows it into a true one.
From shlomif@vipe.technion.ac.il Wed Mar 28 04:36:14 2001
From: shlomif@vipe.technion.ac.il (Shlomi Fish)
Date: Wed, 28 Mar 2001 06:36:14 +0200 (IST)
Subject: (no subject)
In-Reply-To: <20010327233603.39612.qmail@web9205.mail.yahoo.com>
Message-ID:
On Tue, 27 Mar 2001, Atenea Azcue wrote:
>
> Hello
>
> My name is Atenea . I just want to ask you that how can i Creat a program
> that just say "hello word" and another that can add a "matrix" if you
> can
>help me I would really going to apreciate please. Thank you for your
> listening
>
It depends if your matrix is represented as a list of lists or a
two-dimensional array. For lists it is something like that:
plus (a,b) = a+b
plus_vec ([],[]) = []
plus_vec (a:as,b:bs) = (plus (a,b)):(plus_vec (as,bs))
vector_add a b = (map plus (zip a b))
matrix_add a b = (map plus_vec (zip a b))
It can be done a bit better using classes, but then it will be less easy
to understand.
For 2-D arrays, I believe there is an example in the tutorial that shows
matrix _mulitplication_, so addition should be quite trivial after
understanding that.
Check out: http://www.haskell.org/tutorial/
Regards,
Shlomi Fish
>
>
> ---------------------------------
> Do You Yahoo!?
> Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! Mail.
----------------------------------------------------------------------
Shlomi Fish shlomif@vipe.technion.ac.il
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@techie.com
The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.
From mark@chaos.x-philes.com Wed Mar 28 18:05:46 2001
From: mark@chaos.x-philes.com (Mark Carroll)
Date: Wed, 28 Mar 2001 13:05:46 -0500 (EST)
Subject: Printed Haskell 98 Report
Message-ID:
I don't suppose it's possible to get a reasonable printed copy of the
Haskell 98 Report and Haskell 98 Library Report at a sensible price, is
it? Just wondering, before I go pricing printing and binding. Thanks.
-- Mark
From Malcolm.Wallace@cs.york.ac.uk Thu Mar 29 09:21:18 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 29 Mar 2001 10:21:18 +0100
Subject: Printed Haskell 98 Report
In-Reply-To:
Message-ID:
> I don't suppose it's possible to get a reasonable printed copy of the
> Haskell 98 Report and Haskell 98 Library Report at a sensible price, is
> it? Just wondering, before I go pricing printing and binding. Thanks.
The Haskell Reports are freely re-distributable, so I'm not aware
of anyone offering to sell them.
However, they aren't very long, so the cost of printing and binding
should not be excessive. 120 pages double-sided, I reckon should
be less than 10 UKP (15 USD) per copy cost-price.
One caution however. Simon PJ has been promising to issue a new,
corrected edition of the Reports (essentially to incorporate the
accumulated errata). Before you print a hundred copies, you might like
to check how soon the corrected version will be publically available.
Regards,
Malcolm
From ingo@ele.kth.se Thu Mar 29 15:10:10 2001
From: ingo@ele.kth.se (Ingo Sander)
Date: Thu, 29 Mar 2001 17:10:10 +0200 (MET DST)
Subject: Instances of Read and Show
Message-ID:
I have a question concerning the Read and Show classes.
I have read the Haskell 98 report (section 6.3.3 The Read and Show
Classes), but I still do not figure out how to make instances.
I have a simple data type:
data TVal a = Abst
| Prst a
I managed to define the function show, so that I can use it with the data
type TVal
instance (Show a) => Show (TVal a) where
show Abst = "_"
show (Prst x) = show x
Signals> [Prst 1, Abst, Prst 2]
[1,_,2] :: [TVal Integer]
which is what I want to have.
But how do I make a Read instance?
I still do not understand the meaning of 'readsPrec' and
'readList' (and not of 'showPrec' and 'showList') either.
Can somebody explain to me or give me a good reference so that I can make
TVal an instance of the classes Read and Show.
Thanks in advance for your help!
Ingo Sander
From fruehr@willamette.edu Fri Mar 30 00:36:54 2001
From: fruehr@willamette.edu (Fritz K Ruehr)
Date: Thu, 29 Mar 2001 16:36:54 -0800 (PST)
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
Message-ID: <200103300036.QAA04117@gemini.willamette.edu>
Forgive me if the following links were announced here and I just missed
them. I found them through the O'Reilley Meerkat "Open Wire Service",
in the "Lambda" channel of the "Lang" category (see:
). The first link is the "Lambda Dance" page, presumably inspired by
the infamous "Hamster Dance" (if you don't know the latter, you are
better off for it, so don't ask):
"Beta-reduce the night away", as the site says!
The second link is a little polemic entitled "Why People Aren't Using
Haskell", which I presume would be of interest to readers of this
list (the author is Dejan Jelovic, whom I don't recognize as a regular
contributor here):
There are several other interesting looking links on the Meerkat
site ("Moving FP from Academia", "Object Functional Patterns", etc.),
but I will let you investigate on your own. Enjoy ...
-- Fritz Ruehr, still humming to the lambda dance
From karczma@info.unicaen.fr Fri Mar 30 10:28:01 2001
From: karczma@info.unicaen.fr (Jerzy Karczmarczuk)
Date: Fri, 30 Mar 2001 11:28:01 +0100
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
References: <200103300036.QAA04117@gemini.willamette.edu>
Message-ID: <3AC45FB1.7AEBC0D5@info.unicaen.fr>
Fritz K Ruehr wrote:
...
> The second link is a little polemic entitled "Why People Aren't Using
> Haskell", which I presume would be of interest to readers of this
> list (the author is Dejan Jelovic, whom I don't recognize as a regular
> contributor here):
>
>
If you didn't verify this site, forget it. There is NOTHING serious
there.
Over and over again the same silly song, by a person who - visibly -
had never anything to do with functional languages, who thinks now
about hiring some C and java programmers living in Belgrade, but who
writes such silly, incompetent things as:
> And there is an air of staleness: where new versions of these other
> languages appear frequently, the Haskell community is offering you
> Hugs98.
Delovic points out that some languages became "immensely" popular,
as e.g. Ruby, and that Haskell is marginal. Hm. this extremely
orthodox Japanese essence of O-O programming may have some practical
merits, especially those which come from shameless borrowing from
Eiffel, Sather, Clu and Common Lisp, but calling Haskell "marginal"
or "obscure" informs us not what is Haskell, but who is Jelovic.
He accuses the Haskell community of not providing libraries...
==
Perhaps there is *one* point worth mentioning: the necessity to
publish papers about Haskell far from such journals as JFP or HOSC,
but to try to reach DrDobbs etc. I would add: Software: Practice
and experience, and journals on numerical software where one could
show some non-trivial implementations of practical, numerical
algorithms.
Jerzy Karczmarczuk
Caen, France
PS. What is "hamster dance", anyway?
From alex@shop.com Fri Mar 30 14:28:43 2001
From: alex@shop.com (S. Alexander Jacobson)
Date: Fri, 30 Mar 2001 09:28:43 -0500 (Eastern Standard Time)
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
In-Reply-To: <3AC45FB1.7AEBC0D5@info.unicaen.fr>
Message-ID:
Jerszy,
Although I think Haskell is a beautiful language, Jelovic is right on his
core points, Haskell implementations don't meet the needs of the working
programmer.
A user can download Python or Perl to his windows or linux computer,
install, and very quickly be up and running writing code that calls system
libraries, talks to mysql databases, retrieves XML content from the web and parses
it, etc.
Moreover, if the default libraries don't meet his/her needs, it is easy
to find additional libraries on the web, and when found, there is a high
likelyhood that they will work as advertised with the installed system.
Contrast the above with Haskell, which doesn't immediately, easily and
reliably install on all platforms (perhaps aside from Hugs), is still
figuring out core language features,and does not even have a consistent
set of libraries for simple stuff like filesystem access!
There are, perhaps good reasons for all these failures, but please
recognize them for what they are: failures to meet the needs of the
working programmer who just wants to get something done (whether he/she
lives in YU, FR, JP, or US)
I would love to be using Haskell for day to day programming work but I
can't at this time. Unless the community recognizes what is required and
gets it done, I never will.
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
On Fri, 30 Mar 2001, Jerzy Karczmarczuk wrote:
> Fritz K Ruehr wrote:
>
> ...
>
> > The second link is a little polemic entitled "Why People Aren't Using
> > Haskell", which I presume would be of interest to readers of this
> > list (the author is Dejan Jelovic, whom I don't recognize as a regular
> > contributor here):
> >
> >
>
> If you didn't verify this site, forget it. There is NOTHING serious
> there.
>
> Over and over again the same silly song, by a person who - visibly -
> had never anything to do with functional languages, who thinks now
> about hiring some C and java programmers living in Belgrade, but who
> writes such silly, incompetent things as:
>
> > And there is an air of staleness: where new versions of these other
> > languages appear frequently, the Haskell community is offering you
> > Hugs98.
>
>
> Delovic points out that some languages became "immensely" popular,
> as e.g. Ruby, and that Haskell is marginal. Hm. this extremely
> orthodox Japanese essence of O-O programming may have some practical
> merits, especially those which come from shameless borrowing from
> Eiffel, Sather, Clu and Common Lisp, but calling Haskell "marginal"
> or "obscure" informs us not what is Haskell, but who is Jelovic.
> He accuses the Haskell community of not providing libraries...
>
> ==
>
> Perhaps there is *one* point worth mentioning: the necessity to
> publish papers about Haskell far from such journals as JFP or HOSC,
> but to try to reach DrDobbs etc. I would add: Software: Practice
> and experience, and journals on numerical software where one could
> show some non-trivial implementations of practical, numerical
> algorithms.
>
> Jerzy Karczmarczuk
> Caen, France
>
>
> PS. What is "hamster dance", anyway?
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From simonmar@microsoft.com Fri Mar 30 15:22:56 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 30 Mar 2001 16:22:56 +0100
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611582E@TVP-MSG-01.europe.corp.microsoft.com>
> There are, perhaps good reasons for all these failures, but please
> recognize them for what they are: failures to meet the needs of the
> working programmer who just wants to get something done=20
> (whether he/she
> lives in YU, FR, JP, or US)
>=20
> I would love to be using Haskell for day to day programming work but I
> can't at this time. Unless the community recognizes what is=20
> required and
> gets it done, I never will.
There is one good reason that Haskell fails in these areas, and that's
shortage of effort.
We in the GHC team are actively trying to encourage our users to
contribute: with an open CVS source tree, open development mailing
lists, etc. We've had some good results (thanks to our developers!),
but we need more. GHC is a large and complex system, and with trying to
be all things to all people - a research vehicle / experimentation
platform / production compiler, our developer resources are stretched a
bit thin. I'm sure this goes for the other Haskell systems too.
I see libraries as the biggest missing piece in the Haskell language.
Let's face it, Joe Programmer isn't going to pass Haskell by just
because it doesn't support a particular flavour of overlapping instance
declarations. But he might if it doesn't have a networking library, or
unicode support, or an XML parser. Please, join libraries@haskell.org.
Cheers,
Simon
From heringto@cs.unc.edu Fri Mar 30 15:28:15 2001
From: heringto@cs.unc.edu (Dean Herington)
Date: Fri, 30 Mar 2001 10:28:15 -0500
Subject: Instances of Read and Show
References:
Message-ID: <3AC4A60F.1093AEBC@cs.unc.edu>
--------------74E5E9480E30AA4DD6791F2C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ingo Sander wrote:
> I have a question concerning the Read and Show classes.
>
> I have read the Haskell 98 report (section 6.3.3 The Read and Show
> Classes), but I still do not figure out how to make instances.
>
> I have a simple data type:
>
> data TVal a = Abst
> | Prst a
>
> I managed to define the function show, so that I can use it with the data
> type TVal
>
> instance (Show a) => Show (TVal a) where
> show Abst = "_"
> show (Prst x) = show x
>
> Signals> [Prst 1, Abst, Prst 2]
> [1,_,2] :: [TVal Integer]
>
> which is what I want to have.
>
> But how do I make a Read instance?
>
> I still do not understand the meaning of 'readsPrec' and
> 'readList' (and not of 'showPrec' and 'showList') either.
>
> Can somebody explain to me or give me a good reference so that I can make
> TVal an instance of the classes Read and Show.
>
> Thanks in advance for your help!
>
> Ingo Sander
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
I might do it this way:
> data TVal a = Abst | Prst a
> instance (Show a) => Show (TVal a) where
> showsPrec p Abst = ('_' :)
> showsPrec p (Prst x) = showsPrec p x
> instance (Read a) => Read (TVal a) where
> readsPrec p s = case s' of ('_':t) -> (Abst,t) : readsA
> _ -> readsA
> where s' = dropWhile isSpace s
> readsA = map (\(a,t)-> (Prst a,t)) (readsPrec p s')
See section D.4 of the Haskell report for information on 'readsPrec',
'readList', 'showPrec', and 'showList'.
Dean Herington
--------------74E5E9480E30AA4DD6791F2C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ingo Sander wrote:
I have a question concerning the Read and Show classes.
I have read the Haskell 98 report (section 6.3.3 The Read and Show
Classes), but I still do not figure out how to make instances.
I have a simple data type:
data TVal a = Abst
| Prst a
I managed to define the function show, so that I can use it with the
data
type TVal
instance (Show a) => Show (TVal a) where
show Abst
= "_"
show (Prst x) = show
x
Signals> [Prst 1, Abst, Prst 2]
[1,_,2] :: [TVal Integer]
which is what I want to have.
But how do I make a Read instance?
I still do not understand the meaning of 'readsPrec' and
'readList' (and not of 'showPrec' and 'showList') either.
Can somebody explain to me or give me a good reference so that I can
make
TVal an instance of the classes Read and Show.
Thanks in advance for your help!
Ingo Sander
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
I might do it this way:
> data TVal a = Abst | Prst a
> instance (Show a) => Show (TVal a) where
> showsPrec p Abst = ('_' :)
> showsPrec p (Prst x) = showsPrec p x
> instance (Read a) => Read (TVal a) where
> readsPrec p s = case s' of ('_':t) ->
(Abst,t) : readsA
>
_ -> readsA
> where s' = dropWhile isSpace
s
>
readsA = map (\(a,t)-> (Prst a,t)) (readsPrec p s')
See section D.4 of the Haskell report for information on 'readsPrec',
'readList', 'showPrec', and 'showList'.
Dean Herington
--------------74E5E9480E30AA4DD6791F2C--
From Tom.Pledger@peace.com Sat Mar 31 04:41:50 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Sat, 31 Mar 2001 16:41:50 +1200
Subject: constants and functions without arguments
In-Reply-To: <3AC45E6E.AC2DC3C2@sbox.tu-graz.ac.at>
References: <3AC368A9.5BE8721F@sbox.tu-graz.ac.at>
<15043.46052.112130.797961@waytogo.peace.co.nz>
<3AC45E6E.AC2DC3C2@sbox.tu-graz.ac.at>
Message-ID: <15045.24590.927288.729070@waytogo.peace.co.nz>
Andreas Leitner writes:
:
| The classic examlple for this is class POINT, which has an interface
| like that:
| --
| POINT
| -- group 1
| x: DOUBLE
| y: DOUBLE
| -- group 2
| rho: DOUBLE
| abs: DOUBLE
| --
| Now, you can choose to either implement group 1 as attributes, or
| group 2 and calculate the other one. With the uniform access
| principle, which says that accessing attributes and functions with no
| arguments happen in the same syntactic way, you can change the
| implementaion without notice. No user of this class needs to know.
|
| I am to new to FP to say whether this is equaly important in
| FP-languages, since the semantics are different (constants vs.
| attributes and immutable values vs. objects), but for now I am just
| currious wether it is possible theoretically.
That uniformity of access can certainly be achieved in Haskell.
Here's the Point example. I've done it with two constructors so as to
get fewer floating point imprecisions, but some other possible
representations (e.g. one with only the Polar constructor) would look
identical outside the module.
module Point(Point, cartesian, polar, x, y, r, theta) where
-- data type with hidden constructors
data Point = Cartesian Double Double -- corresponds to group 1
| Polar Double Double -- corresponds to group 2
-- proxy constructor functions
cartesian x y = Cartesian x y
polar r theta = Polar r theta
-- attribute extraction functions
x (Cartesian x y) = x
x (Polar r theta) = r * cos theta
y (Cartesian x y) = y
y (Polar r theta) = r * sin theta
r (Cartesian x y) = sqrt (x*x + y*y)
r (Polar r theta) = r
theta (Cartesian x y) = atan2 y x
theta (Polar r theta) = theta