SourceForge's file release system is currently broken. When it's fixed,
I'll put it there too.
Haskell/JVM Bridge and source code is licensed under the GNU Lesser GPL.
I hope to build an Darwin/OS X version just as soon as there's a port of
GHC 5.02 with a working createAdjustor.
--
Ashley Yakeley, Seattle WA
From antony@apocalypse.org Mon Dec 17 02:44:30 2001
From: antony@apocalypse.org (Antony Courtney)
Date: Sun, 16 Dec 2001 21:44:30 -0500
Subject: ANNOUNCE: GCJNI - Java Native Interface for Haskell
References: <200112162357.PAA26291@mail4.halcyon.com>
Message-ID: <3C1D5C0E.5090402@apocalypse.org>
Hi Ashley,
I'm not quite sure why you Cc'ed the whole Haskell list in replying to my
release announcement, but just for clarification:
Ashley Yakeley wrote:
>
> I had no idea anyone else was working on this.
I find it odd you would say that. When you first mentioned your interest in the
JNI on the Haskell list in early July, I replied to you (and the rest of the
Haskell list) informing you I was working on such a project, and offering to
give you a pre-release snapshot of my source code:
http://www.haskell.org/pipermail/haskell/2001-July/001372.html
When you didn't reply to that message, I emailed you again privately on August
1st, specifically suggesting that we combine forces to avoid duplication of
effort. I never received a reply to that message either.
> Nevertheless, I suspect I'm further along.
Perhaps. Let's move this discussion to private email and try to find a way to
work together.
-antony
--
Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
antony@apocalypse.org http://www.apocalypse.org/pub/u/antony
From frank@cc.gatech.edu Mon Dec 17 05:40:21 2001
From: frank@cc.gatech.edu (Frank Dellaert)
Date: Mon, 17 Dec 2001 00:40:21 -0500
Subject: space efficiency question
Message-ID: <002201c186bd$51fcd6b0$a21ccf82@cc.gatech.edu>
This is a multi-part message in MIME format.
------=_NextPart_000_001F_01C18693.68D2E250
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I'm not a compiler/interpreter implementer, just a Haskell user :-)
My question is: if I have two datatypes, say
newtype Attributes =3D Att [String]
data Instance =3D Instance Attributes [Int]
where an Attributes value describes the discrete attributes that are =
stored (as Int) in an Instance.
Now: if I have a couple of thousand of these Instances, created with the =
same Attributes value, as in:
a =3D Attributes ["a","bc"]
i0000 =3D Instance a [1,2]
i0001 =3D Instance a [1,1]
...
i7896 =3D Instance a [2,1]
can I be assured that there are not thousands of actual copies of a but =
that they simply have a pointer to a ? I'm interested in the answer for =
both ghc (compiled/interpreted) as interpreted Hugs.
I would hope, so, right ? Is there an actual guarantee or is that an =
optimization that the implementation might or might not implement ?
Cheers
Frank Dellaert
------=_NextPart_000_001F_01C18693.68D2E250
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I'm not a compiler/interpreter =
implementer, just a=20
Haskell user :-)
My question is: if I have two =
datatypes,=20
say
newtype Attributes =3D Att =
[String]
data Instance =3D Instance Attributes=20
[Int]
where an Attributes value describes the =
discrete=20
attributes that are stored (as Int) in an Instance.
Now: if I have a couple of thousand of =
these=20
Instances, created with the same Attributes value, as in:
a =3D Attributes =
["a","bc"]
i0000 =3D Instance a [1,2]
i0001 =3D Instance a [1,1]
...
i7896 =3D Instance a [2,1]
can I be assured that there are not =
thousands of=20
actual copies of a but that they simply have a pointer to a ? I'm =
interested in=20
the answer for both ghc (compiled/interpreted) as interpreted =
Hugs.
I would hope, so, right ? Is there an =
actual=20
guarantee or is that an optimization that the implementation might or =
might not=20
implement ?
Cheers
Frank =
Dellaert
------=_NextPart_000_001F_01C18693.68D2E250--
From simonpj@microsoft.com Mon Dec 17 09:24:47 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 17 Dec 2001 01:24:47 -0800
Subject: space efficiency question
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066623@RED-MSG-10.redmond.corp.microsoft.com>
This is a multi-part message in MIME format.
--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C186DC.ABC0BECE"
------_=_NextPart_001_01C186DC.ABC0BECE
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Now: if I have a couple of thousand of these Instances, created with the
same Attributes value, as in:
=20
a =3D Attributes ["a","bc"]
i0000 =3D Instance a [1,2]
i0001 =3D Instance a [1,1]
...
i7896 =3D Instance a [2,1]
=20
can I be assured that there are not thousands of actual copies of a but
that they simply have a pointer to a ? I'm interested in the answer for
both ghc (compiled/interpreted) as interpreted Hugs.=20
Yes for GHC: you'll only get one copy of 'a'.
=20
Simon
=20
------_=_NextPart_001_01C186DC.ABC0BECE
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message
Now: if I have a couple of thousand of =
these=20
Instances, created with the same Attributes value, as in:
a =3D Attributes =
["a","bc"]
i0000 =3D Instance a =
[1,2]
i0001 =3D Instance a =
[1,1]
...
i7896 =3D Instance a =
[2,1]
can I be assured that there are =
not=20
thousands of actual copies of a but that they simply have a pointer to =
a ? I'm=20
interested in the answer for both ghc (compiled/interpreted) as =
interpreted=20
Hugs.
Yes for GHC: you'll only get one copy of=20
'a'.
Simon
------_=_NextPart_001_01C186DC.ABC0BECE--
--------------InterScan_NT_MIME_Boundary--
From reiner@cs.chalmers.se Mon Dec 17 09:55:16 2001
From: reiner@cs.chalmers.se (Reiner Haehnle)
Date: Mon, 17 Dec 2001 10:55:16 +0100 (MET)
Subject: Call for Applications to PhD Positions, Chalmers University, Sweden
Message-ID:
Please pass on to interested students. Apologies for multiple copies.
---------------------------------------------------------------------
New PhD Positions (DEADLINE 15 February 2002! See "How to apply" below)
Department of Computing Science,
Chalmers University of Technology & University of Gothenburg
Sweden
The Department has about 70 researchers, half being faculty members
and half PhD students. Our focus is on programming logic, type theory,
functional programming, formal methods, distributed and concurrent
systems, security, algorithms, bioinformatics, human computer
interaction, and computational linguistics, but research is not
restricted to these topics. For more information, see
http://www.cs.chalmers.se/Cs/Research.
PhD positions are for 5 years. There is no tuition fee. A PhD position
is a regular job with social benefits; the salary amounts currently to
about 16700 SEK per month in the first year (the exact amount depends
on teaching duties, usually 20% of your time).
Knowledge of Swedish is not a prerequisite for application. English is
our working language for research. Both Swedish and English are used
in undergraduate courses. Half of our researchers and PhD students
are native Swedes; the rest come from more than 20 different
countries.
Applicants must have a very good undergraduate degree in Computing
Science or in a related subject with a strong Computing Science
component. They must also have a strong interest in doing research.
You may even apply if you have not yet completed your degree, but
expect to do so by September 2002. You are also invited to apply for
our new International Master's Programme in Dependable Computer
Systems, which can help you to obtain the necessary qualification (see
http://www.cs.chalmers.se/Cs/Education/dcs/).
The School especially welcomes female applicants.
How to apply
------------
First, immediately register your intention to apply using the
electronic application form on the WWW via
http://www.md.chalmers.se/Jobs/PhD/phd-02-en.thtml
The full application should contain
1 A letter of application, listing specific research interests
2 A curriculum vitae
3 Attested copies of degrees and other certificates
4 Copies of relevant work, for example dissertations or
articles, that you have authored or co-authored
5 A description of:
a previous teaching experience, documented
b previous PhD studies, also in other subjects;
state financial support for these, if any
c previous work experience
6 Letters of recommendation from your teachers or employers
If you have financial support of your own (industry job, grant, etc.),
please state this fact clearly. It will increase your chances to be
accepted considerably, because you need not compete for the limited
number of fully financed positions.
Send your full application (paper mail) to
Department of Computing Science
School of Computer Science and Engineering
Chalmers University of Technology
412 96 Gothenburg
Sweden
to arrive by 15 February 2002. You will know the result of your
application by 1 May 2002.
From thorinn@diku.dk Mon Dec 17 14:50:21 2001
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Date: 17 Dec 2001 14:50:21 -0000
Subject: gcd 0 0 = 0
In-Reply-To: <20011216133559.C27182@cs.ucc.ie> (message from Marc van Dongen
on Sun, 16 Dec 2001 13:35:59 +0000)
Message-ID: <20011217145021.3269.qmail@tyr.diku.dk>
> From: Marc van Dongen
> Date: Sun, 16 Dec 2001 13:35:59 +0000
>
> Marc van Dongen (dongen@cs.ucc.ie) wrote:
>
> : An integer $a$ divides integer $b$ if there exists an integer
> : $c$ such that $a c= b$.
>
> To make clear why $0$ (and not any other non-zero integer) is the
> gcd of $0$ and $0$ I should have added that for the integer case
> $g$ is called a greatest common divisor (gcd) of $a$ and $b$ if it
> satifies each of the following two properties:
>
> 1) $g$ divides both $a$ and $b$;
> 2) if $g'$ is a common divisor of $a$ and $b$ then $g'$ divides $g$.
In case it isn't clear already, these definitions make a lattice on
the positive integers, with divides ~ leq, gcd ~ meet and lcm ~ join,
using the report's definitions of gcd and lcm.
(Choosing the positive result for gcd/lcm is equivalent to noting that
divides is a partial preorder on the non-zero integers, and that the
quotient identifies x and -x).
The only thing that is lacking to make it a lattice on the
non-negative integers, is that gcd 0 0 = 0 . All other cases
involving zero (i.e., gcd 0 x = x for non-zero x, and lcm 0 x = 0
for all x) are consistent with 0 being the maximal element in the
lattice, i.e., that all integers divide zero.
Lars Mathiesen (U of Copenhagen CS Dep) (Humour NOT marked)
From simonpj@microsoft.com Mon Dec 17 16:57:28 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 17 Dec 2001 08:57:28 -0800
Subject: Confused about default
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066637@RED-MSG-10.redmond.corp.microsoft.com>
Well, Foo *is* an instance of Num, so a correct Haskell impl
should pick that instance always. Since you don't define the
fromInteger method in the instance decl, you get a runtime error.
I don't know what you expect the [Foo] and Foo -> Int defaults
to do.
GHCi fails to put the correct default decl in place for command-line
expressions. This is a known bug which we have not got around
to fixing yet
Simon
| -----Original Message-----
| From: Ian Lynagh [mailto:igloo@earth.li]=20
| Sent: 14 December 2001 21:29
| To: haskell@haskell.org
| Subject: Confused about default
|=20
|=20
|=20
| Hi all
|=20
| I am rather confused about default.
|=20
| In section 4.3.4 the report says
| "each ti must be a monotype for which Num ti holds"
| but according to grep this is the only place "monotype"=20
| appears in the report.
|=20
| If I have the module
|=20
| module TT (Foo(..)) where
|=20
| default (Foo, [Foo], Foo -> Int)
|=20
| data Foo =3D Foo deriving (Eq, Show)
|=20
| instance Num Foo where {}
| instance (Eq a, Show a) =3D> Num [a] where {}
| instance Eq (a -> b) where {}
| instance Show (a -> b) where {}
| instance Num (a -> b) where {}
|=20
| then hugs accepts it and
| TT> 5
|=20
| Program error: Undefined member: fromInteger
|=20
| ghc accepts it and
| TT> 5
| 5
|=20
| nhc tells me
|=20
| Error when renaming::
| Illegal type in default at 4:17
|=20
| If I remove all the list and function stuff then hi says
| TT> 5
| 5
|=20
| If I have a
| main =3D putStrLn $ show 5
|=20
| then nhc gives me
| TT> main
| No default definition for class method fromInteger
|=20
| and ghci gives me
| Main> main
| *** Exception: TT.lhs:8: No instance nor default method for class
| operation PrelNum.fromInteger
|=20
|=20
| It seems to me that hugs is in the right with it's handling=20
| of 5, but I am not sure who is wrong with default ([Foo]) or=20
| (Foo -> Int).
|=20
|=20
| Finally, the context free grammar doesn't currently enforce=20
| the restriction that only one default declaration be given.=20
| Fixing it would make rather a mess, though.
|=20
|=20
| Ian
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From ger@tzi.de Mon Dec 17 17:05:41 2001
From: ger@tzi.de (George Russell)
Date: Mon, 17 Dec 2001 18:05:41 +0100
Subject: gcd 0 0 = 0
Message-ID: <3C1E25E5.81718477@tzi.de>
I've reconsidered my earlier position and think now that the Prelude is wrong to make
gcd 0 0 an error, and should return 0. It probably doesn't make much difference to
anyone, but it's like 1 not being a prime; it may be slightly harder to explain, but it
makes the maths come out nicer and is in the end a simplification.
From herrmann@infosun.fmi.uni-passau.de Mon Dec 17 17:31:17 2001
From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann)
Date: Mon, 17 Dec 2001 18:31:17 +0100
Subject: gcd 0 0 = 0
In-Reply-To: <3C1E25E5.81718477@tzi.de>
References: <3C1E25E5.81718477@tzi.de>
Message-ID: <15390.11237.38564.819599@reger.fmi.uni-passau.de>
>>>>> "George" == George Russell writes:
George> I've reconsidered my earlier position and think now that the
George> Prelude is wrong to make gcd 0 0 an error, and should return
George> 0. It probably doesn't make much difference to anyone, but
George> it's like 1 not being a prime; it may be slightly harder to
George> explain, but it makes the maths come out nicer and is in the
George> end a simplification.
I'm strongly against making 1 a prime number.
In contrast, 0*x=0, thus 0 "divides" 0 (somehow).
But I have problems with "gcd being the greatest positive integer ..."
- 0 is not positive, it is non-negative or natural
- 2 also divides 0 and 2 is a "greater integer" than 0
(0 is the top element of the lattice formed by the division relation
but that is not clear by the expression "greatest")
Anyway, gcd 0 0 = error would be the simplest way to avoid confusion
and catch accidental programming errors; e.g., using the gcd to divide
something else.
--
Christoph
From igloo@earth.li Mon Dec 17 17:32:02 2001
From: igloo@earth.li (Ian Lynagh)
Date: Mon, 17 Dec 2001 17:32:02 +0000
Subject: Confused about default
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE19066637@RED-MSG-10.redmond.corp.microsoft.com>; from simonpj@microsoft.com on Mon, Dec 17, 2001 at 08:57:28AM -0800
References: <1113DDB24D4A2841951BFDF86665EE19066637@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <20011217173202.A10045@stu163.keble.ox.ac.uk>
On Mon, Dec 17, 2001 at 08:57:28AM -0800, Simon Peyton-Jones wrote:
> Well, Foo *is* an instance of Num, so a correct Haskell impl
> should pick that instance always.
I was looking at what the implementations would allow, the module wasn't
supposed to be useful.
> Since you don't define the
> fromInteger method in the instance decl, you get a runtime error.
I expected this, I included it as in some cases I *didn't* et a runtime
error though.
> I don't know what you expect the [Foo] and Foo -> Int defaults
> to do.
Let me try to clarify what I was asking:
What is a monotype? For example, is "[Foo]" a monotype and is
"Foo -> Int" a monotype? The context free grammar implies that a
monotype is identical to a type, in which case why is a different name
used?
The rest was to attempt to highlight some inconsistencies in the
implementations.
Thanks
Ian
From Alan@LCS.MIT.EDU Mon Dec 17 18:45:04 2001
From: Alan@LCS.MIT.EDU (Alan Bawden)
Date: Mon, 17 Dec 2001 13:45:04 -0500 (EST)
Subject: gcd 0 0 = 0
In-Reply-To: <20011217145021.3269.qmail@tyr.diku.dk> (message from Lars Henrik
Mathiesen on 17 Dec 2001 14:50:21 -0000)
References: <20011217145021.3269.qmail@tyr.diku.dk>
Message-ID: <17Dec2001.133056.Alan@LCS.MIT.EDU>
From: Lars Henrik Mathiesen
Date: 17 Dec 2001 14:50:21 -0000
...
In case it isn't clear already, these definitions make a lattice on
the positive integers, with divides ~ leq, gcd ~ meet and lcm ~ join,
using the report's definitions of gcd and lcm.
Indeed, that's a nice way of putting it. How about if the report just
says:
In order to make the non-negative integers into a lattice under `gcd'
and `lcm', we define `gcd 0 0 = 0'.
From foc@cs.indiana.edu Mon Dec 17 22:26:25 2001
From: foc@cs.indiana.edu (LICS)
Date: Mon, 17 Dec 2001 17:26:25 -0500 (EST)
Subject: faculty position in logic
Message-ID: <200112172226.fBHMQHS08034@moose.cs.indiana.edu>
[Sincere apologies for duplicates]
Indiana University invites applications for a tenure-track
assistant professor position in applied logic.
Please see www.informatics.indiana.edu/positions/logic.html
for details. Applications received within the next few
weeks are likely to still get full consideration.
Applicants are welcome to email to foc@cs.indiana.edu
to notify of their mailed application, and to provide
pointers to any pertinent on-line documentation.
From foc@cs.indiana.edu Mon Dec 17 22:26:25 2001
From: foc@cs.indiana.edu (LICS)
Date: Mon, 17 Dec 2001 17:26:25 -0500 (EST)
Subject: faculty position in logic
Message-ID: <200112172226.fBHMQPx08125@moose.cs.indiana.edu>
[Sincere apologies for duplicates]
Indiana University invites applications for a tenure-track
assistant professor position in applied logic.
Please see www.informatics.indiana.edu/positions/logic.html
for details. Applications received within the next few
weeks are likely to still get full consideration.
Applicants are welcome to email to foc@cs.indiana.edu
to notify of their mailed application, and to provide
pointers to any pertinent on-line documentation.
From dongen@cs.ucc.ie Tue Dec 18 09:22:25 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Tue, 18 Dec 2001 09:22:25 +0000
Subject: gcd 0 0 = 0
In-Reply-To: <15390.11237.38564.819599@reger.fmi.uni-passau.de>; from herrmann@infosun.fmi.uni-passau.de on Mon, Dec 17, 2001 at 06:31:17PM +0100
References: <3C1E25E5.81718477@tzi.de> <15390.11237.38564.819599@reger.fmi.uni-passau.de>
Message-ID: <20011218092225.O27182@cs.ucc.ie>
Ch. A. Herrmann (herrmann@infosun.fmi.uni-passau.de) wrote:
: In contrast, 0*x=0, thus 0 "divides" 0 (somehow).
: But I have problems with "gcd being the greatest positive integer ..."
[snip]
: - 0 is not positive, it is non-negative or natural
: - 2 also divides 0 and 2 is a "greater integer" than 0
: (0 is the top element of the lattice formed by the division relation
: but that is not clear by the expression "greatest")
:
gcd a b is the greatest non-negative integer dividing both a
and b such that anything that divides both a and b also divides
gcd a b (so gcd a b is the greatest thing that divides both a
and b).
Regards,
Marc van Dongen
--
Marc van Dongen | dongen@cs.ucc.ie |
Computer Science Department | Western Road | () ASCII ribbon campaign
University College Cork | Cork, Ireland | /\ against HTML mail
phone: +353 (0)21 4903578 | fax: 4903113 |
From juhp@01.246.ne.jp Tue Dec 18 09:32:11 2001
From: juhp@01.246.ne.jp (Jens-Ulrik Petersen)
Date: 18 Dec 2001 18:32:11 +0900
Subject: ANNOUNCE: hsclock-0.01.0 release
Message-ID:
I am pleased to announce the initial release of hsclock,
another gtk+hs "applet" I've written.
hsclock is an accurate multi-zone gtk clock, which can also
run in a tty.
hsclock uses gtk timeouts to synchronise the time updates to
occur on the second or minute "tick" (dependent on the clock
format string), making display updates accurate to within
milliseconds.
More info, source and rpm's are available at:
http://www.01.246.ne.jp/~juhp/haskell/hsclock/
As usual feedback and comments welcome.
Enjoy, Jens
From dongen@cs.ucc.ie Tue Dec 18 09:32:49 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Tue, 18 Dec 2001 09:32:49 +0000
Subject: gcd 0 0 = 0
In-Reply-To: <17Dec2001.133056.Alan@LCS.MIT.EDU>; from Alan@LCS.MIT.EDU on Mon, Dec 17, 2001 at 01:45:04PM -0500
References: <20011217145021.3269.qmail@tyr.diku.dk> <17Dec2001.133056.Alan@LCS.MIT.EDU>
Message-ID: <20011218093249.P27182@cs.ucc.ie>
Alan Bawden (Alan@LCS.MIT.EDU) wrote:
: In case it isn't clear already, these definitions make a lattice on
: the positive integers, with divides ~ leq, gcd ~ meet and lcm ~ join,
: using the report's definitions of gcd and lcm.
:
: Indeed, that's a nice way of putting it. How about if the report just
: says:
:
: In order to make the non-negative integers into a lattice under `gcd'
: and `lcm', we define `gcd 0 0 = 0'.
It would surely make things a lot less accessible to people (including
me) who do not have any (or limited) knowledge about lattices. Why not
make it more accessible and use the following rule (ore something similar)?
The greates common divison (gcd) of two integers a and b is the unique
non-negative integer g which has each of the following two properties:
1) g divides both a and b; and
2) if g' also divides both a and b then g' also divides g,
Here an integer a divides an integer b if there is an integer c
such that b = c*a.
Note that if you regard an integer a to be greater than another
integer b if b divides a then the gcd of two intgerers may also
be regarded as the greatest common divisor of a and b.
Regards,
Marc van Dongen
From simonpj@microsoft.com Tue Dec 18 09:38:21 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 18 Dec 2001 01:38:21 -0800
Subject: gcd 0 0 = 0
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066640@RED-MSG-10.redmond.corp.microsoft.com>
If everyone likes this I'll put it in; otherwise I'll simply state that
gcd 0 0 is defined to be 0.=20
Christoph does not like this, but the weight of world opinion seems=20
to be fairly clearly in favour of gcd 0 0 =3D 0. Let's try to wrap =
this
one
up.
Simon
| -----Original Message-----
| From: Alan Bawden [mailto:Alan@LCS.MIT.EDU]=20
| Sent: 17 December 2001 18:45
| To: haskell@haskell.org; Simon Peyton-Jones
| Subject: Re: gcd 0 0 =3D 0
|=20
|=20
| From: Lars Henrik Mathiesen
| Date: 17 Dec 2001 14:50:21 -0000
| ...
| In case it isn't clear already, these definitions make a lattice on
| the positive integers, with divides ~ leq, gcd ~ meet and=20
| lcm ~ join,
| using the report's definitions of gcd and lcm.
|=20
| Indeed, that's a nice way of putting it. How about if the report just
| says:
|=20
| In order to make the non-negative integers into a lattice=20
| under `gcd'
| and `lcm', we define `gcd 0 0 =3D 0'.
|=20
From simonpj@microsoft.com Tue Dec 18 09:48:34 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 18 Dec 2001 01:48:34 -0800
Subject: Confused about default
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066643@RED-MSG-10.redmond.corp.microsoft.com>
| Let me try to clarify what I was asking:
|=20
| What is a monotype? For example, is "[Foo]" a monotype and is=20
| "Foo -> Int" a monotype? The context free grammar implies=20
| that a monotype is identical to a type, in which case why is=20
| a different name used?
A monotype is a type with no for-alls in it. But you are right that
it's confusing that this is the only occurrence. I think the simplest
thing is to change 'monotype' to 'type' here; after all, Num (forall
a.a->a)=20
does not hold!
thanks for pointing this out.
Simon
From simonpj@microsoft.com Tue Dec 18 09:58:23 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 18 Dec 2001 01:58:23 -0800
Subject: Haskell 98 IO
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066646@RED-MSG-10.redmond.corp.microsoft.com>
| Anyway, what should the report say? I think it is reasonable=20
| to expect that stdin & stdout should both be unbuffered in=20
| order for interact to work right. So the defn of interact should be
|=20
| interact f =3D do
| hSetBuffering stdin NoBuffering -- new
| hSetBuffering stdout NoBuffering -- new
| s <- hGetContents
| putStr (f s)
Simon Marlow raises a good point here. If 'interact' is to be
interactive
it had better be unbuffered. So I propose to add the two new lines
above to the Report. This does not change the intended behaviour
at all.
Simon
From gupta@herbrand.utdallas.edu Mon Dec 17 23:28:05 2001
From: gupta@herbrand.utdallas.edu (Dr. Gopal Gupta)
Date: Mon, 17 Dec 2001 17:28:05 -0600
Subject: 4th Int'l Symp.: Practical Aspects of Declarative Languages
Message-ID: <200112172328.fBHNS5u02536@herbrand.utdallas.edu>
[ o Apologies for multiple messages.
o Please register and make hotel reservations as soon as possible since
both deadlines are approaching fast (Dec. 27th)
].
You are cordially invited to the Fourth International Symposium on
Practical Aspects of Declarative Languages that will be held on Jan 19-20,
2002 right after ACM POPL. The program includes invited talks by three
distinguished speakers: J. Strother Moore of the University of Texas at
Austin, Catherine Meadows of the Naval Research Labs, and Veronica Dahl of
Simon Fraser University. Very low registration rates ($150 regular and
$100 student) and low conference hotel rates have been secured to make the
event affordable. The program ends by late afternoon on Sunday to let
attendees return home on Sunday itself. If you are attending ACM POPL, we
especially encourage you to plan to attend PADL.
More details can be found at:
http://www.cs.sunysb.edu/~padl2002
---------------------------------------------------------------------
Fourth International Symposium on
Practical Aspects of Declarative Languages
(PADL '02)
Portland, Oregon, USA Jan 19-20, 2002
Co-located with POPL 2002
---------------------------------------------------------------------
Conference Program
==================
Jan 19th
8:45-9:00 Opening Remarks
9:00-10:00 Invited Talk #1
Using a Declarative Language to Build an Experimental Analysis Tool
Catherine Meadows (Naval Research Laboratory),
10:00-10:30 Coffee Break
10:30-12:30 Session-I:
Modeling Engineering Structures using Constrained Objects
Bharat Jayaraman and Pallavi Tambay
Compiler Construction in Higher Order Logic Programming
Chuck Liang
Declarative Programming with Application to Clinical Medicine:
On the Use of Gisela in the MedView Project.
Olof Torgersson
Semantics-based Filtering: Logic Programming's Killer App?
Gopal Gupta, Hai-Feng Guo, Arthur Karshmer,
Enrico Pontelli, Desh Ranjan, B. Milligan,
N. Datta, O. El Khatib, M. Noamany, and X. Zhou
12:30-1:30 Lunch
1:30-2:30 Invited Talk #2
How to Talk to Your Computer So That it Will Listen
Veronica Dahl (Simon Fraser University),
2:45-4:15 Session-II:
Linear Scan Register Allocation in a High-Performance Erlang Compiler
Erik Johansson and Konstantinos Sagonas
Typed Combinators for Generic Traversal
Ralf Laemmel and Joost Visser
Event-Driven FRP.
Zhanyong Wan, Walid Taha, and Paul Hudak
4:15-4:30 Coffee Break
4:30-6:00 Session-III:
Compiling Embedded Programs to Byte Code.
Morten Rhiger,
Exploiting Efficient Control and Data Structures in Logic Programs.
Rong Yang and Steve Gregory,
Memory Management and Scheduling in a Tabling Engine
Luis F. Castro and Terrance Swift and David S. Warren
--------------------------------------------------------------------------------
Jan 20th
9:00-10:00 Invited Talk #3:
Single-Threaded Objects in ACL2.
J. Strother Moore (University of Texas, Austin)
10:00-10:30 Coffee Break
10:30-12:30 Session-IV:
Adding Apples and Oranges
Martin Erwig and Margaret Burnett
WASH/CGI: Server-side Web Scripting with Sessions and Typed,
Compositional Forms.
Peter Thiemann
A better XML parser through functional programming.
Oleg Kiselyov
Functional Approach to Texture Generation.
Jerzy Karczmarczuk
12:30-1:30 Lunch
1:30-3:30 Session-V:
Abstract Interpretation over Non-Deterministic Finite
Tree Automata for Set-Based Analysis of Logic Programs.
John Gallagher, German Puebla,
A High-Level Generic Interface to External Programming Languages for ECLiPSe.
Kish Shen, Joachim Schimpf, Stefano Novello, Josh Singer,
Segment Order Preserving and Generational Garbage Collection for Prolog.
Ruben Vandeginste, Konstantinos Sagonas, and Bart Demoen,
A Debugging Scheme for Declarative Equation Based Modeling Languages.
Peter Bunus, Peter Fritzson
From herrmann@infosun.fmi.uni-passau.de Tue Dec 18 11:16:11 2001
From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann)
Date: Tue, 18 Dec 2001 12:16:11 +0100
Subject: gcd 0 0 = 0
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE19066640@RED-MSG-10.redmond.corp.microsoft.com>
References: <1113DDB24D4A2841951BFDF86665EE19066640@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <15391.9595.758521.560553@reger.fmi.uni-passau.de>
>>>>> "Simon" == Simon Peyton-Jones writes:
Simon> Christoph does not like this
It's OK if the definition is clear; it wasn't using
the words "positive" or "greatest integer".
Stating "gcd 0 0 = 0" explicitly is a good thing,
even if it could be expressed verbatim;
people may think about the mathematical background,
but they should not need to think about the
meaning of the definition.
Anyway, I'm still against promoting 1 to a prime number :-)
Cheers
--
Christoph
From frank@cc.gatech.edu Tue Dec 18 11:48:18 2001
From: frank@cc.gatech.edu (Frank Dellaert)
Date: Tue, 18 Dec 2001 12:48:18 +0100
Subject: space efficiency question
References: <1113DDB24D4A2841951BFDF86665EE19066623@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <000f01c187b9$e3216280$544a88d9@oemcomputer>
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C187C2.4477ED80
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MessageThanks !
Now, a small follow-up question: if I subsequently test 2 Instances =
whether they were instantiated with the same Attributes value, as in
test (Instance a1 _) (Instance a2 _) =3D (a1=3D=3Da2)
will this be implemented efficiently ? I.e. will it check first whether =
the pointers happen to be the same, and only then do a full Eq =
comparison ?
Cheers
Frank
----- Original Message -----=20
From: Simon Peyton-Jones=20
To: Frank Dellaert ; Haskell@haskell.org=20
Sent: Monday, December 17, 2001 10:24 AM
Subject: RE: space efficiency question
Now: if I have a couple of thousand of these Instances, created with =
the same Attributes value, as in:
=20
a =3D Attributes ["a","bc"]
i0000 =3D Instance a [1,2]
i0001 =3D Instance a [1,1]
...
i7896 =3D Instance a [2,1]
=20
can I be assured that there are not thousands of actual copies of a =
but that they simply have a pointer to a ? I'm interested in the answer =
for both ghc (compiled/interpreted) as interpreted Hugs.=20
Yes for GHC: you'll only get one copy of 'a'.
=20
Simon
=20
------=_NextPart_000_000C_01C187C2.4477ED80
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message
Thanks !
Now, a small follow-up question: if I =
subsequently=20
test 2 Instances whether they were instantiated with the same Attributes =
value,=20
as in
test (Instance a1 _) (Instance a2 _) =
=3D=20
(a1=3D=3Da2)
will this be implemented efficiently ? =
I.e. will it=20
check first whether the pointers happen to be the same, and only then do =
a full=20
Eq comparison ?
Cheers
Frank
----- Original Message -----
From:=20
Simon=20
Peyton-Jones
Sent: Monday, December 17, 2001 =
10:24=20
AM
Subject: RE: space efficiency=20
question
Now: if I have a couple of thousand =
of these=20
Instances, created with the same Attributes value, as in:
a =3D Attributes =
["a","bc"]
i0000 =3D Instance a =
[1,2]
i0001 =3D Instance a =
[1,1]
...
i7896 =3D Instance a =
[2,1]
can I be assured that there =
are not=20
thousands of actual copies of a but that they simply have a pointer =
to a ?=20
I'm interested in the answer for both ghc (compiled/interpreted) as=20
interpreted Hugs.
Yes for GHC: you'll =
only get one=20
copy of 'a'.
Simon
=
------=_NextPart_000_000C_01C187C2.4477ED80--
From voigt@orchid.inf.tu-dresden.de Tue Dec 18 13:22:19 2001
From: voigt@orchid.inf.tu-dresden.de (Janis Voigtlaender)
Date: Tue, 18 Dec 2001 14:22:19 +0100
Subject: space efficiency question
References: <1113DDB24D4A2841951BFDF86665EE19066623@RED-MSG-10.redmond.corp.microsoft.com> <000f01c187b9$e3216280$544a88d9@oemcomputer>
Message-ID: <3C1F430B.D5B230AC@tcs.inf.tu-dresden.de>
Frank Dellaert asks:
> test (Instance a1 _) (Instance a2 _) = (a1==a2)
>
> will this be implemented efficiently ? I.e. will it check first whether the > pointers happen to be the same, and only then do a full Eq comparison ?
No, otherwise you might also expect that the following test' function:
test' :: String -> Bool
test' s = (s==s)
always returns True, without considering its actual argument s. But this
is not the way of it, (==) evaluates the two strings to be compared as
far as necessary for this comparison. For example:
test' "abc" = True
but:
test' undefined = undefined
If you really need something like pointer equality, you might want to
consider the stable names of:
@inproceedings{ jones99stretching,
author = "Simon L. Peyton Jones and Simon Marlow and Conal Elliott",
title = "Stretching the Storage Manager: Weak Pointers and Stable
Names in Haskell",
booktitle = "Implementation of Functional Languages",
pages = "37-58",
year = "1999",
url = "citeseer.nj.nec.com/jones99stretching.html" }
--
Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:voigt@tcs.inf.tu-dresden.de
From thorinn@diku.dk Tue Dec 18 16:11:08 2001
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Date: 18 Dec 2001 16:11:08 -0000
Subject: gcd 0 0 = 0
In-Reply-To: <20011218093249.P27182@cs.ucc.ie> (message from Marc van Dongen
on Tue, 18 Dec 2001 09:32:49 +0000)
Message-ID: <20011218161108.5990.qmail@tyr.diku.dk>
> From: Marc van Dongen
> Date: Tue, 18 Dec 2001 09:32:49 +0000
>
> Alan Bawden (Alan@LCS.MIT.EDU) wrote:
> : Indeed, that's a nice way of putting it. How about if the report just
> : says:
> :
> : In order to make the non-negative integers into a lattice under `gcd'
> : and `lcm', we define `gcd 0 0 = 0'.
> It would surely make things a lot less accessible to people
> (including me) who do not have any (or limited) knowledge about
> lattices. Why not make it more accessible and use the following rule
> (ore something similar)?
> The greates common divison (gcd) of two integers a and b is the unique
> non-negative integer g which has each of the following two properties:
> 1) g divides both a and b; and
> 2) if g' also divides both a and b then g' also divides g,
> Here an integer a divides an integer b if there is an integer c
> such that b = c*a.
This is exactly what you get if you plug the relation 'divides' on the
non-negative integers into the definition of meet in a lattice. So
this formulation is no more or less complex to use than the lattice
one --- and people who do know about lattices will probably realize
this pretty fast.
It all depends on who you want to convince that gcd 0 0 should be 0,
the mathematicians (by elegance) or the programmers (by concreteness).
But since it seems that Simon is just going to put 'it is so' in the
report, the point is moot.
Lars Mathiesen (U of Copenhagen CS Dep) (Humour NOT marked)
From wittner@uni-duesseldorf.de Tue Dec 18 16:43:33 2001
From: wittner@uni-duesseldorf.de (Toralf Wittner)
Date: Tue, 18 Dec 2001 17:43:33 +0100
Subject: x^y
Message-ID: <0GOJ006RUT6O12@neptun.rz.uni-duesseldorf.de>
Hello,
you can count me as a newbie in functional programming. I'm attempting to
define a function that computes the value of x^y for whole numbers. Intuively
(all efficiency considerations aside) I would start with something like this:
power x y
| x == 0 = 0
| y == 0 = 1
| y > 0 = x * power x (y-1)
| y < 0 = 1 / fromInteger x * power x (y+1)
One recognizes that the function returns either an integer value if y > 0 or
a float value if y < 0. Therefore I can't write a signature like
pow :: Integer -> Integer -> Integer nor can I do
pow :: Integer -> Integer -> Double. If I would use Python I could write
something like this:
def power(m, n):
if m == 0: return 0
if n == 0: return 1
if n > 0: return m * power(m, (n-1))
if n < 0: return (1 / float(m)) * power(m, (n+1))
How then would I write this function in Haskell (concerning types)?
Thanks in advance! Kind regards,
Toralf
From dongen@cs.ucc.ie Tue Dec 18 17:02:36 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Tue, 18 Dec 2001 17:02:36 +0000
Subject: gcd 0 0 = 0
In-Reply-To: <20011218161108.5990.qmail@tyr.diku.dk>; from thorinn@diku.dk on Tue, Dec 18, 2001 at 04:11:08PM -0000
References: <20011218093249.P27182@cs.ucc.ie> <20011218161108.5990.qmail@tyr.diku.dk>
Message-ID: <20011218170236.C4643@cs.ucc.ie>
Lars Henrik Mathiesen (thorinn@diku.dk) wrote:
: > Alan Bawden (Alan@LCS.MIT.EDU) wrote:
: > : Indeed, that's a nice way of putting it. How about if the report just
: > : says:
: > :
: > : In order to make the non-negative integers into a lattice under `gcd'
: > : and `lcm', we define `gcd 0 0 = 0'.
[snip]
: This is exactly what you get if you plug the relation 'divides' on the
: non-negative integers into the definition of meet in a lattice. So
: this formulation is no more or less complex to use than the lattice
: one --- and people who do know about lattices will probably realize
: this pretty fast.
I disagree. Alan is talking about adding things to the haskell report.
That document should be accessible to as many people as possible.
I have not yet met anybody who had lattice theory in primary and/or
secondary school. On the other hand I *have* met quite a few of them
who have a pretty good idea about what it means for one number to
divide another.
[snip]
Regards,
Marc van Dongen
--
Marc van Dongen | dongen@cs.ucc.ie |
Computer Science Department | Western Road | () ASCII ribbon campaign
University College Cork | Cork, Ireland | /\ against HTML mail
phone: +353 (0)21 4903578 | fax: 4903113 |
From kentk@md.chalmers.se Tue Dec 18 17:00:30 2001
From: kentk@md.chalmers.se (Kent Karlsson)
Date: Tue, 18 Dec 2001 18:00:30 +0100
Subject: gcd 0 0 = 0
In-Reply-To: <15391.9595.758521.560553@reger.fmi.uni-passau.de>
Message-ID: <000701c187e5$80c7c1c0$b4e21081@chalmers95a69n>
> >>>>> "Simon" == Simon Peyton-Jones writes:
>
> Simon> Christoph does not like this
I still don't like this. 0 has never, and will never, divide anything,
in particular not 0. 0 may be a prime factor of 0 (see also below!),
but that is different. It is not the greatest (in the ordinary sense)
divisor of 0. Indeed, +infinity is a much larger divisor of 0...
I'm not in favour of using a very special-purpose order, not used for
anything else, and that isn't even an order but a preorder, just to
motivate gcd 0 0 = 0. Even if using this very special-purpose preorder,
an infinity would be included in the 'top' equivalence class, and if we
pick a representative value on the basis of which is 'greater' in the
ordinary sense for integers augmented with infinities(!), then +infinity
should be the representative value. Thus, in any case, gcd 0 0 = +infinity.
This is easy enough for Integer, where +infinity and -infinity can easily
be made representable (and should be made representable), but harder for
a 'pure hardware' Int datatype. But in an ideal world, gcd 0 0 = +infinity
with no error or exception.
> It's OK if the definition is clear; it wasn't using
> the words "positive" or "greatest integer".
>
> Stating "gcd 0 0 = 0" explicitly is a good thing,
> even if it could be expressed verbatim;
> people may think about the mathematical background,
> but they should not need to think about the
> meaning of the definition.
> Anyway, I'm still against promoting 1 to a prime number :-)
Why? If EVERY natural number is to have a prime factorisation, then BOTH
0 AND 1 have to be promoted to prime numbers; otherwise 1 and 0 cannot be
prime factorised; in addition to that 1 is then a prime factor of any number
(that can be excluded from the *minimal* list of prime factors except for 1)...
There is no fundamental reason to except 1 from being a prime number. But
there is a fundamental reason to say that 0 can never be a divisor (i.e. 0|0
is false; x|y is true iff x is a *non-zero* factor of y; the 'non-zero' part
is often left implicit (e.g. one is only talking about strictly positive
integers), which is part of the reason why we are having this discussion).
If you want something similar to gcd, but that returns 0 for 0 and 0, then
it is the 'product of all common prime factors'; where 1 has the (non-minimal)
prime factorisation [1, 1, ...], 0 has the (non-minimal) prime factorisation
[0, 1, 2, ...], and 1 is included at least once in the (non-minimal) prime
factorisation of any natural number. If you want a parallel to the divides
relation where 0 and 0 are related: 0 is a factor of 0. A prime number
is a number that has no integer *between* 1 and itself as factors. People
often say "except" instead of "between", but that does not work for 0, nor
for the non-minimal prime factorisations that people seem to be interested
in, given the interest in having gcd 0 0 = 0 (which isn't the gc*d*!). Again,
the context is often strictly positive integers, and 'between' and 'except'
are then equivalent. For no apparent reason 1 is usually also excepted, but
that does not work for the prime factorisation of 1, nor for finding the
product of all common prime factors of 1 and another natural number... For
integers, -1 is also a prime number, and for imaginary integers, i is also
a prime number... I'm sure somebody can give a nice definition of a partial
order (not just preorder) lattice with 1 as the min value and 0 as the max
value (just larger than the infinities), if you absolutely want a lattice
with a gcd-*like* meet and lcm-*like* join for this (the, positive bias,
factor-of order).
I'd be happy to support such gcd-*like* (pcf?) and lcm-*like* functions, but
they aren't the gcd, nor the lcm (e.g. pcf (-1) (-1) = -1, not 1, etc.).
If you don't like adding these, then I suggest leaving things completely as
they are. Squeezing in two operations into one just because they have the
same results over the first quadrant is not something I find to be too good.
Odd one out?
/kent k
From dpt@math.harvard.edu Tue Dec 18 18:12:14 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Tue, 18 Dec 2001 13:12:14 -0500
Subject: gcd 0 0 = 0
In-Reply-To: <000701c187e5$80c7c1c0$b4e21081@chalmers95a69n>; from kentk@md.chalmers.se on Tue, Dec 18, 2001 at 06:00:30PM +0100
References: <15391.9595.758521.560553@reger.fmi.uni-passau.de> <000701c187e5$80c7c1c0$b4e21081@chalmers95a69n>
Message-ID: <20011218131214.A18214@noether.math.harvard.edu>
On Tue, Dec 18, 2001 at 06:00:30PM +0100, Kent Karlsson wrote:
> Why? If EVERY natural number is to have a prime factorisation, then BOTH
> 0 AND 1 have to be promoted to prime numbers;
1 has a perfectly fine prime factorization. It is the product of 0 primes,
the null product. (A null product is defined, for very good reasons, to
be 1, just like a null sum is defined to be 0.)
I could see defences of calling 0 a prime, although it is not standard
mathematical practice. The ideal generated by 0 is a prime ideal,
for one thing. 0 would still not have a unique prime factorization,
however. (But Haskell should not unilaterally decide to violate standard
mathematical terminology!)
> ... But
> there is a fundamental reason to say that 0 can never be a divisor (i.e. 0|0
> is false; x|y is true iff x is a *non-zero* factor of y; the 'non-zero' part
> is often left implicit (e.g. one is only talking about strictly positive
> integers), which is part of the reason why we are having this discussion).
What fundamental reason do you have in mind? Why do you use this definition
of divisibility? (I'm curious; other mathematicians give the same
definition, and I can't see why.)
This thread made me curious, so I did a little library research. I was
surprised to discover that mathematicians discover on this, the domain
of definition of "gcd a b":
Domain References
------ ----------
a /= 0, b /= 0 Lang, "Algebra, 3rd Edition"
Hasse, "Number Theory"
a, b not both 0 Koblitz, "A Course on Number Theory and Cryptography"
all a, b allowed MacLane and Birkhoff, "Algebra, 2nd Edition"
Koch, "Number Theory"
At least the books by Lang and MacLane-Birkhoff are standard references.
Note that the definitions all agree when they are defined (with gcd 0 0 = 0).
As I said, I was surprised; to me, the definiton with all a and b is the
more natural one. I still recommend using the full domain (especially since
exceptions are awkward to deal with in Haskell), but I'm not as certain.
Best,
Dylan Thurston
From ack@nethere.com Tue Dec 18 23:54:13 2001
From: ack@nethere.com (Michael Ackerman)
Date: Tue, 18 Dec 2001 15:54:13 -0800
Subject: gcd 0 0 = 0
References: <15391.9595.758521.560553@reger.fmi.uni-passau.de> <000701c187e5$80c7c1c0$b4e21081@chalmers95a69n> <20011218131214.A18214@noether.math.harvard.edu>
Message-ID: <3C1FD725.FFC84D92@nethere.com>
The general meaning of `having a prime factorization' is that every
non-zero element is uniquely a product of a unit and a product of
primes. The algebraic structures where unique factorizations live are
`unique factorization domains' (UFDs) of which a central class is formed
by the ring of polynomials over a field. Here the non-zero elements of
the field are the units; no one has ever suggested calling them primes!
In a general UFD one can only speak of _a_ gcd of two elements x and y,
meaning an element d such that one has (x, y) = (d), an equality of
ideals. In some special cases, there is a natural choice for d (e.g., in
the integers, the non-negative d; in the ring of polynomials over a
field, the monic d (having leading coeff. 1)). In some UFDs there is no
canonical choice (e.g. in the Gaussian integers, a + ib for a, b integers).
gcd(0, 0) = 0.
Cheers,
Michael Ackerman
Dylan Thurston wrote:
>
> On Tue, Dec 18, 2001 at 06:00:30PM +0100, Kent Karlsson wrote:
> > Why? If EVERY natural number is to have a prime factorisation, then BOTH
> > 0 AND 1 have to be promoted to prime numbers;
>
> 1 has a perfectly fine prime factorization. It is the product of 0 primes,
> the null product. (A null product is defined, for very good reasons, to
> be 1, just like a null sum is defined to be 0.)
>
> I could see defences of calling 0 a prime, although it is not standard
> mathematical practice. The ideal generated by 0 is a prime ideal,
> for one thing. 0 would still not have a unique prime factorization,
> however. (But Haskell should not unilaterally decide to violate standard
> mathematical terminology!)
>
> > ... But
> > there is a fundamental reason to say that 0 can never be a divisor (i.e. 0|0
> > is false; x|y is true iff x is a *non-zero* factor of y; the 'non-zero' part
> > is often left implicit (e.g. one is only talking about strictly positive
> > integers), which is part of the reason why we are having this discussion).
>
> What fundamental reason do you have in mind? Why do you use this definition
> of divisibility? (I'm curious; other mathematicians give the same
> definition, and I can't see why.)
>
> This thread made me curious, so I did a little library research. I was
> surprised to discover that mathematicians discover on this, the domain
> of definition of "gcd a b":
>
> Domain References
> ------ ----------
> a /= 0, b /= 0 Lang, "Algebra, 3rd Edition"
> Hasse, "Number Theory"
>
> a, b not both 0 Koblitz, "A Course on Number Theory and Cryptography"
>
> all a, b allowed MacLane and Birkhoff, "Algebra, 2nd Edition"
> Koch, "Number Theory"
>
> At least the books by Lang and MacLane-Birkhoff are standard references.
> Note that the definitions all agree when they are defined (with gcd 0 0 = 0).
>
> As I said, I was surprised; to me, the definiton with all a and b is the
> more natural one. I still recommend using the full domain (especially since
> exceptions are awkward to deal with in Haskell), but I'm not as certain.
>
> Best,
> Dylan Thurston
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From Jan de Wit" <000701c187e5$80c7c1c0$b4e21081@chalmers95a69n> <20011218131214.A18214@noether.math.harvard.edu> <3C1FD725.FFC84D92@nethere.com>
Message-ID: <003601c18822$2258e000$2fe5fea9@yatima>
Why not define gcd a b as the largest (in 'normal' order) integer d such
that the set of sums of
multiples of a and b {na+mb | n <- Z, m <- Z} is equal to the set of
multiples of d
{nd | n <- Z}? Easy to understand, no talk of division, lattices, rings,
ideals etcetera, and it covers the cases with 0.
Cheers, Jan de Wit
From ack@nethere.com Wed Dec 19 00:26:46 2001
From: ack@nethere.com (Michael Ackerman)
Date: Tue, 18 Dec 2001 16:26:46 -0800
Subject: gcd oops
Message-ID: <3C1FDEC6.54484152@nethere.com>
Sorry for an error in my previous message. The definition there of a gcd
works only in a prinicpal ideal domain (which covers all the rings
mentioned in the examples). According to Bourbaki, chapter on ordered
groups, the gcd of two non-zero elements of a UFD A is well-defined as
an element of (A-{0})/units, a quotient monoid. So in this context
gcd(0, _) is undefined. But Bourbaki adds that this concept is
`sometimes' extended to the gcd of a finite family (x_i) of elements
some of which may be zero by taking the gcd to be an element d such that
for all z, z divides d iff z divides each x_i.
Cheers,
Michael Ackerman
From ashley@semantic.org Wed Dec 19 06:24:24 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 18 Dec 2001 22:24:24 -0800
Subject: ANN (bis): Release 0.1 of Haskell/Java VM Bridge
Message-ID: <200112190624.WAA02738@mail4.halcyon.com>
OK, the SourceForge file release system bug has been fixed, so I put the
release files up there. Please download from there rather than from
semantic.org.
Revised, expanded announcement...
-------
The first release, 0.1, of Haskell/Java VM Bridge is now available.
Haskell/Java VM Bridge allows Haskell programs access to the Java Virtual
Machine. Features include:
* Calling of Java methods, access to fields, array-handling;
* Integration of garbage collectors;
* Reconciliation of exception models;
* Reconciliation of thread models, including 'synchronized'
monitor support and the ability to fork Haskell actions as
Java threads;
* Strong typing for Java classes and method argument lists
(as tuples), and use of Haskell lists as arrays;
* Creation of Java classes 'on the fly' (using DefineClass and
the Java Class File Format) that can have Haskell callback
methods;
* Lifted monads which do all the necessary JNI class and
method/field ID preloading and 'JNIEnv'-pointer variable
handling for you -- these can be automatically generated via
a tool (MakeJVMModule);
* Layered design includes lower-level IO-based interface;
* Automatic generation of modules for Java API classes;
* All relevant imports, flags and libraries etc. handled by
a single GHC package 'javavm';
* No 'unsafe' Haskell calls or pure function FFI anywhere.
This release should be 'beta' quality, but has undergone little testing.
You will need:
* An x86 machine running some form of Unix;
* GHC 5.02 or later;
* The appropriate JVM, installed in the appropriate place:
- IBM JDK/JRE 1.3 for x86, installed in /usr/lib/ibm-java/IBMJava2-13/
- Blackdown Port of Sun's JRE 1.3/Sun JDK 1.3 for x86, installed in
/usr/lib/j2sdk1.3/ and /usr/lib/j2re1.3/
No documentation is currently available, sorry. Two examples have been
included: a trivial "hello world" program, and a program that shows a
Java Frame containing an instance of a Haskell-defined subclass of Canvas
that has a Haskell 'paint' method that draws an oval. You should be able
to figure out most of it from that... and of course the source is
available from SourceForge CVS.
Be sure to download the correct .tar.gz file for your Java VM. Simple
installation instructions are included in the file.
Haskell/JVM Bridge and source code is licensed under the GNU Lesser GPL.
Future plans:
* documentation
* port to Cygwin
* port to Darwin/OS X (waiting on GHC)
* use of Java 1.4 API (waiting on Sun, though use of beta
versions is possible)
--
Ashley Yakeley, Seattle WA
From mechvel@math.botik.ru Wed Dec 19 08:12:34 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Wed, 19 Dec 2001 11:12:34 +0300
Subject: x^y. Reply
Message-ID:
Toralf Wittner writes
> [..]
> power x y
> [..]
> | y > 0 = x * power x (y-1)
> | y < 0 = 1 / fromInteger x * power x (y+1)
>
> One recognizes that the function returns either an integer value
> if y > 0 or a float value if y < 0. Therefore I can't write a
> signature like
> pow :: Integer -> Integer -> Integer nor can I do
> pow :: Integer -> Integer -> Double.
>
> [..]
> How then would I write this function in Haskell (concerning types)?
The type Rational fits the case n < 0 too, and it includes Integer.
But if you still need Integer | Double, you can, for example,
introduce a new type of a disjoint union of the above two, and then,
to compute like this:
pow (Intg 2) 2 --> Intg 4
pow (Intg 2) (-2) --> D 0.25
pow (D 2.0) (-2) --> D 0.25
This is achieved by
data PowerDom = Intg Integer | D Double deriving(Eq,Show)
pow :: PowerDom -> Integer -> PowerDom
pow x n = p x n
where
p (Intg m) n = if n > 0 then Intg $ powerInteger m n
else D $ powerDouble (fromInteger m :: Double) n
p(D d) n = D $ powerDouble d n
powerInteger m n = m^n :: Integer
powerDouble :: Double -> Integer -> Double
powerDouble d n = ... usual way for float
- something like this.
-----------------
Serge Mechveliani
mechvel@botik.ru
From till@doerges.net Wed Dec 19 09:13:45 2001
From: till@doerges.net (Till Doerges)
Date: Wed, 19 Dec 2001 10:13:45 +0100
Subject: x^y
In-Reply-To: <0GOJ006RUT6O12@neptun.rz.uni-duesseldorf.de>; from wittner@uni-duesseldorf.de on Tue, Dec 18, 2001 at 05:43:33PM +0100
References: <0GOJ006RUT6O12@neptun.rz.uni-duesseldorf.de>
Message-ID: <20011219101345.B2662@atlan.wanderer.none>
On Tue, Dec 18, 2001 at 05:43:33PM +0100, Toralf Wittner wrote:
> power x y
> | x == 0 = 0
> | y == 0 = 1
> | y > 0 = x * power x (y-1)
> | y < 0 = 1 / fromInteger x * power x (y+1)
Why did you put 'fromInteger' into the last line? If you get rid of
that, this will make your 'power' be accepted by the haskell-compiler
or -interpreter.
> One recognizes that the function returns either an integer value if y > 0 or
> a float value if y < 0. Therefore I can't write a signature like
> pow :: Integer -> Integer -> Integer nor can I do
> pow :: Integer -> Integer -> Double.
No, you can't, and that's one of the reasons why type-classes where
introduced. You don't have to state the type of x and y
explicitely. Rather you can specify certain 'properties', i.e. y must
be a number, there must be an ordering relation and x must allow for the
representation of fractions.
--- snip ---
Main> :t power
power :: (Num a, Ord a, Fractional b) => b -> a -> b
Main> power 2 3
8.0
(113 reductions, 147 cells)
Main> power 2 (-1)
0.5
(70 reductions, 87 cells)
Main>
--- snap ---
> How then would I write this function in Haskell (concerning types)?
See above (the type signature was kindly provided by hugs ;-).
HTH -- Till
--
e-mail: reverse(net dot doerges at till) | ENCRYPTED |
pgp/gpg: keys via keyserver or my homepage | MAIL IS |
www: http://www.doerges.net | WELCOME! |
From GACOGNE Louis equipe Bernadette Bouchon-Meunier Wed Dec 19 09:33:39 2001
From: GACOGNE Louis equipe Bernadette Bouchon-Meunier (GACOGNE Louis equipe Bernadette Bouchon-Meunier)
Date: Wed, 19 Dec 2001 10:33:39 +0100 (MET)
Subject: random
Message-ID: <200112190933.KAA05235@atlantide.muses>
Is there a random function in Hugs 98 on macintosh. I found something about
random in the library but I was not able to find a random function running.
Louis Gacogne
IIE-CNAM allee Jean Rostand 91025 Evry (tel 01 69 36 73 41)
Laboratoire d'Informatique de l'Universite Paris VI
Place Jussieu 75252 Paris 5 (tel 01 44 27 88 07)
http://www.iie.cnam.fr/~gacogne/
From kentk@md.chalmers.se Wed Dec 19 13:04:25 2001
From: kentk@md.chalmers.se (Kent Karlsson)
Date: Wed, 19 Dec 2001 14:04:25 +0100
Subject: gcd 0 0 = 0
In-Reply-To: <003601c18822$2258e000$2fe5fea9@yatima>
Message-ID: <000001c1888d$b01113c0$b4e21081@chalmers95a69n>
Let me try again:
greatest -> maximum/supremum of a set of integers (plain everyday order)
common -> intersection (plain everyday intersection of sets)
divisor (of an integer value v) ->
an integer value m, such that v/m is defined and, if so, is an integer
factor (of an integer value v) ->
an integer value m, such that there is an integer value n such that m*n=v
So (mock Haskell syntax; set expression really):
greatest_common_divisor a b = max (intersection {all divisors of a} {all divisors of b})
What is the supremum (result of max in the expression above) if a and b are both 0?
(You're allowed to use values not prescribed by Haskell to exist. ;-)
(You can replace "divisors" by "factors" in that expression and still get the same result.)
I may agree that an operation *similar* to gcd, where <0,0> as argument
returns 0 is useful (maybe even more useful than gcd!). But that operation
is still not the gcd (and might even return other results thaN gcd also for
other value pairs than <0,0>; in particlar negatives; depending on what is
found most useful).
If you want to replace gcd by some other, similar, operation, please go ahead.
But call it something else, because it is something else. If you want to generalise
that to polynomials or Gaussian integers (or at least imaginary integers, as opposed
to complex integers), fine (though not for the current standard Haskell library).
(Micheal, I am interested in the Guassian integer variety of this. If you like,
you can expand on what you said in an off-list message, or give me a reference.)
Kind (and somewhat fundamentalist) regards
/kent k
> -----Original Message-----
> From: haskell-admin@haskell.org [mailto:haskell-admin@haskell.org]On
> Behalf Of Jan de Wit
> Sent: den 19 december 2001 01:15
> To: haskell@haskell.org
> Subject: Re: gcd 0 0 = 0
>
>
> Why not define gcd a b as the largest (in 'normal' order)
> integer d such
> that the set of sums of
> multiples of a and b {na+mb | n <- Z, m <- Z} is equal to the set of
> multiples of d
> {nd | n <- Z}? Easy to understand, no talk of division,
> lattices, rings,
> ideals etcetera, and it covers the cases with 0.
>
> Cheers, Jan de Wit
>
>
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From mechvel@math.botik.ru Wed Dec 19 13:25:17 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Wed, 19 Dec 2001 16:25:17 +0300
Subject: FiniteMap for standard
Message-ID:
Long ago I suggested to include FiniteMap into Haskell-98
standard library.
Is it still late to do this, or maybe, the situation has changed?
-----------------
Serge Mechveliani
mechvel@botik.ru
From icalp2002@lcc.uma.es Wed Dec 19 13:39:55 2001
From: icalp2002@lcc.uma.es (icalp2002@lcc.uma.es)
Date: Wed, 19 Dec 2001 14:39:55 +0100
Subject: ICALP2002 call for papers
Message-ID:
We apologize for possible multiple postings.
In http://www.lcc.uma.es/icalp2002 you can find a pdf
version of this call for paper.
+++++++++++++++++++++++++++++++++++++
Last information:
Second version of the WEB pages at http://www.lcc.uma.es/icalp2002
Workshops confirmed:
Computability and Complexity in Analysis (CCA 2002)
Algorithmic Methods and Models for Optimization of Railways ATMOS 2002
7 th International Workshop on Formal Methods for Industrial Critical Systems
Foundations of Wide Area Network Computing
Invited speakers confirmed:
Heikki Mannila
Manuel Hermenegildo
+++++++++++++++++++++++++++++++++++++
Call for Papers
ICALP 2002
29th International Colloquium on
Automata, Languages and Programming
July 8-13, 2002, M醠aga, Spain
Camera Ready: April 16, 2002
The 29th annual meeting of the European Association of Theoretical
Computer Science will be held in M醠aga, Spain, July 8-13, 2002 (at the
E.T.S. Ingenier韆 Inform醫ica).
As with the Journal Theoretical Computer Science (TCS), the scientific
program of the Colloquium will be split into two parts: Track A of the
meeting will correspond to Algorithms, Automata, Complexity and Games,
while Track B to Logic, Semantics and Theory of Programming.
SUBMISIONS: Authors are invited to submit extended abstract of their
papers, presenting original contributions to the theory of computer
science. Detailed instructions for paper submissions will be found on
the conference webpage (http://www.lcc.uma.es/icalp2002) and in future
calls for papers. Submissions should consist of: a cover page, with the
author's full name, address, fax number, e-mail address, a 100-word
abstract, keywords and to which track (A or B) the paper is being
submitted and an extended abstract describing original research. At
least one author of an accepted paper should be available to present it
at the conference. Simultaneous submission to other conferences with
published proceedings is not allowed.
Further information (dates and instructions for submissions, workshops,
registration, location and travel) will be provided in future
announcements.
ORGANIZING COMMITEE: Buenaventura Clares (University of Granada),
Ricardo Conejo (University of M醠aga), Inmaculada Fortes (University of
M醠aga), Llanos Mora (University of M醠aga), Rafael Morales (co-Chair,
University of M醠aga), Marlon Nu馿z (University of M醠aga), Jos� Luis
P閞ez de la Cruz (University of M醠aga), Gonzalo Ramos (University of
M醠aga), Francisco Triguero (co-Chair, University of M醠aga), Jos� Luis
Trivi駉 (University of M醠aga).
IMPORTANT DATES:
Workshops proposal: November 8, 2001
Submissions: January 14, 2002
Notification: March 20, 2002
CONFERENCE CO-CHAIRS
Prof. Francisco Triguero
Prof. Rafael Morales
Universidad de M醠aga
E.T.S. Ingenier韆 Inform醫ica
Dept. Lenguajes y Ciencias de la Computaci髇
Bulevar Louis Pasteur, 35
29071 - M醠aga (SPAIN)
e-mail: icalp2002@informatica.uma.es
PROGRAM COMMITEE
Track A
Ricardo Baeza-Yates (U. Chile)
Volker Diekert (U. Stuttgart)
Paolo Ferragina (U. Pisa)
Catherine Greenhill (U. Melbourne)
Torben Hagerup (U. Frankfurt)
Johan H錽tad (KTH, Stockholm)
Gabriel Istrate (Los Alamos)
Claire Kenyon (U. Paris XI)
Der-Tsai Lee (Acad. Sinica, Taipei)
Heikki Mannila (Nokia, Helsinki)
Elvira Mayordomo (U. Zaragoza)
Helmut Prodinger (U. Witwatersrand, South Africa)
Jan van Leeuwen(U. Utrecht)
Paul Vit醤yi (CWI, Amsterdam)
Peter Widmayer (ETH Z黵ich) (Chair)
Gerhard Woeginger (T.U. Graz)
Christos Zaroliagis (U. Patras)
Track B
Mart韓 Abadi (Bell Labs Research, Lucent)
Roberto Amadio (U. Provence)
Gilles Barthe (INRIA-SophiaAntipolis)
Manfred Droste (University of Technology Dresden)
C閐ric Fournet (Microsoft Cambridge)
Matthew Hennessy (U. Sussex) (Chair)
Furio Honsell (U. Udine)
Peter O'Hearn (Queen Mary & W. C. London)
Fernando Orejas (U.P.Catalunya)
Ernesto Pimentel (U. M醠aga)
David Sands (Chalmers University of Technology and G鰐eborg University)
Dave Schmidt (U. Kansas)
Gheorghe Stefanescu (U. Bucharest)
Vasco Vasconcelos (U. Lisbon)
Thomas Wilke (U. Kiel)
+++++++++++++++++++++++++++++++++++++++++++
Malaga University uses Christmas holidays for backup and maintenance of his network.
If you have problem to arrive to ICALP 2002 main page, please retry again later.
If you get to the page http://www.lcc.uma.es but not to the page http://www.lcc.uma.es/icalp2002 contact with us:
conejo@lcc.uma.es
morales@lcc.uma.es
From simonpj@microsoft.com Wed Dec 19 13:43:46 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 19 Dec 2001 05:43:46 -0800
Subject: FiniteMap for standard
Message-ID: <1113DDB24D4A2841951BFDF86665EE1906665C@RED-MSG-10.redmond.corp.microsoft.com>
Much, much too late, however desirable.
| -----Original Message-----
| From: S.D.Mechveliani [mailto:mechvel@math.botik.ru]=20
| Sent: 19 December 2001 13:25
| To: haskell@haskell.org
| Subject: FiniteMap for standard
|=20
|=20
| Long ago I suggested to include FiniteMap into Haskell-98=20
| standard library.
| Is it still late to do this, or maybe, the situation has changed?=20
|=20
| -----------------
| Serge Mechveliani
| mechvel@botik.ru
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From wittner@uni-duesseldorf.de Wed Dec 19 14:11:06 2001
From: wittner@uni-duesseldorf.de (Toralf Wittner)
Date: Wed, 19 Dec 2001 15:11:06 +0100
Subject: x^y. Reply
In-Reply-To:
References:
Message-ID: <0GOL00IC6GSOOO@neptun.rz.uni-duesseldorf.de>
On Wednesday, 19. December 2001 09:12, S.D.Mechveliani wrote:
[...]
> But if you still need Integer | Double, you can, for example,
> introduce a new type of a disjoint union of the above two, and then,
> to compute like this:
> pow (Intg 2) 2 --> Intg 4
> pow (Intg 2) (-2) --> D 0.25
> pow (D 2.0) (-2) --> D 0.25
> This is achieved by
>
> data PowerDom = Intg Integer | D Double deriving(Eq,Show)
>
> pow :: PowerDom -> Integer -> PowerDom
> pow x n = p x n
> where
> p (Intg m) n = if n > 0 then Intg $ powerInteger m n
> else D $ powerDouble (fromInteger m :: Double) n
> p(D d) n = D $ powerDouble d n
>
> powerInteger m n = m^n :: Integer
>
> powerDouble :: Double -> Integer -> Double
> powerDouble d n = ... usual way for float
>
> - something like this.
This seems to be what I want. I tried it this way:
module Main where
import System
main = do
[a1, a2] <- getArgs
let x = read a1
let y = read a2 in
putStrLn (show x ++ " ^ " ++ show y ++ " = " ++ show (pow x y))
data PowerNum = INT Integer | DBL Double deriving (Eq, Show, Read)
pow :: PowerNum -> Integer -> PowerNum
pow x y = z x y where
z (INT x) y = if y > 0 then
INT $ powInteger x y
else
DBL $ powDouble (fromInteger x) y
z (DBL x) y = DBL $ powDouble x y
powInteger x y
| x == 0 = 0
| y == 0 = 1
| y > 0 = x * powInteger x (y - 1)
powDouble x y
| x == 0 = 0
| y == 0 = 1
| y > 0 = 1 / x * powDouble x (y - 1)
While GHC compiled this code I get a runtime error:
Fail: Prelude.read: no parse
and HUGS reports:
ERROR: Illegal Haskell 98 class constraint in inferred type
*** Expression : pow 1 2
*** Type : Num PowerNum => PowerNum
Could you tell me what I did wrong? Thank you very much!
Toralf
>
>
> -----------------
> Serge Mechveliani
> mechvel@botik.ru
From wittner@uni-duesseldorf.de Wed Dec 19 15:30:41 2001
From: wittner@uni-duesseldorf.de (Toralf Wittner)
Date: Wed, 19 Dec 2001 16:30:41 +0100
Subject: x^y. Reply
In-Reply-To:
References:
Message-ID: <0GOL005G2KHDMK@neptun.rz.uni-duesseldorf.de>
Ahh - sorry, too much cut and paste ;-)
data PowerNum = INT Integer | DBL Double deriving (Eq, Show, Read)
pow :: PowerNum -> Integer -> PowerNum
pow x y = z x y where
z (INT x) y = if y > 0 then
INT $ powInteger x y
else if y == 0 then
INT $ 1
else
DBL $ powDouble (fromInteger x) y
z (DBL x) y = DBL $ powDouble x y
powInteger x y
| x == 0 = 0
| y == 0 = 1
| y > 0 = x * powInteger x (y - 1)
powDouble x y
| x == 0 = 0
| y == 0 = 1
| y < 0 = 1 / x * powDouble x (y + 1)
Now it basically works. However wouldn't it have been easier to write
something like this:
module Main where
import System
main = do
[a1, a2] <- getArgs
let x = read a1
let y = read a2 in
if y >= 0 then
putStrLn (show x ++ " ^ " ++ show y ++ " = " ++ show (powPos x y))
else
putStrLn (show x ++ " ^ " ++ show y ++ " = " ++ show (powNeg x y))
powPos :: Integer -> Integer -> Integer
powPos x y
| x == 0 = 0
| y == 0 = 1
| y > 0 = x * powPos x (y - 1)
powNeg :: Integer -> Integer -> Double
powNeg x y
| x == 0 = 0
| y == 0 = 1
| y < 0 = 1 / fromInteger x * powNeg x (y + 1)
Initially I wanted something as terse as the Python version, now I either
have to write two functions or I need to define a type. Is there not an
easier way to come as close as possible to the Python version?
Thanks anyway - learnt a lot!
Toralf
From hdaume@ISI.EDU Thu Dec 20 00:18:35 2001
From: hdaume@ISI.EDU (Hal Daume III)
Date: Wed, 19 Dec 2001 16:18:35 -0800 (PST)
Subject: global counters
Message-ID:
Please, no tirade about banishing unsafePerformIO.
I've seen this done before I just don't remember how. I want to use a
state monad to count things, but don't want to monadify the thing I'm
using the counter in.
basically, i want a function getVar :: () -> String which returns a new
string every time. i tried this:
> curVarId = newSTRef (0 :: Integer)
>
> {-# NO-INLINE newVar -}
>
> newVar = \_ -> ('\0' : show x)
> where y = unsafePerformIO (stToIO curVarId)
> x = unsafePerformIO $ stToIO $
> do x <- readSTRef y
> writeSTRef y (x + 1)
> return x
and in ghci it works wonderfully, but when i actually compile, all i get
is "\NUL0".
what's the proper way to write this?
thanks
- hal
From mechvel@math.botik.ru Thu Dec 20 08:00:17 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Thu, 20 Dec 2001 11:00:17 +0300
Subject: x^y. Reply
Message-ID:
Toralf Wittner
writes
> [..]
> data PowerNum = INT Integer | DBL Double deriving (Eq, Show, Read)
> [..]
> Now it basically works. However wouldn't it have been easier to write
> something like this:
>
> powPos :: Integer -> Integer -> Integer
> [..]
> powNeg :: Integer -> Integer -> Double
> [..]
> | y < 0 = 1 / fromInteger x * powNeg x (y + 1)
>
> Initially I wanted something as terse as the Python version, now I either
> have to write two functions or I need to define a type. Is there not an
> easier way to come as close as possible to the Python version?
>
> Thanks anyway - learnt a lot!
For this particular task, the most natural solution is, probably,
pow :: Fractional a => a -> Integer -> a
pow a n =
if n > 0 then a^n else (1/a)^(- n)
(^) is of standard, only pow adds the facility of negative n.
Then, you need each time to convert the argument to appropriate
type of Fractional:
pow (fromInteger 2 :: Ratio.Rational) 2 --> 4 % 1
pow (fromInteger 2 :: Ratio.Rational) (-2) --> 1 % 4
pow (2 :: Double) (-2) --> 0.25
pow (2 :: Integer) (-2) -->
... No instance for (Fractional Integer)
If you replace standard (and not lucky) Fractional with some
class Foo (with multiplication mul and division div),
make Integer an instance of Foo
(where div may fail for some data),
and program
pow :: Foo a => a -> Integer -> a
via mul, div,
then it would work like this:
pow (2 :: Integer) 2 --> 4
pow (2 :: Integer) (-2) --> "Error: cannot invert 2 :: Integer"
pow (2 :: Rational) (-2) --> 1%4
Another way is to try to straggle with overlapping instances by
defining something like this:
class Pow a b where pow :: a -> Integer -> b
instance Num a => Pow a a where pow = (^)
Fractional ?
instance Num a => Pow Integer a where pow = ?
If this succeeds, there will be also no need in new type
constructors.
-----------------
Serge Mechveliani
mechvel@botik.ru
From Jan de Wit"
Message-ID: <001401c18936$92ba3280$2fe5fea9@yatima>
> basically, i want a function getVar :: () -> String which returns a new
> string every time. i tried this:
>
> > curVarId = newSTRef (0 :: Integer)
> >
> > {-# NO-INLINE newVar -}
> >
> > newVar = \_ -> ('\0' : show x)
> > where y = unsafePerformIO (stToIO curVarId)
> > x = unsafePerformIO $ stToIO $
> > do x <- readSTRef y
> > writeSTRef y (x + 1)
> > return x
>
> and in ghci it works wonderfully, but when i actually compile, all i get
> is "\NUL0".
>
> what's the proper way to write this?
I think (haven't tested this one) you should write (modulo layout):
| curVarIdRef :: IORef Integer
| curVarIdRef = unsafePerformIO $ newIORef (0 :: Integer)
|
| {-# NO-INLINE newVar -}
|
| newVar :: () -> String
| newVar = \_ -> ('\0' : show x) where
| x = unsafePerformIO $
| do x <- readIORef curVarIdRef
| writeIORef curVarIdRef (x + 1)
| return x
Because in your original version, curVarId allocates a new reference to 0
every time newVar is called.
Hope this works, Jan de Wit
From johanj@cs.uu.nl Thu Dec 20 08:07:27 2001
From: johanj@cs.uu.nl (Johan Jeuring)
Date: Thu, 20 Dec 2001 09:07:27 +0100
Subject: Working Conference on Generic Programming, 2nd call for papers
Message-ID: <20011220080952.E517D4538@mail.cs.uu.nl>
WCGP '02
IFIP WG2.1 Working Conference on
GENERIC PROGRAMMING
http://www.generic-programming.nl/wcgp/cfp.html
Organised in conjunction with MPC'02
July 8 - July 13, 2002
Dagstuhl, Germany
CALL FOR PAPERS
Generic programming is about making programs more
adaptable by making them more general. Generic
programs often embody non-traditional kinds of
polymorphism; ordinary programs are obtained from
them by suitably instantiating their parameters.
In contrast with normal programs, the parameters
of a generic programs are often quite rich in
structure. For example they may be other programs,
types or type constructors, class hierarchies, or
even programming paradigms.
Generic programming techniques have always been of
interest, both to practitioners and to theoreticians,
but only recently have generic programming
techniques become a specific focus of research in
the functional and object-oriented programming
language communities. This working conference will
bring together leading researchers in generic
programming from around the world, and feature
papers capturing the state of the art in this
important emerging area.
We welcome contributions on all aspects, theoretical
as well as practical, of generic programming,
aspect-oriented programming, polytypic programming,
adaptive object-oriented programming, generic
components, and so on.
SUBMISSION
Full papers should be submitted in Postscript or pdf
format by e-mail to reach Jeremy.Gibbons@comlab.ox.ac.uk
by February 16, 2002. The details of the submission
procedure can be found at
http://www.generic-programming.nl/wcgp/submit.html
Although there is no page limit, submissions should
strive for brevity and clarity.
IMPORTANT DATES
Submission February 16, 2002
Notification April 12, 2002
Final version due May 24, 2002
PROGRAMME COMMITTEE
Matt Austern
Eerke Boiten
Ulrich Eisenecker
Jeremy Gibbons (co-chair)
Ralf Hinze
Johan Jeuring (co-chair)
Gary Leavens
Karl Lieberherr
Lambert Meertens
Eugenio Moggi
Bernhard Moeller
Oege de Moor
David Musser
Martin Odersky
Ross Paterson
Simon Peyton Jones
Colin Runciman
Doaitse Swierstra
Stephanie Weirich
LOCAL ORGANISATION
Jeremy Gibbons
Johan Jeuring
Bernhard Moeller
CORRESPONDENCE
Jeremy Gibbons (Jeremy.Gibbons@comlab.ox.ac.uk)
Johan Jeuring (johan@jeuring.net)
From bernhard@cogs.susx.ac.uk Thu Dec 20 15:05:56 2001
From: bernhard@cogs.susx.ac.uk (Bernhard Reus)
Date: Thu, 20 Dec 2001 15:05:56 +0000
Subject: installation problems with graphics-2.0.4
Message-ID: <3C21FE54.2EBCC4B7@cogs.susx.ac.uk>
The graphics lib of the new December release does not
compile with the shipped makefile.
The makefile does not do anything at all???
Maybe there is a problem with wildcard extensions?
To be honest, I have no clue. I am using a Sparc5/Solaris
machine.
Any help appreciated.
Thanks in advance,
Bernhard
From igloo@earth.li Thu Dec 20 21:49:03 2001
From: igloo@earth.li (Ian Lynagh)
Date: Thu, 20 Dec 2001 21:49:03 +0000
Subject: unsafePerformIO to give warnings
Message-ID: <20011220214903.A2358@stu163.keble.ox.ac.uk>
Hi all
If I want to give warnings when doing something and I don't care too
much about the order they appear in, can I use this?
foo x = if success x then Just x
else warn "Working out x went wrong" Nothing
warn :: String -> a -> a
warn s x = unsafePerformIO (hPutStrLn stderr s) `seq` x
The hslibs docs say
If the I/O computation wrapped in unsafePerformIO performs side
effects, then the relative order in which those side effects take
place (relative to the main I/O trunk, or other calls to
unsafePerformIO) is indeterminate.
but it's not entirely clear on whether or not I could end up with 2
warnings interspersed?
And is it guaranteed that the warnings will be printed at some point?
hugs and ghci only seem to print the first warning, but ISTR similar
problems happen with threads and got the impression that they were in
the wrong.
Thanks
Ian
From simonpj@microsoft.com Fri Dec 21 09:35:37 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 21 Dec 2001 01:35:37 -0800
Subject: "The signature contexts in a mutually recursive group should all be identical"; why?
Message-ID: <1113DDB24D4A2841951BFDF86665EE19374689@RED-MSG-10.redmond.corp.microsoft.com>
[Note to the Haskell list. The question this thread is discussing
is whether the H98 rule that all the functions in a mutually=20
recursive group must have the same context, is a show stopper.]
| Oeer. Come to think of it, if f is getting the dictionary=20
| (in the real world
| example) from the context, rather than from the existential=20
| type, I fear it may be getting the wrong dictionary, and will=20
| crash badly when I try to run the code. =20
No I don't think that can happen. But I have thought of a test
case
data T =3D forall a. Eq a =3D> MkT a a T
| Nil
f :: T -> Bool
f Nil =3D True
f (MkT x y t) =3D g x y t
g :: Eq b =3D> b -> b -> T -> Bool
g x y t =3D (x=3D=3Dy) && f t
Notice that
(a) f and g are mutually recursive
(b) They have different contexts in their type sig
(c) If they were made the same, f would get an
ambiguous type f :: Eq a =3D> T -> Bool
(d) Haskell's polymorphic recursion is essential here;
each call to g may be at a different type
So it looks to me that, in the presence of existentials, the H98
rule goes from being moot to being throughly awkward.=20
Mark's THIH paper shows that there's no real need for the rule,
because one can type-check the bindings without type sigs as
a group, and then the ones with type sigs one by one. =20
But what happens for pattern-bindings that bind more than
one variable. Must all those variables have the same context?
(I hope so.)
Needless to say, I'm not proposing any changes in H98! But
I thought the example would be of interest. Maybe it's well known,
but it wasn't to me.
Simon
From sk@cs.brown.edu Fri Dec 21 06:36:16 2001
From: sk@cs.brown.edu (Shriram Krishnamurthi)
Date: Fri, 21 Dec 2001 01:36:16 -0500 (EST)
Subject: ICFP (Functional Programming) 2002: Call for Papers
Message-ID: <200112210636.BAA10106@bosch.cs.brown.edu>
---------------------------------------------
* Calling all functional programmers! *
* ICFP'02 needs you! *
---------------------------------------------
ICFP 2002: International Conference on Functional Programming
Pittsburgh, 3--5 October 2002
CALL FOR PAPERS
http://icfp2002.cs.brown.edu/
Paper submission deadline: 21 March 2002
General Chair: Mitchell Wand, Northeastern University
Program Chair: Simon Peyton Jones, Microsoft Research
ICFP 2002 seeks original papers on the full spectrum of the art,
science, and practice of functional programming. The conference
invites submissions on all topics ranging from principles to practice,
from foundations to features, and from abstraction to application. The
scope covers all languages that encourage programming with functions,
including both purely applicative and imperative languages, as well as
languages that support objects and concurrency.
You can find the full call for papers at
http://icfp2002.cs.brown.edu/
Program Committee
Matthias Blume (Lucent)
Margaret Burnett (Oregon State University)
Manuel Chakravarty (University of New South Wales)
Matthew Flatt (University of Utah)
Haruo Hosoya (Kyoto University)
Uwe Nestmann (EPFL, Lausanne)
Chris Okasaki (United States Military Academy)
Norman Ramsey (Harvard University)
David Sands (Chalmers University)
Olin Shivers (Georgia Tech)
Stephanie Weirich (Cornell)
Joe Wells (Heriot Watt University)
From simonmar@microsoft.com Fri Dec 21 10:21:06 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 21 Dec 2001 10:21:06 -0000
Subject: unsafePerformIO to give warnings
Message-ID: <9584A4A864BD8548932F2F88EB30D1C607C0BAA4@TVP-MSG-01.europe.corp.microsoft.com>
> If I want to give warnings when doing something and I don't care too
> much about the order they appear in, can I use this?
>=20
> foo x =3D if success x then Just x
> else warn "Working out x went wrong" Nothing
>=20
> warn :: String -> a -> a
> warn s x =3D unsafePerformIO (hPutStrLn stderr s) `seq` x
This is what IOExts.trace is for, BTW.
> The hslibs docs say
>=20
> If the I/O computation wrapped in unsafePerformIO performs side
> effects, then the relative order in which those side effects take
> place (relative to the main I/O trunk, or other calls to
> unsafePerformIO) is indeterminate.
>=20
> but it's not entirely clear on whether or not I could end up with 2
> warnings interspersed?
It is possible to get warnings interspersed if you write something like
warn ("abc" ++ warn "foo" "def")
> And is it guaranteed that the warnings will be printed at some point?
All that is guaranteed is that if an expression 'warn a b' is evaluated
then 'a' will be evaluated to a String and then printed.
> hugs and ghci only seem to print the first warning, but ISTR similar
> problems happen with threads and got the impression that they were in
> the wrong.
Are you sure that laziness and/or optimisation aren't to blame for only
getting a single warning? Given that you say Hugs also produces the
same result, it sounds like a laziness issue.
Cheers,
Simon
From chak@cse.unsw.edu.au Fri Dec 21 10:17:54 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 21 Dec 2001 21:17:54 +1100
Subject: 2002 Haskell Workshop
Message-ID: <20011221211754E.chak@cse.unsw.edu.au>
[My apologies if you receive multiple copies of this message]
------------------------------
PROVISIONAL CALL FOR PAPERS
(Approval for PLI'02 pending)
------------------------------
2002 Haskell Workshop
Pittsburgh, PA, USA
(3rd, 7th, or 8th October 2002;
exact date to be announced)
==================================
The purpose of the Haskell Workshop is to discuss experience
with Haskell, and possible future developments for the
language. The scope of the workshop includes all aspects of
the design, semantics, theory, application, implementation,
and teaching of Haskell. Previous Haskell Workshops have
been held in La Jolla (1995), Amsterdam (1997), Paris
(1999), Montreal (2000), and Firenze (2001).
For detailed information and key dates please consult
http://www.cse.unsw.edu.au/~chak/hw2002/
From simonpj@microsoft.com Fri Dec 21 11:09:42 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 21 Dec 2001 03:09:42 -0800
Subject: Haskell 98 Christmas release
Message-ID: <1113DDB24D4A2841951BFDF86665EE1937468E@RED-MSG-10.redmond.corp.microsoft.com>
In my Sisyphian task of finishing the Haskell 98 Report, I thought
I would put out the current version before Xmas. =20
http://research.microsoft.com/~simonpj/haskell98-revised
It's substantially the same as the one I put out at the start=20
of December, with three exceptions
1. The layout algorithm has changed (again). Simon M, Ian L and
I are now all fairly confident that it is right, but we have been proved
wrong before.
2. The "instance declaration wart" turned out to be closely connnected
to some (unspecified) scoping issues in export lists. So I have=20
nailed all that down. GHC and Hugs both now implement the new
rules.
3. The avalance of email about the True Meaning of gcd 0 0 cannot=20
have escaped your notice. I am too stupid to understand most of it,
but my ill-informed conclusion is:
a) there is a lot of support for gcd 0 0 =3D 0
b) but it is not universal support
The strong default for H98 is "no change", so I've left gcd 0 0 as an
error.
However I have added some examples.
Changes since the early-dec release are marked
[Late Dec 2001] in the Bugs List, so you can find them easily.
I don't think I know of any other loose ends. Happy reading.
Simon
From ross@soi.city.ac.uk Fri Dec 21 11:14:12 2001
From: ross@soi.city.ac.uk (Ross Paterson)
Date: Fri, 21 Dec 2001 11:14:12 +0000
Subject: "The signature contexts in a mutually recursive group should all be identical"; why?
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE19374689@RED-MSG-10.redmond.corp.microsoft.com>
References: <1113DDB24D4A2841951BFDF86665EE19374689@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <20011221111411.GA1143@soi.city.ac.uk>
On Fri, Dec 21, 2001 at 01:35:37AM -0800, Simon Peyton-Jones wrote:
> [Note to the Haskell list. The question this thread is discussing
> is whether the H98 rule that all the functions in a mutually
> recursive group must have the same context, is a show stopper.]
>
> [...]
>
> So it looks to me that, in the presence of existentials, the H98
> rule goes from being moot to being throughly awkward.
It's not moot -- it steers the following (admittedly artificial) example
into the monomorphism restriction:
foo :: Eq a => a -> Bool
foo x = x == x && bar
-- bar :: Bool
bar = foo 'a'
With the declaration, it fails the "identical context" rule (though
Hugs then accepts it in violation of H98).
The definition of "declaration group" could have been relaxed when
explicit type signatures were added: if a variable has one, then
bindings using the variable should depend on the type signature,
not the binding of the variable, so in the above example would
be analysed as three declaration groups:
(1) foo :: Eq a => a -> Bool
(2) bar = foo 'a' -- depends on (1)
(3) foo x = x == x && bar -- depends on (2)
As it is, some extra language was tacked on to exempt variables with
explicit signatures from the mutual type inference, as well as to
impose this restriction.
H98 glitch: the phrase "declaration group" is used in 4.4.2 with a
different meaning to that defined in 4.5.1. "sequence of declarations"?
From igloo@earth.li Fri Dec 21 12:25:31 2001
From: igloo@earth.li (Ian Lynagh)
Date: Fri, 21 Dec 2001 12:25:31 +0000
Subject: unsafePerformIO to give warnings
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C607C0BAA4@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Fri, Dec 21, 2001 at 10:21:06AM -0000
References: <9584A4A864BD8548932F2F88EB30D1C607C0BAA4@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20011221122531.A6180@stu163.keble.ox.ac.uk>
On Fri, Dec 21, 2001 at 10:21:06AM -0000, Simon Marlow wrote:
>
> > If I want to give warnings when doing something and I don't care too
> > much about the order they appear in, can I use this?
> >
> > foo x = if success x then Just x
> > else warn "Working out x went wrong" Nothing
> >
> > warn :: String -> a -> a
> > warn s x = unsafePerformIO (hPutStrLn stderr s) `seq` x
>
> This is what IOExts.trace is for, BTW.
Doh - I associate that with debugging and it never even occurred to me!
> > warnings interspersed?
>
> It is possible to get warnings interspersed if you write something like
>
> warn ("abc" ++ warn "foo" "def")
Ah, yes, OK, thanks.
> > hugs and ghci only seem to print the first warning, but ISTR similar
> > problems happen with threads and got the impression that they were in
> > the wrong.
>
> Are you sure that laziness and/or optimisation aren't to blame for only
> getting a single warning? Given that you say Hugs also produces the
> same result, it sounds like a laziness issue.
Sorry, I meant "hugs and ghci only seem to print the warning the first
time I run the program", e.g. with
module Main where
import IOExts
main :: IO()
main = trace "foo" (putStrLn "bar")
in hugs:
[...]
Type :? for help
Main> main
foobar
Main> main
bar
Main> main
bar
Main> main
bar
and in ghci:
Skipping Main ( q.lhs, ./q.o )
Main> main
foo
bar
Main> main
bar
Main> main
bar
Main> main
bar
Main>
Thanks again
Ian
From simonmar@microsoft.com Fri Dec 21 12:29:05 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 21 Dec 2001 12:29:05 -0000
Subject: unsafePerformIO to give warnings
Message-ID: <9584A4A864BD8548932F2F88EB30D1C607C0BB2B@TVP-MSG-01.europe.corp.microsoft.com>
Ian Lynagh writes:
> Sorry, I meant "hugs and ghci only seem to print the warning the first
> time I run the program", e.g. with
>=20
> module Main where
>=20
> import IOExts
>=20
> main :: IO()
> main =3D trace "foo" (putStrLn "bar")
>=20
> in hugs:
>=20
> [...]
> Type :? for help
> Main> main
> foobar
>=20
> Main> main
> bar
[snip]
> and in ghci:
>=20
> Skipping Main ( q.lhs, ./q.o )
> Main> main
> foo
> bar
> Main> main
> bar
[snip]
This is because 'main' is a CAF: the act of reducing it to normal form
the first time forces the warning to be printed, but thereafter the
evaluated version is returned immediately.
To subvert this behaviour, in GHCi you can say ':set +r' which causes
all CAFs to be reverted between evaluations.
Cheers,
Simon
From Malcolm.Wallace@cs.york.ac.uk Fri Dec 21 13:23:00 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Fri, 21 Dec 2001 13:23:00 +0000
Subject: ICFP (Functional Programming) 2002: Call for Papers
In-Reply-To: <200112210636.BAA10106@bosch.cs.brown.edu>
Message-ID:
> ICFP 2002: International Conference on Functional Programming
> Pittsburgh, 3--5 October 2002
The email announcement says 3-5 Oct, the webpage says 4-6 Oct.
Which are the true dates for ICFP?
Regards,
Malcolm
From simonpj@microsoft.com Fri Dec 21 13:57:42 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 21 Dec 2001 05:57:42 -0800
Subject: ICFP (Functional Programming) 2002: Call for Papers
Message-ID: <1113DDB24D4A2841951BFDF86665EE19374690@RED-MSG-10.redmond.corp.microsoft.com>
It's definitely 4-6 Oct. I'm sorry about the confusion.
Simon
| -----Original Message-----
| From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk]=20
| Sent: 21 December 2001 13:23
| To: haskell@haskell.org
| Subject: Re: ICFP (Functional Programming) 2002: Call for Papers
|=20
|=20
| > ICFP 2002: International Conference on Functional Programming
| > Pittsburgh, 3--5 October 2002
|=20
| The email announcement says 3-5 Oct, the webpage says 4-6=20
| Oct. Which are the true dates for ICFP?
|=20
| Regards,
| Malcolm
From rjmh@cs.chalmers.se Fri Dec 21 16:04:05 2001
From: rjmh@cs.chalmers.se (John Hughes)
Date: Fri, 21 Dec 2001 17:04:05 +0100 (MET)
Subject: New extension in GHC: newtype deriving clause
Message-ID: <200112211604.RAA01425@hotlips.cs.chalmers.se>
Simon PJ and I have come up with an extension to newtype deriving clauses
which is intended to make it easier to make types abstract.
Suppose you are about to write a type definition. You face a choice between
defining it as a type synonym, and making it a new, potentially abstract
type. Often a newtype may be the "right" choice, but that may require
substantial extra work. Specifically, if the representation type already has a
number of useful class instances, which you also want on the newtype, then a
type synonym gives you them for free -- but a newtype definition forces you to
write an instance declaration for each instance you want. These instance
declarations are boring to write: they just strip off and put back the newtype
constructor here and there, and call the representation instance. Especially
galling is that in the implementation, the newtype constructor doesn't even
appear -- so all your work is "for nothing", the dictionary for the
representation type would actually work perfectly well for the new type
also. The work of defining these instances may be enough to put you off making
the new type abstract.
The new extension allows you to derive these instances, just by adding the
classes to the deriving clause of the newtype declaration. It's implemented in
GHC already and will be part of the next release. I've appended the manual
entry describing the extension to this message: that contains examples and a
careful definition of when an instance can be derived.
I'll just remark that you can also use this extension to emulate Hugs'
restricted type synonyms. Suppose you want to implement an abstract type of
sets as lists, and define the set operations without needing to constantly add
and remove a newtype constructor. You can do so as follows:
1. Define a class containing the operations inside the abstraction barrier.
This corresponds to giving the type signatures of these functions in the
Hugs construct.
class SetLike s where
empty :: s a
single :: a -> s a
union :: s a -> s a -> s a
member :: Eq a => a -> s a -> Bool
(This isn't supposed to be a general Collection class: we're just defining
the types of function on sets-as-lists),
2. Define an instance for the representation type. Of course, there's no need
to mess with any newtype constructor here.
instance SetLike [] where
empty = []
single x = [x]
union = (++)
member = elem
3. Define a new Set type, and derive a class instance for it.
newtype Set a = Set [a] deriving SetLike
That's it. Of course, the Set operations are now overloaded, which has its own
penalties, but nevertheless we managed to define operations on an abstract
type without explicitly worrying about the constructor.
Here's the manual entry:
Extended deriving clause for newtype
====================================
When you define an abstract type using newtype, you may want the new type to
inherit some instances from its representation. In Haskell 98, you can inherit
instances of Eq, Ord, Enum and Bounded by deriving them, but for any other
classes you have to write an explicit instance declaration. For example, if
you define
newtype Dollars = Dollars Int
and you want to use arithmetic on Dollars, you have to explicitly define an
instance of Num:
instance Num Dollars where
Dollars a + Dollars b = Dollars (a+b)
...
All the instance does is apply and remove the newtype constructor. It is
particularly galling that, since the constructor doesn't appear at run-time,
this instance declaration defines a dictionary which is wholly equivalent to
the Int dictionary, only slower!
GHC permits such instances to be derived instead, so one can write
newtype Dollars = Dollars Int deriving (Eq,Show,Num)
and the implementation uses the same Num dictionary for Dollars as for
Int. Notionally, the compiler derives an instance declaration of the form
instance Num Int => Num Dollars
which just adds or removes the newtype constructor according to the type.
We can also derive instances of constructor classes in a similar way. For
example, suppose we have implemented state and failure monad transformers,
such that
instance Monad m => Monad (State s m)
instance Monad m => Monad (Failure m)
In Haskell 98, we can define a parsing monad by
type Parser tok m a = State [tok] (Failure m) a
which is automatically a monad thanks to the instance declarations above. With
the extension, we can make the parser type abstract, without needing to write
an instance of class Monad, via
newtype Parser tok m a = Parser (State [tok] (Failure m) a)
deriving Monad
In this case the derived instance declaration is of the form
instance Monad (State [tok] (Failure m)) => Monad (Parser tok m)
Notice that, since Monad is a constructor class, the instance is a partial
application of the new type, not the entire left hand side. We can imagine
that the type declaration is ``eta-converted'' to generate the context of the
instance declaration.
We can even derive instances of multi-parameter classes, provided the newtype
is the last class parameter. In this case, a ``partial application'' of the
class appears in the deriving clause. For example, given the class
class StateMonad s m | m -> s where ...
instance Monad m => StateMonad s (State s m) where ...
then we can derive an instance of StateMonad for Parsers by
newtype Parser tok m a = Parser (State [tok] (Failure m) a)
deriving (Monad, StateMonad [tok])
The derived instance is obtained by completing the application of the class to
the new type:
instance StateMonad [tok] (State [tok] (Failure m)) =>
StateMonad [tok] (Parser tok m)
As a result of this extension, all derived instances in newtype declarations
are treated uniformly (and implemented just by reusing the dictionary for the
representation type), except Show and Read, which really behave differently
for the newtype and its representation.
Derived instance declarations are constructed as follows. Consider the
declaration (after expansion of any type synonyms)
newtype T v1...vn = T' (TC t1...tp vk+1...vn) deriving (c1...cm)
where TC is a type constructor, t1...tp are types, vk+1...vn are type
variables which do not occur in any of the ti, and the ci are partial
applications of classes of the form C t1'...tj'. The derived instance
declarations are, for each ci,
instance ci (TC t1...tp vk+1...vl) => ci (T v1...vl)
where l is chosen so that T v1...vl is of the right kind for the last
parameter of class Ci.
As an example which does not work, consider
newtype NonMonad m s = NonMonad (State s m s) deriving Monad
Here we cannot derive the instance
instance Monad (State s m) => Monad (NonMonad m)
because the type variable s occurs in State s m, and so cannot be
``eta-converted'' away. It is a good thing that this deriving clause is
rejected, because NonMonad m is not, in fact, a monad --- for the same
reason. Try defining >>= with the correct type: you won't be able to.
Notice also that the order of class parameters becomes important, since we can
only derive instances for the last one. If the StateMonad class above were
instead defined as
class StateMonad m s | m -> s where ...
then we would not have been able to derive an instance for the Parser
type above. We hypothesise that multi-parameter classes usually have one
``main'' parameter for which deriving new instances is most interesting.
From simonpj@microsoft.com Fri Dec 21 16:18:34 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 21 Dec 2001 08:18:34 -0800
Subject: New extension in GHC: newtype deriving clause
Message-ID: <1113DDB24D4A2841951BFDF86665EE19374697@RED-MSG-10.redmond.corp.microsoft.com>
| Simon PJ and I have come up with an extension to newtype=20
| deriving clauses which is intended to make it easier to make=20
| types abstract.
This newtype-deriving stuff that John describes is fully implemented
in the GHC in the repository (for those of you who are keen) and
will be in the release of GHC 5.03 we are planning for early new year.
Simon
From lennart@augustsson.net Fri Dec 21 16:44:35 2001
From: lennart@augustsson.net (Lennart Augustsson)
Date: Fri, 21 Dec 2001 17:44:35 +0100
Subject: New extension in GHC: newtype deriving clause
References: <200112211604.RAA01425@hotlips.cs.chalmers.se>
Message-ID: <3C2366F3.97F3843D@augustsson.net>
John Hughes wrote:
> Simon PJ and I have come up with an extension to newtype deriving clauses
> which is intended to make it easier to make types abstract.
>
> The new extension allows you to derive these instances, just by adding the
> classes to the deriving clause of the newtype declaration.
I like this, and I suggested it about 10 years ago. :-)
(And we have it in BlueSpec.)
-- Lennart
From xddainese@xlibero.it Mon Dec 24 11:13:54 2001
From: xddainese@xlibero.it (Diego Dainese)
Date: 24 Dec 2001 12:13:54 +0100
Subject: A question about "Putting Type Annotations to Work"
Message-ID: <87u1ugdg5p.fsf@benten.tomobiki.it>
Hi,
I am not sure whether this is the right place to ask this question: I
don't understand how to compute the least upper bound of 2 (or N)
substitutions in the MGI algorithm of the paper mentioned in the
subject (see Figure 4 on page 10, rules (->) and (T)). Any hint is
welcomed.
Thanks in advance and merry Christmas,
--
Diego
To reply remove the 2 `x' from the address.
From diatchki@cse.ogi.edu Wed Dec 26 18:54:42 2001
From: diatchki@cse.ogi.edu (Iavor S. Diatchki)
Date: Wed, 26 Dec 2001 10:54:42 -0800
Subject: punning in GHC?
Message-ID: <200112261854.KAA25835@church.cse.ogi.edu>
hi there,
i just discovered that GHC does not support punning with the -fglasgow-exts
option. is there another flag to turn this on or has it been completely
removed? if so could we have it back - i really like the feature (in
patterns anyways) and use it (hugs -98 supports it). i don't particularly
care that it is not in haskell 98 as i rarely write haskell 98 programs.
by the way before posting this i did a search on "punning" through the
mailing list archive to see if someone asked this already. i couldnt find
anything but it seems that since 1997 there were 7 posts on "punning" and
all of them seemed to agree that it was a useful feature, so why was it
removed?
bye
iavor
From konsu@microsoft.com Fri Dec 28 04:16:11 2001
From: konsu@microsoft.com (Konst Sushenko)
Date: Thu, 27 Dec 2001 20:16:11 -0800
Subject: Importing in ghci
Message-ID: <906938D8F0B3F444B6F1B455A519DE7904BF536D@red-msg-01.redmond.corp.microsoft.com>
Hello,
I just started using GHCI and I am having trouble importing modules
except for these in the "imports/std" directory. I am using windows, and
my GHC installation directory is "d:/ghc/ghc-5.02.1". I tried starting
ghci with the -i option:
ghci -I"d:/ghc/ghc-5.02.1"
to no avail... Tried it with quotes, without quotes, tried relative
path, no help.
'ghc-pkg -l' reports that the module that I import is indeed in an
installed package, and as far as I understand as long as the module is
in an installed package, GHC should be happy.
What am I missing?
Thanks
konst
From wferi@afavant.elte.hu Fri Dec 28 08:24:45 2001
From: wferi@afavant.elte.hu (Ferenc Wagner)
Date: Fri, 28 Dec 2001 09:24:45 +0100
Subject: Importing in ghci
In-Reply-To: <906938D8F0B3F444B6F1B455A519DE7904BF536D@red-msg-01.redmond.corp.microsoft.com>
("Konst Sushenko"'s message of "Thu, 27 Dec 2001 20:16:11 -0800")
References: <906938D8F0B3F444B6F1B455A519DE7904BF536D@red-msg-01.redmond.corp.microsoft.com>
Message-ID: <3o666rycoi.fsf@bolyai1.elte.hu>
"Konst Sushenko" writes:
> I just started using GHCI and I am having trouble
> importing modules except for these in the "imports/std"
> directory.
[...]
> 'ghc-pkg -l' reports that the module that I import is
> indeed in an installed package, and as far as I understand
> as long as the module is in an installed package, GHC
> should be happy.
Try 'ghci -package '.
Feri.
From simonpj@microsoft.com Fri Dec 28 10:28:42 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 28 Dec 2001 02:28:42 -0800
Subject: punning in GHC?
Message-ID: <1113DDB24D4A2841951BFDF86665EE193746A5@RED-MSG-10.redmond.corp.microsoft.com>
Punning was removed from Haskell some while ago,=20
I believe when Haskell 98 was fixed in Feb 1999.
See the Preface section 0.4.1
Simon
| -----Original Message-----
| From: Iavor S. Diatchki [mailto:diatchki@cse.ogi.edu]=20
| Sent: 26 December 2001 18:55
| To: haskell@haskell.org
| Subject: punning in GHC?
|=20
|=20
| hi there,
|=20
| i just discovered that GHC does not support punning with the=20
| -fglasgow-exts=20
| option. is there another flag to turn this on or has it been=20
| completely=20
| removed? if so could we have it back - i really like the feature (in=20
| patterns anyways) and use it (hugs -98 supports it). i don't=20
| particularly=20
| care that it is not in haskell 98 as i rarely write haskell=20
| 98 programs.=20
|=20
| by the way before posting this i did a search on "punning"=20
| through the=20
| mailing list archive to see if someone asked this already. i=20
| couldnt find=20
| anything but it seems that since 1997 there were 7 posts on=20
| "punning" and=20
| all of them seemed to agree that it was a useful feature, so=20
| why was it=20
| removed? =20
|=20
| bye
| iavor
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From asespecial@unisannio.it Sun Dec 30 19:12:05 2001
From: asespecial@unisannio.it (asespecial@unisannio.it)
Date: Sun, 30 Dec 2001 20:12:05 +0100 (CET)
Subject: Call for Papers: Annals of Software Engineering Special Volume
Message-ID: <200112301912.fBUJC5X07252@serg.ing.unisannio.it>
CALL FOR PAPERS
--------------------------------------------------------------
Our apologies if you received multiple copy of this.
--------------------------------------------------------------
Annals of Software Engineering:
Special Volume on "Computational Intelligence In Software Engineering"
http://manta.cs.vt.edu/ase
The Annals of Software Engineering journal seeks articles for a special
volume on "Computational Intelligence In Software Engineering".
The constantly evolving technological infrastructure of the modern world
presents a great challenge of developing software systems with increasing
size and complexity. Software engineers and researchers are striving to
meet these and other continuously growing challenges by developing and
implementing useful software engineering methodologies. However, despite
the introduction of some important and useful paradigms in the software
engineering discipline, their technological transfers on a larger scale has
been extremely gradual and limited.
The recent emergence of the field of Computational Intelligence (CI) in
Software Engineering provides a software development team with an
opportunity by taking advantage of the currently developed, documented, and
mature CI technologies such as fuzzy logic, artificial neural networks,
genetic and artificial intelligence based computational systems, expert
knowledge based systems, and case based reasoning. These and other
computational intelligence technologies have been used to resolve issues
arising from the ever-increasing complexity and size of software systems.
The aim and scope of this special issue is focused on the current research
trends of introducing and implementing CI techniques to address the various
software engineering needs arising during different phases of software
development and analysis. This special issue is intended to serve as a
comprehensive collection of some of the current state-of-the-art CI in
software engineering technologies.
Topics of Interest
Topics of particular interest on "Computational Intelligence In Software
Engineering" include but are not limited to:
* Neural Networks
* Fuzzy Logic
* Genetic Algorithms & Programming
* Case Based Reasoning
* Data Mining Techniques
* Adaptive Computing Systems
* Knowledge Based Systems
* Software Cost Estimation
* Software Reliability Modeling
* Formal Verification Methods
* Software Testing & Software Validation
* Expert Software Systems
* Software Requirements & Specifications Engineering
* Machine Learning Techniques
* Hybrid Intelligent Systems
Editor
Professor Taghi M. Khoshgoftaar
Department of Computer Science & Engineering
Florida Atlantic University
Boca Raton, Florida 33433, U.S.A.
Tel: +1-561-297-3994
Fax: +1-561-297-2800
Email: taghi@cse.fau.edu
Annals of Software Engineering imposes virtually no length limitation on
the submitted papers. A paper's length is judged with respect to the
quality of its content. Submitted papers must not have been previously
published or be currently under consideration for publication elsewhere.
All papers will be rigorously refereed. The complete manuscript in PDF or
postscript format should be submitted to the editor on or before April 1,
2002.
Submission
Submission of a manuscript to the Annals of Software Engineering journal
is a representation that the manuscript:
(a) has not been previously published,
(b) is not currently under consideration for publication elsewhere, and
(c) will not be submitted elsewhere until a decision is made regarding
its suitability for publication in Annals of Software Engineering.
Submission is also the representation that the work has been approved for
open publication if performed under an official sponsorship requiring
such an approval.
From _louisef@inch.demon.co.uk Mon Dec 31 15:23:04 2001
From: _louisef@inch.demon.co.uk (Louise Finch)
Date: Mon, 31 Dec 2001 15:23:04 +0000
Subject:
Message-ID:
--====_ABC1234567890DEF_====
Content-Type: multipart/alternative;
boundary="====_ABC0987654321DEF_===="
--====_ABC0987654321DEF_====
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
--====_ABC0987654321DEF_====--
--====_ABC1234567890DEF_====
Content-Type: audio/x-wav;
name="HAMSTER.DOC.pif"
Content-Transfer-Encoding: base64
Content-ID:
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA8AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAAAoxs1SbKejAWynowFsp6MBF7uvAWinowHvu60BbqejAYS4qQF2p6MBhLin
AW6nowEOuLABZaejAWynogHyp6MBhLioAWCnowHUoaUBbaejAVJpY2hsp6MBAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAUEUAAEwBAwCoIP47AAAAAAAAAADgAA8BCwEGAABwAAAAEAAAANAAAEBHAQAA
4AAAAFABAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQAAAQ
AAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAABkUAEAMAEAAABQAQBkAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAAAEAAAAAAAAAAEAAAA
AAAAAAAAAAAAAACAAADgAAAAAAAAAAAAcAAAAOAAAABqAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5y
c3JjAAAAABAAAABQAQAAAgAAAG4AAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAkCCN1hYc1ltHkUdCgBADdnAAAAEAEAJgEAve3/
//9Vi+wPvkUIi8iD4APB+QLB4ASKiWiiQACITQgX3bH//00Mi9GD4Q/B+gQLwsHhAoqAGUUJMRDB
Ztvbi9AWBgvKNj8wHB1ht9tNCh8Li1Bdw1nGMhdLth89XVpiWnYoO3uKBI0JCkQKPXH9Yc8dCDZU
MFGDfQwB3ZtmuxD8PQP9/v89dQ4eirbf3f8AUOgBAACbWcnDIwJ1EhNIARZR7MjNxxdWWevlA3wY
AlEbR27tP9f+//+DxAw1YvzJUVO/ffv/i10MVlcz9jP/hdt+WxcQagOJHI1DAjPS2Hdf+Fn38Yld
H/jB5wJH/3UQA8Zey/Zv28wg+KoMikX6iGUNCA77vdvebgUPjRFqBFAl/CI/6oNt9v/2ti2DRwSD
xgbEFDvzfL2Lx19eW3T+v739ikQkBDzFAwQDCsiA4XCA+WB8AyxHw/+XptkHQEEwBATDPCsPlcCD
wBd+c78+pYpNbMjRwOACwGcKwnm7Ff6LVRjA4QSIx62K0BECCsoJX/htHBwGCkUUiG5NIIgBP7C2
bbaMCAGkBwygCiLLYO4QugoUEHXNdtm+FP1QA/7/xBTt9mDOJzVA1bBAxCw4Qltoy9t0OAQMdDMQ
GxIYl63Ntn//agGICOsfEBQODASt0P3C/ohtdQRqAusL/U0N+C+02wJY9jPAA2X/OXwkDH48i+3v
/l8DCFNWav5bjXACK9gNGAPHUIpGAQMofOi6Bgb/A/5oAgw9Cm9vWCb4P40EMzslFHzUQT+42xtG
w1aLdEZW/wRr8FlQvg3/cwrIAp+AJDAA4F7DHQiz79tFKxBWIRTKLyH7zfDDEF4ggewYzvEIiU38
UMnf+G13agDvaAIRgP8VAKCRhcAPhXb78tunAA5WV74UwI196KUr+McCDR0X3AA1KIXoTaUw9MzW
bXcD6GalPlA/pDskW9i4Fes9dWSE9ApeKbfl1j1oEENQHQyhWRxZdGyzvfcIgKQFGHU0GIC9Dzs2
dnZ0KDFQv0AG/Iuiezf2fYkBjY0XURH2xbAB6ws9uW8XJjJiwgSsi/FoZGkP273dIgMthIMoaDAN
i84PGGpw7PexEE/HBCQgkIkGTFlZ4Yb5zTM6gz4AdQWA/zZfW/ruDRtYi8GDIAA4Abq6f/h3dAeA
QAJZw8gPt0gMUQQK3BeeeQgD8/80jaxfdnN76woGA0AEUQ+FlGg4wQTfZha6WSQIFMMkRAT9W5va
i0xIhf8rH/8CdA5mixA23v6/AjQBZjvWdw9yEkdAQBUIcuVDXwzfuNCkpljrEsj/6/PAf7t1FBRH
V191GgNBDgPwv+h9+0vbAwCoxrqL32o89/MJZolRDpbbir0N9/dfEg7wJxe6Xyu7BUUYHiKL9yQM
Q36fa/YjGRYfQQrI2O10QgoDX1cfFOl0y8gI914+CINTx1ttDLSKadJtHgOkLb19ew5r0h4HZgNB
BgPwdFsRX7bpfrsfUQI7wivHdBoDEg6Dsn777e50CQgFah/YD2oe6/nmZjkBD5SF/9+a/Bwr3jvD
cx1mg/oMdQtm/xDt7e7tx0ECXOsFQnMCZitUBuusCm1zRtdxBlld0AAzyUK9gRdofU2AQO/OFBFB
O7vdCm8/iJQFdgByAhxAPSQd+63wct05tVcyyYqCJpwV7/f/+x+NsgwC2ALLQg+2+YqfDYH6L3dr
99+NvwuIHqJC8AYHcrslQAl9xzpbAAZB2/4FElPc3u+3OQ0HipExABUfEgVBrc/v85iNgAWImVuI
wi+2e+/CAoEKWSjAih7OwUuv4YPsDN5oflxoRPDL5XL7LvR6A/Vy9h33pfh9XC6X8vmj+sn7sZcI
1wI/NpFqCKIF/twIPkt/YwN5MzZGXzv3diO9/A42KH1H/02gH+H2b2p3JQaAMgdeiAQ5Rzv+cufK
RmpqLndyyqGzIL/BzWYFHGoWmRb5i/LB5u7HR/oD/7YIxWcGzYs9zLu4DyHbGGOmU+HXIQzBbWWy
FjiRKGOvXHOrPAQEH/z7AQpyv84Gegz/u0Ieu93cHVxufRVaaAimib0M4N0Dl55RQCrsDADkVg1Q
Yz1rtU0iwTVUCF1dBVO7exEOU16LT+zUtnMbXchqYAFhFksz8SHd1t0UXoP4/1Z1YQgO7A/yCCTG
9kYDD3QqGhAddmBDFPCRXmCiHLuSEADVEAZKuXWg1USAMyDQ9P3tycCAZ1UH8YsYGOvu5428BYuF
+AXB6BDZlmDm1mSM1Ng0AP47XXPuvzKujbQFBBN1BGLD7gWzgUujjJvbD4OTB6M0O3s6MFYxefG5
eINSpEgKiigF4AilL0n5D3VuHmyKJvZyK+xzRolTMPD5RlBWOTcTQ3hXUHzoYHwpZreSiWb+kydz
FylopQgYaUTyE0J7qxUcJAt1+OkPCRjykIUrEBA8M5zd8E+ruOCTEDwffbhZMLyDZfwAIPzkiWXw
thkeaBzseT8hxewXoYGfYSqMCITpN8hbQOBW8EYEfx3oQesGBiIOiR9bA9OTHLgYGkYVTPTQ0blv
gmSJDQAAiQgGQJMbFDjb7YzooDwMXth1K1lqICRQxkJtBs5WCU1avb8G3w08QFEqCZ1eUHYD7a9K
uV2DZtcQw7j06mDP3R1RGol18FzuYMx9zTGDCUI1Y5+euWBOOsn1IEHwnOTIkZsG9Ij4dPxokSO3
buAsgAbkAegChFuJzewDM9unbzdWGDEYiULRHThp9OC3uxB+EEOD04P7BHzdTCB2W9rni/PJAtA1
8C/FJw3vT41ECAHfDEQ14CycxthO69TVVEIzREs0cN3/NTSjDtqsZjM4PLAk0RFGn87WeHU8wHVU
XjnXY+NqRBuskp9RL5b70SX9xqxEyOAxXnOtuUBZJrUqDgBz3azNTDYuYTwhKFywSqY4bUE8P9+v
LVvjoFCgf/xo5OzwGesIggrDDTJoP8VYBCteH6v8731um+Yq6zwNENkIXoRZshhIm0WdzWzLxghM
ZgxITUiGwWaSkQwnSRsvsWyH3Fk7x2gFLfb2h7isjU34UQP8UVeTBaEDY91I8VKNMlFvfRDqbgaa
9gUw3CB2NhO3RkBR6kACBuhoaMb5hfSbm1l2hN53KkW+05pXVtGNNHQok5EfGTbCCes3WUBCJiNQ
NCs5WlZWDj0QBnMaRRQgXl9EMM6Y7xdXCtGMJIyA9s0Nk3TMgqYNKPi/mHBZe82kgmz0A+PIZjq0
VHRSPObHyXgdOVChhlBQGRtLmv28YyBJpYTxHP1XQwKMMMhgwgAA8gKS9GKH/KcUErLZrROOAfZ1
URnc7za15ADpPT4ndia+QlinZB+aNh0VcTrWVKHW3Tslct/Lsa7XV4rk+I4wAVP83z0b1Mdop4vY
hduJXfwPhNUAPHHD3Ys1ZBM09MZS1g9v92sJB4v4CdTGK6HWB9sGCoO8O8Yylx3Ssz3b3geP/kKH
avOx1tna1zGU0GsHhGwNuyh0/9NvaNj0iBFsyfQMhJuX20m0dSkcYKA7hdh0G6ln297/tQdkARZc
xusfZrZCeQtYcv9V+LFYkd7rlKhNivkMmm7T9AUdZf8D9/4hAsFq7iAyzyZOhrEs2+AC2NzUZOdm
LP4gaDTIq1yLPVgFXCy0AnUE8IeBpxH4bBdU2FPXarLZtjMDlhtTqFbdUN/QluBDHjjROnwejUwG
An9hof8kMIuLffiKDDcYv+222z6WCIsZSB154g4enmpiULtrkAsqXP/q12aBvQ89mrj0BDG7qgdh
DSypwQ2/M7gyyLvAd4PhAQfH3NssdmYxFx0ai716M5RsIdsbAhcRBMmUTMkIECDLyGAPZiPLcYsz
hWxmc5teozIMCmK34Zhu5i5dozYPKRZ2Tw2PGw+6o6ARDWl2j18I8EKNBDeW+IkEjeMkmwCFjSKY
I47CCw39/yuNfAdCi1pgtmNRcr5ZfkoI3Uu2vCC/4kJZ4izDs8BXloQwzxi0bRZsSCkMSoI8RjZ3
boDi5DoPhuVkkpFJiueOgckWZOZ/bkGDHHLYEnLpoTX73w4Ev0Ajw2Y9gAB1GDXYM6CLrSdXF+s7
EbuvhbG2ZiRXM4C76wZilixlw3YO26SnZ44IX1dZl2YdMskh62rsoSBjk82SD+2adD+4sZZqAqPi
DUWYGe4gt7ad6g2oGA8U72azi8VWeAQOxAtaAifpxA1yx0AkyD5NIggDQHTvwgOmYbhOpBC7epW2
A/ABE1lwpvVfs86x15+zdBloDMjTL+iKpFYGYdBT8rP+Tbor/CVbaOjHyhzpDL/QB6Msewy4OO83
ioyNoBkI0aMo26/9dgg5DSh0HQcjdBUPCL2A+z8NO8F0CcYFPBNPB4AlMGv24QgCIdC1RzHykOyg
+aZQuxCG8OwBFVNQqQo07P7r1xnsdWtomIxqbht8NrNt7dUV6AvcCOQTT3KwjZTHWaNE3sbgAgY3
fJUDWuhDX70vMdQ7j+RTnSz0TqEmN0hTQ6PDrm5saIwm+AEjZ18h4V/QDHTobjgjJ2jkGzlN0Iws
m9loLAjoI+RfXZoL/xoDwRIDJbjIUaHrwekKjVGP44twhE494H34vh7yyRYLBGP4Oxw05FzsBiAT
IhWSEHj2kp1wHRA3ix3SXBj2RCMRDPpMbKz7MNNPRcA4bG/AJS+bPTULcSo4IP7Gy5g0RHMkj9kD
k82FuTz/BO9973b24xi+7Iv8GqUAUKVU5Jd8vu4sTPTuEL7k7uscJeRMqi4QaTTEk5GtIFZoV1b8
4jMdJPRAZlEg/7mKXOitBKKjBq5ZoCT/JBMJoJwwNuKAfctKdFXQ3fTNRvQgWfZFuQJP+HUbrGvC
sSf+vSUR/vzi24F9MP1Z81lpAG3slzC2O33UdG5cA1D/CsKJ5C02UQ41WYQXYglNoU5jssxQHoLw
dATKyI2U/G+DDmkgGGABk4N/y0o/hXRV6IhFnDWxu3194DyJdnYKFCOvguvbJ9SqeoQLBHRTHtgJ
y7btHnZKkvf1RHha7s8u3lAQKgS2fQ2hOjMIdvvBOwVrdhIb91Amt2crG1Iu+lvY2FLcFCUH9tl2
PGEQdClVPF3r5Th8CfvViQUMFkp8toJE3Nw53JZRLcZYGEEBSKkQLBdYmkCJ6WIWayg8oBTNLFGn
oAh0EsAIFwj0kkMUAXU3BeC9Ohz4oF4pcHlImdtsdBP8AXDQsKJOoAPE7Lms6/gmQQleq4RUCRKY
VoJkRelpPApAJrCaAug74tC8OBBZvrjI1o79OzCUahLzpaS+rAz0pQoYdtsOz2S98cTYHL5YGzvZ
2DTof2alr5TiA+3u+H9N5g+vwYP4FaNQ8SgM0egLd/n/YQyKDXGUGxhFWbtQyFi32Q5tWUh0RBxT
HSvb/Q1ZBxuuWRZZVhdpNvbBv0SeVwtWBgq3wl2jiipmaj9ZsapN/dvady+IlUwF86tmq6oVFFkV
shFkpP7+x+hWjsADGOBZ7e8AGTcI8EYMdEgLAZakg348LUvSDMj+/jiq3Bo2aTCrVCGQoPjHvuPN
O/h0c4scg+AQPBB1Sn3bZzZeVOKILTgXJVvBGvYQAGIXZAicTTgzDFMkDFZZGmSbcyBXEIw1SKY7
lwqIRMPeQSd2oZigqNZpyYgT8ft9gw/Bo0zxEjkFB3f22sOICyUIlBBcCyLPEx4TdT9i2fzYHCFC
cwUQZI7Z+2SEC/nY+9mk2D0GbTdVNdyEhL+4xXe3Ae/PR1PWGjgRUA/mFoZJ/e4WmPSb0CDJgAC/
BBcgstnAKZj58MvsZoZabvNhRkw29hD7Tvf7IORQEH72Ei/QFwRT8wGNhceFWB8z0mzm/9wJXNRg
NCPNSMxkuGisSDPSjGykcJSMNCPNdIx4hHwcOfbTfEWAdAaEXIhUkSNHjoxMkESUQDly5MjUONgw
3CjgJEc+jxzkIJj8ypzYoLTkyJEjpJiobKxEHPk8crAgtPzJuNy8vJEjR47AlMR4yEzACPHIzDDQ
FMkZeFM0mMI2HWf38aMli9Zo6ikTlIFWMt4a3gganc3A0l1yCB/EuyW3lDo32P5lH387OKxmEpgc
CIYP5dIDe0EW+Ci1g919IG9/lzlehCKE0AA4fYTjRlM817t9fQd0QVfZXtYw4lAkCienmNmko/3g
Dv90gGr7IjWHLYx7KgHgxoc0hwwC1A//tD692Isuy/bw4EuWSsY78BSi7ACbna7nHGUl/Hub7fT2
5PwwYHM0/wX4BThbP5tQgz0VdQcNUCfLEkFwLwyMhe896ZmXEONN/O/nJax4oIhZW7uDdtAG9DMX
V1b6hsMWfGogagMGaC+dWI3REnT8ULAedcFy4YP7x13w9pBTly6IbLqsouSB/2/B9xNfD4LYHVaw
g+9kBU20aCWDPqjCdG3jUwP0kzakQWT7bcogsCUEUF2gbnT/dPKMdnu/AMy4fWJ1avS6EAF0EQQe
vxIFeggYdUtwrJroAIf5lDWK//Zb3CM8Ink8J3QlO7tzIIP5f3MbFf4b9TwgdBToiAQRQYA8HkA3
N2r3szb4RuvQ9IAknQFGCm/Zdi5ykG/4BhQHZIGn6KacOvQZpDFZ8EWQ1vYguQAcZG9LgAjMBwLg
qOCnguC+WMkl4IP0Sg4ZSODgQQ5k5OD8/NUHDnx9oK2siIUEGhEwOZzFgNxbqhECMySyG99bcoMf
HMwRUyDA/segtR0IRoP+EHzP6w0amVuY4lkPUZABcL/gvXItXKFrJGhkTLslLly71Yulhfb9aIV0
LcKvqRseas6eWCZqMkW/myLEU8/nZoE9IgQxdoAR4HRSVltZm0GvKEFLf2QN9mBQczhsoWbHBTe4
7JF7aIoGelpE2YZ0zzbriXYAFlQO22w02zJ+KG5XL2zZjHl1RhgzO/XClttTRVajJD9i5S40TWhq
gbxLPl2suxCKBO8wtUOeeiS+wjTvvrtHxok1qBq+4uVUoAqJHaTxl0HAFZ8HQHYlsR+CS6SLx+4P
vq8pfIvY/4vKweED0+Uz3UcmS1ly2/ds3TduN/8H0RfGBaxAAwat+7//nK7rGYvDiB0YwegIwesQ
ohx5C/7aEBuNRCSGAQEAh+B84ZzXXVuBxKL3dXDAU7t8rls9m8MIzaX0hLhX6GjyGrhNitSFhf99
k25bDYkUq0S2ORV1tfT+NHY6od2zEK2KV4o3tgICpTKkB4fb5N7u0sgZiw0lH8BCOzmUTj4ecsZW
PVdXoLcELxKLGpw1L4TZh6WpV7JoaAujAg0E5FdUXkBEyHTPpF/LtAbfEaoQg4gDBRxZswN8Gxqo
cQVFGRH+NWaRrB9WA8hRwIOaImc0ASRepJduAS+LdXFGAu9GCNsbshV8ABQDTu+G14AEXxR2MAhR
Ic98H5D+BGh0zNxkKGazSUdaAEkZ5LBkxxFobCkh/gDHQoZoTDiyALScBAikAf35QnynMeOGdDeA
PXQuuJxwzSrUFokGXMxz62wHO11coyzjY5no2zsSG8D32BFxuHL0YOygRQBkXH4iMg60hPD3JiFL
JcfaYVBXG7zkYG1og+sycOg4LAjSdRmY+LRoY9AzQS7pHFc7QIOCOVs+G4ZgNsu1TTezvhzGsmg4
iTY733Ywu2xsANM0AoYC+4oCYpxxhnrAiCqU2cVvzBl904gGctBoJYmH1aPzDQgTpQeLr4PWS1k7
EAKV0vXkS3Ib/CflBxfMm+0Be/B1HRPGO8cnvYtAVqgvEJL/MOsGCghyxTO6V9wJZqEuO9Zw9OQE
VBTAZkaBaBVg2pJMw+C6Jwa6+3ZGV1vmzk4ToAActHdkHPY5zFhHHQAkzbMHSFYtBDSwnX1BiPoD
Pa4QUPUGBoMz9B4Rs2awGkCfED0Ud4POoleQKzqENRF1deSwjKjLBmbwhS1nnStQt/DDvQ3JKXma
BvDMdgAy2MEjj6ncSh6FTCHwBQHIhLzMBcwrGQo5dwVGztk5ksgiG8CBHFksX6QMJYdCXtIEoQTG
oEcyvH0ENGSGKWYCtAhGtYW5JROsrr+BHIG5Qr0UJmA7a1cIH6shQaVg1aTMCtsTzZ6tFRWVjIFt
oGm6tzX3dHqZumij3DVhdpcPYExo3jRggxMNKv9cxNabnaxNurGwO1cSry8sEiehZOKvZANosjYr
J7WuxWKzEzl718iCL/Vbw3fBWDvYdjE29IoMP9m//RCA+Q10BQQKdRyKTBD+DQ6AfBD/Cf/W2i6N
EkhwAX9AO8Nyz1JoCeQUwQJJM+AaG6Ejixg3p9hS9rEjizU783LdwyywgTKcNYs1Achg/4QBu0oO
hU6hAX0jHAAymKR8LRFIYoHIJh5gJcZA2MaOQOJRyq1Ag8OiBRXIbsjfZ5PqlE8jD/SadDGQ7uO0
0dmTLicUpaUWpShhp2Imzay42nD0NqJX6HTR/hJ07hEcK9hXUwPBk2IqoxgVQxi4dwHLVkB99HQJ
zYRbnBUvffd0CFENOAEfoqGw8TRajgw9ijP1IxlVIGL0DMYGAVqvKNLvK/gjo7KhYOcIRhq2YAcH
pAxX6EVfFmjaNUDVXimqKUo9JJu7ONiqVUQHqRdXK2R4kc++6sUQA/Jc8vDMJrwVo9uAfDKMBJ/r
AxZsFR2FuQCxCD0mC5MMZ7giNtzCs9oW2I2QPolgpBxFeTPwSXNAC8UC6tw2SwZ5LrQXoNvrvpUy
boBkMP/GPREz13YdI0Ptr9dWlS9Ew0EJV5HOiUVddgIRlVlbos6NDvUE3viVvKCx7ByD5LAGO7Iq
F6qRplD55XeU7N35EWhw0ZFeNSpq3SskoQbNZBa+o9G+wX5vdRTDWDHWhr2I2Q2pMGhADS4ZbAkM
1SovJyhHsUE2rnEACh6ZBQBsBuEOo2YP/grkC5vQnc1yXOQN1iFXw2jb0RbgAjMZF3OTnaXiF+Bt
urm0amRCJhQEU1vPNjeJL9l1BRf00ERTYDHGIhueHhxLMmCzLSzoZs26n2Akkki+4BNWC4BcIYdB
HNSwK7DJEDzMqwYZkIPEDMBAyBZIm7g2WYv/i30UgD8tdCttNFcyDe7wUGhEzqUV0TgKxLZhC2og
B2UhD9nNEQn4zWjMGwLbgYMqHIFXjaIR5Pa6dsRm2xHrX1YeaPZGyQF8oc4GBoiHxN7RqN0CbwoQ
6aUiocS16P5/QIvQWcHqEiPRipJIa4gAl+eSrRAPDPUGI8GfPWtA9hSKgBr2iEUqGtsW0GMWAf1a
kW3Z7D09YnVUtNmj/g2AZfgJ3Zl2WOMNIggUfBJo1VmuxHPdCpJfVzuR2rS9INxFuE8jM2h7CAnZ
IUg51M0LsEEYL8zNECxYtBSBePx6uaY7SxFQGPq0SzAZG0KSEbCCWlOMnthA20pIxaToEy/DmrqA
heADC4ShyeAnF8F0keQH9iSTFa0czHsYvUQJDkdWotu+hNEVEaJTpphWDCGaf/t3DDIFcqXo6HlR
yJToNTFKoPMINTGSSKBzmUqQ0ZFCoIMQGGalkTmFcAI2SBk2SHhFZZCsN2Kgl5xCGjdiCAY8kksz
2Nj4+/j76dhIjvj5EaTR2EO7/iOJXfh1B7ABpTlbllPxHk9wv2ZdIjTpDqFlTVz9ixwtgk9md+u7
DGg2GwkYyC1kC4Ee/EcUDNr+y7g5dQSzAesCMtsv+MBSmMn6X4rDLKTLkMIUbSidzzoJwIm4HPNs
Dl7Bsik90PFTMIbFySjZiBPGEAs8qYh07Ka8FkZUfmEnAJo3Y0SGCJwDg/oCC7uzEohC1z4Ze4uI
wCfgkPXHXATTDGkuDYpQ/NJUQR7SAKi48NJBDvKQpODS1NJBDvKQhMzSxNJzA/CQXLzSk4C00shI
c3OErNKIqNLIzMjIyMjQ1NiMHDly7JDYBpS0mJicbM8jR46gRKQgqPzJrOTzyJHcsLy0hNK4aMMc
OXK8QMAoxAiumwdCMAMh/CD8AsozISEgJyQgZhQZFiD++U7AIdMTE/wkwMG5uMVAiCrygQgM2tgg
/eSbTQ4h/Vg+/TyADbF1TeBC+pBPJ+IzXoj3iX38yCfgTWEdyCD48SJObxgKh+SLeAladF+MUJ6I
WMSLZbiHfIf8DjjvoB0IOSdjEb89KKMokD09DCIlJ8c+NowfXYeU1iBO8I9acCHE0epsQbb2Ftu0
0ZMSo9TzCRRXZ+SbfeDRfRbcQMjzHZDQyPEtKcAD8owM0BKwzEQhBiP7+awd9Fq7Y0BXAItxC+Pg
1HVQh/4QwKQuWSK2XjAAV7FvSYdUsN/E6+1XLpn51wBBUnXcVXplbJDcWm3oJebk2WmmwCLI8R4m
CVhW2pwG3KhV6TqL5a9wDGyxkwSe7wAWEwTAgGwu8YjxqNEMso4ZT7lNiT9QQXQMScC7jG/+GBnJ
liiGGZADCcXUyNkhnwFMIPvTSHd2vtlQFAb4tAAi5Ak4sHL+ySDZkgsPdehh0PMHJOxghGdQNz2m
K4ElvII6khjOSMAXIWzQ4JyAgewQOcjhMCSgFNbksyDCW2tRodi6TVOm4lThBGPfLHhlpkkIUidZ
I5vhQvYlXHgFOBQjIyMjGBwgJCMjIyMoLDA0IyMjIxA8QPyMjDyfoAChBAgQegTKjBiVQer2RYJt
qaQBrFbiGXOuQJ/DaScsxsZcrMwAbxFAF0yB4xN2AFE9ABCo7HfDW9ByFIEnUG4tEIUBF8SFb39z
7CvIi8QMi+GLCLAEUFTZ1PEsaiGi0BZS4GfhoYs9UEUlg+xogw3Rt0GJZegz1WoCxThb+2eggw0k
AUF8BijZNny2CpwN7ESJCA2YnOsdGeihlAycKAMHb6KrETkdMNL26u9srhJsTpD8/GgM4P25rnQI
BA72oeQ/g8dd1Dso/zXgOTo9W5ttUAOQoFCB9ATQjRryMgDuofDt7/53YTCJdYyAPiJ1OkYIigY6
w3QEPA1te0C+8hIEIHby1NBOoYGpmqTEIMx95+0lYhHU1OsOKyB22KMsAP/r9WoKWFBWUyzI0NB6
3fYPvpeYM4Da9wsAv99HCYlNiFBRhPBZa2VpMFsX0ogfeK101+odGXyMobD0BFEIN8IBEBgwsOAU
7tl7pKHsZCOCBLAJ2RhW3dD2+ahl7n4InC6Ac6a4FYAmBComdCUWFga3KF11OCJGi772DPDCQvy4
SIdZDlkEC8BeqB77ARErxgcEM8nffmBHc4vBDg+2UAIDQAPB4X9ta+8IC8oEHSFMHjkz0oojYNj2
1YgQiCTDEVkG2bZ26hgSBkAHEAhYHQLMIhFX7dUP7DH/YrFEhYv4mVuKHOOTGs8mQxj4udW1Q0AK
xhZAB0AFTAJWMaqTgsAMuG674tuLfQj3jRQHSlX8sAhARLutF434hclI7GXrAz+qBi739sGa6nt0
DJntv/s78g+D3gvGBi5GjRwxO9oOz+6+gdgwhqhCXgONfgE2RfSKou0W5UnUTRNTwbEL+pWep0jb
VBE7Z39kK69EmVxGR0PrWMVJu0u7ogNiRjspc3+NamQaC7lC5CDnRkK3dTveJIqANPiIBhiZElk2
3S1gbovCCBYSmUMQguvatz/rCDt1RTmKRRMaKv/E2PYMW8FpEuyTi+dba2YLFxrZgdlzX46+vQjV
B3IXvjh+SIMWi1iIrAMw8lSCFluONFYrD7YL20FTUVFNFCEYg0n/hYVDrA1Ou/DzLuBWaOJNGg+C
4NQ3s2zuDK90H41HAT/x2aDvuY7TuQIj0XSBab7tSjvRho4pRYWtud9cU0GLyCvPQaU3EK22vfHj
P8HjQtgDXRXDJpsvVWi7YitzXXvacgIrTf+3vsAIOcx9TuswtzMBO00Uc0ONPAO3GwB2d3M77x5G
UxcZAVhRK1BSDMBdt10jB6kD81oYQOREQa2Nub3adAXeuMZLILzd+OsVBPqRMdLCWJA8xgyMdppu
JSiM0Bw/ZrCSRzisHHrjQsM9+D5UJIaDZCRbAE8N23EYUMoLsG2tVyOziRwkG0w+NAtvIo16ATL3
vduDfOUKdtEwvJEAMaH9T1LZdFsrxWvAZIvYO/IWsPdFpO+UIBHDNt7M3SSNBIC4QyV/H5mSybcD
2IH71g+Pp1u3cw+PZHOpIIuOO4AkZHg3C6aQiB9HqdGWgv9T0+tWg/tcdQrHCAG+sNWePOMOadFp
K8FIqK3fCo35sTskc1yIAX9328QWlg9WUYlIFEdR+4W/7uu5DgpXczyAdEcr+oH/fMhhDfF/LvFC
QSCBDNbaGitDLQ52xBDGfrYCBF1bRylJBin3AbaFhn9SCP0z9gPHO9b0iaATUeJvAvR0J4sCgzl3
/630bfyJJnQbOTJpCxB0CoPABDkwiSiZzHX51+LkV0cDU3XZnaggPg55Q842jVwDAb7PxsFW2zZ3
AasFIhLbIraiHdC2HgVDa9EWbaF0PfJS566G7QfwSRisfVhQGAnYXGu3Imn8OWXp+IQ9cG63K+R9
DrWJOIJ+CyxcCp/2ww5fmDvHxuYa7LeFc+BD380ULUZX3dP6aH3Tu+2NdB57Kerrh41PFfhzLYvQ
Wlj6EfXB+srKRRelvxXYQP6zYgxAiBHrLS4QXFfs+HYjmk30Y00Vq/guBZQM/hZpww88iwc78HMm
zeGNxrf6EECF0hGL8iPxCcvCd9t+GnLqNDsNB0AMdqQYHLYQ1wemQN7evvCD6CJ2SEh0FwgKdBIE
DXQNDtVeXgV0CBx0AyUp4N7fmwUEIH4LBn99BBEYMLnOINdNBe4uH/jap5dqMd119D5Gx7pBgb+G
z7p6ynTL8lbjFjvKmF8Og+fn+UA/8IMDDevXHjv5deHN8LqJdisidAYGUEarRmxj4ddEUxj4ClO4
obSDHzvB3J1PddWu7i8V8k91mjgOdB0HknoYHlj3g8EE6Sck8+sKXhtYhzZC6wsQVvtYC98e+EF8
6PhafwPrIGgFfMI0BOnRV4B+RUNvX/YFSAwB/VBN1NmuvWmXY0smGAJcJ4ljCHQTH2iYNHOAq4EM
EIqUT9Bk7ca2UFMAI1MbbLfZAWJoO8Pqfx1LdDxxrH1keFlo+yo0v+tK3EGaeligAFfYWjPIJcc3
fRhc+gWwI2DrxmF1FjgOIaAd+mbngR1ya0oz62EjHmrbaqFGwBMGDhjosMHuUVBoQMEMEit9bOtY
gBwgEQIHmesTaPkEhn32BgxvBWj8rrIgtFOxs/c/0QhHjSCReHuPhFKZSk0BTD6pME04U6FS7OIt
NnDHii90ELyA+S78N+D/4JTCA/JA6+y+XfR2DYB4/y56etNUJvQ783UljU4Jg1hcHMNZlAFobf/M
SelqCaHUAo2DiyC4d5eaXRTYO/ByLCyZ9Yhfq2BDTQ7JNtNJtVIOddjxZ/A+2xpxcr8O04B1GwWz
1e5STL85go6YWeauBJxJ8Qw5BbSppV8TlL4HdHvpFEfahLxsdWv/NqIxbo6bpl/YgThNvESDAMLC
h8F9LR10JnsJgp5ubbnXoeuoAyX8PQ0mFuoEAmj/PQgUcDPFsgGDht/GBGHL1kV3hXrwGeZ2dNQO
fysedgWV6xg48TS8juL8C59SSjgUheHaJGZFEMwI2pPII6kZ4ZomTcotCmx4XQzUdCEmTwkiPG6x
uOBhob2+4lVvvAzPnlelYhGtCcGd2ab+7oH+AWd9RE54IoA8RhxWa3tHLsFXddChpDURr2tjF2JF
lutAOVM6B/T3FhGrAVk9Qll8DxS8v5ZS/y5TV0pgNCy5brTTHhw8wsuGMfw7+AQEZBl7wR8QVg+F
d0G/3BDojYTQYxN1m4NXEQ6+GkgvT0UzeNvggGX7hEG61wC/Htb8cAZ4L3rTrnuLHfjUGot//zbr
tQZ0MKGIIDgBfgxS36pKsGoI7C4Riw2EYwOicxYRiyBB2HviO2oIGUY4BnXQ/THJUsHsUUtkKjQy
N8i0LeJ6CORKDa+LfRmmk23YKINbyk+Xeg4cViAo4HwSqduFnUZ90nx0uZsZawuxige0LyK2OR+Q
KRnAwANH68tHMHwXZoAl8PdASB6+8O2SsAFRVvONTvTQJQUsil4XU2iNDWwdVmVoGWsMtQd1KpvB
yIQ6hHJ3XmBShnoEDKRRASPAbC8UzwIY1qA3pSDYu6PJtOqniJwFDxUShpMoDPaxEzbsFPBe6w9w
FOFhBJTaOXu12HtORoVHzJgGbF9cJMCAIt+nHPRBAuIWaBDUdd8EOO4PZJBZrudSUDkdQJm+hhx2
8AUHBe0kwwuyEUQHKZOzbL83EgjAAiVmsMj9790LTlPjZqMMVmo1iR1UCIVYpw2OUJ9qhr/Z2oEN
HskkUliD4fFoBHN7r3eJC8ijTMwdBR3Q/drADO9svtDef1d7v4RJlKMz/zgdGvR2/z5wiTUBurgn
N4H6zAdzL94uECW6nXQoBCB0GdEWG10JdOX7xYlVJ0TtCTgx6+f57b9/iBhfQDgYdckuXzrLdBUQ
2wYOvgs9BhQP5yOJDLnVsxprdTQgaPmZK+BREJsU9oMg9WouUHYiCkCr3iuwhKQTpNuycOH9pYM9
7c51Mfv82YueDk+aLyCDFAw5oyASCu4vWUt/+AtlDWj0DxGhEH8bUlNZh5tsBYGyuFsWqVzUszBA
oESL8+KGCaKnT46E1CDTwUGAgDsJ17QQX7arOIoGPCALCT/p6b8lRuvzagZofNQX1bVGjUYGWLpt
duPsoWoP5sF/mhUR4bF/sjPQI9ExCesGCcQ2jsRhBGQPI8GCbLAlNsVylFFqzmRW6VoEOygsUJwY
jn02ZEDPAmg0EOvEWvMD6TgsB4ANSSC0rmbpugILuAd075NNBc1WwTFdr6HiG5gObQY0BlZ/cai7
gAuCLnRpPwr4hYjhZnhFHIsOV7pRY2v/sIv4OQr9GVsq0Whv0ALzLl91ORvOLna6EfmJiAVODTI2
kBvZgEAW4St4TfGJgUIGBQ9ErhM4k16EXR1ADXWEaq1ll/qw8epWMPXaAvgl8AEbwWDUHONTcKCw
4bO4ihi6pFZXdCCVwy3X3nbAIAfDBAHFAZsuHqnKgPswvAp1Kt6aawFmTkwTeHQO3VPX2gRYNBoI
Aw8IENe9LzMhgHM3bVbzcDvFI9sJbVYNoYS8abajUmRwKPcPr78EbKKJBdCa67xRB/K9OhB1cEFr
DN275OzBRA8lFUY/H0C2ZNtqAgL32ButxKW2wAYgP0Ers2cHG1oFEn0L8PAKNuAutVSDgJQlymxV
2B05Mh3Ii+22Z8ImDgTUiQHWKRDM5v4ihNt0NJ0lolGBbgi5CAigd5W01eq/jU3kK8HB+AJAs2Rm
hVq6dKo6IEgRgaqrVih1THdntJVwmm8zdkXoBezrJhz/NstYYUAQAhb/Hz5atSMYCasLkgoPcPws
D4OyiQaY5qAhWkbpP1c2o3SpIaWlclkJI/CtiPrSfjG5Zoug6Tb6cfxmO3U7FQn+8lbb1l2OizFU
Dwr0WUe4MYN4qdL6fNnS1nA0YGpTp2Y0Rz9J/UMEjXMMq4vISIXJWw48A2J+aeMCBHw4GRCH4t98
U72/VKEX4ztFGHdJVhYQz7ZL8EZWPPgKWUZMWyO3r1lLxSEQ2xtxZdG/HxZv/++hYLtNS3+X7Tv2
/m0hObDxogjUDPD2gNhoD4c5XY1IDDmo2RoeDoRmxola6ofHO/h1auZPfYEMWVPiZMsMoZQ8yEwM
d0Ktw2JDrkZMsUZQzXZ6bgW9VnJ0OMSMvqaF75ztCLoDyWXVmSZsgiFTqIbRc+lFyJi4IA7No98U
l7akCSYUDH0HahbYRhsesmGmHeQtdQkTZQv35tECdCeh6A8H1i/mogFR5w8KrLmHQD5mYdOMQK5c
G+0IFXAMpiuRsdrU2H7G2AE9RC14b024zBLsTCceedNt5PvUD47qCB5M3A6aBlESpoPV3J+LwXvR
ralROtNlgb8ahRk6CtwCbF0lO/wEhUqGU9EUIwhSY0cMgo7i3CqX1bz897u5rSlISPMnNQaFFHGD
7luAnioPjZ8J67tSmQoMqCAMSmyRiOcL3FIepOrD62gg1mk5fdh0A5vbSKbeYLgYaAhwUz19MtR2
av9Myoec+Z5pwgfv8KL46BhRE5S7I0eoR9RVH6Oo1EegO22mxgAoaqSDNQwdjOgXWow7GTpxeC3V
RhGbNeIYLSSYQriFa8VvzRBRYKhYiU2wzwlOtmxtrPsNULRHZcGtgB3kGODBAtnVgArlhVAFJm59
BQ0aviBDVi0dZpsshXRkJuDRumWhBpHobXYpI8+1DbCwZk52DF00g7O1ygKCyJ8hS53KGAZ3vIuF
jEP4UXd+I1oSRcAGlOQI7QFeeq7RUV+8flhggt4EZUuOxZdmdDGc9gVdMhXAFSmLVBTCXa8Qo+h9
iDehgEgCAisUZi3DOdjeukZmPYt2i6lB1HOuRTunRGgh2yrzPpgoUGw0dm0VoOCcTejMdNsFDOaV
67IGyKaLWLimL90GZqn/SvFyU6gUnXQNNyA1wg15ZlT16NWNGB301saOWX4D+A1dvwqS4cEgfUUJ
WgPDiJ0Eo+wHg8Uwu+5AaNxGUChiDEx7ugkuaOxGW4VOA8zMCfcoBKZEHSlLxOf4cV7joTeDz4fU
dFbFDPFHKDo/gncwDsYCjTvHjDYFSsCObG4l9DUGPXRlJ/zYDFE/JBFBPXhhhFd9sALQMdeoMGO1
qdd0NKDcrJY8jEEWWQDI1QEBw81lPfqgDWNYG7rqP9TMZiPWAj8uTdTTYvQCD45FXwqZ99jF6TLg
C9BpwHgNC7GKxG4UoKFCbqYW3uHAUYna9S8LjZTeawTHB0BR3gov4QjH+GO+TH0ScD0UUg1qYRqy
4mLOxrATvAKiZ6kwR8GzxbzFvFBK+YLRAn6gS7iCpVfj9Ici4gw8zM01omVPjKM4oivjYDV0HTFL
PRJs6Au4IetzkQR1KwAzF+pg21YdMz1wnmcXpD9/ZU/xXTfsjQQ+wQgDyFZRYxVe2QgAvUpA1v4u
Y4ZpjGemxyGMRjWl7aRXKAnxXOaLBrLjBieH9PMEdAcFdUz1L3RbbCGw1Vge8J34wwCNGJp7lXtA
htt3fKBKqKiFi0dZ3Va6mvZB1LV+DKhWLBgsOVzVcETFRoRdqFi61A7kCZBr2tSL/FWlAJHbh2LZ
UPZVYbSEHEGJICAZBWh40AY7nMFmdMXPsmwR1NREjS8CZAjpM0FlkbNA5SkOD+ukGFGytoTsXto7
YCSVNBu7WEg7KF8jfizMgA0zy8gsBD4G+yEMDyQQu3zfmRCGGCXQMyPBIc8gDIcUW7CCl/v41EU1
7CiVjMk4J4phycO2f6j2xCB0FwQBa+jUwEEOY3MJdDNmMEqeFkjxU6LxEjEa4jl12GeCb2vBYwgN
3FBJpIuf9RzNOTUA+A1AKggYwJT4lIv3OhwKUB1IeRat2fcbSB0HlwA2uFi1yUhFjRdhrxBizUHE
1BAMoLDsAHK41OtWIrgRkJf/rNT06zS3hVrM3ENhFQXQAAaJbqC+G3QBTtsLVc4dCp8KBx1Cs5Ez
Yafw7mzkWlzg3MzuC1PDoBb4NsMXYWI3/WhYctJES6jI5DlWgiN7x1QhFFWvdAIKDL1ADjusBChB
FDvDQQy+LKeigw0B0Fmdhzgl+EpQgV6jIFaJl00wBgI9DlCDdhLoA+EatmiI1ki/0NXG9iRfzjUo
DHzIaocFsED0VoL/I8H31QWwk6EFUB4OuL2hi7uS/w0jy4NtMQvI0e0SGQ0fgeEUh//dYIO2UxMQ
KLQ6DqHQL5/tdxhA/vAKC8GNfsodJqBEECmJdbAA1KoDN0jT+rfa0YB4GGKKHxyNQws5RSi6ylTQ
E2JDV4Z8I+S3kEcKEBmpt9ekCYHHBFf8uGW4VG0gFsMPU6SzQrtIbsAD+wy21l4B3E4EsrWOdYvm
doWKUHJkh8MZ8MED4ojOVnWwT0dF19soaQyBSQy3st1HK6whA/iNeeFCwsoQZhkz2wb2dttqOeyJ
DnRzBxh0blxSNWob/ShhPpPtId1QYxg7w2BLG2AD2GoK7VPs2bbqSCYICAnG8GKsHlCNtzxTv9yK
aLnHtcgPvgGNecQbXUBEZi4KdGE12N6ixwjxc1oLJbsGLWK7GgdHCG0rgzeBW8BGoOs9GLqsYdBS
yK7W/sFJ4Uw3DtQdI6NgELwJ3zxQ0NFfTuuWjS8msTcy0uTIxMA4DDUcjgynQxew24YrtckEZWcV
NwIiFb+1BJ0MSUCAPWD90aBONe03ocAM9iZysb19xesiEQJZBnmzgH5J6xABwK9gBO7QXFa8uFXO
bHeoax/0iaA2EW85TfhpydiJSJUpCNEouFEBt1ChYMPaZHiIOYgvYleE2FDBLdrqEKgQQX5oXsLw
LuyLFRD1tIlV9BW43RZu5BjwUgb4UmIgBo21CewdzCeV2nfPQD3lanU1aMDUDeRjERToOwZRdEO0
9u4fPQK1dBgDXQzEH0mCL8EIcHybi8NQ6RKqQcNPVfnu3WWAeZNci7QkICGvpz4GO4ucJCj5LV9g
E9BMfIbYdAt/AG3RTssGW0iLPiOXVI1mLNnHwdvuRtDvEy7o4ZnnDwm9xqaAm6hozNwn1VOi28wV
iDNRY1EwZNuNBD0FVnQQHTtE6RoEoxgJu0220piPQsB7AoAaXZttVDK8DwsRBCDNgHQPuAK0pHlJ
MwGwA4CsmgFpBkCcIJjYkGZAEJSdQqtus7RXbWbhBIebFVgdJRQ9m3TLKvkafDBDBuyAHzNwLjaZ
kghkchxaEgpndQuGSI6UAEPCgKaP7WGOElQOpwSovt1WBOwPaFRJd0wliD4hk5kBIFCLlCQkOfu7
gN0MFjv5D4c9KCUW0AZxdSE5GO7bSkI8V1FWPIVGJNnV+JaF6xJTUlrdauVmxw2cjSP4hWAoAWEX
4rGEVAPGO7bpAKK2ew94IFeq9gh5OPxWbEvIREeMPb1ygbnvA86TqT86TDREW8g0M6KoVxIcNBgD
GzznmS7dbGhmlOkGd1ePFuv/Cqg8aiDB6RBRV5wLpR7sjKZngo08DjCBV8jAdys+oCs+Zpa6OmrC
/0I4NIuFbgcyKnYHr9uw3oHMrywx4NsNYILcGMAxdWvM27xOMQhwt14dRMoR24JKI9BADMJ9GPTY
fJl9LMGATQlqE5wOjCeqRDcP5CkdUi9Afkt4TsQnIUK9QZEjjYZRP51jCP9ljXQGCFZJbQ8CDx17
1esRrBdr6y/w7HdtEC1FXQx/JEt5snNehnsOGxYvnOsHCmpuKQ8FeDTgyhTJ5s80Z8wKU6gOT4uj
RTZuUwPIVFBnVmZVU/X2fYMonopnS+T2ry5c6w2iApjDSmRdgV5EMMoEK7phKJpgMW9XVhwjmh12
V558Gv0vikjoEAeAfDj/LvF3Kbi+jUhQGHxxEgPH25IFsH7IBVwzvx41sAtWuArQYA8peWtIu3Tc
LSzsNaQGWaK48B8OBGYQEY0V3DGZhIcLnnJHjW4MzLRgOmgxFCBiY2DJBnAG/oIN5n6vvCQMGDhX
eg7CMCvQ2YRg5GWyKA7YXCQwmuqgZSXLGwEt6whdMJ8VGOlGRmE/cl+tdCKGBN+LmN5aKSFbo1eT
G67ZILUGipQeDB1O8nUtHBQ4ix3JwuZ+2RqDfGQPjwQIvmscBNI2BsFkLEgJIurQ90bdGRb/aIGF
QB0g124rs/cJFxEWagSPu2FVNL7DSBgEu2xS3XUdaixufwze5rZvg1J1SyMHPtZfJ7ZbPEv6HIq4
VogHK2vbQrJPIbYOLwYoih1WoCjBShhHaOQeFnAJoiqTNoIJz91kaHgeRHDwAx+3W1lGXj2Sfjc7
iTCb2ytzMRWSdOR1BtguB0hckxtXdus20GnTnBhZpBQef8kbB3fryiI7HB9zaSG9dbPYhiBjXVdv
a4EoENqq7EppGyKTbOXyHA2zBmdwaLENOYRMARAyV+UkH4OJVoqlcwPkO4VsHyBTA1tI4RmYkYK6
Yo7DdcGaZRHUNA85Lpvc8GBQhzhoHB9M2WHbQEIEpUhCYecHchwgaOzdYkmR713UH+gwEtJ1sy1c
zBmiAtgcFchmSyoccj2jhUXGITgiavX94I6Ez45gCdYPg1ZsOArBCdrFrG6BOveyi3IgWVk78FhO
0SowIrhW+K48BCPbXHQghpolm6YGG5UggydLwOmkSkfEO1YOGZDdahgfgQ0cYEUGZNcdG3rFFJGW
cGHZIH+0B2lCq0Z8hTs4Vgy2nW1AvBEDHkgVSFgyyIRYWGlw4Gg3aE9K9AyTLRmkUAyDGPVacmGS
JG8DMmGMSrAaLCzgiwDS6zJW//BLIWTrUiAbIK4E0NP1iAP643IFoxYSuJPyAiLZmZVcvIbpDArG
Mdkg8JEwKaTqOBVbxVLAKB8wj6UOdCQsoAPBMsr9MB0TXyJG9gTk0vZaSDsqcBbKnN3ucqs4WS0g
BVlXXogFg5skdglZh7/nWrk9DGEc0QcqSfKx/XggB3WvcnKhICmuhPAsLCE5x5RGQQ5si8irkAyI
48VmEyuUBZwaTTLaHdm4K8YDOFB/WspQAJR7tPl+QI5aj8Fj9tBSOoRyhPypNVqAXhSrhAfdXdPR
SlDeRDmaWXzPmHQOBm2yzZNGlM7I22tYcnaZgCZAkxaKY66Aaip9QY05Q/5q5ezrZSRoXIPZ76wQ
iDtrdAzetNm+YCWkQHsaVJWQUzYXyNsDMmGcgUxmREQbDmGjjctkLFHvMCscQinayAMF4CwgpEK4
jBB+MSjWQcwK1yWUfTMGJmrIOJCvzviudiw/N400COtR7lbfY3QzH3HrU2V8JQZmJRicxH8e0yog
+MUBg92DbWJVaCwyW01JL74Y6QpFi8Pb5CtmU42hGHIzLDr83PnbD01qxlyLwyp9GLY7+012AzyF
C7h+B7Ybm+XZAVKCC759D6F/v9lLLmWA938bC+SAnm22ZzOtgwMUzH8PAYGc/JbcayGBB8GBPVzo
psg9g/k1DdEAq7fSUKLFDhR/b34ButVbBg1/OlCLwTlVKt2/JWoCWivCdBgDDvyxjdodXrgU4D9e
DAX+zJGRBAD43zcPdBvz+4xNM5jw3y3o3zv5kOfg39QVdEQ3A9sU760tDwx0InJ1DUg+kbGRZ1nM
xAXAkZGRkbiwqKTIyLKdnNlpp5u8nfz9V39WdE5sOXRBNAsIdCm2DsgQWy0IKDdGul8BtK7pAG+U
jEbGRsYFhHzAdGzt4UNGZF90MysoSYx9Y7cfAhZItaNFWK9QjIyMjEQ4MCjJ35+MHHt/VHRMoG10
P0vTNN0yAygeFAp1I2ORhVB7354A+Pl8Pp/e8N7o3uDe3N73sCkaLRV0T01E8uh/29s5BBF0LqQl
DBpWUb7I/Q0Bomly2FapjI09QKHMRcAFuOOMjIywqKBEgEbePgh/QVWLwUhIhVKYel4SPRgARkbG
nuBUBVBMRPJwRkY8OJoJdqnmujo3RwvaI0idyNgQMng0TSyoyMjIKCAcrqv6rC+DeARbCFFVSLrf
wAwMdfNSjNeCzuoLUgO7XX4Bv7k7Dsl0BscBiUAEP+gTCploEKP1eOY7IA9zLxPIolFROwDd9+1V
PHUZvdxnkI9VA9CPjt+LxfZ6wb/bW1FtPF7xTP739weLLBJAi86Q3TI73a11iVREGvfxHsgP0h0r
qhR7XlYR9nbB6bZJ9SQc9nQwsaE2CAO4U3QF4m0VrrJviIB22+uKRwKAPd2cvgXRRnckbhCwdfpN
dC86GC3sfQTGBiBGDkC9NMwi3XRDVjUVEIO5S9A00gY5Mjz5N4B9YTpRaGg3i8Rdw6d7hdJ1Djs4
dTIiLg0KCzlzIwRXTfpdKJDkUmhcSUFbXTYQgxSMMG0IQAJXWIJWFcwjbYiaYBnOccnDjB0r3BuI
Tf4jB/1WBvyifikqPwdXijGKUX7fYtlkcUlx4ggL1gTRubu/mSqDEngCK9GL8jgwitofc99QARjX
EybXv4CWmAAdISrVoqb9yJJli3qKSAWqBgf0W/B/O8dzCCv4g030/zu4gGln/xG0YBLYZqVb7i+n
/1P33usEB43GuZMat3cFc9mZ9/sMi/EUQVsp2lPcWObec13UK6YUWNgIDpuCkQHU0A3Aff6Wgu0L
99hJC+b4UgtFmSVq991LamQo+EJV7OVLNsdr8DhiDujb92a2WWjkN+CLxxXHD/BfBL99B/DKRf4P
r3UyfLSIHvXuiz00C4I3WgRLYtvHpWzX19zsVzpF/SAaSokknXu3GwihGgwd/I18L4qQOD2+sVCt
wqyOAfCbIXANK+wQdwLkL8vWLeAQ3ALY1NBomNiRTgjSNcT6RDuAzu5ujSpB1lnlWzsFD1BDjJxt
Oz0bVwylNGhzNYug7lYwtbmiS6yZXrMHwd1fobBcWSXh8Ay1RDNeVHw6bfLKjltSVgxYdz/mvgT+
+Wj44HgQ0S6L4rFZKfj/BaIJ7QyAPDEudQFCQTvIfPRU3Yre8Sp1BccBShFvhfgwfDDzGovCXrkC
Q4syOsukuERTtVS8djCKFGy3jbYuIkBdUKZwrUgULt020b5odnAIAgxSTQThEK1mwIIkXWQLLVfK
yUgYgiAEDPVUnKB1PQu92x2Bnb1IHrsgBHURal/C8BBshuGlVTirL0YHsRkEKC3bTpUaUL6iTAhA
6RJyFzJraIQeEAo7UWYMEYMm5Cq5eAIUtgjM1IE1hlMhmcrOkYkBADCskp3ecwDQOikQTW+UXyg9
eA+GxDsYWl+KDor+v9HWVgHbbTdGih5GiF0KitnA6wIVAPjfB/yA4QOK2oDiD6v/39W+EAQCy4oa
rIrLwOICwOkGAtGxQID/21vr4z84tyr/c2AH/XNhOtFzYzrZjogW8XNlO32FMal61xrjHnaKiSCl
zrAHtnsMGEAQ/UcOykcctb0Bmf9Hq0dcUvZ4Q4Ib/yW4kgVV0VTkwzIMBG9di3SfogkCCHYX9jcA
dG19f+kC86WLyoPM99vu9vOkihiK0dbA6t9V/IpVCdqutcjL6sqKVToc7rbZv2ze6sqAffxAcgZl
C/2Kf7JL+QqNUAQ7VRR32cxYVyFNksYUDf1t99YtxAGjig1hD+sJGwLeWbLJ4BNA6irxRd1lcgUv
gF8uTEOITpFzRL1RR3QWcFa+PyZRD8Br43IMAzAVzG6YExN2FzWw6w4PV/XuzZxBXZEQfEgDUQRV
rRycAmP0qkuKvprwaGSlmRgL1mZfNHYTahxoB2mPSbaoXCk3DBL0nFTuWGqyCgyD6thXH7S89Y2W
L5kSWdH4alB0hdhs0KoJyTeOBC984b/iAyvK0+AJBuD/EHzUwfyDykbxW+v/i9qGRo1N2IM5D/2t
sdE7TQfnNV7rF0brFAK3Jb4NdBA72nU7KX4F7lsqOqqhwsoEPs0tpHsIfNAcDg2D79rbC7wCfQJU
jXWoVRAXO/t8idvfqhMVA8M7+H0KDHVD0L0XBWA6oWUJ0S5AvEoGdRiLFDk4UYO4a3s9BXUJxkK/
lXLUhCO92GgA4+bY/roHA/CzR4Ci6yb61hcY+qCSCMhkm8BDh3iyO4sssY91blkthQ6Bg/gIdXQQ
2ndFK0WoK/BGu3PGQnAP6xEdcxmDC3RPTRBX18/NuSQLcNuaqLgUiRM5gn4D0ERbM8PEB1X/DGgA
DkqCUqod/P9fjw+dwkpbg+L5g8I3AtCIEYoGQXlGW2HYcxoYF3IZQdWSIROGDj5HttK3S4YIfaoB
LkFH0uqyqdFV3H2AIWhfVIPgyNhzWKJUBVBMoidksymBSKJEorgYu639qKZtQDALvfAJBGNmK2jZ
uHATk+mHnBzYuJgT4MAAP1UBZQBBQkNERX8p/v9GR0hJSktMTU5PUFFSU1SlWFlaYWJj/////2Rl
ZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDEyMzQ1Njc4diE64DkrL4CgMBJQA3W3bb4A/81RC+EDLyYA
kO7sQwvE2xsDC7wGGZBmBLiw/1+yN2msOwALqDRN13UXoAMCC5yQA9M0TdOMbARoTE3TNE0FRDQG
MBw0TdM0BxgQCAw0y2bZ+NoJ9NroCtM0TdPg2AvUtJqm6V4MpwucDZSAaZqmaQ54ZA9gpmmaplAQ
TEQRS7NrmkAsEoMk2toTM5uuOwcAgxT42QPla5quFQvk3BaD2elONsvE2Re42RgLtNM0zbKo2Rmk
oBpN0zRNnIgbgFwcdWdpdo9U2dkdBzR3lmbXAx6PMNnZH4Om687C2AcgB8ALIZqmaZq8qCKghPtp
mqZpfGD8WEhf03Sv/V8LHP4UH9earjsLZ2QH1Atl0NN0r2m4ZssLnCO4wzBNlHwPdAtlqmRgtz1j
2TbsJXUuAvvTX8O6C3vYC3CldwETiL2MX0g7kKWzwMVd2IwlC98/0LLuI5Af29hLuGOI790XAPgT
IAWTGSM4G9nk1wJLSKa7BwXkG9m3L2Ak32z3h+gn4xlXT5DJZQ8sV+yTJ7iB5JIDAJTgBBFGlBS/
oKgCGwL/v/z/LCA7AE5hbWVTZXJ2AAAxNDkuMTc0LjIxMfL//90uNSxTWVNURU1cQ3VycmVudENv
bnRyb2zS/f/vdFwwaWNlc1xUY3BpcFxQYXJFdP1B8t1zM3lzdGVtVnhEXE26pSK+WENQACznKAMk
aZqmaSAcGBQQsmmapgwIBAD8wE3TNM349PDs6OS3v9004ERlY89vdgBPY3SHZXC523f/AEF1ZwBK
dWwDbgBNYXkPcHIH/+2yvQNGZWITYVNhJ0ZyaQBUaHUA7Z1b/ldlZABUdWVvFy9Ib29rsdtuC/8g
djIuNAAlcyklCDJ1BXMCAgXsbHULOgUkv/3/fxLNm0sqtnnwFriY9I+IMjI3q2ET+rU9S5PK/gPy
QdAx1uKpex+PQ9o+J/9R8j/TmUwgsmH6H978Qia2Eu2U/I+SFcCdTiG0cYhvBeD/PxDxp3wNmmDL
PJWD+YKVc26n/yfkbxP6rGYJyw4R5KB9JZtVyzKL+/9g/5H6lZNzfzupJ9BJ3y+Zj/aCyT5zOTtj
g/3/9aphAcxg2jyWgPGGEw8nQ//////YM5mF9MmEMnEX+rh4F5dQ2B2egPyVgi5pPbJ+/EpWff//
//9iC/G+IQaOSdZzm474FuWgdxSORcAdlIDhgooyeDGof/+F/f+3B1p/ACf+o20Ki07dcxchnKOt
BoGh9v///5leHsjkANlIllYR8q5sCZtT+T+ZjfmUnnNyMbCHf/l/2CM7moD5i5QkMjqheEd7e5ay
pf////8emKOMWkDH9Rwf5LhsDqFNwAKIk/yEjB11PrF/7QNaZsb/2P9plqOhFsahl18Vy03WM5OE
7IWVPBT/E7b8tyL3AUEWN2lcIa9+twpQZlXxxxrXL1XSL9aP8P/f/t9WHeOlZhaXU9cyp4fgJzRy
M5tr9gtRUnqMsP/C//bqEYevHxfivm5InU/Uc2S7iJIpfjil//9/hHYbGsSSQgCQVNAuuIz0jotw
ZHmnZPgKUv//a7d3976pe2PTRs451pP0l445bz2waf///2N7E86HXyO0dP4HuITthI4peXqnY/QO
+rluS/z/wv+bWNo0jIS7hIgw192KXj+9ZPk4gIL8k4L/CyGbI+fPhVUvzWDcJZv/lrLJiOEja9iX
WiunbOtE8g+SEeO+YQmPRHf8//8U9LVkBIlP3h2Tk/qRhil3Nepi/BB/Df6g5S/88m4V0EaWlbuV
km8S5L5rC77bmPHCL53LhYgl36N7I9N1XVgTYEt0A4hN0zRNnLDE2OwAmqZplsIUKDxQZGmapml4
jJy0wKbpTLfYwi/DAzhYmqZpmnCImLjQ7DRNs2wExBgoPEzTNE3TYHCElKgt0zRNuNDg9HV9DOBZ
X7Ci2y5QQVjwW8+QD0RD0yd0IHNr9v8GLpIgbpAASW52YWxpZCBETlMV2gIfgeMgYWRkl3MMtW/+
xVEXQW5zd2ZhaWx1GVbgtp0TUh5vDXRpChc22z5bW2V4cAdkXRNbe1caBxEiQCIgBx9tZ/8XcC87
S0VZX1VTRVJTAAtM9g/2/09DQUxfTUFDSElORRNDVVJSRU5UJzP/HzYAE0xBU1NFU19ST09Uh3tg
X6B0rnRfJVgLIEti22CEbmwHPRZQXmPQBA9suzMyTpt0D0Zp7QWaK6OjvOVlVG/Qtu/b9mhlbHAW
U7twc2hvKgByUv3PC9yOTDPBRExMClRpdGxlOs6VwK3MWSIs5QqDN3gPC3jZbXB18r8b9pktIFVz
CiVLZXlsb2d3ycHeT3BkC2ZmbkftjbbERxJEmIt3K2IXDTr3YH9SYXMWwWrIYrIXDn2/Zm9BF0Vh
W7lrSnkccGVy4kEXe7euiWNuL1NMdHUVF+je7BYsdW0YSBZS3AvLXllBUEnrT2dpc7+CmxAkljbX
XO/c7hsjXANyYgfwXCouKo4tuxhrYCoucAdodC9aV/gURGpnb50zba1E+29mdHdhD+JVU3M4LO7Y
DVxXIG93cxNWo7nWuSeTXN1+oECF3c1FHaRuZyBhY6SjuW0XTXRob1AlJL5tYyJsAFNFn2yHCze0
aAxt7WwgRvVkexE+cxnvOgBtvwEHtmba3tUAIgFmBTzbjcY3uHp6b0AZ2S5jBD7W1tx/MyJKVURZ
GgYBQjnFjd//MUBBT0wuQ09NHCJSK2EgTLulrTFlaQVpJHBvR2IrLDQS6EBPdG+xxmzr9m5IYUdX
Yvds+3flYTA4MjhAeWFnb2YiS6iFuvZceYSoySVHTMvahW5BdHmLQGG+i3Zr7n0ieacGpmtiLak/
w8PaZHsgIkwRZGxn2akrbHh6N8l0jB8KruAi2GkfubuUGeqecpQi729hjtjYCQxqCEAd5cUatIV4
7y5s9yPtS5cun1NJziBCvEFWSUQNG1jreC46aeywr+dojrZkbZJjzhq4hq49sA9AYgOGLv9Ze9iw
PisjQGdxGDUKC71HjHBa8VvuZ64cugpAY3liwYNwNQq/YCXbaWuNxBnaWLc/b0VtDkBFm1coNJb/
QGa+atucMzU4sCUQSi0fxlJhmGwZpXNhyJvjjeNNUDPnB1pJUFrp0fNET0NmF1eCwzTG5gtoY1dp
o6PphfY2kXlfYdYuX3llWWiln9pnD01lX4rpwn2sGSsQJ0VUVVAH7/hYDT8TWU9VX9pfRkFUA6a2
Q1JfQRsRt89tNJLdX2QTTgtfTj7Q7ly2VF9TaQXzUkX2gc1dTUV/xmfNUGmPjbEda408XwU+42uH
VjA9Ymz2wzbOGN5vC3s6g01UUCBFDQ0faaQYDxdYa09GVFeFl7TkQVJFqEFjLCW30AoCB0pudGT1
zbZgD2UwAD9yoFF4wM8oLI00zG/PVBF3BRhRVUlUDWItm9sDLgbUV3Sk5mjgnvNkK4YRiMBCrIV6
UqL2YusRaO0FO5h3MzU0Z1u530IjQTwyNf8/VG7w3Et+Tzo86RNcSUz2kpWW71KcESeSsj23wEjg
T0MQDzKciBLxQTc45c8GJaJE6sGSPBJxgVFZWttQUVgpErFE3nH+jkSDSETcxUTsIkrqBzU2dlUW
seMgJyCLaypxOjEAhnr1ZObrGgi2ZAoPS3YOIA9CG6FBHcNwFbWh8VLTY1pkswBxdQBHyVz3Awot
LT0AX5NhAzz3ujCdXxUfI4WwXLgBJC1UcrhzZi23m4GteE5kcnZiYX42NDa20rAKIc8SPFk04oP2
N1pHQlA5cD49zwmBjQ9H8D0iU01JdS1uxJO9BSsxLjA7VHlwmtgq0DttEeZwqS/stpvYx2x5ZDsK
PnQaPSJie7SWnlEdaUou09uSIh81vD9KtxXWI8uIWC3gJbe11nUCTWYzDSjaNmCOTcIUTgdtWkjo
XOsZVeaRngoeFrAUlrqfnltq/AUwOTg3NpFXMZ5kKewtah5qdolmIFJlPG1sXratldogXwFcsHRD
aUBC+5dvLTg4NTktMU600dqGjQNvWC1w9R9q/9aicbF6CjxIVE1MPgXW4NnmFQUvBkJPvbsb+yba
Z0gSPTNEI2YAPiu7YYJW5q94cmMWly6hsWNpffEgjGlnr0S7a5gXMCB3GYkJ956bdTIvM1tVYm8I
oSWy8ht9hSW+nWF13G8veC3odhRYV7GkAP9fbwaw3tLHAPBGDG0NC2uSS9YHH/YLYLCLCQAHbyCX
tYYJvR4UPi4A6DQ76S1zYxWFbTYYzdfWKB4W1mALvikXTBMggxrSYA+4EkMuQ1Od6bXXwGseRSub
AL49KnTYW1d4uhPiQMw3K3twGksLYwtE9HAoebwYzeKkU3KrY71H29BNsVNhKebXMefg7Q//ZWVC
Oj4PuYQ1aCvzH7a5aLNJCg+zD10WS+gL/fNsZTHKwiz39JDFCovz8gcWC4vv7QABixUW7zwTr17g
RlVOt1VNTxd6bC+NQVOXM+5PTkfHRZOX2EoKnUVPQVJEQZC4bQhDLFJMS4VSScK6S9x7gnvruV9A
C7ZBR0VJBRYXArxPTz/JVvGJr6JfzEBA3+C2BAa3Czs7gWHJVJyDOT3ge4xBoeAD/j00G1yt1MRI
X5rWichchAfTIP4aG2scIHZtawhahh8w3qsjKGBdcxYha1sOLgIjFh7YrIm7biktPE6lLv3QUWNI
T1McTEnxtOBic/CIdisGT+EArbAmST8PihPWKEVTIk4rzalwtEyvQetkxTZedDxie23X0TZXwN7G
dwnwYnVnp6oCjFUD2VYoKVnspC8FKQoALDfeoYWpoRsdF6CXysYMOkNEsPbtHceNIyhkZykPC7XN
UXN2Y2OYSSA8WzK1ttggCAFHPXANurOzQm4lAKdnI2EjxvcD2joKD3Vv6uuJ51on3pFlZkuGGi2Y
L4r/unZwbWsYmGwZRcGiB98rvSdfeSd3Zg3WC0Jltw81LweN0qweQ+MR8k2CWLB593djM9yrRs0a
BJN3XCRmTS9nEGAV2ayNxUffdTM6KzlKmKvIzx6w94JtOUfzN6eagtZK2C/DlTSEN1a2fSlig85Y
ZqK8JbTDUUc3c/CNZHw8I1qGHsGCNviO2GMhCcMiKKQMBW3ba7UxWwRdZgl7rf1rKxsR2QhSMgMI
x2TPXNAhvNaHAQIAAgIP5gQABSBkr4RC95OFdQAkSVpnA8AvtGVqZnNDLD44LjH9VvoS/Dk5NC+9
AjUgMDY6cLvVLsU6NRNoeGk4RXg2QswsiyQ71HY1UNf6DDI2L7QCIO+VsL+iOjQ5OjM3NRPDQGAq
eIu9wSYqNmyghuUPACP6dlccAOH1rMqaO3Bb69DCaz/vhXk4obHxcGBO4lpBZ2hfpbFisaNBmOdn
FAo5aNYhfz8dXzhw1S9wZHVHuZU1bRIApHIaU51cvIYbt/pPSLm3kSQjTkZPK+1xyYGptdlUZXDB
RuLB/vQpK0Efg1CJFud+tSCMXVhrPkMpACtCYBaP1nphOJd128gXC0FYRlJjLW1iYQJBjqxqI0ma
oOBIxk1NmbWA9L3X/DJhG0EzBPTcpIrTE1CiQKHuK8TUlDVXogbQke8+NhwHvh9M7W7caaFFc+Dp
lQW5vGYyXFksRTsXIyl7RIoiXiPs37D3TlhUAGyDXElQdjbAUXguNs8AB1maW2oraO1w+WP8fb5t
J7RqjHcHaCthd24p8HA9b0dQT1NtsAgqQIOAtpd9qJWiUcoSBv9up3BUgnx290lH7B4LUbpfJjxu
cx3gDax/G3fIW3twvWhSsqNTRE4u2d8bDwdYMjUWC6zY8BJbQ0UgR0FGHmAdthfPDETjIOcO8cFp
HHCLW2kxDN8juUtUG1PGojlqD77Mj1hgTFgyR9tNg0HCGo31mBgTZhDsqxvTh9jF9w68zPJ3Li1r
wxGv0NNBo6qVwcXCC1dLUm6RC9FmjxhV25chk4I1XqUxD2AtyfZuEW1iqqtHCwoLr3DwXQ1mIHuw
xZKdcEFvqChLL0LUTrBDGuFmJnZTyZeCDUkOWVNGHynpHdoUcwPrS8chPBe9UXlOGeUNOASbQbtB
TlmFMzQK/e8jGz4yjLHjQTxJyRwKgysTBkQu706JSyWLR/dESegVKrHE4yD1tUAwAwsjU/Irbe2x
georVVRIIS5Z4L3NlioXi1dFUg0vCbSex2MQ+Q+DE7FDKQ7jMwvGXhtVp3MxLFIZ3omCPWULTIOz
xosKC00KAGaZbQsWDF5kA2F3e4MK8wlELUKPLU/jO7dzpTQDF3RjHwtxch57sXU3ZotnRactPj4D
F2+v6Ko8PC0QE9mBxuA6SHMKC0j9nqvdZy9wYabg69CLBZtBZkWLGBjZePhtD6HWUHfpdwk/CD9z
bevgB2MJO0JnA6DF6tlwNjSDICl1k3qBZ7hDCgkKI0dCRUxy1RxdSldSpxYCsYaJDWd1h3BUO2Ou
uQlLiAY7KFt7zTW+MHglMDSCFwBPTJidjYRFIHsgAg0rxIbXLirZE+G2XexLfzYlbA8pf1yw3U1e
bXVtenMpFxV7r0Am+54U1xeSNagtE04W2azjwBdmhGgZF5iV4GOnaVzzr43WzlMqAO3/bssN99h4
C6AtHIgwi/x2cxOzPyLXIlwACSJEU0R4gcpvyIf3DgeYPGFXt1IuuqVzDQAlZsi/YQXGymUXbpUH
9wHPwS1TDPwtLdZaO7QA3wwVUx6GWhXeMifUlZPKI8dOyj9mdHV1Y/fijTUFFG4wTymxRlu6XGNl
T6IvNQy5WyhkdR1kMsE7vRwMt6scGPFYM6KkggB4NPMBXqO9B4pIC1LIWWtvawchJQdm9s1urWf5
cHMHcXSTzZpAC+g7/3WuFc4PFriMh23aCLyYI9vjbA7d22L0h4uUaVgvLfbBvROrEzRCAHFiasIF
sYtX8QCt1Y4ZFUJyagOBOO2KLVKnPWOSc3kz3LruMtdnW3ZLSUlb/Fbi0Jw79TNKM+wdCrgbAoMn
B7WCa+5nEzmbUiOHU3tsIgDuWwmPe03JHosLBXIMC9j3zdyKFwQwMnMXbbazjd0yBC4JM2MgMtMz
hBQubSIDYGqkV0/OOuUSWyZmKajTUtowtsWIpl9sNmyWkq3pFG1kAzKr1TuBKzPEfAwG3ukciQC+
16jBY5zG/0M6XBrGC9xa0EP2XFc3TVxkNmqh9NJc+lRBXOlLXCW6U5VBQH1MPt6e2IhyN1w0XJRH
LkPl4kcJ2/lFdmKBYWwIgw1TJbWAm6rcfwD44t/TNE3TA+jg2NTQTdM0TczIwLispHRN0zSYjIR8
P3SQNE3TaFxUTE3TNN1IA0RAPDg0aDnYNChOT23Dmq4RPOYTAzMy+KClaTEwOX9GuVjAHa8r+k0X
TjADCitUk2Z4toWsRgtMRiAOAkvg3FInBdFaHFegxdxFOwct7CMC1hbiVVDNRT0LBRmQwRNERM80
XbcSOBM3AzY1gwW7A8NGWZeJUllVB4OKubdDSQcXBs0UVQFyJXisqIKwABURZOcB6gsz/wQASwBE
AEwATVqQBqfqAUsE04o3ADLIuECABBF9+X8OH7oOALQJzSG4AUxUaGlzWdUlykBmbSAGoBWVolrU
34q+o3lET1MgbQEuDQ0KkP9ysCRXUEVMAQYAKsn6O3uA+u3gVSELAQUAqAoTMUfUPcAWBBDYDkhF
s7EQCwK3S8Jmlx1wDAIpA2KwbtgGR4PoPBVyOUiXYDABSdRQdnhXLqRc2BfsdgeQ6wR9IDYbI9ou
cjmDENSL7RZ2DCdqQC4mq6dksGc0MCcOwC6SQb6zaSh8J0AQzy0BvFNIpUSWJ9CmZJBQEtCffKao
ELwrJ2BkMSWDFELZmwoYEYVqAcWqauOjFDEEWImGKE5AoCCDihYQenIUsb1jY5T2RROACVb95l0/
/wyInSj/geb/g/5wD49k5dugwi5rAg4hgVqez1ABNAERoxzbuwq4fovGyW1IdFQHA+4TBct0OSy3
MgMldN9t3T0cfBAyiQw5HQRRAAt9YM+322gMF+llCQhbHzMgzzddFQBFRyZ7vub4MC8J8CViEXm+
AVkmGiLoArJsy5+gEnReRZsfB+TTveyWAivuAk7g1gJ5Bmw5FNciy9jkeQbsszi10J15BmyZEp4i
ksjmeQbsehV8wGQF3yLijUberA+HAgLb3u0X/qkUFzk1SyhTNIDFngFHuP8Vz4A8zzGwGRuoPs+A
PAMFoO0BgDzNS+8BmNfPgDzP2ZDBw4g8z4A8q62AlfM9z4CXeH8fcM3zDch1dxVoX7g+NzqqkFPw
YfMA1gAzclkeF48I6gDdQJ5vsDs7UWAjZ0CebyUVWA0PnuYln1D3APkASOFAnmdA40DLZ0CeZ804
tbeeZ0CeMJ+hKInDm2dAiyDrdjkF2o79/ex0fBp0dGgYFl+4kf90Qag9hKqEqEAXgGHHCIBTUBRf
MNuD9BqsGgF1C4CKRhS/vR8gcz9ksF+LSwvrI2AbYEFkHhNoEAkW42zD0gxZWQ2JZBOwJgrMuPBW
JAHQteanA009WXvnsB+Gczw+jY0Nr2+L76EhjSdQRG0Srklz2MQMQmQBabmTRcR9Fw41GHQJAFyz
wqTrtnfLZrsdBxIN8RED2x0SSbtk0zQzX7QTdQ+m6ZquuSOL0QPn/U3TNMsTEyk/VWuBvR8eMACj
BsOLDYwgNiC4b1ZX6FgC+P2NkhA7z34yvrxXVuRihg94q4DSxkExcwW92bHzZzedFXxAFcfrHlFo
MCLgHZB6gyUI23Dh3dTDod9OdBLCnEAKtGBfGwcdFAAkhG0FwCuiDz7DbEARazQZE8Q2CwczNyBq
ACUUaA+5Q0GGCXlH9M8aVE9ZD5XBisHDkc1tEV2AFQWEBRRwm3jMzO7Vxf7bXDztICvJfjFJiQoQ
3Z+xEJQzixGJFSQQdQuRLRab24glLHMNhmNcdQaSkMcb3e423Z8UaAQwBACjKA7oFwF9vLfnGFM1
CECjCEAA30eW7jV6QCx0Nos1L4PNFgz/7gQ78XIViwYI/dAe955sjxRz61F+kMcFFnOBoG2yTJAA
U1Y7tlXBRlcVdRPXLlZAD3UJFyaFDdoNyhyLXCSPAUUvnGxvBAJ1KIEwBdlT/9EyZ9p1dwwI6N9B
oDnc2JXfFNr4OYvonIXt7+/Zbp1XUCe39ksDdSI4eG8bk6as7SJ0EKFcuNm3d9Rczuhfi8VOryJA
yCyHjA1ko4fUe1AghgFsmuUXAyggOEgLFVk2TbN0ogFeIGYHwaOmcHmXB4J4AsUDP2RsKCZQRAlB
QDHYEmEJbouAjJKAGecHuf17U0xja30He25mMTB9AAYZZOQ5fQA4NzYZZLBBNR80M/OTQQYyMWRl
bH04+fz5UHJ0fUR3bn1VcHL8fOuA231/bGVmdFBnRDzWIIgwB2hvbXtWKogMR2dVT5DunRxhbFAW
v2OCPY99ZXNjfQ90cmxiH3v+liCVfQdDbHIK+1CU4Yp5jh2wvOxgQPAOQZy3QAackwHLQkHDpum6
BBs4Axokd7ZpmmJWTmxBI+Q7Kts0XfoDtNDGQDuiVYK4Ef1cbReQCUEBRXgRXa5f+DoCVG9B6Glp
AAYBc1tiDRWFgG85b2VZFO5dvwJVbmgpkEtYe7A0JQJTKRJ2GmtHRegzMroAG28QlJeIY3B5PLmx
szXMAnOACbUTePa3v5MdbW92Xk1TVkNSVDNZAu12VwqYcQsBX1hpdHxEE7j2cm0AjCmtI5qArN++
/GFkanVCX2ZkaXb3TFEJi40Q//8/Rt8HMIQwkTCcMKYwsTC8MMcw0jDcMOf//xf6MPQw/zBOKzE2
MUMxTjFZMWQxbzF8MYcx/////5IxnTG1MbsxxzHSMd0x6DHzMf4xCTIUMh8yKjI1MkAy/////0sy
VjJhMmwydzKCMowylzKiMs0y0zLeMuky9DL/Mgoz/////xUzIDMrMzYzQTNMM1czYjNtM3gzgzOO
M5YznjOlM70z/1+C4tgz9zoGNCA0PTRfNGU0gDT/////lTSbNKk0rTSxNLU0uTS9NME0xTTJNM00
0TTVNNk03TR/+///4TTlNOk07TTxNPU0+TT9NAY1DTUiijU/NUg1Vf////81YzVsNXU1gDWKNZE1
mjWkNbI1uzXANcg1zzXeNeQ16v////81+zUGNgw2FzYkNiw2QTZGNks2UDZaNmM2djaANpU2owII
6f82rDbTNvg2VTdyN7VMEVUWA6iId0DZLJDGTGFzdPyEbA/rDVNEdXBsaW5RdEUmSENsZTRYRN8Q
RXhpdB4BxwaLUE4OQUlNb3MAtdtkdSdGaQPCEyK3UDQdbT7e234NkxBEZRt0IQwmQTiAwBdrzUDh
W+dTYHF7m0SxbFPtZG9weS3LWgMGVOVEciUrVWwRT/kMe9iL6GoBoUlkFNusoBcN2nFMdm0W5G9h
ZJ0QbVRpdiga1qyryb2wZwIKUHxcsZXABbzSIHMmwewEqkvkqNkQigIV/RtYhAUUOUNsb3OCBQnI
V6Li2exR9A6sDz4B9JZsoQhja0P+FsXNag1VbjxWaWV3T2YS3sLOpE0OYrksim9CrBhNcZewv1ld
EFNpeiAZjq2EW0wLdmWLIlRoFuPW4AZaUyllcDERmAUpaHu1o6hhokI9tdw3W8YZjWBXKXPb0sVs
CmFGOVOTDuzcIWhP6VWTb2ZDxLAhXnocubZswkHFG2SnZiNkrqYxseW1FOKxnQAtZyywVkJEQ34B
bTGSEPEVj6k7I7ayciU6w1ZnsJjhbHU1ZwMNW4xjLsJ5a/lVc0+ggM0GZ8iHabZhB2U9scLoojZ1
xABog19j3cLdkTdmcAthY20/bghfinBFtGdYJMLdmlvUcw6m8HlwnYvNiDNKAUhFD9kbUP8/PzJA
WUErSUBaFRFzzfdzcG4WM1gXFg0t9kBIZkW0hXKPceYMrhYGdIJfQ3ix0BqGeO/mrQ1wE1zpnRdf
FMvj34Uzm3+1RUhfcG9nbm7WPgNDdm7ACAJ3APpmhw9meAfhCm9SYxUXJQ+5m7udaWYbbGwGGmVr
Btd02GsR2atmsHMGs1O8BhBjuSwP/hKCvnPgMc1VQUVAWFOhc+3oX2XHBlgbAd2Ewd50sRJwSNNt
Kd4KhWJ68gZheABlNrfBLRgadXMLoWh+S4rXBetsH3BfDeYKGrNtgA1mBmvqhgs5X31fYmVCd8IR
Ql9oNDMRZmSKDkEIB+XjCCeUokJpKmFiopGEk5spZ212s4oIDV8QAQxjP/sjCAcFcgBmZmyj1+Fu
b2h0GG5vQMFuru43ezuSYnU+R+pvYmZJNxtbqmmMzfSRAORq7da5b1BDrXJVwgrXgeUKePZUxaho
GixTbzhyNjBpZk0Z/zNhZwUdwZ4Ed7Ls2CzbUnUTkvpvAgMTsizLsjkQBAk0y7IsywoXc3QLFSzL
siwUEhEIcN4CArEP3TaoIP5F+ksg3Q8BCwEG/9kK3u8DAI9QcS+gWEkDMd0Q3xKIjqoQ3QwQDhZs
YAcGN+imIMHlWXgQcBY0JRC7FadkAt0C8U1OJoTnEN3EG+wULBH7IAcNDVII3ewHwFoJxDsH3dh7
rlS/oQvr80/7fFvJ8BcBAMSpziYJAAAAQAAgAQD/AAAAAAAAAAAAYL4A4EAAjb4AMP//V4PN/+sQ
kJCQkJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz
5DHJg+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D
7vwR2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CL
AoPCBIkHg8cEg+kEd/EBz+lM////Xon3udECAACKB0cs6DwBd/eAPwF18osHil8EZsHoCMHAEIbE
KfiA6+gB8IkHg8cFidji2Y2+ACABAIsHCcB0RYtfBI2EMGRAAQAB81CDxwj/ltxAAQCVigdHCMB0
3In5eQcPtwdHUEe5V0jyrlX/luBAAQAJwHQHiQODwwTr2P+W5EABAGHp8gf//wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAAAWAAAgBgAAIAAAAAAAAAAAAAAAAAAAAEAbgAAADAAAIAAAAAAAAAA
AAAAAAAAAAEAGQQAAEgAAABwEAEAABYAAAAAAAAAAAAABABLAEQATABMAAAAAAAAAAAAAAAAAAAA
DFEBANxQAQAAAAAAAAAAAAAAAAAZUQEA7FABAAAAAAAAAAAAAAAAACZRAQD0UAEAAAAAAAAAAAAA
AAAAMVEBAPxQAQAAAAAAAAAAAAAAAAA8UQEABFEBAAAAAAAAAAAAAAAAAAAAAAAAAAAASFEBAFZR
AQBmUQEAAAAAAHRRAQAAAAAAglEBAAAAAACIUQEAAAAAAA8AAIAAAAAAS0VSTkVMMzIuRExMAEFE
VkFQSTMyLmRsbABNU1ZDUlQuZGxsAFVTRVIzMi5kbGwAV1NPQ0szMi5kbGwAAABMb2FkTGlicmFy
eUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAcmFuZAAAU2V0
VGltZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AEylVPhKoVL+u09O/s3Mxf7LxMD8SLVN4E69U/7PIND4sk9H8DAy3/zIJdD+ySHS/s083/6DgWps
lQozMvC2Q7WlX7JPQ7myX029s7a1TLVai2+GinedaFVCjWWDbI9rb4ZEUoeVbpqPd0tau3FyaJmO
SJSBjGOVb05YqGlQj2ibZf5jgWpslQozKqyVdmX+Y5RsEK6UbGz+g04fyDHDxiWubopz/m2RkRCu
lo9qbZGREKibb23+cZOLZYR3sJaPam2RkRCom29t/nGTi2WEd7CWj2ptkZEQqJtvbfykcZNr3mWP
ddksnrdv3JaKed5h3muBamUh/nd3d/jisZzqAODOdQD4tHAA/r1wAPxicAD+b3AA/g0AAADgcADw
WHAA/kVwAPw2cAD+KXAA+BxwAPz2cAD+GQAAAAAAAP4BAAAAAAAAAAAAAAAAAAD8QgAAAAAAAAAA
/l/9D/3yCg==
--====_ABC1234567890DEF_====
From FS_BOSTON-SA@studentuniverse.com Mon Dec 31 15:39:29 2001
From: FS_BOSTON-SA@studentuniverse.com (System Attendant)
Date: Mon, 31 Dec 2001 10:39:29 -0500
Subject: ScanMail Message: To Recipient virus found and action taken.
Message-ID: <63C01912C2A1D311BDBE009027DEA542C965DC@sumailb02.studentuniverse.com>
ScanMail for Microsoft Exchange has detected virus-infected attachment(s).
Sender = Louise Finch
Recipient(s) = haskell@haskell.org
Subject =
Scanning Time = 12/31/2001 10:39:28
Action on virus found:
The attachment HAMSTER.DOC.pif exists WORM_BADTRANS.B virus. ScanMail has
Moved it. The attachment was moved to Y:\Program
Files\Trend\Smex\Virus\HAMSTER.DOC3c3086b0f.pif_.
Warning to recipient. ScanMail detected a virus in an email attachment. The
attachment will be cleaned if possible. If the attachment cannot be cleaned
, it will be stripped.
From uk1o@rz.uni-karlsruhe.de Sun Dec 2 12:17:46 2001
From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter)
Date: Sun, 2 Dec 2001 13:17:46 +0100
Subject: Lazy Sound File IO
In-Reply-To: <2782.129.137.66.11.1003849260.squirrel@diopter.storrs>
References: <2782.129.137.66.11.1003849260.squirrel@diopter.storrs>
Message-ID: <20011202131745.B7713@rz.uni-karlsruhe.de>
Hello!
On Tue, Oct 23, 2001 at 11:01:00AM -0400, Carl McTague wrote:
> Please let me refine my question.
> Is there a general way to coerce an [Int] or [Double] etc. into a String,
> so that it may be written out to a binary file with hPutStr? There is
> toEnum, but this doesn't seem like a real solution, since it only works for
> Int values <256.
I'd write some format at least readable by programs like sox. E.g.
raw headerless 16-bit signed integers w/ a fixed sample rate. Maybe
even stereo if you are generating stereo sounds.
Now, let's do simple 16-bit integer lists, assume we have a stream
of Ints which additionally are between -2^15 and 2^15 - 1. And assume
we want network byte order (high byte first).
writeInts :: [Int] -> IO ()
writeInts = putStr . ints2Str
ints2Str :: [Int] -> String
ints2Str = concatMap int2str
where
int2str i | i >= -32768 && i <= 32767 =
map Char.chr [(i `mod` 65536) `div` 256, i `mod` 256]
That's it.
If you want to write stereo, you should interleave the Ints,
such as
nullElement :: Int -- the sample value for silence
mixStereo :: [Int] -> [Int] -> ([Int], [Int])
mixStereo [] [] = []
mixStereo l [] = zip l (repeat nullElement)
mixStereo [] l = zip (repeat nullElement) l
mixStereo (x:xs) (y:ys) = (x,y) : mixStereo xs ys
Hope that helps, even if late.
Kind regards,
Hannah.
From vcomic@speed.sender.com Mon Dec 3 07:46:07 2001
From: vcomic@speed.sender.com (vcomic@speed.sender.com)
Date: Mon, 3 Dec 2001 02:46:07 -0500 (EST)
Subject: 爆笑时事漫画 12-3
Message-ID: <20011203074607.9CFF7255C2@www.haskell.org>
新建网页 1
|
本刊物所有文章及内容版权为www.viacomic.com
V动漫网站所有，未经书面授权任何媒体不得转载 |
From mpc02@ukc.ac.uk Mon Dec 3 11:51:28 2001
From: mpc02@ukc.ac.uk (mpc02)
Date: Mon, 3 Dec 2001 11:51:28 +0000 (GMT)
Subject: Mathematics of Program Construction, 2nd CFP
Message-ID:
[Apologies for multiple copies]
MPC 2002
6th International Conference on
MATHEMATICS OF PROGRAM CONSTRUCTION
-----------------------------------
http://www.cs.ukc.ac.uk/conf/mpc2002/
Organised in conjunction with WCGP '02
8--10 July, 2002
Dagstuhl, Germany
INVITED SPEAKERS
include:
Robert Giegerich
Dexter Kozen
CALL FOR PAPERS
This conference aims to promote the development of mathematical
principles and techniques that are demonstrably useful and usable
in the process of constructing computer programs (whether
implemented in hardware or software).
The focus of the conference is on techniques that combine
precision with conciseness, enabling programs to be constructed by
formal calculation. Within this theme, the scope of the conference
is very diverse. We welcome contributions to programming
methodology (for example, formal methods for program specification
and transformation), to programming paradigms (for example,
generic programming techniques and type systems) and to language
design (for example, programming calculi and programming language
semantics). Theoretical contributions are welcome provided their
relevance to program construction is evident; discussion of
applications is welcome provided the mathematical basis is evident.
The conference will be organised in conjunction with the IFIP TC2
Working Conference on Generic Programming, WCGP '02. There will also be
a number of co-located workshops, including CMPP.
IMPORTANT DATES
Deadline for submission of papers: 6th January, 2002
Notification of acceptance/rejection: 4th March, 2002
Final papers due: 25th April, 2002
Full papers should be submitted in Postscript or pdf format by e-mail
to mpc02@ukc.ac.uk by 6th January, 2002.
PROGRAMME COMMITTEE
Roland Backhouse (UK) Eerke Boiten (UK, co-chair)
Michael Butler (UK) Ernie Cohen (USA)
Jules Desharnais (Canada) Jeremy Gibbons (UK, GP liaison)
David Gries (USA) Lindsay Groves (New Zealand)
Ian Hayes (Australia) Eric Hehner (Canada)
Zhenjiang Hu (Japan) John Hughes (Sweden)
Bart Jacobs (The Netherlands) Johan Jeuring (The Netherlands, GP liaison)
Dick Kieburtz (USA) Dexter Kozen (USA)
K. Rustan M. Leino (USA) Christian Lengauer (Germany, CMPP liaison)
Erik Meijer (The Netherlands/USA) Bernhard Moeller (Germany, co-chair)
David Naumann (USA) J.N. Oliveira (Portugal)
Alberto Pardo (Uruguay) Peter Pepper (Germany)
Kaisa Sere (Finland) Mark Utting (New Zealand)
FURTHER INFORMATION
Please refer to the web page for further details.
http://www.cs.ukc.ac.uk/conf/mpc2002/
--
Mathematics of Program Construction '02 at Dagstuhl
Eerke Boiten, Computing Laboratory, University of Kent at Canterbury, UK
+44.1227.827615 (fax 762811)
From thiemann@informatik.uni-freiburg.de Mon Dec 3 13:51:27 2001
From: thiemann@informatik.uni-freiburg.de (Peter Thiemann)
Date: 03 Dec 2001 14:51:27 +0100
Subject: PEPM'02 -- call for participation
Message-ID:
CALL FOR PARTICIPATION
2002 ACM SIGPLAN Workshop on
Partial Evaluation and Semantics-Based Program Manipulation (PEPM'02)
Portland, Oregon, USA, January 14-15, 2002
(colocated with POPL'02)
http://www.informatik.uni-freiburg.de/~thiemann/pepm02
The PEPM'02 workshop will bring together researchers working in the
areas of semantics-based program manipulation, partial evaluation, and
program generation. The workshop focuses on techniques, supporting
theory, and applications of the analysis and manipulation of programs.
PRELIMINARY PROGRAM
Monday, 14 January 2002
BREAKFAST
8:45 WELCOME (chair: PT)
9:00 Invited Talk: Staged Compilation
Craig Chambers (U Washington)
10:00 BREAK
10:30 Towards Bridging the Gap Between Programming Languages and Partial Evaluation
Anne-Francoise Le Meur, Julia L. Lawall, Charles Consel (INRIA/LaBRI, France)
11:00 Online Partial Evaluation for Shift and Reset
Kenichi Asai (Ochanomizu University, Japan)
11:30 Growing Languages with Metamorphic Syntax Macros
Claus Brabrand, Michael I. Schwartzbach (BRICS, University of Aarhus, Denmark)
12:00 LUNCH
14:00 From Checking to Inference via Driving and Dag Grammars
Jens Peter Secher and Morten Heine S鴕ensen (DIKU, Denmark)
14:30 Cost-Augmented Narrowing-Driven Specialization
Germ醤 Vidal (DSIC, Technical University of Valencia, Spain)
15:00 Path Dependent Analysis of Logic Programs
Lunjin Lu (Oakland University, USA)
15:30 BREAK
16:00 Automatic Time-Bound Analysis for a Higher-Order Language
Gustavo G髆ez and Yanhong A. Liu (Indiana University, USA)
16:30 Compositionality in the Puzzle of Semantics
Roberto Giacobazzi, Isabella Mastroeni
(Dipartimento di Informatica, Universita' degli studi di Verona, Italy)
17:00 PC REPORT
Tuesday, 15 January 2002
BREAKFAST
9:00 shared WITS-Session "Non-Interference and Probability"
10:30 BREAK
11:00 Invited Talk: Implementation of Automatic Differentiation Tools
Christian Bischof (Technical University of Aachen, Germany),
Paul Hovland, Boyana Norris (Argonne National Laboratory, USA),
12:00 LUNCH
14:00 Program Optimization Using Indexed and Recursive Data Structures
Yanhong A. Liu and Scott D. Stoller
(State University of New York at Stony Brook, USA)
14:30 Mixed-Initiative Interaction = Mixed Computation
Naren Ramakrishnan, Robert Capra, Manuel Perez-Quinones
(Department of Computer Science, Virginia Tech, USA)
15:00 CPS Translating Inductive and Coinductive Types
Gilles Barthe (INRIA, France),
Tarmo Uustalu (University of Minho, Portugal)
15:30 CLOSING
From ad@dcs.st-and.ac.uk Tue Dec 4 09:38:49 2001
From: ad@dcs.st-and.ac.uk (Tony Davie)
Date: Tue, 4 Dec 2001 09:38:49 +0000
Subject: We need "Documentation" (Was: Re: Integer to String
Conversion?)
In-Reply-To:
References:
Message-ID:
--============_-1204663764==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Tuesday 04 December 2001 02:51, you wrote:
>> On Tue, 4 Dec 2001, Chris wrote:
>> > is there a function that converts Integers to Strings and vice versa?
>>
>> Prelude> (reads "123 abc") :: [(Integer, String)]
>> [(123," abc")]
>> Prelude> show 123
> > "123"
>>
>
...
>Why doesn't an author or two who have written Haskell books consider opening
>their books for public use on the Internet? "The Craft Of ..." especially
>seems great. I'm sure many coders would appreciate a non-dead-tree version of
>that book or a shortened version of the book.
>
>The material we have is simply lacking. What we need is a good tutorial and a
>comprehensive reference book.
...
I suggest you look at http://www.haskell.org/bookshelf/, specifically
the section on
Papers available on the Web. This gives numerous tutorials and introductions.
--
Tony Davie
Computer Science (retired), St.Andrews University
G.F. Handel Site:
http://bruichladdich.dcs.st-and.ac.uk/HandelWWW/HandelCat.html
Handel was half German, half Italian, and half English. He was very
large. (from a music exam)
--============_-1204663764==_ma============
Content-Type: text/html; charset="us-ascii"
Re: We need "Documentation" (Was: Re:
Integer to Strin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 04 December 2001 02:51, you wrote:
> On Tue, 4 Dec 2001, Chris wrote:
> > is there a function that converts Integers to Strings and
vice versa?
>
> Prelude> (reads "123 abc") :: [(Integer,
String)]
> [(123," abc")]
> Prelude> show 123
> "123"
>
...
Why doesn't an author or two who have
written Haskell books consider opening
their books for public use on the Internet? "The Craft Of ..."
especially
seems great. I'm sure many coders would appreciate a non-dead-tree
version of
that book or a shortened version of the book.
The material we have is simply lacking. What we need is a good
tutorial and a
comprehensive reference
book.
...
I suggest you look at http://www.haskell.org/bookshelf/,
specifically the section on
Papers available on the Web. This gives numerous tutorials
and introductions.
--
Tony Davie
Computer Science (retired), St.Andrews University
G.F. Handel Site:
http://bruichladdich.dcs.st-and.ac.uk/HandelWWW/HandelCat.html
Handel was half
German, half Italian, and half English. He was very
large. (from a music
exam)
--============_-1204663764==_ma============--
From simonpj@microsoft.com Tue Dec 4 12:02:31 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 4 Dec 2001 04:02:31 -0800
Subject: Haskell 98 Revised
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066542@RED-MSG-10.redmond.corp.microsoft.com>
Gentle Haskellers
The December issue of the Haskell 98 Report is done.
http://research.microsoft.com/~simonpj/haskell98-revised
As usual, changes are highlighted in the overall bugs list thus: [Dec
2001],
so you can find them easily.
There are the usual crop of presentational improvements (thanks
esp to Ian Lynagh, George Russel, Feliks Kluzniak for much careful
reading).
There are two non-trivial changes that I decided to adopt:
1. Add showIntAtBase, showOct and showHex to the Numeric library.
2. Remove the wart concerning qualified names in instance declarations.
This a breaking change, in the sense that exotic Haskell programs
may have to change, but I judge it worth it, after some
consultation.
In particular:=20
* if you use H/Direct, you'll have to re-generate your
Haskell files with a different flag
* if you use the Edison library, you'll need a new copy of
the library (this isn't a problem in practice because it
comes bundled with your compiler)
The other thing I'd ask you to look at particularly is the layout
algorithm.
George and Ian have both pointed out bugs, but it's very easy to get
wrong
so a few more eyeballs on it would be a Good Thing.
The only unresolved thing I have in my pile is some stuff
about the lexical syntax of comments, which I find it hard to get
excited about. We are definitely converging. My earnest hope is to
finally freeze the Report at Christmas. So this is your last chance.
I hope.
Thanks
Simon
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
The instance decl wart
In Haskell 98 as she stands, when you give an instance declaration,
the method name is treated as an *occurrence* and so has to be=20
qualified if it is ambiguous:
module Foo where
compare =3D
instance Ord T where
Prelude.compare =3D ... -- NB!
You have to say "Prelude.compare" on the LHS, because both
Prelude.compare and Foo.compare are in scope. This is reasonable
on the RHS, of course, but it is plain silly on the LHS, because it=20
*must* refer to the compare from the Ord class! After all, its an
instance
declaration for Ord. =20
Not only is it surprising (most people think that plain "compare" should
be fine) but it also adds a whole new big production to the grammar
(qfunlhs).
So, after some consulation, I have decided to remove this wierd thing.
The analogy is with type signatures, where we can already write
module Foo where
compare :: Int -> Int
compare =3D ...
Note that we don't have to write "Foo.compare :: Int -> Int" in the
type signature. =20
The remaining question is how to explain this point in the Report.
My initial conclusion is that simply deleting the offending text was
enough.
Explaining the problem (given that it isn't really a problem) seems to
complicate matters. Nevertheless I'm entirely happy to add an
explanation, if people want it and say what they'd like to see.
The relevant section is 4.3.2. page 46 of the Report.
From biene2xxl@mail.com Tue Dec 4 17:25:41 2001
From: biene2xxl@mail.com (biene2xxl@mail.com)
Date: Tue, 4 Dec 2001 10:25:41 -0700 (MST)
Subject: hallo
Message-ID: <200112041725.KAA0000018394@int.iwhm.com>
Mein Geheimnis ist, da� ich immer Lust auf Erotik habe.
Bin ich eine Nymphomanin? Oder fehlt mir nur der richtige
Partner/in?
K鰊ntest Du das sein?
Ja? Dann besuch mich doch mal auf meiner kleinen Homepage
http://free.adult-freespace.de/coolgirl22/
cu bis bald
Biene
From diatchki@cse.ogi.edu Tue Dec 4 18:40:55 2001
From: diatchki@cse.ogi.edu (Iavor S. Diatchki)
Date: Tue, 4 Dec 2001 10:40:55 -0800
Subject: Haskell 98 Revised
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE19066542@RED-MSG-10.redmond.corp.microsoft.com>
References: <1113DDB24D4A2841951BFDF86665EE19066542@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <200112041840.KAA20987@church.cse.ogi.edu>
hello,
it seems that if the qualified names in instance declarations are removed,
the qualified methods (data constructors) in exports ought to be removed as
well. example: currently in Haskell one may write
module M ( P.C(Q.f) ) where
import qualified P
import qualified Q
...
qualifying the method (or data cosntructor) does not give any additional
information. however if i read the current report correctly (and i don't
think it is quite clear on that) omitting the qualifier of "f" results in an
invalid program as there is no method "f" in scope (there probably are "P.f"
and "Q.f"however). having said that, GHC accepts the program without the
qualifier,so it seems that it essentailly ignores the qualifiers of
"subordinate" names in export lists. so why not adjust the report so that
such qualified names are just not allowed?
bye
iavor
From diatchki@cse.ogi.edu Tue Dec 4 19:13:39 2001
From: diatchki@cse.ogi.edu (Iavor S. Diatchki)
Date: Tue, 4 Dec 2001 11:13:39 -0800
Subject: hiding imports
Message-ID: <200112041913.LAA13918@church.cse.ogi.edu>
hello,
i was wondering if there was a reasong why "hiding imports" have different
semantics from "importing imports" and "exports". what i mean is, if one
writes:
module A(T) where
data T = T
only the type constructor T is exported. simillarly if i write:
module A where
data T = T
module B where
import A(T)
only the type constructor is imported, but if i write
(module A as above)
module B where
import A hiding (T)
both the type constructor and the value constructor are hidden.
this seems not only irregular, but may also be inconvinient in practise
as sometimes it happens that a type constructor and a data constructor
have the same name, but the data constructor does not "belong" to the
type constructor. for example:
module A where
type T = TGen Int
data TGen a = T a | S
module B where
import A hiding (T) -- intending to just hide the type T
genF = T -- error T not in scope!
so if i wanted to ignore the type T, but still have the data constructor i
have to explicitly import it, i.e. write:
module B where
import A hiding (T)
import A (TGen(T))
which is kind of ugly. is this strange behaviour for historical reasons,
or was there a practical reason why this decision was made?
bye
iavor
From afelty@site.uottawa.ca Tue Dec 4 19:34:18 2001
From: afelty@site.uottawa.ca (Amy Felty)
Date: Tue, 4 Dec 2001 14:34:18 -0500 (EST)
Subject: CFP: Special Journal Issue on Proof-Carrying Code
Message-ID:
Call for Papers
JOURNAL OF AUTOMATED REASONING
Special issue on PROOF-CARRYING CODE
Proof-carrying code is a technology that allows a host, or code
consumer, to safely run code delivered by an untrusted code producer.
The code producer delivers both a program and a formal proof that
verifies that the code meets the desired safety policies. Safety
policies generally express properties that prohibit the code from
harmful behavior such as accessing private data, overwriting important
data, accessing unauthorized resources, or consuming too many
resources. Ideally, a proof is constructed automatically, and proof
search may be directed using information that is passed on from the
code producer's compiler. Proofs provided semi-automatically or
interactively using a proof assistant are possible as well. Upon
receiving the code and proof, the code consumer uses a mechanical
proof checker to check the proof before executing the code.
This special issue will be devoted to the topic of proof-carrying code
and related approaches which use formal reasoning to enhance safety
and reliability of software. Manuscripts emphasizing original results
and study of tools and methods for proof generation, proof checking,
and their integration with code generation/compilation are of
particular interest.
Manuscripts should be unpublished works and not submitted elsewhere.
Revised and enhanced versions of papers published in conference
proceedings that have not appeared in archival journals are eligible
for submission. All submissions will be reviewed according to the
usual standards of scholarship and originality. Information on JAR
submissions can be found at URL http://www-unix.mcs.anl.gov/JAR/.
Please format your submissions using JAR macros (available at
http://www.wkap.nl/kaphtml.htm/STYLEFILES).
Submissions should be sent to the guest editor in postscript format,
preferably gzipped and uuencoded. In addition, please send as plain
text, the title, authors, abstract, and contact information for the
paper. The submission deadline is February 22, 2002.
Guest Editor:
Amy Felty, University of Ottawa, afelty@site.uottawa.ca
This information is available on the web at:
http://www.site.uottawa.ca/~afelty/jar-pcc/
From simonpj@microsoft.com Wed Dec 5 10:42:18 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 5 Dec 2001 02:42:18 -0800
Subject: hiding imports
Message-ID: <1113DDB24D4A2841951BFDF86665EE1906655A@RED-MSG-10.redmond.corp.microsoft.com>
I think it's an ill-thought-out exception. The point is this:
if a data constructor cannot appear on its own in a hiding
list, then you can't hide the constructor without hiding the
type. Currently you can say
import Maybe hiding( Just )
It would be simpler and more uniform to only allow data
constructors inside parens, just as for exports, but then
I'd have to say
import Maybe hiding( Maybe(Just) )
and now the type constructor Maybe is hidden too.
I say "ill thought out" because the exception doesn't actually
solve the problem, as you point out. You may accidentally hide
things you didn't mean to. So perhaps the cure is as bad
as the disease.
Changing this would be technically easy (delete a sentence)
but it might break some programs, so that suggests the status
quo.
Simon
| -----Original Message-----
| From: Iavor S. Diatchki [mailto:diatchki@cse.ogi.edu]=20
| Sent: 04 December 2001 19:14
| To: haskell@haskell.org
| Subject: hiding imports
|=20
|=20
| hello,
|=20
| i was wondering if there was a reasong why "hiding imports"=20
| have different semantics from "importing imports" and=20
| "exports". what i mean is, if one=20
| writes:
|=20
| module A(T) where
| data T =3D T
| only the type constructor T is exported. simillarly if i write:
|=20
| module A where
| data T =3D T
|=20
| module B where
| import A(T)
|=20
| only the type constructor is imported, but if i write
| (module A as above)
|=20
| module B where
| import A hiding (T)
|=20
| both the type constructor and the value constructor are hidden.
|=20
| this seems not only irregular, but may also be inconvinient=20
| in practise as sometimes it happens that a type constructor=20
| and a data constructor have the same name, but the data=20
| constructor does not "belong" to the type constructor. for example:
|=20
| module A where
| type T =3D TGen Int
| data TGen a =3D T a | S
|=20
| module B where
| import A hiding (T) -- intending to just hide the type T
| genF =3D T -- error T not in scope!
|=20
| so if i wanted to ignore the type T, but still have the data=20
| constructor i=20
| have to explicitly import it, i.e. write:
| module B where
| import A hiding (T)
| import A (TGen(T))
| which is kind of ugly. is this strange behaviour for=20
| historical reasons,=20
| or was there a practical reason why this decision was made?
|=20
| bye
| iavor
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From simonpj@microsoft.com Wed Dec 5 10:42:17 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 5 Dec 2001 02:42:17 -0800
Subject: Haskell 98 Revised
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066559@RED-MSG-10.redmond.corp.microsoft.com>
A good point. You are right that the report is not very explicit
on this point; and right that omitting the qualifier would be in the
spirit of the story for type sigs and instance decls. =20
I'd be interested to know what others think.
Simon
| -----Original Message-----
| From: Iavor S. Diatchki [mailto:diatchki@cse.ogi.edu]=20
| Sent: 04 December 2001 18:41
| To: haskell@haskell.org
| Subject: Re: Haskell 98 Revised
|=20
|=20
| hello,
|=20
| it seems that if the qualified names in instance declarations=20
| are removed, the qualified methods (data constructors) in=20
| exports ought to be removed as=20
| well. example: currently in Haskell one may write
|=20
| module M ( P.C(Q.f) ) where
| import qualified P
| import qualified Q
| ...
| qualifying the method (or data cosntructor) does not give=20
| any additional=20
| information. however if i read the current report correctly=20
| (and i don't=20
| think it is quite clear on that) omitting the qualifier of=20
| "f" results in an=20
| invalid program as there is no method "f" in scope (there=20
| probably are "P.f"=20
| and "Q.f"however). having said that, GHC accepts the=20
| program without the=20
| qualifier,so it seems that it essentailly ignores the qualifiers of=20
| "subordinate" names in export lists. so why not adjust the=20
| report so that=20
| such qualified names are just not allowed?
|=20
| bye
| iavor
|=20
|=20
|=20
|=20
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From simonpj@microsoft.com Wed Dec 5 11:13:54 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 5 Dec 2001 03:13:54 -0800
Subject: Haskell 98 Revised
Message-ID: <1113DDB24D4A2841951BFDF86665EE1906655B@RED-MSG-10.redmond.corp.microsoft.com>
Folks,
Concerning the recent change about instance declarations, should
this be valid?
module M( C(op1) ) where -- NB: op2 not exported
class C a where
op1 :: a->a
op2 :: a->a
module N where
import M
instance C Int where
op1 =3D ...
op2 =3D ... -- Is this ok?
The point here is that M does not export op2. Can
we still bind it in the instance declaration in N? The old Report
was silent on this point, and so is the new one.
I'd like to say "no, this is illegal". Haskell uses hiding as its
main abstraction mechanism, and if op2 is hidden then an
importing module should not be able to see it in any way.
I'll clarify this; but I thought I should point out the issue.
Simon
| -----Original Message-----
| From: Simon Peyton-Jones [mailto:simonpj@microsoft.com]=20
| Sent: 04 December 2001 12:03
| To: haskell@haskell.org
| Cc: Simon Peyton-Jones
| Subject: Haskell 98 Revised
|=20
|=20
| Gentle Haskellers
|=20
| The December issue of the Haskell 98 Report is done.
|=20
| http://research.microsoft.com/~simonpj/haskell98-revised
|=20
| As usual, changes are highlighted in the overall bugs list=20
| thus: [Dec 2001], so you can find them easily.
|=20
| There are the usual crop of presentational improvements=20
| (thanks esp to Ian Lynagh, George Russel, Feliks Kluzniak for=20
| much careful reading). There are two non-trivial changes that=20
| I decided to adopt:
|=20
| 1. Add showIntAtBase, showOct and showHex to the Numeric library.
|=20
| 2. Remove the wart concerning qualified names in instance=20
| declarations.
| This a breaking change, in the sense that exotic Haskell programs
| may have to change, but I judge it worth it, after some=20
| consultation.
| In particular:=20
| * if you use H/Direct, you'll have to re-generate your
| Haskell files with a different flag
| * if you use the Edison library, you'll need a new copy of
| the library (this isn't a problem in practice because it
| comes bundled with your compiler)
|=20
| The other thing I'd ask you to look at particularly is the=20
| layout algorithm. George and Ian have both pointed out bugs,=20
| but it's very easy to get wrong so a few more eyeballs on it=20
| would be a Good Thing.
|=20
| The only unresolved thing I have in my pile is some stuff
| about the lexical syntax of comments, which I find it hard to=20
| get excited about. We are definitely converging. My earnest=20
| hope is to finally freeze the Report at Christmas. So this=20
| is your last chance. I hope.
|=20
| Thanks
|=20
| Simon
|=20
| =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
| The instance decl wart
|=20
| In Haskell 98 as she stands, when you give an instance=20
| declaration, the method name is treated as an *occurrence*=20
| and so has to be=20
| qualified if it is ambiguous:
|=20
| module Foo where
|=20
| compare =3D
|=20
| instance Ord T where
| Prelude.compare =3D ... -- NB!
|=20
| You have to say "Prelude.compare" on the LHS, because both=20
| Prelude.compare and Foo.compare are in scope. This is=20
| reasonable on the RHS, of course, but it is plain silly on=20
| the LHS, because it=20
| *must* refer to the compare from the Ord class! After all,=20
| its an instance declaration for Ord. =20
|=20
| Not only is it surprising (most people think that plain=20
| "compare" should be fine) but it also adds a whole new big=20
| production to the grammar (qfunlhs).
|=20
| So, after some consulation, I have decided to remove this=20
| wierd thing. The analogy is with type signatures, where we=20
| can already write
|=20
| module Foo where
|=20
| compare :: Int -> Int
| compare =3D ...
|=20
| Note that we don't have to write "Foo.compare :: Int -> Int"=20
| in the type signature. =20
|=20
|=20
| The remaining question is how to explain this point in the=20
| Report. My initial conclusion is that simply deleting the=20
| offending text was enough. Explaining the problem (given that=20
| it isn't really a problem) seems to complicate matters. =20
| Nevertheless I'm entirely happy to add an explanation, if=20
| people want it and say what they'd like to see.
|=20
| The relevant section is 4.3.2. page 46 of the Report.
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From kff@it.kth.se Wed Dec 5 13:13:43 2001
From: kff@it.kth.se (Karl-Filip Faxen)
Date: Wed, 05 Dec 2001 14:13:43 +0100
Subject: Haskell 98 Revised
In-Reply-To: Your message of Wed, 05 Dec 2001 03:13:54 -0800.
<1113DDB24D4A2841951BFDF86665EE1906655B@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <200112051313.OAA14174@mail2.it.kth.se>
Hi!
For whatever that is worth, my semantics agrees with Simon's point here,
ie in the example code
module M( C(op1) ) where -- NB: op2 not exported
class C a where
op1 :: a->a
op2 :: a->a
module N where
import M
instance C Int where
op1 = ...
op2 = ... -- Is this ok?
the method binding for op2 is not allowed.
But then there *is* a scope issue with instance declarations. What about
the following example:
module M( C(..) ) where -- NB: both methods exported ...
class C a where
op1 :: a->a
op2 :: a->a
module N where
import M hiding (op2) -- ... but op2 is not imported
instance C Int where
op1 = ...
op2 = ... -- Is this ok?
As far as I've understood, the current revision of the Report states that
a 'hiding' clause affects the qualified names as well as the unqualified
names. Then 'op2' is not visible either qualified or unqualified.
So, should it be legal to make a method declaration for it?
Cheers,
/kff
From martin.odersky@epfl.ch Thu Dec 6 09:14:48 2001
From: martin.odersky@epfl.ch (Martin Odersky)
Date: Thu, 6 Dec 2001 10:14:48 +0100
Subject: FOOL 9 Call for Participation
Message-ID: <200112060914.KAA16836@lamppc11.epfl.ch>
CALL FOR PARTICIPATION
The Ninth International Workshop on
Foundations of Object-Oriented Languages
FOOL 9
Sponsored by ACM SIGPLAN
January 19, 2002
Portland, Oregon
Following POPL '02
The search for sound principles for object-oriented languages has
given rise to much work on the theory of programming languages during
the past 15 years, leading to a better understanding of the key
concepts of object-oriented languages and to important developments in
type theory, semantics, and program verification. The FOOL workshops
bring together researchers to share new ideas and results in these
areas.
The next workshop, FOOL 9, will be held in Portland, Oregon, on
Saturday January 19, 2002, the day after POPL'02. To register for the
workshop, use the standard registration form, available through:
http://www.cse.ogi.edu/PacSoft/conf/popl
--------------------------------------------------------------------------
Preliminary schedule
Saturday, January 29, 2002
8:40 Start
8:45-9:45 Invited Talk
Distributed Objects - The Next 10 Years
Andrew Black
9:45-10:15 Break
10:15-12:15 Session 1
Modular Typechecking for Hierarchically Extensible
Datatypes and Functions
Todd Millstein, Craig Chambers
Type-checking multi-methods in ML (A modular approach)
Daniel Bonniot
First-Class Modules for Haskell
Mark Shields, Simon Peyton Jones
Extensible Objects Without Labels
Christopher Stone
12:15-14:00 Lunch
14:00-15:30 Session 2
Modern Concurrency Abstractions for C#
Nick Benton, Luca Cardelli, Cedric Fournet
OO languages late-binding signature
Antoine Beugnard
A Semantics for Advice and Dynamic Joint Points in
Aspect-Oriented Programming
Mitchell Wand, Gregor Kiczales, Christopher Dutchyn
15:30-16:00 Break
16:00-17:30 Session 3
Automatic Discovery of Read-Only Fields,
Jens Palsberg, Tian Zhao, Trevor Jim.
Generation of Verification Conditions for
Abadi and Leino's Logic of Objects
Francis Tang, Martin Hofmann
Simple Type Inference for Structural Polymorphism
Jacques Garrigue
-------------------------------------------------------------------------
Steering Committee:
Martin Abadi, University of California, Santa Cruz
Kim Bruce, Williams College
Luca Cardelli, Microsoft Research
Kathleen Fisher, AT&T Labs
Benjamin Pierce, University of Pennsylvania (chair)
Didier Remy, INRIA Rocquencourt
Program Committee:
Viviana Bono, Universita di Torino
Craig Chambers, University of Washington
Erik Ernst, University of Aalborg
Giorgio Ghelli, University of Pisa
Atsushi Igarashi, University of Tokyo
Shriram Krishnamurthi, Brown University
Martin Odersky, EPFL (chair)
Clemens Szyperski, Microsoft Research
Jan Vitek, Purdue University
From ng13@mcs.le.ac.uk Thu Dec 6 12:25:43 2001
From: ng13@mcs.le.ac.uk (N Ghani)
Date: Thu, 06 Dec 2001 12:25:43 +0000
Subject: Rewriting Implementations
Message-ID: <200112061225.fB6CPgD24023@ithaca.mcs.le.ac.uk>
Is there any Haskell implementations of rewriting tools. This could be
any of string, term, equational or whatever forms of rewriting.
Also are there any Haskell packages including data structures for
algebriac objects like monoids, groups, rings, modules, graphs,
categories, enriched categories, K-algebras (ie monoids in K-modules),
kan extensions ....
Finally, are there any haskell packages for computing quotients of
such structures (perhpas using rewriting)
Neil
From herrmann@infosun.fmi.uni-passau.de Thu Dec 6 19:19:02 2001
From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann)
Date: Thu, 6 Dec 2001 20:19:02 +0100
Subject: Strict foldl
Message-ID: <15375.50342.279681.360674@reger.fmi.uni-passau.de>
Hi Haskellers,
which compiler settings do I have to pass to ghc-5.02
in order to achieve that the strictness analyzer
recognizes strictness of (+) in foldl and computes
sum in constant space?
Prelude> sum [1..10000000]
had the following effect:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
23542 herrmann 20 0 250M 130M 97500 R 66.3 52.4 0:21 ghc-5.02
Of course, one could define a strict foldl oneself:
> sfoldl f e [] = e
> sfoldl f e (x:xs) = (sfoldl f $! (f e x)) xs
( > sfoldl (+) 0 [1..10000000]
returns 50000005000000 in about a minute interpreted
using 18MB of total space.)
But with the own definition one has to redefine many of the prelude functions.
Thanks in advance
--
Christoph Herrmann
From hdaume@ISI.EDU Thu Dec 6 19:19:31 2001
From: hdaume@ISI.EDU (Hal Daume III)
Date: Thu, 6 Dec 2001 11:19:31 -0800 (PST)
Subject: class parameters to existential datatypes
Message-ID:
Hi,
I would like to be able to write something like this:
> data Foo c = forall a . c a => Foo a
Unfortunately, this isn't allowed (apparently) because it's an illegal
class assertion (or at least that's what ghc tells me).
My motivation for doing this is I want to have something like List, but a
class list where all you know is that every element is a member of some
class. I would write something like:
> data CList c = CNil
> | forall a . (c a) => CCons a (CList c)
that way I could have something like the prototypical:
> class Shape a where { area :: a -> Double }
> data Circle = Circle Double
> data Rectangle = Rectangle Double Double
> instance Shape Circle where { area (Circle r) = 2 * pi * r }
> instance Shape Rectangle where { area (Rectangle l w) = l*w }
> MyList :: CList Shape
> MyList = CCons (Circle 5) (CCons (Rectangle 2 3) CNil)
and then maybe have a function:
> totalArea :: (CList Shape) -> Double
> totalArea = sum . map area
obviously this function declaration is also invalid.
so I have two questions:
1) Is there any particular reason whey we can't do this (it would
break some type safety things or whatever)
2) Any ways to get around it?
Thanks!
- Hal
From rjmh@cs.chalmers.se Thu Dec 6 21:04:46 2001
From: rjmh@cs.chalmers.se (John Hughes)
Date: Thu, 6 Dec 2001 22:04:46 +0100 (MET)
Subject: class parameters to existential datatypes
Message-ID: <200112062104.WAA11520@hotlips.cs.chalmers.se>
I would like to be able to write something like this:
> data Foo c = forall a . c a => Foo a
Unfortunately, this isn't allowed (apparently) because it's an illegal
class assertion (or at least that's what ghc tells me).
...
so I have two questions:
1) Is there any particular reason whey we can't do this (it would
break some type safety things or whatever)
2) Any ways to get around it?
Thanks!
- Hal
Hmm. Interesting.
I wrote a paper a couple of years ago, on "Restricted Data Types", which
discusses among other things how to simulate abstraction over a class by
abstraction over the corresponding dictionary type. You might find the
technique useful. It's at
http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
John Hughes
From ashley@semantic.org Thu Dec 6 21:11:07 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Thu, 6 Dec 2001 13:11:07 -0800
Subject: class parameters to existential datatypes
Message-ID: <200112062111.NAA02412@mail4.halcyon.com>
At 2001-12-06 13:04, John Hughes wrote:
> > data Foo c = forall a . c a => Foo a
What are you trying to say? In 'data Foo c' you are saying that c is a
type (as a parameter). In 'c a =>' you are saying that c is a class. So
naturally Haskell complains.
--
Ashley Yakeley, Seattle WA
From ashley@semantic.org Thu Dec 6 21:12:59 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Thu, 6 Dec 2001 13:12:59 -0800
Subject: class parameters to existential datatypes
Message-ID: <200112062112.NAA02509@mail4.halcyon.com>
At 2001-12-06 13:11, Ashley Yakeley wrote:
>At 2001-12-06 13:04, John Hughes wrote:
>
>> > data Foo c = forall a . c a => Foo a
>
>What are you trying to say? In 'data Foo c' you are saying that c is a
>type (as a parameter). In 'c a =>' you are saying that c is a class. So
>naturally Haskell complains.
I'm sorry, I'm not paying attention today...
--
Ashley Yakeley, Seattle WA
From chak@cse.unsw.edu.au Thu Dec 6 23:34:40 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 07 Dec 2001 10:34:40 +1100
Subject: Strict foldl
In-Reply-To: <15375.50342.279681.360674@reger.fmi.uni-passau.de>
References: <15375.50342.279681.360674@reger.fmi.uni-passau.de>
Message-ID: <20011207103440M.chak@cse.unsw.edu.au>
"Ch. A. Herrmann" wrote,
> which compiler settings do I have to pass to ghc-5.02
> in order to achieve that the strictness analyzer
> recognizes strictness of (+) in foldl and computes
> sum in constant space?
>
> Prelude> sum [1..10000000]
>
> had the following effect:
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> 23542 herrmann 20 0 250M 130M 97500 R 66.3 52.4 0:21 ghc-5.02
Is this what I think it is? Do you benchmark the
interpreter? Interpreted code isn't optimised. When I
compile
main = print $ sum [1..10000000]
with -O2, it takes 13s on a 600MHz P3 and runs in 1.5MB of
space.
Now, you may think that `sum' should have been compiled
optimised in the Prelude and you just call this optimised
version from the interpreter. However, this reasoning is
flawed for a number of reasons (one being that you won't
make use of specialised versions of Prelude functions in
this way).
> Of course, one could define a strict foldl oneself:
>
> > sfoldl f e [] = e
> > sfoldl f e (x:xs) = (sfoldl f $! (f e x)) xs
>
> ( > sfoldl (+) 0 [1..10000000]
> returns 50000005000000 in about a minute interpreted
> using 18MB of total space.)
>
> But with the own definition one has to redefine many of the prelude functions.
GHC's Prelude does not define `sum' in terms of foldl;
instead, it uses the definition
sum :: (Num a) => [a] -> a
sum l = sum' l 0
where
sum' [] a = a
sum' (x:xs) a = sum' xs (a+x)
The Prelude also defines a specialisation of the function
for `Integer' (which is what you get in your example) by way
of
{-# SPECIALISE sum :: [Integer] -> Integer #-}
I haven't checked the Core code produced for the above
definition, but as I know GHC, I am pretty sure that it
compiles the Prelude definition into a nice tight loop
making use of all available strictness.
Cheers,
Manuel
From hdaume@ISI.EDU Thu Dec 6 23:43:08 2001
From: hdaume@ISI.EDU (Hal Daume III)
Date: Thu, 6 Dec 2001 15:43:08 -0800 (PST)
Subject: Strict foldl
In-Reply-To: <20011207103440M.chak@cse.unsw.edu.au>
Message-ID:
Hi,
> Is this what I think it is? Do you benchmark the
> interpreter? Interpreted code isn't optimised. When I
> compile
>
> main = print $ sum [1..10000000]
>
> with -O2, it takes 13s on a 600MHz P3 and runs in 1.5MB of
> space.
Out of curiousity, why doesn't this get compiled down to
main = print 50000005000000
?
That is, why doesn't the compiler carry out the calculation and then just
embed that in the compiled version?
I know that some C compilers do (at least somewhat) similar things when,
for example, you say:
x = y * 4
it will rewrite this as
x = y << 2
and even do more complicated stuff, like if you say
x = y * 12
it will give
x = 3 * (y << 2)
or whatnot.
can I expect this from ghc/nhc/etc?
- hal
From chak@cse.unsw.edu.au Fri Dec 7 02:33:13 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 07 Dec 2001 13:33:13 +1100
Subject: Strict foldl
In-Reply-To:
References: <20011207103440M.chak@cse.unsw.edu.au>
Message-ID: <20011207133313X.chak@cse.unsw.edu.au>
Hal Daume III wrote,
> > Is this what I think it is? Do you benchmark the
> > interpreter? Interpreted code isn't optimised. When I
> > compile
> >
> > main = print $ sum [1..10000000]
> >
> > with -O2, it takes 13s on a 600MHz P3 and runs in 1.5MB of
> > space.
>
> Out of curiousity, why doesn't this get compiled down to
>
> main = print 50000005000000
>
> ?
>
> That is, why doesn't the compiler carry out the calculation and then just
> embed that in the compiled version?
Because the compiler can't be sure that the computation
terminates. If it doesn't, the compiler would not
terminate, which usually makes users quite unhappy ;-)
> I know that some C compilers do (at least somewhat) similar things when,
> for example, you say:
>
> x = y * 4
>
> it will rewrite this as
>
> x = y << 2
>
> and even do more complicated stuff, like if you say
>
> x = y * 12
>
> it will give
>
> x = 3 * (y << 2)
>
> or whatnot.
>
> can I expect this from ghc/nhc/etc?
These kinds of optimisations are different from the use of a
Prelude function like `sum', because they don't affect the
termination behaviour of the compiler. With -fvia-C GHC
will generate C code that is, then, run through the C
compiler. If you take this route, then optimisations, such
as those you describe, are performed by the C compiler on
your Haskell code.
The natice code generator probably also performs some of
those optimisations, but I am not sure exactly which.
Cheers,
Manuel
From max630@mail.ru Fri Dec 7 02:45:11 2001
From: max630@mail.ru (Max A . K .)
Date: Fri, 7 Dec 2001 08:45:11 +0600
Subject: class parameters to existential datatypes
In-Reply-To: ; from hdaume@ISI.EDU on Thu, Dec 06, 2001 at 11:19:31AM -0800
References:
Message-ID: <20011207084511.B1617@max.home>
On Thu, Dec 06, 2001 at 11:19:31AM -0800, Hal Daume III wrote:
> 2) Any ways to get around it?
Is the following what you want?
> data ShapeType = forall t. (Shape t) => ShapeType t
> instance Shape ShapeType where { area (ShapeType a) = area a }
> class Shape a where { area :: a -> Double }
> data Circle = Circle Double
> data Rectangle = Rectangle Double Double
> instance Shape Circle where { area (Circle r) = 2 * pi * r }
> instance Shape Rectangle where { area (Rectangle l w) = l*w }
> myList :: [ShapeType]
> myList = [ShapeType (Circle 5), ShapeType (Rectangle 2 3)]
and then maybe have a function:
> totalArea :: [ShapeType] -> Double
> totalArea = sum . map area
works OK with ghc -fglasgow-exts
Max.
From michael.vorin@eds.com Fri Dec 7 03:20:45 2001
From: michael.vorin@eds.com (Vorin, Michael)
Date: Fri, 7 Dec 2001 13:20:45 +1000
Subject: Haskell Persistence
Message-ID: <1D1A08E56535D111BD0400805F59041A03C14514@AUADM100>
I am interested in pursuing practical development of persistence in Haskell.
To this end I have been looking for code/systems which have been developed
previously to build upon - not wishing to reinvent the wheel.
I have found some references in the literature but have been enable to track
down any "artefacts".
I was hopping someone could help me.
I have found:
(1) Efficient Persistent Haskell, Tony Davie, Kevin Hammond, and Juan
Quintela Division of Computer Science, University of St Andrews, 1998
(2) Models for Persistence in Lazy Functional Programming Systems, McNally,
University of St Andrews, 1993.
(3) A Functional Database (1989) (Correct) Phil Trinder
(4) Two Models For Integrating Persistence and Lazy Functional Languages
(1991) David J. McNally, Antony J.T. Davie
(5) Realizing State-Based Database Concepts in a Non-Strict, Statically
Typed, Purely Functional Persistent Programming Language Yoshihiko Ichikawa
Department of Information Sciences, Ochanomizu University
From trb@eastpac.com.au Fri Dec 7 04:02:35 2001
From: trb@eastpac.com.au (Tim Barbour)
Date: Fri, 7 Dec 2001 15:02:35 +1100 (EST)
Subject: Haskell Persistence
In-Reply-To: <1D1A08E56535D111BD0400805F59041A03C14514@AUADM100>
References: <1D1A08E56535D111BD0400805F59041A03C14514@AUADM100>
Message-ID: <15376.16219.746147.59447@hermes.virtue>
Vorin, Michael writes:
> I am interested in pursuing practical development of persistence in Haskell.
> To this end I have been looking for code/systems which have been developed
> previously to build upon - not wishing to reinvent the wheel.
I am implementing persistent memory for Linux (i.e. like virtual memory, but
non-volatile, with ACID transaction semantics). Perhaps something will be
working sometime in 2002.
It is my hope that persistent memory will serve as a foundation for making
functional data structures persistent, eventually leading towards a functional
operating system.
Tim
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin
From herrmann@infosun.fmi.uni-passau.de Fri Dec 7 09:34:05 2001
From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann)
Date: Fri, 7 Dec 2001 10:34:05 +0100
Subject: Strict foldl
In-Reply-To: <20011207103440M.chak@cse.unsw.edu.au>
References: <15375.50342.279681.360674@reger.fmi.uni-passau.de>
<20011207103440M.chak@cse.unsw.edu.au>
Message-ID: <15376.36109.341751.586793@reger.fmi.uni-passau.de>
Hi Manuel,
>> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 23542
>> herrmann 20 0 250M 130M 97500 R 66.3 52.4 0:21 ghc-5.02
Manuel> Is this what I think it is? Do you benchmark the
Manuel> interpreter? Interpreted code isn't optimised.
not really. I wanted to have a strict foldl (for a different purpose
than sum) and could not figure out how to tell the compiler.
I tried different things, precompile just one module, compile
the entire program, using -fglasgow-exts, but nothing seems to work.
Thus, I reduced the problem to sum to make it simpler for you.
However, the sum computation based on my sfold definition did not
take too long even with the interpreter. Thus, I wondered why
the predefined sum computation behaves that bad.
Manuel> GHC's Prelude does not define `sum' in terms of foldl;
Manuel> instead, it uses the definition ...
Where can I find the ghc prelude?
Is there also the definition of the mysterious foldl' function
which I saw from time to time before it disappeared again?
Manuel> I haven't checked the Core code produced for the above
Manuel> definition, but as I know GHC, I am pretty sure that it
Manuel> compiles the Prelude definition into a nice tight loop
Manuel> making use of all available strictness.
One would expect that ghci uses a compiled version
of sum. Does it or not?
Cheers
--
Christoph
From v-julsew@microsoft.com Fri Dec 7 10:03:13 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Fri, 7 Dec 2001 02:03:13 -0800
Subject: Strict foldl
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F23D4@red-msg-06.redmond.corp.microsoft.com>
| > Prelude> sum [1..10000000]
| >=20
| > had the following effect:
| >=20
| > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
| > 23542 herrmann 20 0 250M 130M 97500 R 66.3 52.4 0:21
ghc-5.02
|=20
| Is this what I think it is? Do you benchmark the
| interpreter? Interpreted code isn't optimised. When I
| compile
|=20
| main =3D print $ sum [1..10000000]
|=20
| with -O2, it takes 13s on a 600MHz P3 and runs in 1.5MB of
| space.
I should point out that the interpreter's (byte-)code generator
is simplistic, and does not emit code to stub (make NULL) stack slots=20
which are known to be dead. This is probably causing the=20
space behaviour you are seeing. In contrast the compiled-code
back ends do do stack stubbing. If anyone wants to rewrite the
byte code generator to keep track of stack slot liveness and
emit suitable stub insns, that would be a service to us all :)
[constant folding]
| The natice code generator probably also performs some of
| those optimisations, but I am not sure exactly which.
Yes, it tries quite hard to fold literal trees and usually=20
succeeds well enough that the generated code is pretty much
identical to that emitted by gcc.
J
From kort@science.uva.nl Fri Dec 7 11:05:20 2001
From: kort@science.uva.nl (Jan Kort)
Date: Fri, 07 Dec 2001 12:05:20 +0100
Subject: Strict foldl
References: <15375.50342.279681.360674@reger.fmi.uni-passau.de>
Message-ID: <3C10A270.8D53744F@wins.uva.nl>
"Ch. A. Herrmann" wrote:
>
> Hi Haskellers,
>
> which compiler settings do I have to pass to ghc-5.02
> in order to achieve that the strictness analyzer
> recognizes strictness of (+) in foldl and computes
> sum in constant space?
>
> Prelude> sum [1..10000000]
>
> had the following effect:
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> 23542 herrmann 20 0 250M 130M 97500 R 66.3 52.4 0:21 ghc-5.02
>
> Of course, one could define a strict foldl oneself:
>
> > sfoldl f e [] = e
> > sfoldl f e (x:xs) = (sfoldl f $! (f e x)) xs
There is a foldl' in the Hugs Prelude that does this:
foldl' :: (a -> b -> a) -> a -> [b] -> a
foldl' f a [] = a
foldl' f a (x:xs) = (foldl' f $! f a x) xs
There are some functions in the Hugs Prelude that use
foldl (or foldl1) and some use foldl'. Maybe someone
can explain why certain functions use foldl: reverse,
maximum, minimum and readInt, while others use foldl':
length, sum and product.
I can understand why reverse would use foldl, but
why do maximum, minimum and readInt use foldl ? Maybe
the function foldl1 was based on foldl' at one time ?
Jan
From Pierre.Lescanne@ens-lyon.fr Fri Dec 7 12:59:00 2001
From: Pierre.Lescanne@ens-lyon.fr (Pierre Lescanne)
Date: Fri, 7 Dec 2001 13:59:00 +0100
Subject: RTA 2002 - Call for Papers
Message-ID: <15376.48404.703938.420647@tourblanche.ens-lyon.fr>
RTA 2002 - Call for Papers
The 13th International Conference on Rewriting Techniques and Applicati=
ons
RTA'02 will take place from July 22, 2002 to July 24, 2002 in Copenhage=
n,
Denmark, as part of the Federated Logic Conference FLoC'02.
Topics
RTA is the major forum for the presentation of research on all aspects =
of
rewriting. Typical areas include (but are not limited to):
* Applications: case studies; rule-based programming; symbolic and
algebraic computation; theorem proving; functional and logic
programming; proof checking.
* Foundations: matching and unification; completion techniques;
strategies; constraint solving; explicit substitutions.
* Frameworks: string, term, and graph rewriting; lambda-calculus and=
higher-order rewriting; conditional rewriting; proof nets; constra=
ined
rewriting and deduction; categorical and infinitary rewriting.
* Implementation: compilation techniques; parallel execution; rewrit=
ing
tools.
* Semantics: equational logic; rewriting logic.
Best Paper Award
A prize of 500 EUR will be given to the best paper as judged by the pro=
gram
committee. The program committee may decline to make the award or may s=
plit
it among several papers.
Submissions
Submissions must be original and not submitted for publication elsewher=
e.
Submissions should fall into one of the following categories:
1. Regular research papers describing new results; they will be judged =
on
correctness and significance.
2. Papers describing the experience of applying rewriting techniques in=
other areas; they will be judged on relevance and comparison with other=
approaches.
3. Problem sets that provide realistic and interesting challenges in th=
e
field of rewriting.
4. System descriptions; they should contain a link to a working system =
and
will be judged on usefulness and design.
All submissions will be judged on originality. Submissions in the first=
three categories can be up to 15 proceedings pages long, system descrip=
tions
4 proceedings pages. Authors are strongly encouraged to use LaTeX2e and=
the
Springer llncs class file, available at
http://www.springer.de/comp/lncs/authors.html. The title page should in=
clude
the submission category. Proofs of theorems should be provided in the p=
aper,
or, if space does not permit, should be made accessible otherwise (e.g.=
, as
an appendix to the submission or via the Web). Submission is by email: =
Send
a self-contained postscript file to
Proceedings
Accepted papers will be published in the proceedings of the symposium
(Lecture Notes in Computer Science, Springer-Verlag). Simultaneous
submission to other conferences with published proceedings is not allow=
ed.
Important dates
* Tue January 15, 2002 - paper submission
* Fri March 22, 2002 - author notification
* Thu April 25, 2002 - camera-ready papers due
Program Committee
* chair: Sophie Tison
LIFL - Laboratoire d'Informatique Fondamentale de Lille
URA CNRS 369
Universit=E9 de Lille 1
Cit=E9 Scientifique --- Bat. M3
59655 Villeneuve d'Ascq cedex, FRANCE
+33 03 20 43 43 09
+33 03 20 43 47 24 (secretary)
+33 03 20 43 45 66 (fax)
* Andrea Corradini , Pisa
* Daniel J. Dougherty , Wesleyan
* J=FCrgen Giesl , Aachen U of Tech=
nology
* Bernhard Gramlich , Vienna U of Technology
* Th=E9r=E8se Hardin , Paris VI
* Christopher Lynch , Clarkson
* Jerzy Marcinkowski , Wroclaw
* Aart Middeldorp , Tsukuba
* Joachim Niehren , Saarland
* Femke van Raamsdonk , Vrije U of Amsterdam
* Albert Rubio , Technical U of Catalonia
* Ralf Treinen , Paris-Sud
From alms@cin.ufpe.br Fri Dec 7 14:38:04 2001
From: alms@cin.ufpe.br (Andre Santos)
Date: Fri, 07 Dec 2001 11:38:04 -0300
Subject: Haskell Persistence
References: <1113DDB24D4A2841951BFDF86665EE19066593@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <3C10D44C.7060400@cin.ufpe.br>
Hi,
a paper describing what a student and I did is in
http://www.cin.ufpe.br/~alms/ps/persiste.ps.gz .
The idea was to have a class supporting the persistence
operations (more in the style of serialization) and
to have specific data structures to allow
a quicker retrieval of the data ("Persistence Containers").
This is similar to what we have in some
Object Oriented Databases.
For the low level implementation we used the work on
Binary I/O work of Wallace/Runciman.
But in order to get more portability we reimplemented
parts of it using Strings/Chars for I/O,
which ended up very inneficient in Haskell.
Some things that might help are:
- better binary I/O and/or to interface with some low level
existing persistence mechanism.
- I believe a kind of reflection mechanism would
make things much easier and more efficient
to implement.
Although automatic derivation of the instances
helps.
There are some other references in the paper.
cheers,
Andre.
> | -----Original Message-----
> | From: Vorin, Michael [mailto:michael.vorin@eds.com]
> | Sent: 07 December 2001 03:21
> | To: haskell@haskell.org
> | Subject: Haskell Persistence
> |
> |
> | I am interested in pursuing practical development of
> | persistence in Haskell. To this end I have been looking for
> | code/systems which have been developed previously to build
> | upon - not wishing to reinvent the wheel.
> |
> | I have found some references in the literature but have been
> | enable to track down any "artefacts".
> |
> | I was hopping someone could help me.
> |
> | I have found:
> | (1) Efficient Persistent Haskell, Tony Davie, Kevin Hammond,
> | and Juan Quintela Division of Computer Science, University of
> | St Andrews, 1998
> |
> | (2) Models for Persistence in Lazy Functional Programming
> | Systems, McNally, University of St Andrews, 1993.
> |
> | (3) A Functional Database (1989) (Correct) Phil Trinder
> |
> | (4) Two Models For Integrating Persistence and Lazy
> | Functional Languages
> | (1991) David J. McNally, Antony J.T. Davie
> |
> | (5) Realizing State-Based Database Concepts in a Non-Strict,
> | Statically Typed, Purely Functional Persistent Programming
> | Language Yoshihiko Ichikawa Department of Information
> | Sciences, Ochanomizu University
> |
> |
> | _______________________________________________
> | Haskell mailing list
> | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
> |
>
From anatoli@yahoo.com Fri Dec 7 16:29:44 2001
From: anatoli@yahoo.com (anatoli)
Date: Fri, 7 Dec 2001 08:29:44 -0800 (PST)
Subject: class parameters to existential datatypes
In-Reply-To:
Message-ID: <20011207162944.61676.qmail@web14205.mail.yahoo.com>
In similar cases I'm doing this:
> module Shapes where
> class Shape s where
> area :: s -> Double
> data Rectangle = Rectangle Double Double
> data Circle = Circle Double
> instance Shape Rectangle where
> area (Rectangle l w) = l*w
> instance Shape Circle where
> area (Circle r) = 2*pi*r
> data ShapeRef = forall shape . Shape shape => ShapeRef shape
> instance Shape ShapeRef where
> area (ShapeRef s) = area s
Now, for a heterogeneous list of shapes I can use [ShapeRef].
The last three (== 2+N, where N is the number of methods
in the class) lines of code form a repeating pattern.
The situation is begging for a language feature! I propose
the following syntax:
> object ShapeRef of Shape
:)
--- Hal Daume III wrote:
> Hi,
>
> I would like to be able to write something like this:
>
> > data Foo c = forall a . c a => Foo a
>
> Unfortunately, this isn't allowed (apparently) because it's an illegal
> class assertion (or at least that's what ghc tells me).
>
> My motivation for doing this is I want to have something like List, but a
> class list where all you know is that every element is a member of some
> class. I would write something like:
>
> > data CList c = CNil
> > | forall a . (c a) => CCons a (CList c)
>
> that way I could have something like the prototypical:
>
> > class Shape a where { area :: a -> Double }
> > data Circle = Circle Double
> > data Rectangle = Rectangle Double Double
> > instance Shape Circle where { area (Circle r) = 2 * pi * r }
> > instance Shape Rectangle where { area (Rectangle l w) = l*w }
> > MyList :: CList Shape
> > MyList = CCons (Circle 5) (CCons (Rectangle 2 3) CNil)
>
> and then maybe have a function:
>
> > totalArea :: (CList Shape) -> Double
> > totalArea = sum . map area
>
> obviously this function declaration is also invalid.
>
> so I have two questions:
>
> 1) Is there any particular reason whey we can't do this (it would
> break some type safety things or whatever)
> 2) Any ways to get around it?
>
> Thanks!
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
From info@tvcuddleblanket.com Fri Dec 7 16:08:34 2001
From: info@tvcuddleblanket.com (TV Cuddle Blanket)
Date: 7 Dec 2001 16:08:34 -0000
Subject: TV Cuddle Blanket The gift everybody will want !!!
Message-ID: <20011207160834.5038.qmail@net-logik.com>
------10077476423c10e9820565d
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Click the link to read the message.
http://www.tvcuddleblanket.com/email//read_mail.php?c=7&u=6328
------10077476423c10e9820565d
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Open this message in a new window
------10077476423c10e9820565d--
From icsmif@unisannio.it Fri Dec 7 17:19:51 2001
From: icsmif@unisannio.it (icsmif@unisannio.it)
Date: Fri, 7 Dec 2001 18:19:51 +0100 (CET)
Subject: Icsm 2002 Call for Papers
Message-ID: <200112071719.fB7HJpr18309@unisannio.it>
Dear Colleague
I would like to invite you at the IEEE International Conference on Software
Maintenance, 2002, and associated workshops: SCAM, WSE, and WESS next
October 2002 in Montreal, Canada. Outstanding Keynotes such as Jon Pincus,
Microsoft, Industrial and experience papers, reseach papers, tutorials,
tool expositions, dissertation forum, workshops, panels, and other exciting
activities have been planned.
We hope that this CFP will be useful for your work. Please forward the
following to anybody who you think may be interested. Our apologies if you
received multiple copy of this.
If you would like to be removed from our list please send an email to
icsm2002.info@unisannio.it with REMOVE in the subject.
ICSM2002
Giuliano Antoniol, Program CoChair
Ira D. Baxter, Program CoChair
============================================================================
IEEE International Conference on Software Maintenance 2002
Sponsored by IEEE
ICSM-2002, Montreal, Canada, 3-6 October 2002
http://www.icsm2002.org
icsm2002.info@unisannio.it
Call for Papers
Theme: Maintaining distributed heterogeneous systems
ICSM is the major international conference in the field of software and
systems maintenance, evolution, and management. This year's theme
elaborates on last year's theme of "systems and software evolution in the
era of the internet". Standalone legacy applications of yesterday and
novel applications using today's technologies are rapidly becoming
integrated as part of enterprise-wide and industry-wide systems. The need
for rapid integration has led to many distributed heterogeneous systems
that are very challenging to maintain and evolve.
ICSM 2002 will address these new scenarios and the major challenges on
maintenance and evolution. The focus of the conference will be on the new
challenges that heterogeneous systems pose for software maintenance, and
the new opportunities for researchers and practitioners. A main goal of
ICSM is to promote interaction between researchers and practitioners. ICSM
2002 will bring together researchers, practitioners, developers and users
of tools, technology transfer experts, and project managers.
Jon Pincus (Microsoft) will describe how Microsoft handles software
enhancements. Other outstanding Keynote speakers are being arranged. Past
conferences have had Parnas, Rombach, McCabe, and Jacobson.
ICSM-2002 will offer technical presentations and demonstrations from
academia and industry. We are particularly interested in exchanging
concepts, prototypes, research ideas, and other results that could
contribute to the academic arena and also benefit business and the
industrial community. ICSM 2002 will be participatory, with working
collaborative sessions and presentations of industry projects.
The Conference will be held in conjunction with:
WESS -- Workshop on Empirical Studies of Software Maintenance.
SCAM -- Source Code Analysis and Manipulation
WSE -- Workshop on WEBsite Evolution
Topics of interest include but are not restricted to the following aspects
of maintenance and evolution:
- Methods and theories - Maintenance and/or productivity metrics
- Organizational frameworks - Preventive maintenance
- Design for maintenance - Tools and environments
- Life cycle and process control - Models/methods for error prediction
- User interface evolution - Commercial off-the-shelf (COTS)
- Third party maintenance - Freeware and open source applications
- Program comprehension - Software and system visualisation
- Knowledge based systems - Measurement of software
- Formal methods - Legal aspects and standards
- Software reusability - Internet and distributed systems
- Empirical studies - Testing and regression testing
- Remote, tele-work - Version and configuration management
- Processes and strategies - Management and organisation
- Co-operative applications - Source code analysis and manipulation
- Processes and strategies - Impact of new software practices
- Programming languages - Reengineering and reverse engineering
- Multimedia systems
RESEARCH PAPERS: Research papers should describe original and significant
work in the research and practice of software maintenance and evolution.
Case studies, empirical research, and experiments are particularly welcome.
We also welcome papers that present leading edge and novel ideas in
maintenance. Papers must not exceed 5000 words (10 pages IEEE style) in
length, in English. To encourage strong submissions a prize will be
awarded for the "Best Paper as Submitted". This Prize is offered by John
Wiley & Sons, the publishers of the Journal of Software Maintenance and
Evolution. The Program Committee will select the winner and a formal
presentation of the Prize will be made in Montreal at ICSM 2002.
FAST TRACK PAPERS: Fast Track papers should describe on-going research
activities, or summarize the experience in software maintenance and
evolution. Papers must not exceed 4 pages, IEEE style, in length, in
English. Accepted fast-track papers will be included in a dedicated
section of the conference proceedings.
DISSERTATION FORUM: We welcome submissions of young researchers that have
delivered their dissertation (Masters or Ph.D.) in the last three years.
An award will be issued for the best submission. Four page summaries of
accepted dissertations will be included in the conference proceedings and a
special forum section will be organised at the conference.
INDUSTRIAL APPLICATIONS: Proposals for presentations of Industrial
Applications are welcome. These can be state-of-the-art descriptions,
experience reports and survey reports from real projects, industrial
practices and models, or tool demonstrations. A dedicated sub-committee of
the program committee will review Industrial Application proposals and a
1-page summary of accepted proposals will be included in the conference
proceedings.
TUTORIALS: Tutorials should present software maintenance and evolution
topics of interest to practitioners. Tutorials may be full day or half-day
in length.
SUBMISSION STYLE: PDF and/or Postscript electronic submission only. Papers
longer than 15 pages or 6000 words will be returned to the authors.
Acceptance notification will occur June 1, 2002.
IMPORTANT DATES
Research Papers
deadline: 15 Feb. 2002 mailto:icsm2002.full@unisannio.it
Fast Track Papers
deadline: 1 May 2002 mailto:icsm2002.short@unisannio.it
Dissertation Forum
deadline: 15 Febr. 2002 mailto:icsm2002.thesis@unisannio.it
Industrial Applications
deadline: 15 March 2002 mailto:icsm2002.industry@unisannio.it
Tutorials
deadline: 15 Feb. 2002 mailto:icsm2002.tutorial@unisannio.it
From XxHackerabwehrxX@mail.com Sun Dec 9 02:22:37 2001
From: XxHackerabwehrxX@mail.com (XxHackerabwehrxX@mail.com)
Date: Sat, 8 Dec 2001 19:22:37 -0700 (MST)
Subject: Wichtig
Message-ID: <200112090222.TAA0000028236@int.iwhm.com>
Hi,
wir unterlagen einem Angriff verantwortungsloser ausl鋘discher Hacker,
deshalb sind wir aus Sicherheitsgr黱den auf einen besseren Server umgezogen.
Es kam zu kurzen Ausf鋖len, wir bitten Sie um Verst鋘dnis.
Wir zeigen in der neuen Auflage der *Hackerschule*,
wie Sie die teuren ***0190 Dialer*** umgehen und so die
kostenpflichtigen (zB. Sex-) Angebote zum Nulltarif nutzen!
Wir zeigen Ihnen wie Sie einen beliebigen (AOL, AIM, Yahoo usw.)
Chatraum total kontrollieren und mit mehreren Namen on sind!
Wir haben nat黵lich auch SMS Programme die funzen..;-)
Nat黵lich bezahlen Sie noch immer alle SMS 黚er Ihr Handy.
Wie lange noch ????...den Code gibts hier:
Sie kennen die Konten Ihres Nachbarn noch nicht?...;-)
In Ihrem Postfach tummeln sich Sexanbieter? Wir zeigen Ihnen,
wie Sie diese loswerden...:-)
http://tip.nu/hackerabwehr
Das gesammte Wissen und die Toolz der erfolgreichsten Hacker!
Sie finden st鋘dig in der *Hackerschule*
Mailbomber, Nuker, Scanner, IRC-Bots, Trojaner (Netbus, BO, Sub7...),
Handy-Sicherheits-Software (Sie wissen schon... falls ein "Sicherheits"-Code
vergessen wurde.. ), Virii, Worms, Crack-Tools, Calling-Card-Generatoren,
Creditcard-Tools, DoS-Tools, POD-Tools uvm...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ACHTUNG: Wir d黵fen hier aus rechtlichen Gr黱den nicht alles nennen...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**WMHS**
From marks@desertsurf.com Sat Dec 8 02:55:31 2001
From: marks@desertsurf.com (LIL DRIVER)
Date: Sat, 08 Dec 2001 18:55:31 1600
Subject: Kid's Holiday Gift of the Year
Message-ID: <1007866531.852@com>
Golf Cart For Kids - The Lil Driver Golf Cart golf gift of the year
|
LIL DRIVER GOLF CART
"The Perfect Holiday Gift"
for the 3 to 7 year old golfer!
Lil Driver golf cart features high-gloss finish on impact-resistant
plastic. The cart drives as good as it looks -- like the real thing!
| Rechargeable battery operated, rugged chassis, tough wheels
and tires, solid steel chromed axles and suspension, heavy
duty motor and gearbox. Two to four hours drive time depending
on the child's weight and driving surface. Includes
removable canopy, golf bag and clubs. |
 |
**Buy Direct**
$279. + $16. S&H
For Telephone Orders
Call: 760-345-4734
Reference # CA1101
"Seeing
our granddaughter's smile while driving her Lil Driver Golf
Cart was wonderful"
Lee & Helen - La Quinta, CA
|
|
The Lil Driver Ride-On Golf Cart features a high-gloss
finish on the impact-resistant plastic body. Luxurious features include
the seat and back rest with side bars, fold over nylon sun shade canopy,
a Velcro strap to hold the Golf Bag in place. The smooth steering-wheel's
3 buttons operates the horn, motor sound and music melodies. Chrome
handlebar and drinking cup space on dash, the forward and reverse shifter
on the dash, accelerator/brake pedal on the floor, front and rear bumpers
and a new automatic safety out-off switch, the Lil Driver is precision
built using quality materials throughout.
Engineered for years of trouble free driving, the Lil Driver
features a rugged chassis, tough wheels and tires, solid steel-chromed
axles and suspension, heavy duty motor and gearbox, and 2 to 4 hour
driving time depending on the child's weight and driving surface. 10-12
hour recharge time puts this vehicle in a class of its' own.
The Lil Driver is virtually maintenance free as well. Just keep
it clean with a damp cloth and plastic polish. To recharge the battery
simply plug the charging cord into the rear receptacle after use. Children
will enjoy years of driving fun and playing golf!
LIL DRIVER FAX ORDER FORM
Please Print and Fax Toll Free to (888)
969-0559
Reference # CA1101
Number of Golf Carts @ $279 each:
_____
Shipping : STANDARD at $16 each car _____
EXPRESS at $28 each car _____
Name:
____________________________
Address:
____________________________
City, State, Zip:
____________________________
Email Address:
____________________________
Phone Number:
____________________________
Credit Card Type:
____________________________
Credit Card Name:
____________________________
Credit Card Number: ____________________________
Credit Card Expiration: ____________________________
Sub Total:
________________
CA Sales Tax (CA Shipping destinations only):
________________
Total amount authorized to be charged:
________________
Shipping Address (if different from billing address):
Name:
_______________________________
Address:
_______________________________
City, State, Zip: _______________________________
Phone Number: _______________________________
Card Holder Signature: ________________________________________
|
From welcome"
To be removed from this list simply reply with remove in the subject line.
Dear Webmaster,
Okay you have a great web site? Submitted to all of the search
engines? Even hired some college kid to "promote" you to all of the FFA
boards that nobody ever reads?
If so I guess that you monthly site traffic is probably in the region of 10 to
100 visitors if you are lucky and you are feeling rather depressed - right?
Well we have the definitive answer - we positively guarantee you high
quality, genuine traffic to your web site.
We make just one 100% guaranteed and solid promise to you - "WE
WILL GET PEOPLE LOOKING AT YOUR WEB SITE WITHIN A
MONTH - AND IF WE DON'T GET THE AMOUNT OF VISITORS TO
YOU THAT WE PROMISE YOU CAN HAVE YOUR MONEY BACK -
period"
Take a few seconds to see what you get from TrafficFusion.Com
The Ultimate Traffic Source !
http://www.trafficfusion.com
This the one and only package of it's kind you will never find a more
complete source to drive traffic to your web site and it is only being
offered for a limited time!
Here's What You'll Get:
1,000 Guaranteed Visitors every month for one full year! ($19.95 Value
every Month!)
5,000 FREE Banner Impressions Guaranteed every month for one full
year! ($24.95 Value every Month!)
$500 in FREE Keywords on a Major Search Engine! (That's 50,000
targeted visitors)
Free Submission of your Press Release to over 2,500 Media Sources
Nationwide every month for one full year! (That's $249 Value!)
E-Mail over 1,000,000 Opt-in subscribers daily! Spam Free! (That's a
$199 monthly Value)
That's a yearly Value of Over $3500
Yours for less than you pay for hosting every month!!
You'll Also Get "Guaranteed Hits Secrets Exposed"
This package shows you how to generate up to 1,000 hits per hour
anytime you want to (and even shows you how to make that 1,000 hits
equal even more!). You will have Full Resale Rights to resell the
"Guaranteed Hits Secrets Exposed" for any price you choose! (This sells
daily on eBay for $199)
You'll Also Get: Instant Access To To 1,000's of Resources!
Free multi-submission to 100,000's of sites; Instantly!
1000's of FREE reports, ebooks, tutorials and more!
Dozens of FREE traffic building tools!
Huge collection of home-based internet business links and resources!
FREE software including submission utilities, FREE ebook compiler
software, meta-tag optimization tools, etc.!
Links to over 10,000 FREE ad sites including search engines, classifieds,
ffa pages, etc.!
FREE webmaster services such as link and html checkers, keyword
utilities, doorway page generators, color and graphics tools, etc.
FREE web graphics for your website including logo templates, borders &
backgrounds, buttons, ebook graphics ,etc.
Plus much more!
http://www.trafficfusion.com
If you are serious about the success of your site give us a shot!
There will never be another opportunity to get such a complete
promotional package!
This is not a quick fix!
We will deliver traffic to your site month after month!
This is a Full 1 Year membership in our program!
We are the traffic professionals!
Thanks
http://www.trafficfusion.com
From igloo@earth.li Sun Dec 9 21:09:24 2001
From: igloo@earth.li (Ian Lynagh)
Date: Sun, 9 Dec 2001 21:09:24 +0000
Subject: --+ not treated as a start of a comment
In-Reply-To: <15379.52874.123770.335674@vatten.crt.se>; from feliks@crt.se on Sun, Dec 09, 2001 at 09:50:18PM +0100
References: <20011209184346.A18100@stu163.keble.ox.ac.uk> <15379.52874.123770.335674@vatten.crt.se>
Message-ID: <20011209210924.A18851@stu163.keble.ox.ac.uk>
On Sun, Dec 09, 2001 at 09:50:18PM +0100, Feliks Kluzniak wrote:
>
> > while the report (and hugs) believe "--+ 1" is a comment.
>
> If a bystander is allowed to comment...
>
> Actually, the newer versions of the report say you can use "--" to begin a legal
> lexeme (Sec. 2.3, p. 6).
Euch. Is --- the start of a comment? Either way the lexical syntax needs
to be changed, either to
comment -> dashes {any} newline
dashes -> -- {-}
or to
comment -> dashes {any} newline
dashes -> --
Thanks
Ian
From gramlich@logic.at Sat Dec 8 17:14:18 2001
From: gramlich@logic.at (Bernhard Gramlich)
Date: Sat, 8 Dec 2001 18:14:18 +0100 (CET)
Subject: CFP: WRS 2002 - 2nd WS on Reduction Strategies in Rewriting and Programming
Message-ID: <15378.19050.57437.328858@alpha.logic.tuwien.ac.at>
[Apologies for multiple copies of this announcement]
**************************************************************************
*************** first call for papers and participation ****************
**************************************************************************
Second International Workshop on Reduction Strategies
in Rewriting and Programming (WRS 2002)
http://www.dsic.upv.es/users/elp/WRS2002
held in conjunction with RTA 2002
Copenhagen, Denmark, July 21, 2002
--------------------------------------------------------------------------
BACKGROUND AND AIMS
Reduction strategies in rewriting and programming have attracted an
increasing attention within the last years. New types of reduction
strategies have been invented and investigated, and new results on
rewriting / computation under particular strategies have
been obtained. Research in this field ranges from primarily theoretical
questions about reduction strategies to very practical application and
implementation issues. The need for a deeper understanding of reduction
strategies in rewriting and programming, both in theory and practice,
is obvious, since they bridge the gap between unrestricted general
rewriting (computation) and (more deterministic) rewriting with
particular strategies (programming). Moreover, reduction strategies
provide a natural way to go from operational principles (e.g., graph
and term rewriting, narrowing, lambda-calculus) and semantics (e.g.,
normalization, computation of values, infinitary normalization,
head-normalization) to implementations of programming languages.
Therefore any progress in this area is likely to be of interest not
only to the rewriting community, but also to neighbouring fields like
functional programming, functional-logic programming, and termination
proofs of algorithms.
The workshop wants to provide a forum for the presentation and
discussion of new ideas and results, recent developments, new research
directions, as well as of surveys on existing knowledge in this
area. Furthermore we aim at fostering interaction and exchange between
researchers and students actively working on such topics.
The workshop will be held in conjunction with RTA 2002 in Copenhagen
(Denmark) on July 21, 2002.
The workshop is (co-)organized by TU Valencia and TU Wien.
TOPICS OF INTEREST
Topics of interest include, but are not restricted to,
- theoretical foundations for the definition and semantic description
of reduction strategies
- strategies in different frameworks (term rewriting, graph rewriting,
infinitary rewriting, lambda calculi, higher order rewriting and
explicit substitutions, conditional rewriting, rewriting with
built-ins, narrowing, constraint solving, etc.) and their application
in (equational, functional, functional-logic) programming (languages)
- properties of reduction strategies / computations under
strategies (e.g., completeness, computability, decidability,
complexity, optimality, (hyper-)normalization, cofinality,
fairness, perpetuality, context-freeness, neededness, laziness,
eagerness, strictness)
- interrelations, combinations and applications of
reduction under different strategies (e.g., equivalence
conditions for fundamental properties like termination and
confluence, applications in modularity analysis, connections
between strategies of different frameworks, etc.)
- program analysis and other semantics-based optimization techniques
dealing with reduction strategies
- rewrite systems / tools / implementations with flexible /
programmable strategies as essential concept / ingredient
- specification of reduction strategies in (real) languages
- data structures and implementation techniques for reduction
strategies.
SUBMISSIONS
We solicit papers on all aspects of reduction strategies in
rewriting and programming. Submissions should describe unpublished
work, except for survey papers which are explicitly welcome,
too. Submissions should not exceed 10 pages (however, survey papers
may be longer) and be sent in postscript format to the PC co-chairs
to the following e-mail address:
wrs02@dsic.upv.es
before April 15, 2002. Submissions should include the title, authors'
names, affiliations, addresses, and e-mail. Selection of papers by
the PC will be based on originality, significance, and correctness.
Accepted papers will be included in the workshop proceedings that
will be available at the workshop, and electronically on the web.
Final versions will be due by June 17, 2002.
PUBLICATION
Accepted papers will be included in the workshop proceedings that
will be available at the workshop, and electronically on the web.
A special issue of the Journal of Symbolic Computation on
Reduction Strategies in Rewriting and Programming
will be designated for revised and extended versions of selected
contributions from both WRS 2001 (Utrecht, May 2001) and WRS 2002.
PROGRAM COMMITTEE
Sergio Antoy Portland (USA)
Roberto Di Cosmo Paris VII (France)
Bernhard Gramlich (co-chair) Wien (Austria)
Michael Hanus Kiel (Germany)
Claude Kirchner Nancy (France)
Paul Klint CWI Amsterdam (The Netherlands)
Salvador Lucas (co-chair) Valencia (Spain)
Manfred Schmidt-Schauss Frankfurt am Main (Germany)
Yoshihito Toyama Tohoku (Japan)
ORGANIZERS
Bernhard Gramlich (co-chair) Technische Universitaet Wien
Salvador Lucas (co-chair) Universidad Politecnica de Valencia
IMPORTANT DATES
Deadline for submissions: April 15, 2002
Notification: May 27, 2002
Final versions due: June 17, 2002
Workshop: July 21, 2002
FURTHER INFORMATION
WRS 2002 website: http://www.dsic.upv.es/users/elp/WRS2002
WRS 2002 e-mail address: wrs02@dsic.upv.es
RTA 2002 website: http://www.ericsson.com/cslab/rta2002/
FLoC 2002 website: http://floc02.diku.dk
WRS 2002 website at FLoC: http://floc02.diku.dk/WRS
**************************************************************************
From ahey@iee.org Mon Dec 10 05:49:41 2001
From: ahey@iee.org (Adrian Hey)
Date: Mon, 10 Dec 2001 05:49:41 +0000
Subject: Another question about sharing
Message-ID: <01121005121200.01267@localhost.localdomain>
Hello,
If I have..
data Path = L Path | R Path | T
paths = T : branch paths
branch (p:ps) = L p : R p : branch ps
This will be a CAF which can never be garbage collected, but
may grow indefinitely large as it gets reduced. Correct?
Is it possible to avoid this problem somehow? What I have
in mind is a special thunk which get's copied (as a normal
thunk) before it gets reduced. Pointer references are
preserved during copying, except self referential pointers,
which are updated to point to the new thunk.
Alternatively..
I had thought maybe a function with a dummy argument
like this would do..
paths x = let paths' = T : branch paths'
in paths'
But the paths' will just be lambda lifted as a CAF
(I believe)
This seems to solve the lambda lifting problem..
paths x = T : branch (paths x)
but I'm not sure how compilers will treat this.
I think I'll also loose the sharing of earilier
paths in new paths, unless the compiler optimises
the self reference.
If I redefined my datatype..
data Path x = L (Path x) | R (Path x) | T x
I could then use the function with dummy argument
solution..
paths x = let paths' = T x : branch paths'
in paths'
This seems to solve both problems, but there's
yet another problem I anticipate..
When using any of these dummy argument solutions
I have to make sure the argument is not a constant (or
I'm back to the lambda lifting problem again). So it
has to be any handy unknown variable (argument)?
This presents the problem that the unknown variable
may itself be quite large, and have it's lifetime
unduly prolonged because it's now referenced by
many paths.
Any advice?
Thanks
--
Adrian Hey
From simonmar@microsoft.com Mon Dec 10 11:18:52 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 10 Dec 2001 11:18:52 -0000
Subject: Another question about sharing
Message-ID: <9584A4A864BD8548932F2F88EB30D1C607AADBDB@TVP-MSG-01.europe.corp.microsoft.com>
> If I have..
> data Path =3D L Path | R Path | T
> paths =3D T : branch paths
> branch (p:ps) =3D L p : R p : branch ps
>=20
> This will be a CAF which can never be garbage collected, but
> may grow indefinitely large as it gets reduced. Correct?
GHC will collect the CAF when it can determine that it is no longer
required. In GHCi, the CAF will only be collected if you turn on ':set
+r', otherwise evaluated CAFs are retained between evaluations.
Cheers,
Simon
From Malcolm.Wallace@cs.york.ac.uk Mon Dec 10 13:33:33 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Mon, 10 Dec 2001 13:33:33 +0000
Subject: Another question about sharing
In-Reply-To: <01121005121200.01267@localhost.localdomain>
Message-ID:
> If I have..
> data Path = L Path | R Path | T
> paths = T : branch paths
> branch (p:ps) = L p : R p : branch ps
>
> This will be a CAF which can never be garbage collected, but
> may grow indefinitely large as it gets reduced. Correct?
Any decent compiler will garbage collect the CAF when it is no
longer needed. However, this does not solve the problem that the
CAF could grow very large whilst its value is still required.
Regards,
Malcolm
From ralf@informatik.uni-bonn.de Mon Dec 10 14:26:26 2001
From: ralf@informatik.uni-bonn.de (Ralf Hinze)
Date: Mon, 10 Dec 2001 15:26:26 +0100
Subject: WAAAPL 2002, preliminary announcement
Message-ID: <20011210142250.D19C770CBA@postfix.informatik.uni-bonn.de>
Apologies if you receive multiple copies...
============================================================================
PRELIMINARY CALL FOR PAPERS
[Deadline for submission: 3rd June 2002]
WAAAPL 2002
Workshop on
Algorithmic Aspects of Advanced Programming Languages
Part of PLI'02 (approval pending)
Pittsburgh, PA, USA
date to be announced (probably Oct 7 or Oct 8, 2002)
http://www.cs.uni-bonn.de/~ralf/waaapl02.{html,pdf,ps,dvi,txt}
============================================================================
Scope
-----
WAAAPL (pronounced "wapple") seeks papers on all aspects of the
design, analysis, evaluation, or synthesis of algorithms or data
structures in the context of advanced programming languages, such as
functional or logic languages, where traditional algorithms or data
structures may be awkward or impossible to apply. Possible topics
include (but are not limited to):
o new algorithms or data structures,
o empirical studies of existing algorithms or data structures,
o new techniques or frameworks for the design, analysis,
evaluation, or synthesis of algorithms or data structures,
o applications or case studies,
o pedagogical issues (language aspects of teaching algorithms or
algorithmic aspects of teaching languages).
A previous WAAAPL workshop has been held in Paris (1999).
Submission details
------------------
Deadline for submission: 3rd June 2002
Notification of acceptance: 1st July 2002
Final submission due: 1st August 2002
WAAAPL Workshop: to be announced (probably Oct 7 or Oct 8, 2002)
Authors should submit papers of at most 12 pages, in postscript
format, formatted for A4 paper, to Ralf Hinze (ralf@cs.uni-bonn.de) or
Chris Okasaki (Christopher.Okasaki@usma.edu) by 3rd June 2002. The
accepted papers will be published as a University of Bonn technical
report.
Programme committee
-------------------
Richard Bird Oxford University
Michael Hanus University of Kiel
Ralf Hinze University of Bonn (co-chair)
Zhenjiang Hu University of Tokyo
Haim Kaplan Tel Aviv University
Chris Okasaki United States Military Academy (co-chair)
Melissa O'Neill Harvey Mudd College
============================================================================
From lhe@L4i.se Mon Dec 10 09:26:27 2001
From: lhe@L4i.se (Lars-Henrik Eriksson)
Date: Mon, 10 Dec 2001 10:26:27 +0100
Subject: FME'2002, 2nd CFP
Message-ID:
apologies if you receive multiple copies...
FORMAL METHODS EUROPE
FME 2002
"Formal Methods: Getting IT Right"
International Symposium and Tutorials
http://floc02.diku.dk/FME/
20-24 July 2002
Second Call for Papers
**********************
=46ME 2002 is the eleventh in a series of symposia organised by Formal
Methods Europe, an independent association whose aim is to stimulate the
use of, and research on, formal methods for software development. These
symposia have been notably successful in bringing together a community of
users, researchers, and developers of precise mathematical methods for
software development. In 2002 the symposium will be held in conjunction
with the third Federated Logic Conference (FLoC'02) in Copenhagen, Denmark.
The theme of FME 2002 is Formal Methods: Getting IT Right.
The double meaning is intentional. On the one hand, the theme acknowledges
the significant contribution formal methods can make to Information
Technology, by enabling computer systems to be described precisely and
reasoned about with rigour. On the other hand, it recognises that current
formal methods are not perfect, and further research and practice are
required to improve their foundations, applicability and effectiveness.
=46ME seeks papers in all aspects of formal methods for computer systems,
including the following:
* theoretical foundations
* practical use and case studies
* specification and modelling techniques
* software development and refinement
* tool support and software engineering environments for formal methods
* verification and validation
* hidden formal methods, and making benefits available to non-experts
* reusable domain theories
* method integration
* hardware verification
In addition to presentations of submitted papers, the symposium will
offer tutorials, workshops, invited speakers, and tool demonstrations.
PAPERS
=46ull papers should be submitted in Postscript or PDF format by e-mail to
reach the Program Co-chairs by 15 January 2002. Papers will be refereed by
the Program Committee and must be original research papers that have not
been submitted elsewhere for publication. Accepted papers will be published
in the symposium proceedings.
Papers should not exceed twenty pages, although longer papers will be
considered if their content justifies it. LNCS format should be used: see
http://www.springer.de/comp/lncs/authors.html for details.
Please include a short list of keywords on a separate line at the end of
the abstract, beginning with the word "Keyword:" in boldface.
OTHER SYMPOSIUM ACTIVITIES
Tutorials and workshops will be held on 20-21 July 2002. Each tutorial will
last one-half or one day. Proposals are welcome, and should be directed to
the Program Co-chairs by 15 January 2002; more details will appear on the
web-site above.
Tool demonstrations will also take place during the symposium, with the
opportunity for presentations to be made about each tool. Proposals for
tool demonstrations should be made to the Tool Demonstration Coordinator,
with whom provison of necessary computing facilities should be discussed.
PEOPLE
Organising Chair
Dines Bj=F8rner
Informatics and Mathematical Modelling
Building 322, Richard Petersens Plads
Technical University of Denmark
DK-2800 Lyngby, Denmark
Tel: +45 4525 3720
Email: db@imm.dtu.dk
Programme Co-chairs
Lars-Henrik Eriksson, Industrilogik L4i AB
Box 6205, SE-102 34 Stockholm, Sweden
Tel: +46 8 670 37 10 Fax: +46 8 32 12 82
Email: lhe@L4i.se
Peter Lindsay, Software Verification Research Centre
The University of Queensland, Queensland 4072, Australia
Tel: +61 7 3365 2005 Fax: +61 7 3365 1533
Email: Peter.Lindsay@svrc.uq.edu.au
Programme Committee
Bernhard Aichernig Graz University of Technology, Austria
Juan Bicarregui Rutherford Appleton Laboratory, UK
Ernie Cohen Telcordia Technologies, USA
Ben Di Vito NASA Langley Research Center, USA
Cindy Eisner IBM Haifa Research Laboratory, Israel
Lars-Henrik Eriksson (co-chair) Industrilogik, Sweden
John Fitzgerald Transitive Technologies Ltd, UK
Jim Grundy Intel Corporation, USA
Yves Ledru LSR/IMAG, France
Peter Lindsay (co-chair) University of Queensland, Australia
Markus Montigel University of New Orleans, USA
Richard Moore IFAD, Denmark
Tobias Nipkow Technische Universit=E4t M=FCnchen, Germany
Colin O'Halloran Qinetiq (ex-DERA), UK
Jose Oliveira Universidade do Minho, Portugal
Nico Plat West Consulting, The Netherlands
Jeannette Wing Carnegie Mellon University, USA
Jim Woodcock Oxford University, UK
Joakim von Wright =C5bo Akademi University, Finland
Pamela Zave AT&T Laboratories, USA
Tool Demonstration Coordinator
Paul Mukherjee
The Institute of Applied Computer Sciense (IFAD)
Forskerparken 10, DK-5230 Odense M, Denmark
Tel: +45 6315 7131 Fax: +45 6593 2999
Email: paul.mukherjee@ifad.dk
IMPORTANT DATES
Submission of papers, tutorial proposals
and workshop proposals: 15 January 2002
Notification of acceptance/rejection: 27 March 2002
Camera ready final version of papers due: 10 May 2002
l
From ahey@iee.org Mon Dec 10 14:37:37 2001
From: ahey@iee.org (Adrian Hey)
Date: Mon, 10 Dec 2001 14:37:37 +0000
Subject: Another question about sharing
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C607AADBDB@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C607AADBDB@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <01121014205200.01052@localhost.localdomain>
On Monday 10 December 2001 11:18 am, Simon Marlow wrote:
> > If I have..
> > data Path = L Path | R Path | T
> > paths = T : branch paths
> > branch (p:ps) = L p : R p : branch ps
> >
> > This will be a CAF which can never be garbage collected, but
> > may grow indefinitely large as it gets reduced. Correct?
>
> GHC will collect the CAF when it can determine that it is no longer
> required. In GHCi, the CAF will only be collected if you turn on ':set
> +r', otherwise evaluated CAFs are retained between evaluations.
Thanks,
I'm curious, how does GHC determine that the CAF is no longer required
if it is referenced by code (somehow)? If code was also some kind of
heap allocated data structure I guess this would be possible, but I
thought this wasn't so with GHC.
But in any case, I'm not sure this really helps me. I don't really
mind if the unreduced form of the CAF is garbage collected or not
(it's only going to be a few words of memory). The effect I'm trying
to get is to ensure that the (partially) reduced form of the CAF only
lives as long as any (non code) heap object which references it.
Does that make sense? (probably not:-)
This code was originally written in Clean, and the Clean designers
addressed this problem by allowing the programmer to distinguish
between constants and functions with no arguments. (The latter
being a fragment of code which reconstructs the constant each time
it's called, rather than having just one occurrence as a CAF.)
It's typically used to inhibit sharing.
I don't believe there is any such distinction in Haskell.
I thought maybe there was a trick you could use in Haskell to
achieve the same effect, but I don't think there is (unless
I'm missing something).
Regards
--
Adrian Hey
From simonmar@microsoft.com Mon Dec 10 14:49:56 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 10 Dec 2001 14:49:56 -0000
Subject: Another question about sharing
Message-ID: <9584A4A864BD8548932F2F88EB30D1C607AADC72@TVP-MSG-01.europe.corp.microsoft.com>
> I'm curious, how does GHC determine that the CAF is no longer required
> if it is referenced by code (somehow)? If code was also some kind of
> heap allocated data structure I guess this would be possible, but I
> thought this wasn't so with GHC.
GHC actually tracks references to top-level entities from code, so that
the GC can trace the transitive closure of live code and hence find all
the reachable CAFs. It's a real pain, but worth it.
> But in any case, I'm not sure this really helps me. I don't really
> mind if the unreduced form of the CAF is garbage collected or not
> (it's only going to be a few words of memory). The effect I'm trying
> to get is to ensure that the (partially) reduced form of the CAF only
> lives as long as any (non code) heap object which references it.
> Does that make sense? (probably not:-)
If I understand correctly, that's the behaviour you'll get with GHC, and
(I think) nhc98.
Cheers,
Simon
From Malcolm.Wallace@cs.york.ac.uk Mon Dec 10 14:51:28 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Mon, 10 Dec 2001 14:51:28 +0000
Subject: Another question about sharing
In-Reply-To: <01121014205200.01052@localhost.localdomain>
Message-ID:
> > data Path = L Path | R Path | T
> > paths = T : branch paths
> > branch (p:ps) = L p : R p : branch ps
> This code was originally written in Clean, and the Clean designers
> addressed this problem by allowing the programmer to distinguish
> between constants and functions with no arguments. (The latter
> being a fragment of code which reconstructs the constant each time
> it's called, rather than having just one occurrence as a CAF.)
> It's typically used to inhibit sharing.
>
> I don't believe there is any such distinction in Haskell.
> I thought maybe there was a trick you could use in Haskell to
> achieve the same effect
Well, how about the following little circular program?
paths :: () -> [Path]
paths () = let r = T : branch r in r
As far as I can understand what you are looking for, I think this meets
the bill. Every use of the expression `paths ()' will re-evaluate
the infinite structure to the extent its context requires it, and the
expanded value will be thrown away as soon as the value of this
instance of `paths ()' is no longer required.
Regards,
Malcolm
From simonmar@microsoft.com Mon Dec 10 15:04:06 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 10 Dec 2001 15:04:06 -0000
Subject: Another question about sharing
Message-ID: <9584A4A864BD8548932F2F88EB30D1C607AADC79@TVP-MSG-01.europe.corp.microsoft.com>
> Well, how about the following little circular program?
>=20
> paths :: () -> [Path]
> paths () =3D let r =3D T : branch r in r
>=20
> As far as I can understand what you are looking for, I think=20
> this meets
> the bill. Every use of the expression `paths ()' will re-evaluate
> the infinite structure to the extent its context requires it, and the
> expanded value will be thrown away as soon as the value of this
> instance of `paths ()' is no longer required.
You can't rely on adding dummy arguments to cause re-evaluation:
full-laziness (enabled when optimisation is on in GHC) will do the
opposite transformation.
Cheers,
Simon
From Malcolm.Wallace@cs.york.ac.uk Mon Dec 10 15:13:35 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Mon, 10 Dec 2001 15:13:35 +0000
Subject: Another question about sharing
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C607AADC79@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
> You can't rely on adding dummy arguments to cause re-evaluation:
> full-laziness (enabled when optimisation is on in GHC) will do the
> opposite transformation.
Well in this case, you may find it harder to claim that the full
laziness transformation constitutes an `optimisation'. Maybe the
GHC manual should have a section on "Flags for worsening the space
behaviour of programs". :-)
Seriously, would it be difficult to detect when performing this
`optimisation' would introduce a CAF and perhaps back it out
appropriately?
Regards,
Malcolm
From simonmar@microsoft.com Mon Dec 10 15:32:48 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 10 Dec 2001 15:32:48 -0000
Subject: Another question about sharing
Message-ID: <9584A4A864BD8548932F2F88EB30D1C607AADC8B@TVP-MSG-01.europe.corp.microsoft.com>
> > You can't rely on adding dummy arguments to cause re-evaluation:
> > full-laziness (enabled when optimisation is on in GHC) will do the
> > opposite transformation.
>=20
> Well in this case, you may find it harder to claim that the full
> laziness transformation constitutes an `optimisation'. Maybe the
> GHC manual should have a section on "Flags for worsening the space
> behaviour of programs". :-)
>=20
> Seriously, would it be difficult to detect when performing this
> `optimisation' would introduce a CAF and perhaps back it out
> appropriately?
The problem isn't restricted to CAFs - full laziness always trades space
for time. We found that it can be a large win in some cases: if
repeated computation is replaced by sharing in an inner loop, then the
gains can be dramatic. We didn't meet any cases where it caused space
problems, so you get it by default[1] when optimisation is turned on in
GHC. You can always disable it with -fno-full-laziness.
Cheers,
Simon
[1] Actually what you get is almost-full-laziness: GHC won't split
adjacent lambda abstractions if it finds it can float an expression past
some of the lambdas but not all.
From igloo@earth.li Mon Dec 10 16:34:47 2001
From: igloo@earth.li (Ian Lynagh)
Date: Mon, 10 Dec 2001 16:34:47 +0000
Subject: Clarification of \begin{code} ... \end{code} stuff
In-Reply-To: <20011210160327.A24481@stu163.keble.ox.ac.uk>; from igloo@earth.li on Mon, Dec 10, 2001 at 04:03:27PM +0000
References: <20011210160327.A24481@stu163.keble.ox.ac.uk>
Message-ID: <20011210163447.A24643@stu163.keble.ox.ac.uk>
On Mon, Dec 10, 2001 at 04:03:27PM +0000, Ian Lynagh wrote:
>
> In the thread "Literate scripts not handled correctly" Simon Marlow
> said:
>
> > Yes, it looks like GHC's unlit program removes whitespace when looking
> > for \begin{code}, but not for \end{code}. The report isn't explicit
> > about whether whitespace is allowed on these lines, but I would tend to
> > the view that it isn't.
>
> Can you please clarify this in the report [...]
Here's an interesting snippet:
\begin{code}
foo = "hello\
\end{code}"
\end{code}
which nhc and hugs accept, GHC says "error in character literal".
I think this is a good reason for at least non-whitespace to not be
allowed on the \begin{code} and \end{code} lines (or rather, for lines
with other non-whitespace on them not to be treated as such).
Thanks
Ian
From simonpj@microsoft.com Tue Dec 11 09:15:17 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 11 Dec 2001 01:15:17 -0800
Subject: FW: Clarification of \begin{code} ... \end{code} stuff
Message-ID: <1113DDB24D4A2841951BFDF86665EE190665BB@RED-MSG-10.redmond.corp.microsoft.com>
> In the thread "Literate scripts not handled correctly" Simon Marlow
> said:
>=20
> > Yes, it looks like GHC's unlit program removes whitespace when=20
> > looking for \begin{code}, but not for \end{code}. The report isn't=20
> > explicit about whether whitespace is allowed on these lines, but I=20
> > would tend to the view that it isn't.
>=20
> Can you please clarify this in the report [...]
I'm sure the "\begin{code}" and "\end{code}" should
be at the beginning of a line. Whether anything else should be allowed
on that line is moot. Maybe not. What would the layout be for this?
\begin{code} f x =3D x
\end{code}
On the other hand it would be painful if a block of code was omitted
because
of a trailing space on the \begin{code} line; an easy error.
I therefore propose code starts on the line *following* a line beginning
with \begin{code}. And similarly stops on a line beginning \end{code}.
For Ian's snippet:
\begin{code}
foo =3D "hello\
\end{code}"
\end{code}
I think it's clear that the first \end{code} should be scanned as part
of the string literal.
Simon
From simonpj@microsoft.com Tue Dec 11 09:37:05 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 11 Dec 2001 01:37:05 -0800
Subject: GCD
Message-ID: <1113DDB24D4A2841951BFDF86665EE190665BD@RED-MSG-10.redmond.corp.microsoft.com>
About the GCD operator, the Haskell Report currently says:
"gcd x y is the greatest integer that divides both x and y.=20
lcm x y is the smallest positive integer that both x and y divide."
Why does 'lcm' say 'positive' while 'gcd' does not? What is
gcd -3 -6
Presumably 3, not -3. You could say that is obvious, since 3 > -3.
So I propose to add "positive" to the gcd spec:
gcd x y is the greatest POSITIVE integer=20
that divides both x and y.=20
I don't think that changes the specification in fact, but experience
has led me to always check these things!
Simon
From herrmann@infosun.fmi.uni-passau.de Tue Dec 11 10:06:28 2001
From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann)
Date: Tue, 11 Dec 2001 11:06:28 +0100
Subject: GCD
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE190665BD@RED-MSG-10.redmond.corp.microsoft.com>
References: <1113DDB24D4A2841951BFDF86665EE190665BD@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <15381.55972.799338.486379@reger.fmi.uni-passau.de>
>>>>> "Simon" == Simon Peyton-Jones writes:
Simon> gcd x y is the greatest POSITIVE integer that divides
Simon> both x and y.
Simon> I don't think that changes the specification in fact, but
Simon> experience has led me to always check these things!
I find it confusing to read a definition which contains redundant
information. Instead, I'd suggest to add something like:
"Note: this number is always positive"
Cheers
--
Christoph Herrmann
From simonpj@microsoft.com Tue Dec 11 10:07:39 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 11 Dec 2001 02:07:39 -0800
Subject: Instance declarations and class exports
Message-ID: <1113DDB24D4A2841951BFDF86665EE190665C2@RED-MSG-10.redmond.corp.microsoft.com>
Folks,
Iavor has made two excellent points, upon which I have been
ruminating (and consulting). Consider
module Foo( M.Ix( index ) ) where
import qualified Ix as M( Ix )
import qualified Ix as T( index )
instance M.Ix MyType where
index a =3D ...
index v =3D ... -- A local declaration
Notice that:
* The Ix class is in scope as "M.Ix", but
its index method is in scope ias "T.index". =20
* Nevertheless, it's 100% clear what we mean in the
instance declaration
* It's also 100% clear what we mean in the export list
M.Ix( index )
(The report is currently silent about whether this is legal.)
* These two situations are very similar, and should be=20
resolved in the same way
* I think we all agree that it woudl be illegal to mention
the 'range' method of the Ix class, either in the
instance cecl, or in theexport list.
Why? Because 'range' is not imported.
I therefore want to propose:
1. "subordinate" names in export lists are always unqualified
Thus, we can have M.Ix( index ), but not M.Ix( T.index ).
2. A subordinate name in an export list is legal if the entity (class
operation or data constructor) is in scope in the module, regardless
of whether it is in scope under a qualified or unqualified name. =20
(In the example, T.index.)
3. The exact same rule is used to determine whether the class method
name on the LHS of an instance-decl binding is legal.
This time I have implemented the rule first, and it seems fine.
These are basically clarifications. Objections? Comments?
I'd like to find a better wording for (2) above.
Simon
From drs@dmu.ac.uk Tue Dec 11 10:16:11 2001
From: drs@dmu.ac.uk (David Smallwood)
Date: Tue, 11 Dec 2001 10:16:11 GMT
Subject: haxml
Message-ID: <200112111016.fBBAGBG00226@crazy-horse.cs.cse.dmu.ac.uk>
Does anyone know of a mirror site where I can download the latest
version of HaXml. (Connection to York is - and has been for a
while - apparently down: ftp://ftp.cs.york.ac.uk/pub/haskell/HaXml/HaXml-1.02.tar.gz, that is)
Many thanks
d.
--
David Smallwood
Dept. of Computing Science
De Montfort University
The Gateway
Leicester LE1 9BH, UK
drs@dmu.ac.uk
From john@repetae.net Tue Dec 11 10:17:18 2001
From: john@repetae.net (John Meacham)
Date: Tue, 11 Dec 2001 02:17:18 -0800
Subject: GCD
In-Reply-To: <15381.55972.799338.486379@reger.fmi.uni-passau.de>; from herrmann@infosun.fmi.uni-passau.de on Tue, Dec 11, 2001 at 11:06:28AM +0100
References: <1113DDB24D4A2841951BFDF86665EE190665BD@RED-MSG-10.redmond.corp.microsoft.com> <15381.55972.799338.486379@reger.fmi.uni-passau.de>
Message-ID: <20011211021718.A1728@momenergy.repetae.net>
On Tue, Dec 11, 2001 at 11:06:28AM +0100, Ch. A. Herrmann wrote:
> >>>>> "Simon" == Simon Peyton-Jones writes:
> Simon> gcd x y is the greatest POSITIVE integer that divides
> Simon> both x and y.
>
> Simon> I don't think that changes the specification in fact, but
> Simon> experience has led me to always check these things!
>
> I find it confusing to read a definition which contains redundant
> information. Instead, I'd suggest to add something like:
>
> "Note: this number is always positive"
yeah. I strongly agree with this wording. precision without confusion is
a really nice feature in specifications. mainly i know that if i were to
read the redundant version I would invariably spend several brain cycles
trying to figure out why it isn't redundant, only to conclude that it
is.
John
--
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john@repetae.net
---------------------------------------------------------------------------
From S.M.Kahrs@ukc.ac.uk Tue Dec 11 10:20:39 2001
From: S.M.Kahrs@ukc.ac.uk (S.M.Kahrs)
Date: Tue, 11 Dec 2001 10:20:39 +0000
Subject: GCD
Message-ID:
The natural reading of 'greatest' is, of course,
the greatest in the divisibility preorder (it's partial order
on natural numbers but only a preorder on integers).
Thus, gcd 0 0 =3D 0.
3 and -3 are equivalent in that preoder.
Thus, an additional comment may be in order.
Stefan
From Malcolm.Wallace@cs.york.ac.uk Tue Dec 11 10:36:27 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Tue, 11 Dec 2001 10:36:27 +0000
Subject: Instance declarations and class exports
Message-ID:
> I therefore want to propose:
>
> 1. "subordinate" names in export lists are always unqualified
> Thus, we can have M.Ix( index ), but not M.Ix( T.index ).
I don't see a compelling reason to outlaw the latter. We can permit
the subordinate name to be unqualified, but why should we enforce it?
Ditto for method names in instance decls.
> I'd like to find a better wording for (2):
>
> 2. A subordinate name in an export list is legal if the entity (class
> operation or data constructor) is in scope in the module, regardless
> of whether it is in scope under a qualified or unqualified name.
> (In the example, T.index.)
Suggestion:
A method name, constructor, or field name is permitted to be used
unqualified in a subordinate position of an export list, iff the
entity it refers to is in scope in the module, regardless of whether
the name must be used qualified elsewhere in the module.
There is a distinction between a subordinate name (e.g. the index
method of Ix), and its use in a subordinate position (e.g. in
Ix(index)). In the example, it would be perfectly legal to say
module Foo( T.index ) where
import qualified Ix as M( Ix )
import qualified Ix as T( index )
index v = ... -- A local declaration
where the method name (but not its class) is re-exported.
Regards,
Malcolm
From Keith.Wansbrough@cl.cam.ac.uk Tue Dec 11 10:42:55 2001
From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough)
Date: Tue, 11 Dec 2001 10:42:55 +0000
Subject: GCD
In-Reply-To: Your message of "Tue, 11 Dec 2001 11:06:28 +0100."
<15381.55972.799338.486379@reger.fmi.uni-passau.de>
Message-ID:
> Simon> gcd x y is the greatest POSITIVE integer that divides
> Simon> both x and y.
>
> I find it confusing to read a definition which contains redundant
> information. Instead, I'd suggest to add something like:
>
> "Note: this number is always positive"
Or, perhaps easier on the eye,
"gcd x y is the greatest (positive) integer that divides both x and y."
--KW 8-)
--
Keith Wansbrough
http://www.cl.cam.ac.uk/users/kw217/
University of Cambridge Computer Laboratory.
From simonpj@microsoft.com Tue Dec 11 11:02:37 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 11 Dec 2001 03:02:37 -0800
Subject: Instance declarations and class exports
Message-ID: <1113DDB24D4A2841951BFDF86665EE190665C8@RED-MSG-10.redmond.corp.microsoft.com>
| > 1. "subordinate" names in export lists are always=20
| unqualified Thus,=20
| > we can have M.Ix( index ), but not M.Ix( T.index ).
|=20
| I don't see a compelling reason to outlaw the latter. We can=20
| permit the subordinate name to be unqualified, but why should=20
| we enforce it? Ditto for method names in instance decls.
Allowing qualified names on the *lhs* of instance decls involves
two new productions (qfunlhs, etc) that I have only just nuked. I
sent mail about that some while ago, to see if anyone really thought
we should keep it.
Then, for export lists, the argument becomes one of uniformity=20
(with instance decls) and simplicity. It seems compelling enough to
me.
Thanks for your wording suggestions.
Simon
From mechvel@math.botik.ru Tue Dec 11 11:28:49 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Tue, 11 Dec 2001 14:28:49 +0300
Subject: gcd 0 0
Message-ID:
People write about the Report definition of
gcd x y
as of greatest integer that divides x and y,
and mention
> gcd 0 0 = 0
But 2 also divides 0, because 2*0 = 0.
Does the Report specify that gcd 0 0 is not defined?
For an occasion: probably, it is better to specify this.
-----------------
Serge Mechveliani
mechvel@botik.ru
From kentk@md.chalmers.se Tue Dec 11 16:10:59 2001
From: kentk@md.chalmers.se (Kent Karlsson)
Date: Tue, 11 Dec 2001 17:10:59 +0100
Subject: GCD
In-Reply-To:
Message-ID: <000101c1825e$6ce26e80$b4e21081@chalmers95a69n>
I don't think preorders of any kind should be involved here.
Just the ordinary order on integers. No divisibility preorder (I'm not
sure how that is even defined, so how it could be natural beats me), no
absolute value.
I find the unaltered text Simon quoted to be fine as is.
But for those who like to be more precise (forgive the TeXese):
% Most of you may wish to stop reading at this point.
% I is the set of integers representable in the integral datatype.
% result_I may return "overflow" or the argument, as appropriate.
\begin{example}\atab
$gcd_I : I \times I \rightarrow I \cup \{\overflow, \infinitary\}$
\end{example}
\begin{example}\atab
$gcd_I(x,y)$
\>$= result_I(\max\{v \in \ZZ ~~|~~ v|x $ and $v|y\})$\\
\> \>if $x,y \in I$ and ($x \neq 0$ or $y \neq 0$)\\
\>$= \infinitary(\posinf)$ \>if $x = 0$ and $y = 0$
\end{example}
% There is no need to say "v>0" above, since there are always positive values in that
% set, and max picks the largest/greatest one. 0 has all integer values except(!) 0
% as divisors. So for gcd 0 0 (maximum, supremum really, of the intersection of the two
% sets of divisors) the result is really positive infinity, which should be the result
% returned when representable (recommendable for Haskell's Integer datatype). gcd will
% overflow for instances like gcd (minBound::Int) (minBound::Int).
\begin{example}\atab\\
$lcm_I : I \times I \rightarrow I \cup \{\overflow\}$
\end{example}
\begin{example}\atab
$lcm_I(x,y)$
\>$= result_I(\min\{v \in \ZZ ~~|~~ x|v $ and $ y|v $ and $ v > 0\})$\\
\> \>if $x,y \in I$ and $x \neq 0$ and $y \neq 0$\\
\>$= 0$ \>if $x,y \in I$ and ($x = 0$ or $y = 0$)
\end{example}
% the "v>0" is needed here, since the set here would otherwise always contain
% infinitely many negative values, and then minimum of that...
Kind regards
/kent k
> -----Original Message-----
> From: haskell-admin@haskell.org [mailto:haskell-admin@haskell.org]On
> Behalf Of S.M.Kahrs
> Sent: den 11 december 2001 11:21
> To: haskell@haskell.org
> Subject: Re: GCD
>
>
> The natural reading of 'greatest' is, of course,
> the greatest in the divisibility preorder (it's partial order
> on natural numbers but only a preorder on integers).
> Thus, gcd 0 0 = 0.
>
> 3 and -3 are equivalent in that preoder.
>
> Thus, an additional comment may be in order.
>
> Stefan
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From ger@tzi.de Tue Dec 11 17:18:31 2001
From: ger@tzi.de (George Russell)
Date: Tue, 11 Dec 2001 18:18:31 +0100
Subject: gcd 0 0
Message-ID: <3C163FE7.15D7F3F3@tzi.de>
S.D.Mechveliani wrote
> Does the Report specify that gcd 0 0 is not defined?
Yes. The Report definition says
gcd :: (Integral a) => a -> a -> a
gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"
gcd x y = gcd' (abs x) (abs y)
where gcd' x 0 = x
gcd' x y = gcd' y (x `rem` y)
On reflection, this is quite right. a divides b <=> there is an
integer n with na = b. Thus any integer divides 0, and so the
"greatest common divisor" would have to be the greatest integer,
which is nonsense.
Of course if you adopt Stephan Kahrs definition of "greatest", taken with respect
to the partial order a<=b <=> a divides b, then gcd 0 0 = 0, because 0 is indeed
the greatest integer in this ordering. Mathematically this makes sense, but it's not necessarily
what people expect.
From Alan@LCS.MIT.EDU Tue Dec 11 18:07:51 2001
From: Alan@LCS.MIT.EDU (Alan Bawden)
Date: Tue, 11 Dec 2001 13:07:51 -0500 (EST)
Subject: gcd 0 0
In-Reply-To: <3C163FE7.15D7F3F3@tzi.de> (message from George Russell on Tue,
11 Dec 2001 18:18:31 +0100)
References: <3C163FE7.15D7F3F3@tzi.de>
Message-ID: <11Dec2001.125247.Alan@LCS.MIT.EDU>
From: George Russell
Date: Tue, 11 Dec 2001 18:18:31 +0100
...
Yes. The Report definition says
gcd :: (Integral a) => a -> a -> a
gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"
gcd x y = gcd' (abs x) (abs y)
where gcd' x 0 = x
gcd' x y = gcd' y (x `rem` y)
On reflection, this is quite right. a divides b <=> there is an
integer n with na = b. Thus any integer divides 0, and so the
"greatest common divisor" would have to be the greatest integer,
which is nonsense.
Of course if you adopt Stephan Kahrs definition of "greatest", taken
with respect to the partial order a<=b <=> a divides b, then gcd 0 0 =
0, because 0 is indeed the greatest integer in this ordering.
Mathematically this makes sense, but it's not necessarily what people
expect.
If you take the point-of-view that gcd is actually an operation on
ideals, then gcd(0, 0) is 0. I.e. define gcd(x, y) to be the smallest
z >= 0 such that {m*x + n*y | m, n in Z} = {n*z | n in Z}. This is
probably the most natural and general definition of gcd, and is, in fact,
what many mathematicians would expect.
Also, it is nice to be able to know that gcd(x, 0) = x for -all- x.
From fstaylo@alpha.ncsc.mil Tue Dec 11 19:31:53 2001
From: fstaylo@alpha.ncsc.mil (Frank Seaton Taylor)
Date: Tue, 11 Dec 2001 14:31:53 -0500
Subject: gcd 0 0
In-Reply-To: <11Dec2001.125247.Alan@LCS.MIT.EDU>
Message-ID: <200112111935.OAA14617@orion.ncsc.mil>
Folks,
Let me chime in in favor of gcd(0,0) = 0 rather than undefined.
On Tuesday, December 11, 2001, at 01:07 , Alan Bawden wrote:
> Also, it is nice to be able to know that gcd(x, 0) = x for -all- x.
Alan is in good company:
1. Steele in "Common Lisp: The Language" says the same thing.
2. Knuth in "The Art of Computer Programming" defines gcd(0,0)=0.
---Frank
From igloo@earth.li Tue Dec 11 23:16:39 2001
From: igloo@earth.li (Ian Lynagh)
Date: Tue, 11 Dec 2001 23:16:39 +0000
Subject: Layout rule (again)
Message-ID: <20011211231639.A2444@stu163.keble.ox.ac.uk>
I'm afraid it doesn't seem to be quite right yet :-(
Consider
instance Foo Maybe where
foo = 5
=>
{4}instance Foo Maybe where
{4}foo = 5
=>
{instance Foo Maybe where
{}}foo = 5
The second {4} has meant there is no <4> to cause an implicit semicolon
to be inserted. This can be fixed by changing
L ({n}:ts) (m:ms) = { : (L ts (n:m:ms)) if n > m, (Note 1)
= { : } : (L ts (m:ms)) otherwise
to
L ({n}:ts) (m:ms) = { : (L ts (n:m:ms)) if n > m, (Note 1)
= { : } : (L (:ts) (m:ms)) otherwise
Thanks
Ian, having a bad day, predominantly due to the layout rule :-(
From petersen@redhat.com Wed Dec 12 01:18:04 2001
From: petersen@redhat.com (Jens Petersen)
Date: 12 Dec 2001 10:18:04 +0900
Subject: haxml
In-Reply-To: <200112111016.fBBAGBG00226@crazy-horse.cs.cse.dmu.ac.uk>
References: <200112111016.fBBAGBG00226@crazy-horse.cs.cse.dmu.ac.uk>
Message-ID:
David Smallwood writes:
> Does anyone know of a mirror site where I can download the latest
> version of HaXml. (Connection to York is - and has been for a
> while - apparently down: ftp://ftp.cs.york.ac.uk/pub/haskell/HaXml/HaXml-1.02.tar.gz, that is)
The above url seemed to work for me just now.
Jens
From chak@cse.unsw.edu.au Wed Dec 12 05:52:01 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Wed, 12 Dec 2001 16:52:01 +1100
Subject: ANN: GHC 5.02.1 RPMs including xlib and HGL packages
Message-ID: <20011212165201G.chak@cse.unsw.edu.au>
The following might be of special interest to people who are
using Paul Hudak's Haskell textbook for teaching and or
study and would like to run the SOE graphics examples with
GHC - or if you simply want to have an X-based graphics
library for an application.
GHC's source distribution contains the two library packages
`xlib' and `HGL' (Alastair Reid's Haskell Graphics Library)
as part of hslibs, which are not by default built and
installed. For our local teaching needs at the University
of New South Wales, we have produced a patched version of
GHC 5.02.1 that includes the aforementioned libraries in a
working form. Haskell modules can be compiled or linked
against these libraries, by providing the command line
options `-package xlib' and `-package HGL', respectively (or
you can specify them using the :s command in the
interpreter).
RPM packages for x86 GNU/Linux based on glibc 2.2 (eg,
RedHat 7.x) containing GHC 5.02.1 including the xlib and HGL
packages are available as
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.02.1-graphics.1.i386.rpm
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.02.1-graphics.1.i386.rpm
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-doc-5.02.1-graphics.1.i386.rpm
with the source RPM at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.02.1-graphics.1.src.rpm
The source RPM contains a patched source tar ball and build
instructions in the form of an RPM .spec that may be used to
build the packages for other Linux distributions and on
other Unix systems. (NB: GreenCard need not be installed to
build this package, as a throw-away version of GreenCard is
included in the tar ball - ie, it is used in the build
process, but not installed.)
Cheers,
Manuel
From ahey@iee.org Wed Dec 12 07:47:44 2001
From: ahey@iee.org (Adrian Hey)
Date: Wed, 12 Dec 2001 07:47:44 +0000
Subject: Another question about sharing
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C607AADC8B@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C607AADC8B@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <01121207463700.03104@localhost.localdomain>
On Monday 10 December 2001 3:32 pm, Simon Marlow wrote:
> The problem isn't restricted to CAFs - full laziness always trades space
> for time. We found that it can be a large win in some cases: if
> repeated computation is replaced by sharing in an inner loop, then the
> gains can be dramatic. We didn't meet any cases where it caused space
> problems, so you get it by default[1] when optimisation is turned on in
> GHC. You can always disable it with -fno-full-laziness.
and Malcolm Wallace wrote:
> Well, how about the following little circular program?
> � � � paths :: () -> [Path]
>� 牋牋 paths () = let r = T : branch r in r
Just to be clear, (with GHC) if I compile a module with this
flag, with a local definition of paths..
mkLUT def = where
paths = T : branch paths
then I'll get a new paths graph every time mkLUT is called?
But the effect of this is local to the module, so if mkLUT
is exported, any local use of (mkLUT def) where def is a
constant will still give a CAF (containing paths) unless
that module has also been compiled with -fno-full-laziness?
If I'm not mistaken, I have essentially the same problem
with Malcolms solution. (() is a constant.)
I don't want to make too big an issue over this because
it really isn't a show stopper for my purposes, but it
would be nice if I could make (what I consider to be)
a reasonably safe self contained library module.
I.E. Doesn't contain or cause space leaks
Is not GHC specific
Doesn't require other modules which make use
of it to be compiled with particular options.
I wonder if those people who know more about formal semantics
than I do might consider making the definition of the language
less ambiguous wrt sharing and also (maybe) giving programmers
more explicit control if they need it, as in Clean.
BTW, I can't find any information re. -fno-full-laziness in the
current GHC users guide. Is it a deprecated feature?
If I try it in an OPTIONS pragma I discover that it's static.
Does that mean it has to be applied to a whole program in any
case? (I can't think of any other reason it can't be included
in a source file).
Regards
--
Adrian Hey
From mailinglist@fmeurope.org Mon Dec 10 12:18:22 2001
From: mailinglist@fmeurope.org (mailinglist@fmeurope.org)
Date: Mon, 10 Dec 2001 13:18:22 +0100
Subject: FME 2002: 2nd call for papers
Message-ID: <001401c18174$c56cb5f0$dcd22bc0@west.nl>
apologies if you receive multiple copies...
FORMAL METHODS EUROPE
FME 2002
"Formal Methods: Getting IT Right"
International Symposium and Tutorials
http://floc02.diku.dk/FME/
20-24 July 2002
Second Call for Papers
**********************
FME 2002 is the eleventh in a series of symposia organised by Formal
Methods Europe, an independent association whose aim is to stimulate the
use of, and research on, formal methods for software development. These
symposia have been notably successful in bringing together a community of
users, researchers, and developers of precise mathematical methods for
software development. In 2002 the symposium will be held in conjunction
with the third Federated Logic Conference (FLoC'02) in Copenhagen, Denmark.
The theme of FME 2002 is Formal Methods: Getting IT Right.
The double meaning is intentional. On the one hand, the theme acknowledges
the significant contribution formal methods can make to Information
Technology, by enabling computer systems to be described precisely and
reasoned about with rigour. On the other hand, it recognises that current
formal methods are not perfect, and further research and practice are
required to improve their foundations, applicability and effectiveness.
FME seeks papers in all aspects of formal methods for computer systems,
including the following:
* theoretical foundations
* practical use and case studies
* specification and modelling techniques
* software development and refinement
* tool support and software engineering environments for formal methods
* verification and validation
* hidden formal methods, and making benefits available to non-experts
* reusable domain theories
* method integration
* hardware verification
In addition to presentations of submitted papers, the symposium will
offer tutorials, workshops, invited speakers, and tool demonstrations.
PAPERS
Full papers should be submitted in Postscript or PDF format by e-mail to
reach the Program Co-chairs by 15 January 2002. Papers will be refereed by
the Program Committee and must be original research papers that have not
been submitted elsewhere for publication. Accepted papers will be published
in the symposium proceedings.
Papers should not exceed twenty pages, although longer papers will be
considered if their content justifies it. LNCS format should be used: see
http://www.springer.de/comp/lncs/authors.html for details.
Please include a short list of keywords on a separate line at the end of
the abstract, beginning with the word "Keyword:" in boldface.
OTHER SYMPOSIUM ACTIVITIES
Tutorials and workshops will be held on 20-21 July 2002. Each tutorial will
last one-half or one day. Proposals are welcome, and should be directed to
the Program Co-chairs by 15 January 2002; more details will appear on the
web-site above.
Tool demonstrations will also take place during the symposium, with the
opportunity for presentations to be made about each tool. Proposals for
tool demonstrations should be made to the Tool Demonstration Coordinator,
with whom provison of necessary computing facilities should be discussed.
PEOPLE
Organising Chair
Dines Bj鴕ner
Informatics and Mathematical Modelling
Building 322, Richard Petersens Plads
Technical University of Denmark
DK-2800 Lyngby, Denmark
Tel: +45 4525 3720
Email: db@imm.dtu.dk
Programme Co-chairs
Lars-Henrik Eriksson, Industrilogik L4i AB
Box 6205, SE-102 34 Stockholm, Sweden
Tel: +46 8 670 37 10 Fax: +46 8 32 12 82
Email: lhe@L4i.se
Peter Lindsay, Software Verification Research Centre
The University of Queensland, Queensland 4072, Australia
Tel: +61 7 3365 2005 Fax: +61 7 3365 1533
Email: Peter.Lindsay@svrc.uq.edu.au
Programme Committee
Bernhard Aichernig Graz University of Technology, Austria
Juan Bicarregui Rutherford Appleton Laboratory, UK
Ernie Cohen Telcordia Technologies, USA
Ben Di Vito NASA Langley Research Center, USA
Cindy Eisner IBM Haifa Research Laboratory, Israel
Lars-Henrik Eriksson (co-chair) Industrilogik, Sweden
John Fitzgerald Transitive Technologies Ltd, UK
Jim Grundy Intel Corporation, USA
Yves Ledru LSR/IMAG, France
Peter Lindsay (co-chair) University of Queensland, Australia
Markus Montigel University of New Orleans, USA
Richard Moore IFAD, Denmark
Tobias Nipkow Technische Universit鋞 M黱chen, Germany
Colin O'Halloran Qinetiq (ex-DERA), UK
Jose Oliveira Universidade do Minho, Portugal
Nico Plat West Consulting, The Netherlands
Jeannette Wing Carnegie Mellon University, USA
Jim Woodcock Oxford University, UK
Joakim von Wright 舃o Akademi University, Finland
Pamela Zave AT&T Laboratories, USA
Tool Demonstration Coordinator
Paul Mukherjee
The Institute of Applied Computer Sciense (IFAD)
Forskerparken 10, DK-5230 Odense M, Denmark
Tel: +45 6315 7131 Fax: +45 6593 2999
Email: paul.mukherjee@ifad.dk
IMPORTANT DATES
Submission of papers, tutorial proposals
and workshop proposals: 15 January 2002
Notification of acceptance/rejection: 27 March 2002
Camera ready final version of papers due: 10 May 2002
l
_______________________________________________
Mailinglist mailing list
Mailinglist@fmeurope.org
http://www.fmeurope.org/mailman/listinfo/mailinglist
From chinwn@comp.nus.edu.sg Wed Dec 12 11:38:53 2001
From: chinwn@comp.nus.edu.sg (Chin Wei Ngan)
Date: Wed, 12 Dec 2001 19:38:53 +0800 (GMT-8)
Subject: CFP : ASIA-PEPM 2002
Message-ID: <200112121138.TAA20037@sunA.comp.nus.edu.sg>
CALL FOR PAPERS
ACM SIGPLAN ASIAN Symposium on
Partial Evaluation and Semantics-Based Program Manipulation (ASIA-PEPM'02)
Aizu, JAPAN, September 12-14 2002
(co-located with FLOPS2002)
http://www.comp.nus.edu.sg/asia-pepm02
Submission deadline: 1st March 2002
The ASIA-PEPM'02 symposium will bring together researchers working in the
areas of semantics-based program manipulation, partial evaluation, and
program analysis. The symposium focuses on techniques, supporting
theory, and applications for the analysis and manipulation of programs.
Technical topics include, but are not limited to:
* Program manipulation techniques: transformation, specialization,
normalization, reflection, rewriting, run-time code generation,
multi-level programming.
* Program analysis techniques: abstract interpretation, static
analysis, binding-time analysis, type-based analysis.
* Related issues in language design and models of computation:
imperative, functional, logical, constraint-based, object-oriented,
parallel, concurrent, secure, domain-specific.
* Programs as data objects: staging, meta-programming, incremental
computation, mobility, tools and techniques, prototyping and
debugging.
* Applications: systems programming, scientific computing, embedded
systems, graphics, security, model checking, compiler
generation, compiler optimization, decompilation.
Original results that bear on these and related topics are solicited.
Papers investigating novel uses and applications of program
manipulation are especially encouraged. Authors concerned about
the appropriateness of a topic are welcome to consult with the
program chair prior to submission.
SUBMISSION INFORMATION
Papers should be submitted electronically via the workshop's Web
page. Exceptionally, submissions may be emailed to the program
chair: asiapepm@comp.nus.edu.sg. Acceptable formats are PostScript
or PDF, viewable by gv. Submissions should not exceed 5000 words,
excluding bibliography and figures.
Submitted papers will be judged on the basis of significance,
relevance, correctness, originality, and clarity. They should clearly
identify what has been accomplished and why it is significant.
The work described should not have been previously published in
a major forum. Authors must indicate if a closely related paper
is also being considered for another conference or journal.
The proceeding of the symposium will be published by ACM Press.
A special issue of Higher-Order Symbolic Computation is also
planned.
LOCAL ARRANGEMENT
Mizuhito Ogawa (NTT, Japan)
GENERAL CHAIR
Kenichi Asai (Ochanomizu University, Japan)
PROGRAM CHAIR
Wei-Ngan Chin (National University of Singapore, Singapore)
PROGRAM COMMITTEE
Manuel Chakravarty (University of New South Wales, Australia)
Tyng-Ruey Chuang (Academia Sinica, Taiwan)
Charles Consel (ENSEIRB, France)
Oege de Moor (University of Oxford, UK)
Masami Hagiya (University of Tokyo, Japan)
Nevin Heintze (Agere Systems, USA)
Neil Jones (Univ of Copenhagen, Denmark)
Yanhong Annie Liu (SUNY at Stony Brook, USA)
Atsushi Ohori (JAIST, Japan)
Alberto Pettorossi (University of Roma, Italy)
Simon Peyton Jones (Microsoft, UK)
Carolyn Talcott (Stanford University, USA)
Zhe Yang (University of Pennsylvania, USA)
From olaf@cs.york.ac.uk Wed Dec 12 17:43:53 2001
From: olaf@cs.york.ac.uk (Olaf Chitil)
Date: Wed, 12 Dec 2001 17:43:53 +0000
Subject: Functional Programming Languages in Education disappeared
Message-ID: <3C179759.F9DC779E@cs.york.ac.uk>
Christopher Milton informed me that the link from haskell.org to
http://www.cs.kun.nl/fple/, the pages on Functional Programming
Languages in Education is broken. In fact, the pages seem to have
disappeared completely.
I think that this is a pity. I believe the pages have not been updated
already for a few years. I suppose the maintainers didn't get much
feedback from users and hence finally gave up. I wonder if the
maintainers would like to comment on this. Didn't the pages have quite a
collection of teaching materials? Maybe there are volunteers who would
keep this site going?
Ciao,
Olaf
--
OLAF CHITIL,
Dept. of Computer Science, The University of York, York YO10 5DD, UK.
URL: http://www.cs.york.ac.uk/~olaf/
Tel: +44 1904 434756; Fax: +44 1904 432767
From mechvel@math.botik.ru Thu Dec 13 09:53:32 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Thu, 13 Dec 2001 12:53:32 +0300
Subject: gcd 0 0 = 0
Message-ID:
People write on gcd 0 0 :
Alan Bawden
> If you take the point-of-view that gcd is actually an operation on
> ideals, then gcd(0, 0) is 0. I.e. define gcd(x, y) to be the smallest
> z >= 0 such that {m*x + n*y | m, n in Z} = {n*z | n in Z}. This is
> probably the most natural and general definition of gcd, and is, in fact,
> what many mathematicians would expect.
>
> Also, it is nice to be able to know that gcd(x, 0) = x for -all- x.
Frank Seaton Taylor writes
T> Let me chime in in favor of gcd(0,0) = 0 rather than undefined.
T>
T> On Tuesday, December 11, 2001, at 01:07 , Alan Bawden wrote:
T>
T> > Also, it is nice to be able to know that gcd(x, 0) = x for -all- x.
T>
T> Alan is in good company:
T>
T> 1. Steele in "Common Lisp: The Language" says the same thing.
T>
T> 2. Knuth in "The Art of Computer Programming" defines gcd(0,0)=0.
T> classic algebra
All right. Let us try to investigate this.
In such cases one should consult mathematics, not programming.
So, let us ignore "Common Lisp ...".
And Knuth is all right, I think.
Further, the definintion
> gcd(x, y) to be the smallest
> z >= 0 such that {m*x + n*y | m, n in Z} = {n*z | n in Z}
is not natural. In particular, how does it generalize to gcd X Y
for polynomials in X, Y with rational coefficients?
It is 1. And how would one obtain 1 = f*X + g*Y ?
According to classic algebra (Kummer, I guess),
gcd x y in (such and such) domain R
is the least by inclusion principal ideal (g)
that includes the ideal (x, y).
Here (a1..an) = set of all combinations y1*a1 + .. + yn*an,
yi from R.
According to this definition, gcd (X) (Y) = (1)
in polynomials, all right,
and gcd n m :: Integer is (0)
Because (0) is the least by inclusion principal ideal containing (0).
And this also contradicts the part "greatest integer that divides ..."
in recent Haskell specification.
Probably, the best specification would be
gcd n m :: Integer = if n == 0 && m == 0 then 0
else
greatest integer that divides both n and m
-----------------
Serge Mechveliani
mechvel@botik.ru
From frank@cc.gatech.edu Thu Dec 13 14:04:42 2001
From: frank@cc.gatech.edu (Frank Dellaert)
Date: Thu, 13 Dec 2001 09:04:42 -0500
Subject: Integer Enum ?
Message-ID: <005301c183df$1f34bc60$a21ccf82@cc.gatech.edu>
This is a multi-part message in MIME format.
------=_NextPart_000_0050_01C183B5.340C38E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi
I'm not entirely clear how Integer can be an Enum instance. I thought =
Integer was arbitrary size, while for the Enum class you need to define =
a mapping from and to Int, which is bounded (in a machine dependent way, =
even ?). I'm probably missing something obvious...
Cheers
Frank Dellaert
------=_NextPart_000_0050_01C183B5.340C38E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi
I'm not entirely clear how Integer can =
be an Enum=20
instance. I thought Integer was arbitrary size, while for the Enum class =
you=20
need to define a mapping from and to Int, which is bounded (in a machine =
dependent way, even ?). I'm probably missing something =
obvious...
Cheers
Frank =
Dellaert
------=_NextPart_000_0050_01C183B5.340C38E0--
From shae@www.webwitches.com Thu Dec 13 15:42:45 2001
From: shae@www.webwitches.com (Shae Erisson)
Date: Thu, 13 Dec 2001 17:42:45 +0200 (EET)
Subject: We need "Documentation"
In-Reply-To:
References:
Message-ID: <20011213.174245.884009776.shae@www.webwitches.com>
From: Tony Davie
Subject: Re: We need "Documentation" (Was: Re: Integer to String Conversion?)
Date: Tue, 4 Dec 2001 09:38:49 +0000
> >The material we have is simply lacking. What we need is a good tutorial and a
> >comprehensive reference book.
>
> ...
>
> I suggest you look at http://www.haskell.org/bookshelf/, specifically
> the section on
> Papers available on the Web. This gives numerous tutorials and introductions.
I agree with Eray, I tried to learn Haskell without any printed material, and failed.
Once I had the Simon Thompson's "Craft of.." I was doing fine.
I have an irc friend who would also like to learn Haskell, and who is blind.
He uses a braille reader in the Linux console, but the electronically available Haskell documentation just isn't sufficient.
I taught myself Python in about two weeks with the online Python tutorial, I think something similar for Haskell would greatly increase the number of Haskell users.
----
Shae Matijs Erisson - http://www.webwitches.com/~shae/
Rabid Linux/XEmacs User - MSOffice documents will be returned as LaTeX
From hdaume@ISI.EDU Thu Dec 13 17:07:12 2001
From: hdaume@ISI.EDU (Hal Daume III)
Date: Thu, 13 Dec 2001 09:07:12 -0800 (PST)
Subject: We need "Documentation"
In-Reply-To: <20011213.174245.884009776.shae@www.webwitches.com>
Message-ID:
> I taught myself Python in about two weeks with the online Python tutorial, I think something similar for Haskell would greatly increase the number of Haskell users.
I'm not familiar with the Python tutorial, but the Java tutorial which
resides at java.sun.com is pretty much the most highly praised thing I
know about. If ever anyone has a Java question or is trying to learn
Java, everyone I know simply tells them to read that. It takes about 10
minutes to get up and running (assuming some programming background).
Where is the Python tutorial located and is it more-or-less the same as
the Java one?
Would anyone be interested in working on a similar thing for Haskell?
- Hal
From shae@www.webwitches.com Thu Dec 13 18:31:50 2001
From: shae@www.webwitches.com (Shae Erisson)
Date: Thu, 13 Dec 2001 20:31:50 +0200 (EET)
Subject: We need "Documentation"
In-Reply-To:
References: <20011213.174245.884009776.shae@www.webwitches.com>
Message-ID: <20011213.203150.276755180.shae@www.webwitches.com>
From: Hal Daume III
Subject: Re: We need "Documentation"
Date: Thu, 13 Dec 2001 09:07:12 -0800 (PST)
> Where is the Python tutorial located and is it more-or-less the same as
> the Java one?
http://www.python.org/doc/current/tut/tut.html
> Would anyone be interested in working on a similar thing for Haskell?
me!
I'd suggest a HaskellWiki page, since multiuser edits are low overhead there.
----
Shae Matijs Erisson - http://www.webwitches.com/~shae/
Rabid Linux/XEmacs User - MSOffice documents will be returned as LaTeX
From hdaume@ISI.EDU Thu Dec 13 18:47:53 2001
From: hdaume@ISI.EDU (Hal Daume III)
Date: Thu, 13 Dec 2001 10:47:53 -0800 (PST)
Subject: We need "Documentation"
In-Reply-To: <20011213.203150.276755180.shae@www.webwitches.com>
Message-ID:
I think we should move this off the mailing list. I'm willing to
spear-head such an effort. Anyone who is interested in contributing,
please email me. I'll compile a list of people and we can figure out what
we want to do.
- Hal
--
Hal Daume III
"Computer science is no more about computers | hdaume@isi.edu
than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
On Thu, 13 Dec 2001, Shae Erisson wrote:
> From: Hal Daume III
> Subject: Re: We need "Documentation"
> Date: Thu, 13 Dec 2001 09:07:12 -0800 (PST)
>
> > Where is the Python tutorial located and is it more-or-less the same as
> > the Java one?
>
> http://www.python.org/doc/current/tut/tut.html
>
> > Would anyone be interested in working on a similar thing for Haskell?
>
> me!
> I'd suggest a HaskellWiki page, since multiuser edits are low overhead there.
> ----
> Shae Matijs Erisson - http://www.webwitches.com/~shae/
> Rabid Linux/XEmacs User - MSOffice documents will be returned as LaTeX
>
From pat@jantar.org Fri Dec 14 00:39:56 2001
From: pat@jantar.org (Patryk Zadarnowski)
Date: Fri, 14 Dec 2001 11:39:56 +1100 (EST)
Subject: Typesetting literate scripts in TeX
Message-ID: <20011214.113956.74747160.pat@jantar.org>
Recently I've hacked up a (yet another) TeX package for typesetting
literate scripts in TeX, which, I think belongs in
http://haskell.org/libraries/#tex". What's different about lambdaTeX
is that it is not a cumbersome preprocessor, but a full TeX program
(an almost-complete Haskell lexical analyzer written entirely in
plain TeX ;-) which typesets Bird-style literate scripts _directly_.
The output looks much like the code from Chris Okasaki's book "Purely
Functional Data Structures", doing syntax highlighting and converting
ASCII art such as "->" or "alpha" to proper mathematical symbols.
It should work with both LaTeX and plain TeX, and it does its magic
without any annotations, directly on the source code (the only thing
that you will probably want to do is add \input lambdaTeX at the top
of your source file, and manually typeset your literate comments so they
look as good as the source code ;-)
I've got a rudimentary web page for it at http://www.jantar.org/lambdaTeX/
with examples and a summary of features. If you have any comments or
suggestions, I wouldn't mind hearing them.
Enjoy.
Pat.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk Zadarnowski University of New South Wales
School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From Alan@LCS.MIT.EDU Fri Dec 14 03:55:31 2001
From: Alan@LCS.MIT.EDU (Alan Bawden)
Date: Thu, 13 Dec 2001 22:55:31 -0500 (EST)
Subject: gcd 0 0 = 0
In-Reply-To: (mechvel@math.botik.ru)
References:
Message-ID: <13Dec2001.210227.Alan@LCS.MIT.EDU>
From: "S.D.Mechveliani"
Date: Thu, 13 Dec 2001 12:53:32 +0300
Further, the definintion
> gcd(x, y) to be the smallest
> z >= 0 such that {m*x + n*y | m, n in Z} = {n*z | n in Z}
is not natural. In particular, how does it generalize to gcd X Y
for polynomials in X, Y with rational coefficients?
Well, that -is- the way gcd is defined in the commutative algebra textbook
I used in graduate school -- I just specialized the definition for the case
of the ring of integers, and so I didn't mention that Z was a principle
ideal domain. Polynomials in two variables aren't a PID, so yes, you'd
have to restore some things I left out. When I said my definition was
"general" I suppose I should have anticipated someone would generalize in a
way I hadn't intended... (Actually, that definition doesn't even
generalize exactly to the Gaussian Integers, where "z >= 0" would have to
be replaced by some specification of a region of the complex plane.)
...
Probably, the best specification would be
gcd n m :: Integer = if n == 0 && m == 0 then 0
else
greatest integer that divides both n and m
Fortunately, we all seem to agree on what the actual definition should be.
I did make a mistake in my previous message. I said that it was nice that
gcd(0, x) = x for all x. I should have said: gcd(0, x) = abs(x).
From simonpj@microsoft.com Fri Dec 14 09:18:56 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 14 Dec 2001 01:18:56 -0800
Subject: gcd 0 0 = 0
Message-ID: <1113DDB24D4A2841951BFDF86665EE1906660A@RED-MSG-10.redmond.corp.microsoft.com>
| Probably, the best specification would be
|=20
| gcd n m :: Integer =3D if n =3D=3D 0 && m =3D=3D 0 then 0
| else
| greatest integer that divides both n and m
Well, thank you all those that have contributed. My original point
was simply to say
greatest (positive) integer that divides both n and m
but debate seems to have swirled round whether (gcd 0 0) should
be 0 or an error. Currently in H98 it's an error; but it is the kind=20
of thing I'm willing to change IF there is a consensus, because it
will only make more programs work. Is there a consensus that
such a change would be desirable?
If someone could write a sentence or two to explain why gcd 0 0 =3D 0,
(ideally, brief ones I can put in the report by way of explanation),
I think that might help those of us who have not followed the details
of the discussion. =20
Simon
From dongen@cs.ucc.ie Fri Dec 14 12:38:58 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Fri, 14 Dec 2001 12:38:58 +0000
Subject: gcd 0 0 = 0
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE1906660A@RED-MSG-10.redmond.corp.microsoft.com>; from simonpj@microsoft.com on Fri, Dec 14, 2001 at 01:18:56AM -0800
References: <1113DDB24D4A2841951BFDF86665EE1906660A@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <20011214123858.J21918@cs.ucc.ie>
Simon Peyton Jones (simonpj@microsoft.com) wrote:
: If someone could write a sentence or two to explain why gcd 0 0 = 0,
: (ideally, brief ones I can put in the report by way of explanation),
: I think that might help those of us who have not followed the details
: of the discussion.
Division in the context of gcds (of integers) is usually defined
along the lines of:
An integer $a$ divides integer $b$ if there exists an integer
$c$ such that $a c= b$.
Note that here division is a *relation* an not a *function*/*operator*.
Given the definition of division being a relation it makes perfect
sense to say that $0$ divides $0$ which is why
gcd 0 0 = 0; and
gcd 0 0 /= error "Blah"
The gcd of two integers is usually defined as a non-negative
number to make it unique.
HTH.
PS: I am strongly in favour of gcd 0 0 = 0.
Regards,
Marc van Dongen
From qrczak@knm.org.pl Fri Dec 14 21:00:13 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Fri, 14 Dec 2001 22:00:13 +0100
Subject: Typesetting literate scripts in TeX
Message-ID: <20011214210013.GA19310@qrnik.zagroda>
> Recently I've hacked up a (yet another) TeX package for typesetting
> literate scripts in TeX
Cool! I will use it in my thesis.
One bug: a line can be broken between an inline code and a comma
which immediately follows it.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^
QRCZAK
From igloo@earth.li Fri Dec 14 21:28:30 2001
From: igloo@earth.li (Ian Lynagh)
Date: Fri, 14 Dec 2001 21:28:30 +0000
Subject: Confused about default
Message-ID: <20011214212830.A25845@stu163.keble.ox.ac.uk>
Hi all
I am rather confused about default.
In section 4.3.4 the report says
"each ti must be a monotype for which Num ti holds"
but according to grep this is the only place "monotype" appears in the
report.
If I have the module
module TT (Foo(..)) where
default (Foo, [Foo], Foo -> Int)
data Foo = Foo deriving (Eq, Show)
instance Num Foo where {}
instance (Eq a, Show a) => Num [a] where {}
instance Eq (a -> b) where {}
instance Show (a -> b) where {}
instance Num (a -> b) where {}
then hugs accepts it and
TT> 5
Program error: Undefined member: fromInteger
ghc accepts it and
TT> 5
5
nhc tells me
Error when renaming::
Illegal type in default at 4:17
If I remove all the list and function stuff then hi says
TT> 5
5
If I have a
main = putStrLn $ show 5
then nhc gives me
TT> main
No default definition for class method fromInteger
and ghci gives me
Main> main
*** Exception: TT.lhs:8: No instance nor default method for class
operation PrelNum.fromInteger
It seems to me that hugs is in the right with it's handling of 5, but I
am not sure who is wrong with default ([Foo]) or (Foo -> Int).
Finally, the context free grammar doesn't currently enforce the
restriction that only one default declaration be given. Fixing it would
make rather a mess, though.
Ian
From nordland@cse.ogi.edu Sat Dec 15 19:11:15 2001
From: nordland@cse.ogi.edu (Johan Nordlander)
Date: Sat, 15 Dec 2001 11:11:15 -0800
Subject: ANNOUNCE: Hugs98 Christmas release
Message-ID: <82E00FDE-F18F-11D5-ABD3-003065BDF7A4@cse.ogi.edu>
------------------------------------------------------------------------------
__ __ __ __ ____ ___
_________________________________________
|| || || || || || ||__ Hugs 98: Based on the Haskell 98
standard
||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001
||---|| ___|| World Wide Web: http://haskell.org/hugs
|| || Report bugs to: hugs-bugs@haskell.org
|| || Version: Dec
2001 _________________________________________
------------------------------------------------------------------------------
We are pleased to announce a new release of Hugs98, a Haskell
interpreter and programming environment for developing cool Haskell
programs. Sources and binaries are freely available on the
World-Wide Web.
The most important features of this new release are:
- The incompatibilities between Hugs and the Haskell Graphics Library
have been fixed, and binaries for the HGL are now available on the
Hugs download page.
- The missing standard libraries Directory, CPUTime, Time and Locale
have been added along with a complete implementation of
Haskell98 IO.
- Hugs is now delivered with most of the hslibs libraries installed
in the lib/exts/ directory. The added modules cover the Edison,
Parsec, HaXml, QuickCheck, concurrent, monad, and html
subdirectories
of hslibs.
- The :set option now refuses the user to set a module search path
that doesn't contain the Prelude. This is to protect users from
accidentally rendering their Hugs setups unusable, esp. so on
Windows machines where the options are persisted to the Registry.
- MacOS X is now one of the supported unix ports, with pre-built
binaries available on the download page.
- Experimental support is provided for hierarchical module names,
where a module name A.B.C is mapped onto the file path
A/B/C{.hs,.lhs} and appended to each of the path prefixes in
HUGSPATH until the name of a readable file is found.
Most reported bugs have also been fixed; however, some issues still
remain. See the heading "Hugs Bugs & Features" on the Hugs web site
for further information.
Send email to hugs-users-request@haskell.org to join the hugs-users
mailing list. Bug reports should be sent to hugs-bugs@haskell.org.
Send email to hugs-bugs-request@haskell.org to subscribe to the
hugs-bugs list.
The home page for Hugs is at http://www.haskell.org/hugs.
------------------------------------------------------------------------------
The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, the
Yale Haskell Group, and the Oregon Graduate Institute of Science and
Technology, 1994-2001, All rights reserved. It is distributed as
free software under the license in the file "License", which is
included in the distribution.
------------------------------------------------------------------------------
From sof@galois.com Sat Dec 15 19:14:42 2001
From: sof@galois.com (Sigbjorn Finne)
Date: Sat, 15 Dec 2001 11:14:42 -0800
Subject: Announce: Hugs Graphics Library
Message-ID: <0a6501c1859c$c02fe040$4576fea9@sofbox>
We are pleased to announce a new release of the Hugs Graphics Library,
version 2.0.4. The Hugs Graphics Library gives the programmer access
to the most interesting and portable parts of the Win32 and X11 library.
The library is distributed as open source and is suitable for use in
teaching and applications.
This version is compatible with the December 2001 release of Hugs, but
won't work with the February 2001 release.
This version supports:
* filled and unfilled 2-dimensional objects (text, lines, polygons,
ellipses).
* Bitmaps (Win32 version only, for now).
* Control over text alignment, fonts, color.
* Simple input events (keyboard, mouse, window resize) to support
reactivity.
* Timers and double-buffering to support simple animation.
* Use of concurrency to avoid the usual inversion of the code
associated with event-loop programming.
* Multiple windows may be handled at one time.
To keep the library simple and portable, the library makes no attempt to
support:
* User interface widgets (menus, toolbars, dialog boxes, etc.)
* Palette manipulation and other advanced features.
* Many kinds of input event.
The library can be downloaded from: http://www.haskell.org/graphics/.
Installation instructions are in graphics-2.0.4/Install.
Bug reports should be sent to reid@cs.utah.edu
Enjoy!
From matth@mindspring.com Sat Dec 15 23:04:19 2001
From: matth@mindspring.com (Matt Harden)
Date: Sat, 15 Dec 2001 17:04:19 -0600
Subject: Integer Enum ?
References: <005301c183df$1f34bc60$a21ccf82@cc.gatech.edu>
Message-ID: <3C1BD6F3.DF4E1FD3@mindspring.com>
> Frank Dellaert wrote:
>
> Hi
> I'm not entirely clear how Integer can be an Enum instance. I thought
> Integer was arbitrary size, while for the Enum class you need to
> define a mapping from and to Int, which is bounded (in a machine
> dependent way, even ?). I'm probably missing something obvious...
You're right to wonder about that. It's even worse than you thought.
Float and Double are also Enum instances!
IMHO, this is a wart in the Haskell definition. Enum is used for two
purposes: to support the [x,y..z] syntactic sugar, and to define
conversion to/from Int. I think everybody agrees that the [x,y..z]
syntax should support Integers, so it has to be an instance of Enum. I
suspect that for convenience, the fromEnum and toEnum functions were put
in the class to allow easier definitions of new Enum instances for small
bounded enumerations. It has the undesireable effect of forcing the
implementer of an Enum instance to produce a mapping to/from Int even
when it doesn't make any sense. My preference would be to define them
as errors in that case; the Haskell Report does not.
The Report defines fromEnum for Float and Double; it is silent on
Integer, and the Ratio module in the Library Report defines fromEnum for
Ratio. In all cases, the reports specify truncation to integer, and
there is a comment that the conversion may overflow. Complex does not
define an Enum instance, even though it would make sense to me to be
able to write [0, 1:+2 .. 5:+10] or the like. I guess fromEnum for
Complex, if it existed, would have to just "truncate" the imaginary
part!
Regarding the Integer instance, Hugs only issues errors on fromEnum x
where x is out of range. GHC just returns the value modulo 2^32, or
something like that.
My advice is to just ignore fromEnum and toEnum for Integer, Float,
Double, and Ratio, and, if you need to define your own Enum instance,
just define some reasonable mapping to Int, and don't worry much about
truncation and overflow... the Haskell designers didn't! :)
Matt Harden
P.S. I hope the Haskell designers don't take offense; in reality, they
have nothing but my deepest respect!
From Alan@LCS.MIT.EDU Sun Dec 16 07:34:05 2001
From: Alan@LCS.MIT.EDU (Alan Bawden)
Date: Sun, 16 Dec 2001 02:34:05 -0500 (EST)
Subject: gcd 0 0 = 0
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE1906660A@RED-MSG-10.redmond.corp.microsoft.com>
(simonpj@microsoft.com)
References: <1113DDB24D4A2841951BFDF86665EE1906660A@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <15Dec2001.202504.Alan@LCS.MIT.EDU>
From: "Simon Peyton-Jones"
Date: Fri, 14 Dec 2001 01:18:56 -0800
...
If someone could write a sentence or two to explain why gcd 0 0 = 0,
(ideally, brief ones I can put in the report by way of explanation),
I think that might help those of us who have not followed the details
of the discussion.
Well, Serge and I have both offered variations on the real reason why
mathematicians agree that gcd 0 0 = 0. I prefer my simpler
specialized-for-integers version, but I suspect even that is more
mathematics than you want. At the other extreme, you could follow Knuth
and simply state: "it is convenient to set gcd(0, 0) = 0", but that seems a
bit unconvincing.
If I were in your shoes, I'd simply pass the buck to the authorities by
saying something like: "Mathematicians agree that gcd(0, 0) = 0".
Incidentally, somebody wrote here that Common Lisp defines `(gcd 0 0)' to
be 0, but it looks to me like all the language definition really does is
state that `(gcd)' (no arguments) is 0 because 0 "is an identity for this
operation" (which is technically false, but never mind), from which it is
natural for the reader to conclude that `(gcd 0 0)' must be 0.
From mechvel@math.botik.ru Sun Dec 16 12:35:57 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Sun, 16 Dec 2001 15:35:57 +0300
Subject: gcd definition
Message-ID:
Simon Peyton-Jones writes
> [..]
> If someone could write a sentence or two to explain why gcd 0 0 = 0,
> (ideally, brief ones I can put in the report by way of explanation),
> I think that might help those of us who have not followed the details
> of the discussion.
Here it is.
gcd n m :: Integer = if n == 0 && m == 0 then 0
else
greatest integer that divides both n and m
It is set so according to classic definition
(by Pythago, Euclid ...)
GCD x y = such g that divides both x and y and is a multiple
of any g' that divides both x and y.
In particular, GCD 0 0 :: Integer = 0 and can be nothing else.
Because
0 divides 0 and divides nothing else,
everything divides 0 (z*0 = 0).
Other comments -------------------------------------------------
*
People say, D.Knuth writes gcd 0 0 = 0 in his book.
And he is a known mathematically reliable person.
*
Example. gcd 12 18 :: Integer = 6 or -6,
because 6 divides 12 and 18, and any other such number divides 6.
*
The Haskell report says "greatest integer" for domain = Integer,
and thus, chooses the sign `+' for the result.
This choice is not a mistake and helps to write shorter programs.
*
All the above agrees with the modern generic theory of ideals
(started in |XX by Kummer, Gauss, Lagrange)
for any commutative domain R having the properties of
(a /= 0, b /= 0 ==> a*b /= 0),
existence of unique factorization to primes.
According to it
gcd x y =
least by inclusion ideal of kind (g) that includes the ideal
(x, y),
where Ideal (a,b..c) =def= {x*a + y*b +..+ z*c | x,y..z <- R}
- a subset in R.
`includes` (as set) is a partial order on ideals, and it is true
that
(1) a divides b <==> (a) includes (b),
(2) (a) includes (a).
Specializing this definition to Integer, we obtain the source
formula.
-----------------
Serge Mechveliani
mechvel@botik.ru
From dongen@cs.ucc.ie Sun Dec 16 13:35:59 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Sun, 16 Dec 2001 13:35:59 +0000
Subject: gcd 0 0 = 0
In-Reply-To: <20011214123858.J21918@cs.ucc.ie>; from dongen@cs.ucc.ie on Fri, Dec 14, 2001 at 12:38:58PM +0000
References: <1113DDB24D4A2841951BFDF86665EE1906660A@RED-MSG-10.redmond.corp.microsoft.com> <20011214123858.J21918@cs.ucc.ie>
Message-ID: <20011216133559.C27182@cs.ucc.ie>
Marc van Dongen (dongen@cs.ucc.ie) wrote:
: An integer $a$ divides integer $b$ if there exists an integer
: $c$ such that $a c= b$.
[snip]
: gcd 0 0 = 0; and
: gcd 0 0 /= error "Blah"
To make clear why $0$ (and not any other non-zero integer) is the
gcd of $0$ and $0$ I should have added that for the integer case
$g$ is called a greatest common divisor (gcd) of $a$ and $b$ if it
satifies each of the following two properties:
1) $g$ divides both $a$ and $b$;
2) if $g'$ is a common divisor of $a$ and $b$ then $g'$ divides $g$.
First notice that $0$ is a gcd of $0$ and $0$ because of the following:
*) $0$ divides $0$ (and divides $0$);
*) whenever $g'$ is an integer that divides $0$ and divides $0$
then $g'$ divides $0$.
Next notice that if $g$ is any non-zero integer then $g$ cannot be
a gcd of $0$ and $0$ because $0$ (a common divisor of $0$ and $0$)
does not divide $g$.
Finally, observe that this makes $0$ the unique gcd of $0$ and $0$.
: The gcd of two integers is usually defined as a non-negative
: number to make it unique.
Regards,
Marc van Dongen
From antony@apocalypse.org Sun Dec 16 20:53:08 2001
From: antony@apocalypse.org (Antony Courtney)
Date: Sun, 16 Dec 2001 15:53:08 -0500
Subject: ANNOUNCE: GCJNI - Java Native Interface for Haskell
Message-ID: <3C1D09B4.2090103@apocalypse.org>
I am pleased to announce an experimental release of GCJNI.
GCJNI is a library that allows Haskell to invoke Java code via the
Java Native Interface (JNI). The implementation uses GreenCard to make
the JNI (a C language interface) available to Haskell. GCJNI includes
a few convenient features, such as:
- Integration of the Haskell and Java garbage collectors, so that
Java objects are garbage collected when they are no longer
accessible from Haskell.
- Type class based overloading, which makes it easy to pass common
types (like Int, Float and String) to or from Java code.
- A tool (GenBindings) which uses Java reflection on a set of
compiled Java classes to generate a Haskell module with a simple,
high-level, type-safe interface to the underlying Java code.
GCJNI has been succesfully tested using both hugs98 and ghc under both
Linux and Windows. Binary distributions are provided for all for of
these (compiler, platform) combinations.
More information (including pointers to the relevant distributions) is
available from the GCJNI web page at:
http://www.haskell.org/gcjni
Bug reports and feedback should be sent to antony@apocalypse.org
Enjoy!
--
Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
antony@apocalypse.org http://www.apocalypse.org/pub/u/antony
From antony@apocalypse.org Sun Dec 16 20:54:41 2001
From: antony@apocalypse.org (Antony Courtney)
Date: Sun, 16 Dec 2001 15:54:41 -0500
Subject: ANNOUNCE: Haven - Scalable Vector Graphics for Haskell
Message-ID: <3C1D0A11.4070702@apocalypse.org>
I am pleased to announce an experimental release of Haven,
a library for scalable vector graphics in Haskell.
Haven provides a wealth of features, including:
- Data types for common geometric shapes such as rectangles,
ellipses and Bezier curves.
- Composition of arbitrary shapes from sequences of straight
and curved segments.
- Intersection tests and bounds calculations on shapes.
- Cropping of any image by any shape.
- Affine transformations on images and paths.
- Calculation of precise rectangular bounds of shapes and images.
- High quality, anti-aliased rendering.
- Scalable outline fonts.
- Smooth blending of colors (gradients)
- Alpha blending (transparency).
- Fine-grained control of stroke width, join rules and end caps.
- Constructive Area Geometry (CAG) for composing shapes using simple
set-theoretic operations.
Haven presents a purely functional API, but is implemented using the
Java2D renderer. For more information on Haven, including examples
and download instructions, please visit the haven web page at:
http://www.haskell.org/haven
Please send suggestions and bug reports to: antony@apocalypse.org
Enjoy!
--
Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
antony@apocalypse.org http://www.apocalypse.org/pub/u/antony
From ashley@semantic.org Sun Dec 16 23:57:53 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Sun, 16 Dec 2001 15:57:53 -0800
Subject: ANNOUNCE: GCJNI - Java Native Interface for Haskell
Message-ID: <200112162357.PAA26291@mail4.halcyon.com>
At 2001-12-16 12:53, Antony Courtney wrote:
>I am pleased to announce an experimental release of GCJNI.
Eh, you beat me to a first release, which I was going to announce
yesterday, but SourceForge's file release system is currently broken. I
guess I'll have to put it on semantic.org
I had no idea anyone else was working on this. Nevertheless, I suspect
I'm further along.
--
Ashley Yakeley, Seattle WA
From ashley@semantic.org Mon Dec 17 00:34:13 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Sun, 16 Dec 2001 16:34:13 -0800
Subject: ANN: Release 0.1 of Haskell/Java VM Bridge
Message-ID: <200112170034.QAA27519@mail4.halcyon.com>
The first release, 0.1, of Haskell/Java VM Bridge is now available.
Haskell/Java VM Bridge allows Haskell programs access to the Java Virtual
Machine. Features include:
* On-the-fly creation of Java classes with Haskell functions
for methods.
* Lifted monads which do all the necessary JNI preloading and
'env'-pointer variable handling for you. These can be
automatically generated via a tool (MakeJVMModule).
* Integration of garbage collectors, type-class based
overloading, and a tool (MakeClassModule) which uses Java
reflection etc. to generate a Haskell module etc., etc.
It is, however, only available for Unix and works only with GHC.
This release should be 'beta' quality, but has undergone little testing.
You will need:
An x86 machine running some form of Unix;
GHC 5.02 or later;
The appropriate JVM, installed in the appropriate place:
- IBM JDK/JRE 1.3 for x86, installed in /usr/lib/ibm-java/IBMJava2-13/
- Blackdown Port of Sun's JRE 1.3/Sun JDK 1.3 for x86, installed in
/usr/lib/j2sdk1.3/ and /usr/lib/j2re1.3/
No documentation is currently available, sorry. Two examples have been
included: a trivial "hello world" program, and a program that shows a
Java Frame containing an instance of a Haskell-defined subclass of Canvas
that has a Haskell 'paint' method that draws an oval. You should be able
to figure out most of it from that... and of course the source is
available from SourceForge CVS.
Be sure to download the correct .tar.gz file for your Java VM. Simple
installation instructions are included in the file.
SourceForge's file release system is currently broken. When it's fixed,
I'll put it there too.
Haskell/JVM Bridge and source code is licensed under the GNU Lesser GPL.
I hope to build an Darwin/OS X version just as soon as there's a port of
GHC 5.02 with a working createAdjustor.
--
Ashley Yakeley, Seattle WA
From antony@apocalypse.org Mon Dec 17 02:44:30 2001
From: antony@apocalypse.org (Antony Courtney)
Date: Sun, 16 Dec 2001 21:44:30 -0500
Subject: ANNOUNCE: GCJNI - Java Native Interface for Haskell
References: <200112162357.PAA26291@mail4.halcyon.com>
Message-ID: <3C1D5C0E.5090402@apocalypse.org>
Hi Ashley,
I'm not quite sure why you Cc'ed the whole Haskell list in replying to my
release announcement, but just for clarification:
Ashley Yakeley wrote:
>
> I had no idea anyone else was working on this.
I find it odd you would say that. When you first mentioned your interest in the
JNI on the Haskell list in early July, I replied to you (and the rest of the
Haskell list) informing you I was working on such a project, and offering to
give you a pre-release snapshot of my source code:
http://www.haskell.org/pipermail/haskell/2001-July/001372.html
When you didn't reply to that message, I emailed you again privately on August
1st, specifically suggesting that we combine forces to avoid duplication of
effort. I never received a reply to that message either.
> Nevertheless, I suspect I'm further along.
Perhaps. Let's move this discussion to private email and try to find a way to
work together.
-antony
--
Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
antony@apocalypse.org http://www.apocalypse.org/pub/u/antony
From frank@cc.gatech.edu Mon Dec 17 05:40:21 2001
From: frank@cc.gatech.edu (Frank Dellaert)
Date: Mon, 17 Dec 2001 00:40:21 -0500
Subject: space efficiency question
Message-ID: <002201c186bd$51fcd6b0$a21ccf82@cc.gatech.edu>
This is a multi-part message in MIME format.
------=_NextPart_000_001F_01C18693.68D2E250
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I'm not a compiler/interpreter implementer, just a Haskell user :-)
My question is: if I have two datatypes, say
newtype Attributes =3D Att [String]
data Instance =3D Instance Attributes [Int]
where an Attributes value describes the discrete attributes that are =
stored (as Int) in an Instance.
Now: if I have a couple of thousand of these Instances, created with the =
same Attributes value, as in:
a =3D Attributes ["a","bc"]
i0000 =3D Instance a [1,2]
i0001 =3D Instance a [1,1]
...
i7896 =3D Instance a [2,1]
can I be assured that there are not thousands of actual copies of a but =
that they simply have a pointer to a ? I'm interested in the answer for =
both ghc (compiled/interpreted) as interpreted Hugs.
I would hope, so, right ? Is there an actual guarantee or is that an =
optimization that the implementation might or might not implement ?
Cheers
Frank Dellaert
------=_NextPart_000_001F_01C18693.68D2E250
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I'm not a compiler/interpreter =
implementer, just a=20
Haskell user :-)
My question is: if I have two =
datatypes,=20
say
newtype Attributes =3D Att =
[String]
data Instance =3D Instance Attributes=20
[Int]
where an Attributes value describes the =
discrete=20
attributes that are stored (as Int) in an Instance.
Now: if I have a couple of thousand of =
these=20
Instances, created with the same Attributes value, as in:
a =3D Attributes =
["a","bc"]
i0000 =3D Instance a [1,2]
i0001 =3D Instance a [1,1]
...
i7896 =3D Instance a [2,1]
can I be assured that there are not =
thousands of=20
actual copies of a but that they simply have a pointer to a ? I'm =
interested in=20
the answer for both ghc (compiled/interpreted) as interpreted =
Hugs.
I would hope, so, right ? Is there an =
actual=20
guarantee or is that an optimization that the implementation might or =
might not=20
implement ?
Cheers
Frank =
Dellaert
------=_NextPart_000_001F_01C18693.68D2E250--
From simonpj@microsoft.com Mon Dec 17 09:24:47 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 17 Dec 2001 01:24:47 -0800
Subject: space efficiency question
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066623@RED-MSG-10.redmond.corp.microsoft.com>
This is a multi-part message in MIME format.
--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C186DC.ABC0BECE"
------_=_NextPart_001_01C186DC.ABC0BECE
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Now: if I have a couple of thousand of these Instances, created with the
same Attributes value, as in:
=20
a =3D Attributes ["a","bc"]
i0000 =3D Instance a [1,2]
i0001 =3D Instance a [1,1]
...
i7896 =3D Instance a [2,1]
=20
can I be assured that there are not thousands of actual copies of a but
that they simply have a pointer to a ? I'm interested in the answer for
both ghc (compiled/interpreted) as interpreted Hugs.=20
Yes for GHC: you'll only get one copy of 'a'.
=20
Simon
=20
------_=_NextPart_001_01C186DC.ABC0BECE
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message
Now: if I have a couple of thousand of =
these=20
Instances, created with the same Attributes value, as in:
a =3D Attributes =
["a","bc"]
i0000 =3D Instance a =
[1,2]
i0001 =3D Instance a =
[1,1]
...
i7896 =3D Instance a =
[2,1]
can I be assured that there are =
not=20
thousands of actual copies of a but that they simply have a pointer to =
a ? I'm=20
interested in the answer for both ghc (compiled/interpreted) as =
interpreted=20
Hugs.
Yes for GHC: you'll only get one copy of=20
'a'.
Simon
------_=_NextPart_001_01C186DC.ABC0BECE--
--------------InterScan_NT_MIME_Boundary--
From reiner@cs.chalmers.se Mon Dec 17 09:55:16 2001
From: reiner@cs.chalmers.se (Reiner Haehnle)
Date: Mon, 17 Dec 2001 10:55:16 +0100 (MET)
Subject: Call for Applications to PhD Positions, Chalmers University, Sweden
Message-ID:
Please pass on to interested students. Apologies for multiple copies.
---------------------------------------------------------------------
New PhD Positions (DEADLINE 15 February 2002! See "How to apply" below)
Department of Computing Science,
Chalmers University of Technology & University of Gothenburg
Sweden
The Department has about 70 researchers, half being faculty members
and half PhD students. Our focus is on programming logic, type theory,
functional programming, formal methods, distributed and concurrent
systems, security, algorithms, bioinformatics, human computer
interaction, and computational linguistics, but research is not
restricted to these topics. For more information, see
http://www.cs.chalmers.se/Cs/Research.
PhD positions are for 5 years. There is no tuition fee. A PhD position
is a regular job with social benefits; the salary amounts currently to
about 16700 SEK per month in the first year (the exact amount depends
on teaching duties, usually 20% of your time).
Knowledge of Swedish is not a prerequisite for application. English is
our working language for research. Both Swedish and English are used
in undergraduate courses. Half of our researchers and PhD students
are native Swedes; the rest come from more than 20 different
countries.
Applicants must have a very good undergraduate degree in Computing
Science or in a related subject with a strong Computing Science
component. They must also have a strong interest in doing research.
You may even apply if you have not yet completed your degree, but
expect to do so by September 2002. You are also invited to apply for
our new International Master's Programme in Dependable Computer
Systems, which can help you to obtain the necessary qualification (see
http://www.cs.chalmers.se/Cs/Education/dcs/).
The School especially welcomes female applicants.
How to apply
------------
First, immediately register your intention to apply using the
electronic application form on the WWW via
http://www.md.chalmers.se/Jobs/PhD/phd-02-en.thtml
The full application should contain
1 A letter of application, listing specific research interests
2 A curriculum vitae
3 Attested copies of degrees and other certificates
4 Copies of relevant work, for example dissertations or
articles, that you have authored or co-authored
5 A description of:
a previous teaching experience, documented
b previous PhD studies, also in other subjects;
state financial support for these, if any
c previous work experience
6 Letters of recommendation from your teachers or employers
If you have financial support of your own (industry job, grant, etc.),
please state this fact clearly. It will increase your chances to be
accepted considerably, because you need not compete for the limited
number of fully financed positions.
Send your full application (paper mail) to
Department of Computing Science
School of Computer Science and Engineering
Chalmers University of Technology
412 96 Gothenburg
Sweden
to arrive by 15 February 2002. You will know the result of your
application by 1 May 2002.
From thorinn@diku.dk Mon Dec 17 14:50:21 2001
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Date: 17 Dec 2001 14:50:21 -0000
Subject: gcd 0 0 = 0
In-Reply-To: <20011216133559.C27182@cs.ucc.ie> (message from Marc van Dongen
on Sun, 16 Dec 2001 13:35:59 +0000)
Message-ID: <20011217145021.3269.qmail@tyr.diku.dk>
> From: Marc van Dongen
> Date: Sun, 16 Dec 2001 13:35:59 +0000
>
> Marc van Dongen (dongen@cs.ucc.ie) wrote:
>
> : An integer $a$ divides integer $b$ if there exists an integer
> : $c$ such that $a c= b$.
>
> To make clear why $0$ (and not any other non-zero integer) is the
> gcd of $0$ and $0$ I should have added that for the integer case
> $g$ is called a greatest common divisor (gcd) of $a$ and $b$ if it
> satifies each of the following two properties:
>
> 1) $g$ divides both $a$ and $b$;
> 2) if $g'$ is a common divisor of $a$ and $b$ then $g'$ divides $g$.
In case it isn't clear already, these definitions make a lattice on
the positive integers, with divides ~ leq, gcd ~ meet and lcm ~ join,
using the report's definitions of gcd and lcm.
(Choosing the positive result for gcd/lcm is equivalent to noting that
divides is a partial preorder on the non-zero integers, and that the
quotient identifies x and -x).
The only thing that is lacking to make it a lattice on the
non-negative integers, is that gcd 0 0 = 0 . All other cases
involving zero (i.e., gcd 0 x = x for non-zero x, and lcm 0 x = 0
for all x) are consistent with 0 being the maximal element in the
lattice, i.e., that all integers divide zero.
Lars Mathiesen (U of Copenhagen CS Dep) (Humour NOT marked)
From simonpj@microsoft.com Mon Dec 17 16:57:28 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 17 Dec 2001 08:57:28 -0800
Subject: Confused about default
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066637@RED-MSG-10.redmond.corp.microsoft.com>
Well, Foo *is* an instance of Num, so a correct Haskell impl
should pick that instance always. Since you don't define the
fromInteger method in the instance decl, you get a runtime error.
I don't know what you expect the [Foo] and Foo -> Int defaults
to do.
GHCi fails to put the correct default decl in place for command-line
expressions. This is a known bug which we have not got around
to fixing yet
Simon
| -----Original Message-----
| From: Ian Lynagh [mailto:igloo@earth.li]=20
| Sent: 14 December 2001 21:29
| To: haskell@haskell.org
| Subject: Confused about default
|=20
|=20
|=20
| Hi all
|=20
| I am rather confused about default.
|=20
| In section 4.3.4 the report says
| "each ti must be a monotype for which Num ti holds"
| but according to grep this is the only place "monotype"=20
| appears in the report.
|=20
| If I have the module
|=20
| module TT (Foo(..)) where
|=20
| default (Foo, [Foo], Foo -> Int)
|=20
| data Foo =3D Foo deriving (Eq, Show)
|=20
| instance Num Foo where {}
| instance (Eq a, Show a) =3D> Num [a] where {}
| instance Eq (a -> b) where {}
| instance Show (a -> b) where {}
| instance Num (a -> b) where {}
|=20
| then hugs accepts it and
| TT> 5
|=20
| Program error: Undefined member: fromInteger
|=20
| ghc accepts it and
| TT> 5
| 5
|=20
| nhc tells me
|=20
| Error when renaming::
| Illegal type in default at 4:17
|=20
| If I remove all the list and function stuff then hi says
| TT> 5
| 5
|=20
| If I have a
| main =3D putStrLn $ show 5
|=20
| then nhc gives me
| TT> main
| No default definition for class method fromInteger
|=20
| and ghci gives me
| Main> main
| *** Exception: TT.lhs:8: No instance nor default method for class
| operation PrelNum.fromInteger
|=20
|=20
| It seems to me that hugs is in the right with it's handling=20
| of 5, but I am not sure who is wrong with default ([Foo]) or=20
| (Foo -> Int).
|=20
|=20
| Finally, the context free grammar doesn't currently enforce=20
| the restriction that only one default declaration be given.=20
| Fixing it would make rather a mess, though.
|=20
|=20
| Ian
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From ger@tzi.de Mon Dec 17 17:05:41 2001
From: ger@tzi.de (George Russell)
Date: Mon, 17 Dec 2001 18:05:41 +0100
Subject: gcd 0 0 = 0
Message-ID: <3C1E25E5.81718477@tzi.de>
I've reconsidered my earlier position and think now that the Prelude is wrong to make
gcd 0 0 an error, and should return 0. It probably doesn't make much difference to
anyone, but it's like 1 not being a prime; it may be slightly harder to explain, but it
makes the maths come out nicer and is in the end a simplification.
From herrmann@infosun.fmi.uni-passau.de Mon Dec 17 17:31:17 2001
From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann)
Date: Mon, 17 Dec 2001 18:31:17 +0100
Subject: gcd 0 0 = 0
In-Reply-To: <3C1E25E5.81718477@tzi.de>
References: <3C1E25E5.81718477@tzi.de>
Message-ID: <15390.11237.38564.819599@reger.fmi.uni-passau.de>
>>>>> "George" == George Russell writes:
George> I've reconsidered my earlier position and think now that the
George> Prelude is wrong to make gcd 0 0 an error, and should return
George> 0. It probably doesn't make much difference to anyone, but
George> it's like 1 not being a prime; it may be slightly harder to
George> explain, but it makes the maths come out nicer and is in the
George> end a simplification.
I'm strongly against making 1 a prime number.
In contrast, 0*x=0, thus 0 "divides" 0 (somehow).
But I have problems with "gcd being the greatest positive integer ..."
- 0 is not positive, it is non-negative or natural
- 2 also divides 0 and 2 is a "greater integer" than 0
(0 is the top element of the lattice formed by the division relation
but that is not clear by the expression "greatest")
Anyway, gcd 0 0 = error would be the simplest way to avoid confusion
and catch accidental programming errors; e.g., using the gcd to divide
something else.
--
Christoph
From igloo@earth.li Mon Dec 17 17:32:02 2001
From: igloo@earth.li (Ian Lynagh)
Date: Mon, 17 Dec 2001 17:32:02 +0000
Subject: Confused about default
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE19066637@RED-MSG-10.redmond.corp.microsoft.com>; from simonpj@microsoft.com on Mon, Dec 17, 2001 at 08:57:28AM -0800
References: <1113DDB24D4A2841951BFDF86665EE19066637@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <20011217173202.A10045@stu163.keble.ox.ac.uk>
On Mon, Dec 17, 2001 at 08:57:28AM -0800, Simon Peyton-Jones wrote:
> Well, Foo *is* an instance of Num, so a correct Haskell impl
> should pick that instance always.
I was looking at what the implementations would allow, the module wasn't
supposed to be useful.
> Since you don't define the
> fromInteger method in the instance decl, you get a runtime error.
I expected this, I included it as in some cases I *didn't* et a runtime
error though.
> I don't know what you expect the [Foo] and Foo -> Int defaults
> to do.
Let me try to clarify what I was asking:
What is a monotype? For example, is "[Foo]" a monotype and is
"Foo -> Int" a monotype? The context free grammar implies that a
monotype is identical to a type, in which case why is a different name
used?
The rest was to attempt to highlight some inconsistencies in the
implementations.
Thanks
Ian
From Alan@LCS.MIT.EDU Mon Dec 17 18:45:04 2001
From: Alan@LCS.MIT.EDU (Alan Bawden)
Date: Mon, 17 Dec 2001 13:45:04 -0500 (EST)
Subject: gcd 0 0 = 0
In-Reply-To: <20011217145021.3269.qmail@tyr.diku.dk> (message from Lars Henrik
Mathiesen on 17 Dec 2001 14:50:21 -0000)
References: <20011217145021.3269.qmail@tyr.diku.dk>
Message-ID: <17Dec2001.133056.Alan@LCS.MIT.EDU>
From: Lars Henrik Mathiesen
Date: 17 Dec 2001 14:50:21 -0000
...
In case it isn't clear already, these definitions make a lattice on
the positive integers, with divides ~ leq, gcd ~ meet and lcm ~ join,
using the report's definitions of gcd and lcm.
Indeed, that's a nice way of putting it. How about if the report just
says:
In order to make the non-negative integers into a lattice under `gcd'
and `lcm', we define `gcd 0 0 = 0'.
From foc@cs.indiana.edu Mon Dec 17 22:26:25 2001
From: foc@cs.indiana.edu (LICS)
Date: Mon, 17 Dec 2001 17:26:25 -0500 (EST)
Subject: faculty position in logic
Message-ID: <200112172226.fBHMQHS08034@moose.cs.indiana.edu>
[Sincere apologies for duplicates]
Indiana University invites applications for a tenure-track
assistant professor position in applied logic.
Please see www.informatics.indiana.edu/positions/logic.html
for details. Applications received within the next few
weeks are likely to still get full consideration.
Applicants are welcome to email to foc@cs.indiana.edu
to notify of their mailed application, and to provide
pointers to any pertinent on-line documentation.
From foc@cs.indiana.edu Mon Dec 17 22:26:25 2001
From: foc@cs.indiana.edu (LICS)
Date: Mon, 17 Dec 2001 17:26:25 -0500 (EST)
Subject: faculty position in logic
Message-ID: <200112172226.fBHMQPx08125@moose.cs.indiana.edu>
[Sincere apologies for duplicates]
Indiana University invites applications for a tenure-track
assistant professor position in applied logic.
Please see www.informatics.indiana.edu/positions/logic.html
for details. Applications received within the next few
weeks are likely to still get full consideration.
Applicants are welcome to email to foc@cs.indiana.edu
to notify of their mailed application, and to provide
pointers to any pertinent on-line documentation.
From dongen@cs.ucc.ie Tue Dec 18 09:22:25 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Tue, 18 Dec 2001 09:22:25 +0000
Subject: gcd 0 0 = 0
In-Reply-To: <15390.11237.38564.819599@reger.fmi.uni-passau.de>; from herrmann@infosun.fmi.uni-passau.de on Mon, Dec 17, 2001 at 06:31:17PM +0100
References: <3C1E25E5.81718477@tzi.de> <15390.11237.38564.819599@reger.fmi.uni-passau.de>
Message-ID: <20011218092225.O27182@cs.ucc.ie>
Ch. A. Herrmann (herrmann@infosun.fmi.uni-passau.de) wrote:
: In contrast, 0*x=0, thus 0 "divides" 0 (somehow).
: But I have problems with "gcd being the greatest positive integer ..."
[snip]
: - 0 is not positive, it is non-negative or natural
: - 2 also divides 0 and 2 is a "greater integer" than 0
: (0 is the top element of the lattice formed by the division relation
: but that is not clear by the expression "greatest")
:
gcd a b is the greatest non-negative integer dividing both a
and b such that anything that divides both a and b also divides
gcd a b (so gcd a b is the greatest thing that divides both a
and b).
Regards,
Marc van Dongen
--
Marc van Dongen | dongen@cs.ucc.ie |
Computer Science Department | Western Road | () ASCII ribbon campaign
University College Cork | Cork, Ireland | /\ against HTML mail
phone: +353 (0)21 4903578 | fax: 4903113 |
From juhp@01.246.ne.jp Tue Dec 18 09:32:11 2001
From: juhp@01.246.ne.jp (Jens-Ulrik Petersen)
Date: 18 Dec 2001 18:32:11 +0900
Subject: ANNOUNCE: hsclock-0.01.0 release
Message-ID:
I am pleased to announce the initial release of hsclock,
another gtk+hs "applet" I've written.
hsclock is an accurate multi-zone gtk clock, which can also
run in a tty.
hsclock uses gtk timeouts to synchronise the time updates to
occur on the second or minute "tick" (dependent on the clock
format string), making display updates accurate to within
milliseconds.
More info, source and rpm's are available at:
http://www.01.246.ne.jp/~juhp/haskell/hsclock/
As usual feedback and comments welcome.
Enjoy, Jens
From dongen@cs.ucc.ie Tue Dec 18 09:32:49 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Tue, 18 Dec 2001 09:32:49 +0000
Subject: gcd 0 0 = 0
In-Reply-To: <17Dec2001.133056.Alan@LCS.MIT.EDU>; from Alan@LCS.MIT.EDU on Mon, Dec 17, 2001 at 01:45:04PM -0500
References: <20011217145021.3269.qmail@tyr.diku.dk> <17Dec2001.133056.Alan@LCS.MIT.EDU>
Message-ID: <20011218093249.P27182@cs.ucc.ie>
Alan Bawden (Alan@LCS.MIT.EDU) wrote:
: In case it isn't clear already, these definitions make a lattice on
: the positive integers, with divides ~ leq, gcd ~ meet and lcm ~ join,
: using the report's definitions of gcd and lcm.
:
: Indeed, that's a nice way of putting it. How about if the report just
: says:
:
: In order to make the non-negative integers into a lattice under `gcd'
: and `lcm', we define `gcd 0 0 = 0'.
It would surely make things a lot less accessible to people (including
me) who do not have any (or limited) knowledge about lattices. Why not
make it more accessible and use the following rule (ore something similar)?
The greates common divison (gcd) of two integers a and b is the unique
non-negative integer g which has each of the following two properties:
1) g divides both a and b; and
2) if g' also divides both a and b then g' also divides g,
Here an integer a divides an integer b if there is an integer c
such that b = c*a.
Note that if you regard an integer a to be greater than another
integer b if b divides a then the gcd of two intgerers may also
be regarded as the greatest common divisor of a and b.
Regards,
Marc van Dongen
From simonpj@microsoft.com Tue Dec 18 09:38:21 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 18 Dec 2001 01:38:21 -0800
Subject: gcd 0 0 = 0
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066640@RED-MSG-10.redmond.corp.microsoft.com>
If everyone likes this I'll put it in; otherwise I'll simply state that
gcd 0 0 is defined to be 0.=20
Christoph does not like this, but the weight of world opinion seems=20
to be fairly clearly in favour of gcd 0 0 =3D 0. Let's try to wrap =
this
one
up.
Simon
| -----Original Message-----
| From: Alan Bawden [mailto:Alan@LCS.MIT.EDU]=20
| Sent: 17 December 2001 18:45
| To: haskell@haskell.org; Simon Peyton-Jones
| Subject: Re: gcd 0 0 =3D 0
|=20
|=20
| From: Lars Henrik Mathiesen
| Date: 17 Dec 2001 14:50:21 -0000
| ...
| In case it isn't clear already, these definitions make a lattice on
| the positive integers, with divides ~ leq, gcd ~ meet and=20
| lcm ~ join,
| using the report's definitions of gcd and lcm.
|=20
| Indeed, that's a nice way of putting it. How about if the report just
| says:
|=20
| In order to make the non-negative integers into a lattice=20
| under `gcd'
| and `lcm', we define `gcd 0 0 =3D 0'.
|=20
From simonpj@microsoft.com Tue Dec 18 09:48:34 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 18 Dec 2001 01:48:34 -0800
Subject: Confused about default
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066643@RED-MSG-10.redmond.corp.microsoft.com>
| Let me try to clarify what I was asking:
|=20
| What is a monotype? For example, is "[Foo]" a monotype and is=20
| "Foo -> Int" a monotype? The context free grammar implies=20
| that a monotype is identical to a type, in which case why is=20
| a different name used?
A monotype is a type with no for-alls in it. But you are right that
it's confusing that this is the only occurrence. I think the simplest
thing is to change 'monotype' to 'type' here; after all, Num (forall
a.a->a)=20
does not hold!
thanks for pointing this out.
Simon
From simonpj@microsoft.com Tue Dec 18 09:58:23 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 18 Dec 2001 01:58:23 -0800
Subject: Haskell 98 IO
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066646@RED-MSG-10.redmond.corp.microsoft.com>
| Anyway, what should the report say? I think it is reasonable=20
| to expect that stdin & stdout should both be unbuffered in=20
| order for interact to work right. So the defn of interact should be
|=20
| interact f =3D do
| hSetBuffering stdin NoBuffering -- new
| hSetBuffering stdout NoBuffering -- new
| s <- hGetContents
| putStr (f s)
Simon Marlow raises a good point here. If 'interact' is to be
interactive
it had better be unbuffered. So I propose to add the two new lines
above to the Report. This does not change the intended behaviour
at all.
Simon
From gupta@herbrand.utdallas.edu Mon Dec 17 23:28:05 2001
From: gupta@herbrand.utdallas.edu (Dr. Gopal Gupta)
Date: Mon, 17 Dec 2001 17:28:05 -0600
Subject: 4th Int'l Symp.: Practical Aspects of Declarative Languages
Message-ID: <200112172328.fBHNS5u02536@herbrand.utdallas.edu>
[ o Apologies for multiple messages.
o Please register and make hotel reservations as soon as possible since
both deadlines are approaching fast (Dec. 27th)
].
You are cordially invited to the Fourth International Symposium on
Practical Aspects of Declarative Languages that will be held on Jan 19-20,
2002 right after ACM POPL. The program includes invited talks by three
distinguished speakers: J. Strother Moore of the University of Texas at
Austin, Catherine Meadows of the Naval Research Labs, and Veronica Dahl of
Simon Fraser University. Very low registration rates ($150 regular and
$100 student) and low conference hotel rates have been secured to make the
event affordable. The program ends by late afternoon on Sunday to let
attendees return home on Sunday itself. If you are attending ACM POPL, we
especially encourage you to plan to attend PADL.
More details can be found at:
http://www.cs.sunysb.edu/~padl2002
---------------------------------------------------------------------
Fourth International Symposium on
Practical Aspects of Declarative Languages
(PADL '02)
Portland, Oregon, USA Jan 19-20, 2002
Co-located with POPL 2002
---------------------------------------------------------------------
Conference Program
==================
Jan 19th
8:45-9:00 Opening Remarks
9:00-10:00 Invited Talk #1
Using a Declarative Language to Build an Experimental Analysis Tool
Catherine Meadows (Naval Research Laboratory),
10:00-10:30 Coffee Break
10:30-12:30 Session-I:
Modeling Engineering Structures using Constrained Objects
Bharat Jayaraman and Pallavi Tambay
Compiler Construction in Higher Order Logic Programming
Chuck Liang
Declarative Programming with Application to Clinical Medicine:
On the Use of Gisela in the MedView Project.
Olof Torgersson
Semantics-based Filtering: Logic Programming's Killer App?
Gopal Gupta, Hai-Feng Guo, Arthur Karshmer,
Enrico Pontelli, Desh Ranjan, B. Milligan,
N. Datta, O. El Khatib, M. Noamany, and X. Zhou
12:30-1:30 Lunch
1:30-2:30 Invited Talk #2
How to Talk to Your Computer So That it Will Listen
Veronica Dahl (Simon Fraser University),
2:45-4:15 Session-II:
Linear Scan Register Allocation in a High-Performance Erlang Compiler
Erik Johansson and Konstantinos Sagonas
Typed Combinators for Generic Traversal
Ralf Laemmel and Joost Visser
Event-Driven FRP.
Zhanyong Wan, Walid Taha, and Paul Hudak
4:15-4:30 Coffee Break
4:30-6:00 Session-III:
Compiling Embedded Programs to Byte Code.
Morten Rhiger,
Exploiting Efficient Control and Data Structures in Logic Programs.
Rong Yang and Steve Gregory,
Memory Management and Scheduling in a Tabling Engine
Luis F. Castro and Terrance Swift and David S. Warren
--------------------------------------------------------------------------------
Jan 20th
9:00-10:00 Invited Talk #3:
Single-Threaded Objects in ACL2.
J. Strother Moore (University of Texas, Austin)
10:00-10:30 Coffee Break
10:30-12:30 Session-IV:
Adding Apples and Oranges
Martin Erwig and Margaret Burnett
WASH/CGI: Server-side Web Scripting with Sessions and Typed,
Compositional Forms.
Peter Thiemann
A better XML parser through functional programming.
Oleg Kiselyov
Functional Approach to Texture Generation.
Jerzy Karczmarczuk
12:30-1:30 Lunch
1:30-3:30 Session-V:
Abstract Interpretation over Non-Deterministic Finite
Tree Automata for Set-Based Analysis of Logic Programs.
John Gallagher, German Puebla,
A High-Level Generic Interface to External Programming Languages for ECLiPSe.
Kish Shen, Joachim Schimpf, Stefano Novello, Josh Singer,
Segment Order Preserving and Generational Garbage Collection for Prolog.
Ruben Vandeginste, Konstantinos Sagonas, and Bart Demoen,
A Debugging Scheme for Declarative Equation Based Modeling Languages.
Peter Bunus, Peter Fritzson
From herrmann@infosun.fmi.uni-passau.de Tue Dec 18 11:16:11 2001
From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann)
Date: Tue, 18 Dec 2001 12:16:11 +0100
Subject: gcd 0 0 = 0
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE19066640@RED-MSG-10.redmond.corp.microsoft.com>
References: <1113DDB24D4A2841951BFDF86665EE19066640@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <15391.9595.758521.560553@reger.fmi.uni-passau.de>
>>>>> "Simon" == Simon Peyton-Jones writes:
Simon> Christoph does not like this
It's OK if the definition is clear; it wasn't using
the words "positive" or "greatest integer".
Stating "gcd 0 0 = 0" explicitly is a good thing,
even if it could be expressed verbatim;
people may think about the mathematical background,
but they should not need to think about the
meaning of the definition.
Anyway, I'm still against promoting 1 to a prime number :-)
Cheers
--
Christoph
From frank@cc.gatech.edu Tue Dec 18 11:48:18 2001
From: frank@cc.gatech.edu (Frank Dellaert)
Date: Tue, 18 Dec 2001 12:48:18 +0100
Subject: space efficiency question
References: <1113DDB24D4A2841951BFDF86665EE19066623@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <000f01c187b9$e3216280$544a88d9@oemcomputer>
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C187C2.4477ED80
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MessageThanks !
Now, a small follow-up question: if I subsequently test 2 Instances =
whether they were instantiated with the same Attributes value, as in
test (Instance a1 _) (Instance a2 _) =3D (a1=3D=3Da2)
will this be implemented efficiently ? I.e. will it check first whether =
the pointers happen to be the same, and only then do a full Eq =
comparison ?
Cheers
Frank
----- Original Message -----=20
From: Simon Peyton-Jones=20
To: Frank Dellaert ; Haskell@haskell.org=20
Sent: Monday, December 17, 2001 10:24 AM
Subject: RE: space efficiency question
Now: if I have a couple of thousand of these Instances, created with =
the same Attributes value, as in:
=20
a =3D Attributes ["a","bc"]
i0000 =3D Instance a [1,2]
i0001 =3D Instance a [1,1]
...
i7896 =3D Instance a [2,1]
=20
can I be assured that there are not thousands of actual copies of a =
but that they simply have a pointer to a ? I'm interested in the answer =
for both ghc (compiled/interpreted) as interpreted Hugs.=20
Yes for GHC: you'll only get one copy of 'a'.
=20
Simon
=20
------=_NextPart_000_000C_01C187C2.4477ED80
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message
Thanks !
Now, a small follow-up question: if I =
subsequently=20
test 2 Instances whether they were instantiated with the same Attributes =
value,=20
as in
test (Instance a1 _) (Instance a2 _) =
=3D=20
(a1=3D=3Da2)
will this be implemented efficiently ? =
I.e. will it=20
check first whether the pointers happen to be the same, and only then do =
a full=20
Eq comparison ?
Cheers
Frank
----- Original Message -----
From:=20
Simon=20
Peyton-Jones
Sent: Monday, December 17, 2001 =
10:24=20
AM
Subject: RE: space efficiency=20
question
Now: if I have a couple of thousand =
of these=20
Instances, created with the same Attributes value, as in:
a =3D Attributes =
["a","bc"]
i0000 =3D Instance a =
[1,2]
i0001 =3D Instance a =
[1,1]
...
i7896 =3D Instance a =
[2,1]
can I be assured that there =
are not=20
thousands of actual copies of a but that they simply have a pointer =
to a ?=20
I'm interested in the answer for both ghc (compiled/interpreted) as=20
interpreted Hugs.
Yes for GHC: you'll =
only get one=20
copy of 'a'.
Simon
=
------=_NextPart_000_000C_01C187C2.4477ED80--
From voigt@orchid.inf.tu-dresden.de Tue Dec 18 13:22:19 2001
From: voigt@orchid.inf.tu-dresden.de (Janis Voigtlaender)
Date: Tue, 18 Dec 2001 14:22:19 +0100
Subject: space efficiency question
References: <1113DDB24D4A2841951BFDF86665EE19066623@RED-MSG-10.redmond.corp.microsoft.com> <000f01c187b9$e3216280$544a88d9@oemcomputer>
Message-ID: <3C1F430B.D5B230AC@tcs.inf.tu-dresden.de>
Frank Dellaert asks:
> test (Instance a1 _) (Instance a2 _) = (a1==a2)
>
> will this be implemented efficiently ? I.e. will it check first whether the > pointers happen to be the same, and only then do a full Eq comparison ?
No, otherwise you might also expect that the following test' function:
test' :: String -> Bool
test' s = (s==s)
always returns True, without considering its actual argument s. But this
is not the way of it, (==) evaluates the two strings to be compared as
far as necessary for this comparison. For example:
test' "abc" = True
but:
test' undefined = undefined
If you really need something like pointer equality, you might want to
consider the stable names of:
@inproceedings{ jones99stretching,
author = "Simon L. Peyton Jones and Simon Marlow and Conal Elliott",
title = "Stretching the Storage Manager: Weak Pointers and Stable
Names in Haskell",
booktitle = "Implementation of Functional Languages",
pages = "37-58",
year = "1999",
url = "citeseer.nj.nec.com/jones99stretching.html" }
--
Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:voigt@tcs.inf.tu-dresden.de
From thorinn@diku.dk Tue Dec 18 16:11:08 2001
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Date: 18 Dec 2001 16:11:08 -0000
Subject: gcd 0 0 = 0
In-Reply-To: <20011218093249.P27182@cs.ucc.ie> (message from Marc van Dongen
on Tue, 18 Dec 2001 09:32:49 +0000)
Message-ID: <20011218161108.5990.qmail@tyr.diku.dk>
> From: Marc van Dongen
> Date: Tue, 18 Dec 2001 09:32:49 +0000
>
> Alan Bawden (Alan@LCS.MIT.EDU) wrote:
> : Indeed, that's a nice way of putting it. How about if the report just
> : says:
> :
> : In order to make the non-negative integers into a lattice under `gcd'
> : and `lcm', we define `gcd 0 0 = 0'.
> It would surely make things a lot less accessible to people
> (including me) who do not have any (or limited) knowledge about
> lattices. Why not make it more accessible and use the following rule
> (ore something similar)?
> The greates common divison (gcd) of two integers a and b is the unique
> non-negative integer g which has each of the following two properties:
> 1) g divides both a and b; and
> 2) if g' also divides both a and b then g' also divides g,
> Here an integer a divides an integer b if there is an integer c
> such that b = c*a.
This is exactly what you get if you plug the relation 'divides' on the
non-negative integers into the definition of meet in a lattice. So
this formulation is no more or less complex to use than the lattice
one --- and people who do know about lattices will probably realize
this pretty fast.
It all depends on who you want to convince that gcd 0 0 should be 0,
the mathematicians (by elegance) or the programmers (by concreteness).
But since it seems that Simon is just going to put 'it is so' in the
report, the point is moot.
Lars Mathiesen (U of Copenhagen CS Dep) (Humour NOT marked)
From wittner@uni-duesseldorf.de Tue Dec 18 16:43:33 2001
From: wittner@uni-duesseldorf.de (Toralf Wittner)
Date: Tue, 18 Dec 2001 17:43:33 +0100
Subject: x^y
Message-ID: <0GOJ006RUT6O12@neptun.rz.uni-duesseldorf.de>
Hello,
you can count me as a newbie in functional programming. I'm attempting to
define a function that computes the value of x^y for whole numbers. Intuively
(all efficiency considerations aside) I would start with something like this:
power x y
| x == 0 = 0
| y == 0 = 1
| y > 0 = x * power x (y-1)
| y < 0 = 1 / fromInteger x * power x (y+1)
One recognizes that the function returns either an integer value if y > 0 or
a float value if y < 0. Therefore I can't write a signature like
pow :: Integer -> Integer -> Integer nor can I do
pow :: Integer -> Integer -> Double. If I would use Python I could write
something like this:
def power(m, n):
if m == 0: return 0
if n == 0: return 1
if n > 0: return m * power(m, (n-1))
if n < 0: return (1 / float(m)) * power(m, (n+1))
How then would I write this function in Haskell (concerning types)?
Thanks in advance! Kind regards,
Toralf
From dongen@cs.ucc.ie Tue Dec 18 17:02:36 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Tue, 18 Dec 2001 17:02:36 +0000
Subject: gcd 0 0 = 0
In-Reply-To: <20011218161108.5990.qmail@tyr.diku.dk>; from thorinn@diku.dk on Tue, Dec 18, 2001 at 04:11:08PM -0000
References: <20011218093249.P27182@cs.ucc.ie> <20011218161108.5990.qmail@tyr.diku.dk>
Message-ID: <20011218170236.C4643@cs.ucc.ie>
Lars Henrik Mathiesen (thorinn@diku.dk) wrote:
: > Alan Bawden (Alan@LCS.MIT.EDU) wrote:
: > : Indeed, that's a nice way of putting it. How about if the report just
: > : says:
: > :
: > : In order to make the non-negative integers into a lattice under `gcd'
: > : and `lcm', we define `gcd 0 0 = 0'.
[snip]
: This is exactly what you get if you plug the relation 'divides' on the
: non-negative integers into the definition of meet in a lattice. So
: this formulation is no more or less complex to use than the lattice
: one --- and people who do know about lattices will probably realize
: this pretty fast.
I disagree. Alan is talking about adding things to the haskell report.
That document should be accessible to as many people as possible.
I have not yet met anybody who had lattice theory in primary and/or
secondary school. On the other hand I *have* met quite a few of them
who have a pretty good idea about what it means for one number to
divide another.
[snip]
Regards,
Marc van Dongen
--
Marc van Dongen | dongen@cs.ucc.ie |
Computer Science Department | Western Road | () ASCII ribbon campaign
University College Cork | Cork, Ireland | /\ against HTML mail
phone: +353 (0)21 4903578 | fax: 4903113 |
From kentk@md.chalmers.se Tue Dec 18 17:00:30 2001
From: kentk@md.chalmers.se (Kent Karlsson)
Date: Tue, 18 Dec 2001 18:00:30 +0100
Subject: gcd 0 0 = 0
In-Reply-To: <15391.9595.758521.560553@reger.fmi.uni-passau.de>
Message-ID: <000701c187e5$80c7c1c0$b4e21081@chalmers95a69n>
> >>>>> "Simon" == Simon Peyton-Jones writes:
>
> Simon> Christoph does not like this
I still don't like this. 0 has never, and will never, divide anything,
in particular not 0. 0 may be a prime factor of 0 (see also below!),
but that is different. It is not the greatest (in the ordinary sense)
divisor of 0. Indeed, +infinity is a much larger divisor of 0...
I'm not in favour of using a very special-purpose order, not used for
anything else, and that isn't even an order but a preorder, just to
motivate gcd 0 0 = 0. Even if using this very special-purpose preorder,
an infinity would be included in the 'top' equivalence class, and if we
pick a representative value on the basis of which is 'greater' in the
ordinary sense for integers augmented with infinities(!), then +infinity
should be the representative value. Thus, in any case, gcd 0 0 = +infinity.
This is easy enough for Integer, where +infinity and -infinity can easily
be made representable (and should be made representable), but harder for
a 'pure hardware' Int datatype. But in an ideal world, gcd 0 0 = +infinity
with no error or exception.
> It's OK if the definition is clear; it wasn't using
> the words "positive" or "greatest integer".
>
> Stating "gcd 0 0 = 0" explicitly is a good thing,
> even if it could be expressed verbatim;
> people may think about the mathematical background,
> but they should not need to think about the
> meaning of the definition.
> Anyway, I'm still against promoting 1 to a prime number :-)
Why? If EVERY natural number is to have a prime factorisation, then BOTH
0 AND 1 have to be promoted to prime numbers; otherwise 1 and 0 cannot be
prime factorised; in addition to that 1 is then a prime factor of any number
(that can be excluded from the *minimal* list of prime factors except for 1)...
There is no fundamental reason to except 1 from being a prime number. But
there is a fundamental reason to say that 0 can never be a divisor (i.e. 0|0
is false; x|y is true iff x is a *non-zero* factor of y; the 'non-zero' part
is often left implicit (e.g. one is only talking about strictly positive
integers), which is part of the reason why we are having this discussion).
If you want something similar to gcd, but that returns 0 for 0 and 0, then
it is the 'product of all common prime factors'; where 1 has the (non-minimal)
prime factorisation [1, 1, ...], 0 has the (non-minimal) prime factorisation
[0, 1, 2, ...], and 1 is included at least once in the (non-minimal) prime
factorisation of any natural number. If you want a parallel to the divides
relation where 0 and 0 are related: 0 is a factor of 0. A prime number
is a number that has no integer *between* 1 and itself as factors. People
often say "except" instead of "between", but that does not work for 0, nor
for the non-minimal prime factorisations that people seem to be interested
in, given the interest in having gcd 0 0 = 0 (which isn't the gc*d*!). Again,
the context is often strictly positive integers, and 'between' and 'except'
are then equivalent. For no apparent reason 1 is usually also excepted, but
that does not work for the prime factorisation of 1, nor for finding the
product of all common prime factors of 1 and another natural number... For
integers, -1 is also a prime number, and for imaginary integers, i is also
a prime number... I'm sure somebody can give a nice definition of a partial
order (not just preorder) lattice with 1 as the min value and 0 as the max
value (just larger than the infinities), if you absolutely want a lattice
with a gcd-*like* meet and lcm-*like* join for this (the, positive bias,
factor-of order).
I'd be happy to support such gcd-*like* (pcf?) and lcm-*like* functions, but
they aren't the gcd, nor the lcm (e.g. pcf (-1) (-1) = -1, not 1, etc.).
If you don't like adding these, then I suggest leaving things completely as
they are. Squeezing in two operations into one just because they have the
same results over the first quadrant is not something I find to be too good.
Odd one out?
/kent k
From dpt@math.harvard.edu Tue Dec 18 18:12:14 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Tue, 18 Dec 2001 13:12:14 -0500
Subject: gcd 0 0 = 0
In-Reply-To: <000701c187e5$80c7c1c0$b4e21081@chalmers95a69n>; from kentk@md.chalmers.se on Tue, Dec 18, 2001 at 06:00:30PM +0100
References: <15391.9595.758521.560553@reger.fmi.uni-passau.de> <000701c187e5$80c7c1c0$b4e21081@chalmers95a69n>
Message-ID: <20011218131214.A18214@noether.math.harvard.edu>
On Tue, Dec 18, 2001 at 06:00:30PM +0100, Kent Karlsson wrote:
> Why? If EVERY natural number is to have a prime factorisation, then BOTH
> 0 AND 1 have to be promoted to prime numbers;
1 has a perfectly fine prime factorization. It is the product of 0 primes,
the null product. (A null product is defined, for very good reasons, to
be 1, just like a null sum is defined to be 0.)
I could see defences of calling 0 a prime, although it is not standard
mathematical practice. The ideal generated by 0 is a prime ideal,
for one thing. 0 would still not have a unique prime factorization,
however. (But Haskell should not unilaterally decide to violate standard
mathematical terminology!)
> ... But
> there is a fundamental reason to say that 0 can never be a divisor (i.e. 0|0
> is false; x|y is true iff x is a *non-zero* factor of y; the 'non-zero' part
> is often left implicit (e.g. one is only talking about strictly positive
> integers), which is part of the reason why we are having this discussion).
What fundamental reason do you have in mind? Why do you use this definition
of divisibility? (I'm curious; other mathematicians give the same
definition, and I can't see why.)
This thread made me curious, so I did a little library research. I was
surprised to discover that mathematicians discover on this, the domain
of definition of "gcd a b":
Domain References
------ ----------
a /= 0, b /= 0 Lang, "Algebra, 3rd Edition"
Hasse, "Number Theory"
a, b not both 0 Koblitz, "A Course on Number Theory and Cryptography"
all a, b allowed MacLane and Birkhoff, "Algebra, 2nd Edition"
Koch, "Number Theory"
At least the books by Lang and MacLane-Birkhoff are standard references.
Note that the definitions all agree when they are defined (with gcd 0 0 = 0).
As I said, I was surprised; to me, the definiton with all a and b is the
more natural one. I still recommend using the full domain (especially since
exceptions are awkward to deal with in Haskell), but I'm not as certain.
Best,
Dylan Thurston
From ack@nethere.com Tue Dec 18 23:54:13 2001
From: ack@nethere.com (Michael Ackerman)
Date: Tue, 18 Dec 2001 15:54:13 -0800
Subject: gcd 0 0 = 0
References: <15391.9595.758521.560553@reger.fmi.uni-passau.de> <000701c187e5$80c7c1c0$b4e21081@chalmers95a69n> <20011218131214.A18214@noether.math.harvard.edu>
Message-ID: <3C1FD725.FFC84D92@nethere.com>
The general meaning of `having a prime factorization' is that every
non-zero element is uniquely a product of a unit and a product of
primes. The algebraic structures where unique factorizations live are
`unique factorization domains' (UFDs) of which a central class is formed
by the ring of polynomials over a field. Here the non-zero elements of
the field are the units; no one has ever suggested calling them primes!
In a general UFD one can only speak of _a_ gcd of two elements x and y,
meaning an element d such that one has (x, y) = (d), an equality of
ideals. In some special cases, there is a natural choice for d (e.g., in
the integers, the non-negative d; in the ring of polynomials over a
field, the monic d (having leading coeff. 1)). In some UFDs there is no
canonical choice (e.g. in the Gaussian integers, a + ib for a, b integers).
gcd(0, 0) = 0.
Cheers,
Michael Ackerman
Dylan Thurston wrote:
>
> On Tue, Dec 18, 2001 at 06:00:30PM +0100, Kent Karlsson wrote:
> > Why? If EVERY natural number is to have a prime factorisation, then BOTH
> > 0 AND 1 have to be promoted to prime numbers;
>
> 1 has a perfectly fine prime factorization. It is the product of 0 primes,
> the null product. (A null product is defined, for very good reasons, to
> be 1, just like a null sum is defined to be 0.)
>
> I could see defences of calling 0 a prime, although it is not standard
> mathematical practice. The ideal generated by 0 is a prime ideal,
> for one thing. 0 would still not have a unique prime factorization,
> however. (But Haskell should not unilaterally decide to violate standard
> mathematical terminology!)
>
> > ... But
> > there is a fundamental reason to say that 0 can never be a divisor (i.e. 0|0
> > is false; x|y is true iff x is a *non-zero* factor of y; the 'non-zero' part
> > is often left implicit (e.g. one is only talking about strictly positive
> > integers), which is part of the reason why we are having this discussion).
>
> What fundamental reason do you have in mind? Why do you use this definition
> of divisibility? (I'm curious; other mathematicians give the same
> definition, and I can't see why.)
>
> This thread made me curious, so I did a little library research. I was
> surprised to discover that mathematicians discover on this, the domain
> of definition of "gcd a b":
>
> Domain References
> ------ ----------
> a /= 0, b /= 0 Lang, "Algebra, 3rd Edition"
> Hasse, "Number Theory"
>
> a, b not both 0 Koblitz, "A Course on Number Theory and Cryptography"
>
> all a, b allowed MacLane and Birkhoff, "Algebra, 2nd Edition"
> Koch, "Number Theory"
>
> At least the books by Lang and MacLane-Birkhoff are standard references.
> Note that the definitions all agree when they are defined (with gcd 0 0 = 0).
>
> As I said, I was surprised; to me, the definiton with all a and b is the
> more natural one. I still recommend using the full domain (especially since
> exceptions are awkward to deal with in Haskell), but I'm not as certain.
>
> Best,
> Dylan Thurston
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From Jan de Wit" <000701c187e5$80c7c1c0$b4e21081@chalmers95a69n> <20011218131214.A18214@noether.math.harvard.edu> <3C1FD725.FFC84D92@nethere.com>
Message-ID: <003601c18822$2258e000$2fe5fea9@yatima>
Why not define gcd a b as the largest (in 'normal' order) integer d such
that the set of sums of
multiples of a and b {na+mb | n <- Z, m <- Z} is equal to the set of
multiples of d
{nd | n <- Z}? Easy to understand, no talk of division, lattices, rings,
ideals etcetera, and it covers the cases with 0.
Cheers, Jan de Wit
From ack@nethere.com Wed Dec 19 00:26:46 2001
From: ack@nethere.com (Michael Ackerman)
Date: Tue, 18 Dec 2001 16:26:46 -0800
Subject: gcd oops
Message-ID: <3C1FDEC6.54484152@nethere.com>
Sorry for an error in my previous message. The definition there of a gcd
works only in a prinicpal ideal domain (which covers all the rings
mentioned in the examples). According to Bourbaki, chapter on ordered
groups, the gcd of two non-zero elements of a UFD A is well-defined as
an element of (A-{0})/units, a quotient monoid. So in this context
gcd(0, _) is undefined. But Bourbaki adds that this concept is
`sometimes' extended to the gcd of a finite family (x_i) of elements
some of which may be zero by taking the gcd to be an element d such that
for all z, z divides d iff z divides each x_i.
Cheers,
Michael Ackerman
From ashley@semantic.org Wed Dec 19 06:24:24 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 18 Dec 2001 22:24:24 -0800
Subject: ANN (bis): Release 0.1 of Haskell/Java VM Bridge
Message-ID: <200112190624.WAA02738@mail4.halcyon.com>
OK, the SourceForge file release system bug has been fixed, so I put the
release files up there. Please download from there rather than from
semantic.org.
Revised, expanded announcement...
-------
The first release, 0.1, of Haskell/Java VM Bridge is now available.
Haskell/Java VM Bridge allows Haskell programs access to the Java Virtual
Machine. Features include:
* Calling of Java methods, access to fields, array-handling;
* Integration of garbage collectors;
* Reconciliation of exception models;
* Reconciliation of thread models, including 'synchronized'
monitor support and the ability to fork Haskell actions as
Java threads;
* Strong typing for Java classes and method argument lists
(as tuples), and use of Haskell lists as arrays;
* Creation of Java classes 'on the fly' (using DefineClass and
the Java Class File Format) that can have Haskell callback
methods;
* Lifted monads which do all the necessary JNI class and
method/field ID preloading and 'JNIEnv'-pointer variable
handling for you -- these can be automatically generated via
a tool (MakeJVMModule);
* Layered design includes lower-level IO-based interface;
* Automatic generation of modules for Java API classes;
* All relevant imports, flags and libraries etc. handled by
a single GHC package 'javavm';
* No 'unsafe' Haskell calls or pure function FFI anywhere.
This release should be 'beta' quality, but has undergone little testing.
You will need:
* An x86 machine running some form of Unix;
* GHC 5.02 or later;
* The appropriate JVM, installed in the appropriate place:
- IBM JDK/JRE 1.3 for x86, installed in /usr/lib/ibm-java/IBMJava2-13/
- Blackdown Port of Sun's JRE 1.3/Sun JDK 1.3 for x86, installed in
/usr/lib/j2sdk1.3/ and /usr/lib/j2re1.3/
No documentation is currently available, sorry. Two examples have been
included: a trivial "hello world" program, and a program that shows a
Java Frame containing an instance of a Haskell-defined subclass of Canvas
that has a Haskell 'paint' method that draws an oval. You should be able
to figure out most of it from that... and of course the source is
available from SourceForge CVS.
Be sure to download the correct .tar.gz file for your Java VM. Simple
installation instructions are included in the file.
Haskell/JVM Bridge and source code is licensed under the GNU Lesser GPL.
Future plans:
* documentation
* port to Cygwin
* port to Darwin/OS X (waiting on GHC)
* use of Java 1.4 API (waiting on Sun, though use of beta
versions is possible)
--
Ashley Yakeley, Seattle WA
From mechvel@math.botik.ru Wed Dec 19 08:12:34 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Wed, 19 Dec 2001 11:12:34 +0300
Subject: x^y. Reply
Message-ID:
Toralf Wittner writes
> [..]
> power x y
> [..]
> | y > 0 = x * power x (y-1)
> | y < 0 = 1 / fromInteger x * power x (y+1)
>
> One recognizes that the function returns either an integer value
> if y > 0 or a float value if y < 0. Therefore I can't write a
> signature like
> pow :: Integer -> Integer -> Integer nor can I do
> pow :: Integer -> Integer -> Double.
>
> [..]
> How then would I write this function in Haskell (concerning types)?
The type Rational fits the case n < 0 too, and it includes Integer.
But if you still need Integer | Double, you can, for example,
introduce a new type of a disjoint union of the above two, and then,
to compute like this:
pow (Intg 2) 2 --> Intg 4
pow (Intg 2) (-2) --> D 0.25
pow (D 2.0) (-2) --> D 0.25
This is achieved by
data PowerDom = Intg Integer | D Double deriving(Eq,Show)
pow :: PowerDom -> Integer -> PowerDom
pow x n = p x n
where
p (Intg m) n = if n > 0 then Intg $ powerInteger m n
else D $ powerDouble (fromInteger m :: Double) n
p(D d) n = D $ powerDouble d n
powerInteger m n = m^n :: Integer
powerDouble :: Double -> Integer -> Double
powerDouble d n = ... usual way for float
- something like this.
-----------------
Serge Mechveliani
mechvel@botik.ru
From till@doerges.net Wed Dec 19 09:13:45 2001
From: till@doerges.net (Till Doerges)
Date: Wed, 19 Dec 2001 10:13:45 +0100
Subject: x^y
In-Reply-To: <0GOJ006RUT6O12@neptun.rz.uni-duesseldorf.de>; from wittner@uni-duesseldorf.de on Tue, Dec 18, 2001 at 05:43:33PM +0100
References: <0GOJ006RUT6O12@neptun.rz.uni-duesseldorf.de>
Message-ID: <20011219101345.B2662@atlan.wanderer.none>
On Tue, Dec 18, 2001 at 05:43:33PM +0100, Toralf Wittner wrote:
> power x y
> | x == 0 = 0
> | y == 0 = 1
> | y > 0 = x * power x (y-1)
> | y < 0 = 1 / fromInteger x * power x (y+1)
Why did you put 'fromInteger' into the last line? If you get rid of
that, this will make your 'power' be accepted by the haskell-compiler
or -interpreter.
> One recognizes that the function returns either an integer value if y > 0 or
> a float value if y < 0. Therefore I can't write a signature like
> pow :: Integer -> Integer -> Integer nor can I do
> pow :: Integer -> Integer -> Double.
No, you can't, and that's one of the reasons why type-classes where
introduced. You don't have to state the type of x and y
explicitely. Rather you can specify certain 'properties', i.e. y must
be a number, there must be an ordering relation and x must allow for the
representation of fractions.
--- snip ---
Main> :t power
power :: (Num a, Ord a, Fractional b) => b -> a -> b
Main> power 2 3
8.0
(113 reductions, 147 cells)
Main> power 2 (-1)
0.5
(70 reductions, 87 cells)
Main>
--- snap ---
> How then would I write this function in Haskell (concerning types)?
See above (the type signature was kindly provided by hugs ;-).
HTH -- Till
--
e-mail: reverse(net dot doerges at till) | ENCRYPTED |
pgp/gpg: keys via keyserver or my homepage | MAIL IS |
www: http://www.doerges.net | WELCOME! |
From GACOGNE Louis equipe Bernadette Bouchon-Meunier Wed Dec 19 09:33:39 2001
From: GACOGNE Louis equipe Bernadette Bouchon-Meunier (GACOGNE Louis equipe Bernadette Bouchon-Meunier)
Date: Wed, 19 Dec 2001 10:33:39 +0100 (MET)
Subject: random
Message-ID: <200112190933.KAA05235@atlantide.muses>
Is there a random function in Hugs 98 on macintosh. I found something about
random in the library but I was not able to find a random function running.
Louis Gacogne
IIE-CNAM allee Jean Rostand 91025 Evry (tel 01 69 36 73 41)
Laboratoire d'Informatique de l'Universite Paris VI
Place Jussieu 75252 Paris 5 (tel 01 44 27 88 07)
http://www.iie.cnam.fr/~gacogne/
From kentk@md.chalmers.se Wed Dec 19 13:04:25 2001
From: kentk@md.chalmers.se (Kent Karlsson)
Date: Wed, 19 Dec 2001 14:04:25 +0100
Subject: gcd 0 0 = 0
In-Reply-To: <003601c18822$2258e000$2fe5fea9@yatima>
Message-ID: <000001c1888d$b01113c0$b4e21081@chalmers95a69n>
Let me try again:
greatest -> maximum/supremum of a set of integers (plain everyday order)
common -> intersection (plain everyday intersection of sets)
divisor (of an integer value v) ->
an integer value m, such that v/m is defined and, if so, is an integer
factor (of an integer value v) ->
an integer value m, such that there is an integer value n such that m*n=v
So (mock Haskell syntax; set expression really):
greatest_common_divisor a b = max (intersection {all divisors of a} {all divisors of b})
What is the supremum (result of max in the expression above) if a and b are both 0?
(You're allowed to use values not prescribed by Haskell to exist. ;-)
(You can replace "divisors" by "factors" in that expression and still get the same result.)
I may agree that an operation *similar* to gcd, where <0,0> as argument
returns 0 is useful (maybe even more useful than gcd!). But that operation
is still not the gcd (and might even return other results thaN gcd also for
other value pairs than <0,0>; in particlar negatives; depending on what is
found most useful).
If you want to replace gcd by some other, similar, operation, please go ahead.
But call it something else, because it is something else. If you want to generalise
that to polynomials or Gaussian integers (or at least imaginary integers, as opposed
to complex integers), fine (though not for the current standard Haskell library).
(Micheal, I am interested in the Guassian integer variety of this. If you like,
you can expand on what you said in an off-list message, or give me a reference.)
Kind (and somewhat fundamentalist) regards
/kent k
> -----Original Message-----
> From: haskell-admin@haskell.org [mailto:haskell-admin@haskell.org]On
> Behalf Of Jan de Wit
> Sent: den 19 december 2001 01:15
> To: haskell@haskell.org
> Subject: Re: gcd 0 0 = 0
>
>
> Why not define gcd a b as the largest (in 'normal' order)
> integer d such
> that the set of sums of
> multiples of a and b {na+mb | n <- Z, m <- Z} is equal to the set of
> multiples of d
> {nd | n <- Z}? Easy to understand, no talk of division,
> lattices, rings,
> ideals etcetera, and it covers the cases with 0.
>
> Cheers, Jan de Wit
>
>
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
From mechvel@math.botik.ru Wed Dec 19 13:25:17 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Wed, 19 Dec 2001 16:25:17 +0300
Subject: FiniteMap for standard
Message-ID:
Long ago I suggested to include FiniteMap into Haskell-98
standard library.
Is it still late to do this, or maybe, the situation has changed?
-----------------
Serge Mechveliani
mechvel@botik.ru
From icalp2002@lcc.uma.es Wed Dec 19 13:39:55 2001
From: icalp2002@lcc.uma.es (icalp2002@lcc.uma.es)
Date: Wed, 19 Dec 2001 14:39:55 +0100
Subject: ICALP2002 call for papers
Message-ID:
We apologize for possible multiple postings.
In http://www.lcc.uma.es/icalp2002 you can find a pdf
version of this call for paper.
+++++++++++++++++++++++++++++++++++++
Last information:
Second version of the WEB pages at http://www.lcc.uma.es/icalp2002
Workshops confirmed:
Computability and Complexity in Analysis (CCA 2002)
Algorithmic Methods and Models for Optimization of Railways ATMOS 2002
7 th International Workshop on Formal Methods for Industrial Critical Systems
Foundations of Wide Area Network Computing
Invited speakers confirmed:
Heikki Mannila
Manuel Hermenegildo
+++++++++++++++++++++++++++++++++++++
Call for Papers
ICALP 2002
29th International Colloquium on
Automata, Languages and Programming
July 8-13, 2002, M醠aga, Spain
Camera Ready: April 16, 2002
The 29th annual meeting of the European Association of Theoretical
Computer Science will be held in M醠aga, Spain, July 8-13, 2002 (at the
E.T.S. Ingenier韆 Inform醫ica).
As with the Journal Theoretical Computer Science (TCS), the scientific
program of the Colloquium will be split into two parts: Track A of the
meeting will correspond to Algorithms, Automata, Complexity and Games,
while Track B to Logic, Semantics and Theory of Programming.
SUBMISIONS: Authors are invited to submit extended abstract of their
papers, presenting original contributions to the theory of computer
science. Detailed instructions for paper submissions will be found on
the conference webpage (http://www.lcc.uma.es/icalp2002) and in future
calls for papers. Submissions should consist of: a cover page, with the
author's full name, address, fax number, e-mail address, a 100-word
abstract, keywords and to which track (A or B) the paper is being
submitted and an extended abstract describing original research. At
least one author of an accepted paper should be available to present it
at the conference. Simultaneous submission to other conferences with
published proceedings is not allowed.
Further information (dates and instructions for submissions, workshops,
registration, location and travel) will be provided in future
announcements.
ORGANIZING COMMITEE: Buenaventura Clares (University of Granada),
Ricardo Conejo (University of M醠aga), Inmaculada Fortes (University of
M醠aga), Llanos Mora (University of M醠aga), Rafael Morales (co-Chair,
University of M醠aga), Marlon Nu馿z (University of M醠aga), Jos� Luis
P閞ez de la Cruz (University of M醠aga), Gonzalo Ramos (University of
M醠aga), Francisco Triguero (co-Chair, University of M醠aga), Jos� Luis
Trivi駉 (University of M醠aga).
IMPORTANT DATES:
Workshops proposal: November 8, 2001
Submissions: January 14, 2002
Notification: March 20, 2002
CONFERENCE CO-CHAIRS
Prof. Francisco Triguero
Prof. Rafael Morales
Universidad de M醠aga
E.T.S. Ingenier韆 Inform醫ica
Dept. Lenguajes y Ciencias de la Computaci髇
Bulevar Louis Pasteur, 35
29071 - M醠aga (SPAIN)
e-mail: icalp2002@informatica.uma.es
PROGRAM COMMITEE
Track A
Ricardo Baeza-Yates (U. Chile)
Volker Diekert (U. Stuttgart)
Paolo Ferragina (U. Pisa)
Catherine Greenhill (U. Melbourne)
Torben Hagerup (U. Frankfurt)
Johan H錽tad (KTH, Stockholm)
Gabriel Istrate (Los Alamos)
Claire Kenyon (U. Paris XI)
Der-Tsai Lee (Acad. Sinica, Taipei)
Heikki Mannila (Nokia, Helsinki)
Elvira Mayordomo (U. Zaragoza)
Helmut Prodinger (U. Witwatersrand, South Africa)
Jan van Leeuwen(U. Utrecht)
Paul Vit醤yi (CWI, Amsterdam)
Peter Widmayer (ETH Z黵ich) (Chair)
Gerhard Woeginger (T.U. Graz)
Christos Zaroliagis (U. Patras)
Track B
Mart韓 Abadi (Bell Labs Research, Lucent)
Roberto Amadio (U. Provence)
Gilles Barthe (INRIA-SophiaAntipolis)
Manfred Droste (University of Technology Dresden)
C閐ric Fournet (Microsoft Cambridge)
Matthew Hennessy (U. Sussex) (Chair)
Furio Honsell (U. Udine)
Peter O'Hearn (Queen Mary & W. C. London)
Fernando Orejas (U.P.Catalunya)
Ernesto Pimentel (U. M醠aga)
David Sands (Chalmers University of Technology and G鰐eborg University)
Dave Schmidt (U. Kansas)
Gheorghe Stefanescu (U. Bucharest)
Vasco Vasconcelos (U. Lisbon)
Thomas Wilke (U. Kiel)
+++++++++++++++++++++++++++++++++++++++++++
Malaga University uses Christmas holidays for backup and maintenance of his network.
If you have problem to arrive to ICALP 2002 main page, please retry again later.
If you get to the page http://www.lcc.uma.es but not to the page http://www.lcc.uma.es/icalp2002 contact with us:
conejo@lcc.uma.es
morales@lcc.uma.es
From simonpj@microsoft.com Wed Dec 19 13:43:46 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 19 Dec 2001 05:43:46 -0800
Subject: FiniteMap for standard
Message-ID: <1113DDB24D4A2841951BFDF86665EE1906665C@RED-MSG-10.redmond.corp.microsoft.com>
Much, much too late, however desirable.
| -----Original Message-----
| From: S.D.Mechveliani [mailto:mechvel@math.botik.ru]=20
| Sent: 19 December 2001 13:25
| To: haskell@haskell.org
| Subject: FiniteMap for standard
|=20
|=20
| Long ago I suggested to include FiniteMap into Haskell-98=20
| standard library.
| Is it still late to do this, or maybe, the situation has changed?=20
|=20
| -----------------
| Serge Mechveliani
| mechvel@botik.ru
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From wittner@uni-duesseldorf.de Wed Dec 19 14:11:06 2001
From: wittner@uni-duesseldorf.de (Toralf Wittner)
Date: Wed, 19 Dec 2001 15:11:06 +0100
Subject: x^y. Reply
In-Reply-To:
References:
Message-ID: <0GOL00IC6GSOOO@neptun.rz.uni-duesseldorf.de>
On Wednesday, 19. December 2001 09:12, S.D.Mechveliani wrote:
[...]
> But if you still need Integer | Double, you can, for example,
> introduce a new type of a disjoint union of the above two, and then,
> to compute like this:
> pow (Intg 2) 2 --> Intg 4
> pow (Intg 2) (-2) --> D 0.25
> pow (D 2.0) (-2) --> D 0.25
> This is achieved by
>
> data PowerDom = Intg Integer | D Double deriving(Eq,Show)
>
> pow :: PowerDom -> Integer -> PowerDom
> pow x n = p x n
> where
> p (Intg m) n = if n > 0 then Intg $ powerInteger m n
> else D $ powerDouble (fromInteger m :: Double) n
> p(D d) n = D $ powerDouble d n
>
> powerInteger m n = m^n :: Integer
>
> powerDouble :: Double -> Integer -> Double
> powerDouble d n = ... usual way for float
>
> - something like this.
This seems to be what I want. I tried it this way:
module Main where
import System
main = do
[a1, a2] <- getArgs
let x = read a1
let y = read a2 in
putStrLn (show x ++ " ^ " ++ show y ++ " = " ++ show (pow x y))
data PowerNum = INT Integer | DBL Double deriving (Eq, Show, Read)
pow :: PowerNum -> Integer -> PowerNum
pow x y = z x y where
z (INT x) y = if y > 0 then
INT $ powInteger x y
else
DBL $ powDouble (fromInteger x) y
z (DBL x) y = DBL $ powDouble x y
powInteger x y
| x == 0 = 0
| y == 0 = 1
| y > 0 = x * powInteger x (y - 1)
powDouble x y
| x == 0 = 0
| y == 0 = 1
| y > 0 = 1 / x * powDouble x (y - 1)
While GHC compiled this code I get a runtime error:
Fail: Prelude.read: no parse
and HUGS reports:
ERROR: Illegal Haskell 98 class constraint in inferred type
*** Expression : pow 1 2
*** Type : Num PowerNum => PowerNum
Could you tell me what I did wrong? Thank you very much!
Toralf
>
>
> -----------------
> Serge Mechveliani
> mechvel@botik.ru
From wittner@uni-duesseldorf.de Wed Dec 19 15:30:41 2001
From: wittner@uni-duesseldorf.de (Toralf Wittner)
Date: Wed, 19 Dec 2001 16:30:41 +0100
Subject: x^y. Reply
In-Reply-To:
References:
Message-ID: <0GOL005G2KHDMK@neptun.rz.uni-duesseldorf.de>
Ahh - sorry, too much cut and paste ;-)
data PowerNum = INT Integer | DBL Double deriving (Eq, Show, Read)
pow :: PowerNum -> Integer -> PowerNum
pow x y = z x y where
z (INT x) y = if y > 0 then
INT $ powInteger x y
else if y == 0 then
INT $ 1
else
DBL $ powDouble (fromInteger x) y
z (DBL x) y = DBL $ powDouble x y
powInteger x y
| x == 0 = 0
| y == 0 = 1
| y > 0 = x * powInteger x (y - 1)
powDouble x y
| x == 0 = 0
| y == 0 = 1
| y < 0 = 1 / x * powDouble x (y + 1)
Now it basically works. However wouldn't it have been easier to write
something like this:
module Main where
import System
main = do
[a1, a2] <- getArgs
let x = read a1
let y = read a2 in
if y >= 0 then
putStrLn (show x ++ " ^ " ++ show y ++ " = " ++ show (powPos x y))
else
putStrLn (show x ++ " ^ " ++ show y ++ " = " ++ show (powNeg x y))
powPos :: Integer -> Integer -> Integer
powPos x y
| x == 0 = 0
| y == 0 = 1
| y > 0 = x * powPos x (y - 1)
powNeg :: Integer -> Integer -> Double
powNeg x y
| x == 0 = 0
| y == 0 = 1
| y < 0 = 1 / fromInteger x * powNeg x (y + 1)
Initially I wanted something as terse as the Python version, now I either
have to write two functions or I need to define a type. Is there not an
easier way to come as close as possible to the Python version?
Thanks anyway - learnt a lot!
Toralf
From hdaume@ISI.EDU Thu Dec 20 00:18:35 2001
From: hdaume@ISI.EDU (Hal Daume III)
Date: Wed, 19 Dec 2001 16:18:35 -0800 (PST)
Subject: global counters
Message-ID:
Please, no tirade about banishing unsafePerformIO.
I've seen this done before I just don't remember how. I want to use a
state monad to count things, but don't want to monadify the thing I'm
using the counter in.
basically, i want a function getVar :: () -> String which returns a new
string every time. i tried this:
> curVarId = newSTRef (0 :: Integer)
>
> {-# NO-INLINE newVar -}
>
> newVar = \_ -> ('\0' : show x)
> where y = unsafePerformIO (stToIO curVarId)
> x = unsafePerformIO $ stToIO $
> do x <- readSTRef y
> writeSTRef y (x + 1)
> return x
and in ghci it works wonderfully, but when i actually compile, all i get
is "\NUL0".
what's the proper way to write this?
thanks
- hal
From mechvel@math.botik.ru Thu Dec 20 08:00:17 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Thu, 20 Dec 2001 11:00:17 +0300
Subject: x^y. Reply
Message-ID:
Toralf Wittner
writes
> [..]
> data PowerNum = INT Integer | DBL Double deriving (Eq, Show, Read)
> [..]
> Now it basically works. However wouldn't it have been easier to write
> something like this:
>
> powPos :: Integer -> Integer -> Integer
> [..]
> powNeg :: Integer -> Integer -> Double
> [..]
> | y < 0 = 1 / fromInteger x * powNeg x (y + 1)
>
> Initially I wanted something as terse as the Python version, now I either
> have to write two functions or I need to define a type. Is there not an
> easier way to come as close as possible to the Python version?
>
> Thanks anyway - learnt a lot!
For this particular task, the most natural solution is, probably,
pow :: Fractional a => a -> Integer -> a
pow a n =
if n > 0 then a^n else (1/a)^(- n)
(^) is of standard, only pow adds the facility of negative n.
Then, you need each time to convert the argument to appropriate
type of Fractional:
pow (fromInteger 2 :: Ratio.Rational) 2 --> 4 % 1
pow (fromInteger 2 :: Ratio.Rational) (-2) --> 1 % 4
pow (2 :: Double) (-2) --> 0.25
pow (2 :: Integer) (-2) -->
... No instance for (Fractional Integer)
If you replace standard (and not lucky) Fractional with some
class Foo (with multiplication mul and division div),
make Integer an instance of Foo
(where div may fail for some data),
and program
pow :: Foo a => a -> Integer -> a
via mul, div,
then it would work like this:
pow (2 :: Integer) 2 --> 4
pow (2 :: Integer) (-2) --> "Error: cannot invert 2 :: Integer"
pow (2 :: Rational) (-2) --> 1%4
Another way is to try to straggle with overlapping instances by
defining something like this:
class Pow a b where pow :: a -> Integer -> b
instance Num a => Pow a a where pow = (^)
Fractional ?
instance Num a => Pow Integer a where pow = ?
If this succeeds, there will be also no need in new type
constructors.
-----------------
Serge Mechveliani
mechvel@botik.ru
From Jan de Wit"
Message-ID: <001401c18936$92ba3280$2fe5fea9@yatima>
> basically, i want a function getVar :: () -> String which returns a new
> string every time. i tried this:
>
> > curVarId = newSTRef (0 :: Integer)
> >
> > {-# NO-INLINE newVar -}
> >
> > newVar = \_ -> ('\0' : show x)
> > where y = unsafePerformIO (stToIO curVarId)
> > x = unsafePerformIO $ stToIO $
> > do x <- readSTRef y
> > writeSTRef y (x + 1)
> > return x
>
> and in ghci it works wonderfully, but when i actually compile, all i get
> is "\NUL0".
>
> what's the proper way to write this?
I think (haven't tested this one) you should write (modulo layout):
| curVarIdRef :: IORef Integer
| curVarIdRef = unsafePerformIO $ newIORef (0 :: Integer)
|
| {-# NO-INLINE newVar -}
|
| newVar :: () -> String
| newVar = \_ -> ('\0' : show x) where
| x = unsafePerformIO $
| do x <- readIORef curVarIdRef
| writeIORef curVarIdRef (x + 1)
| return x
Because in your original version, curVarId allocates a new reference to 0
every time newVar is called.
Hope this works, Jan de Wit
From johanj@cs.uu.nl Thu Dec 20 08:07:27 2001
From: johanj@cs.uu.nl (Johan Jeuring)
Date: Thu, 20 Dec 2001 09:07:27 +0100
Subject: Working Conference on Generic Programming, 2nd call for papers
Message-ID: <20011220080952.E517D4538@mail.cs.uu.nl>
WCGP '02
IFIP WG2.1 Working Conference on
GENERIC PROGRAMMING
http://www.generic-programming.nl/wcgp/cfp.html
Organised in conjunction with MPC'02
July 8 - July 13, 2002
Dagstuhl, Germany
CALL FOR PAPERS
Generic programming is about making programs more
adaptable by making them more general. Generic
programs often embody non-traditional kinds of
polymorphism; ordinary programs are obtained from
them by suitably instantiating their parameters.
In contrast with normal programs, the parameters
of a generic programs are often quite rich in
structure. For example they may be other programs,
types or type constructors, class hierarchies, or
even programming paradigms.
Generic programming techniques have always been of
interest, both to practitioners and to theoreticians,
but only recently have generic programming
techniques become a specific focus of research in
the functional and object-oriented programming
language communities. This working conference will
bring together leading researchers in generic
programming from around the world, and feature
papers capturing the state of the art in this
important emerging area.
We welcome contributions on all aspects, theoretical
as well as practical, of generic programming,
aspect-oriented programming, polytypic programming,
adaptive object-oriented programming, generic
components, and so on.
SUBMISSION
Full papers should be submitted in Postscript or pdf
format by e-mail to reach Jeremy.Gibbons@comlab.ox.ac.uk
by February 16, 2002. The details of the submission
procedure can be found at
http://www.generic-programming.nl/wcgp/submit.html
Although there is no page limit, submissions should
strive for brevity and clarity.
IMPORTANT DATES
Submission February 16, 2002
Notification April 12, 2002
Final version due May 24, 2002
PROGRAMME COMMITTEE
Matt Austern
Eerke Boiten
Ulrich Eisenecker
Jeremy Gibbons (co-chair)
Ralf Hinze
Johan Jeuring (co-chair)
Gary Leavens
Karl Lieberherr
Lambert Meertens
Eugenio Moggi
Bernhard Moeller
Oege de Moor
David Musser
Martin Odersky
Ross Paterson
Simon Peyton Jones
Colin Runciman
Doaitse Swierstra
Stephanie Weirich
LOCAL ORGANISATION
Jeremy Gibbons
Johan Jeuring
Bernhard Moeller
CORRESPONDENCE
Jeremy Gibbons (Jeremy.Gibbons@comlab.ox.ac.uk)
Johan Jeuring (johan@jeuring.net)
From bernhard@cogs.susx.ac.uk Thu Dec 20 15:05:56 2001
From: bernhard@cogs.susx.ac.uk (Bernhard Reus)
Date: Thu, 20 Dec 2001 15:05:56 +0000
Subject: installation problems with graphics-2.0.4
Message-ID: <3C21FE54.2EBCC4B7@cogs.susx.ac.uk>
The graphics lib of the new December release does not
compile with the shipped makefile.
The makefile does not do anything at all???
Maybe there is a problem with wildcard extensions?
To be honest, I have no clue. I am using a Sparc5/Solaris
machine.
Any help appreciated.
Thanks in advance,
Bernhard
From igloo@earth.li Thu Dec 20 21:49:03 2001
From: igloo@earth.li (Ian Lynagh)
Date: Thu, 20 Dec 2001 21:49:03 +0000
Subject: unsafePerformIO to give warnings
Message-ID: <20011220214903.A2358@stu163.keble.ox.ac.uk>
Hi all
If I want to give warnings when doing something and I don't care too
much about the order they appear in, can I use this?
foo x = if success x then Just x
else warn "Working out x went wrong" Nothing
warn :: String -> a -> a
warn s x = unsafePerformIO (hPutStrLn stderr s) `seq` x
The hslibs docs say
If the I/O computation wrapped in unsafePerformIO performs side
effects, then the relative order in which those side effects take
place (relative to the main I/O trunk, or other calls to
unsafePerformIO) is indeterminate.
but it's not entirely clear on whether or not I could end up with 2
warnings interspersed?
And is it guaranteed that the warnings will be printed at some point?
hugs and ghci only seem to print the first warning, but ISTR similar
problems happen with threads and got the impression that they were in
the wrong.
Thanks
Ian
From simonpj@microsoft.com Fri Dec 21 09:35:37 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 21 Dec 2001 01:35:37 -0800
Subject: "The signature contexts in a mutually recursive group should all be identical"; why?
Message-ID: <1113DDB24D4A2841951BFDF86665EE19374689@RED-MSG-10.redmond.corp.microsoft.com>
[Note to the Haskell list. The question this thread is discussing
is whether the H98 rule that all the functions in a mutually=20
recursive group must have the same context, is a show stopper.]
| Oeer. Come to think of it, if f is getting the dictionary=20
| (in the real world
| example) from the context, rather than from the existential=20
| type, I fear it may be getting the wrong dictionary, and will=20
| crash badly when I try to run the code. =20
No I don't think that can happen. But I have thought of a test
case
data T =3D forall a. Eq a =3D> MkT a a T
| Nil
f :: T -> Bool
f Nil =3D True
f (MkT x y t) =3D g x y t
g :: Eq b =3D> b -> b -> T -> Bool
g x y t =3D (x=3D=3Dy) && f t
Notice that
(a) f and g are mutually recursive
(b) They have different contexts in their type sig
(c) If they were made the same, f would get an
ambiguous type f :: Eq a =3D> T -> Bool
(d) Haskell's polymorphic recursion is essential here;
each call to g may be at a different type
So it looks to me that, in the presence of existentials, the H98
rule goes from being moot to being throughly awkward.=20
Mark's THIH paper shows that there's no real need for the rule,
because one can type-check the bindings without type sigs as
a group, and then the ones with type sigs one by one. =20
But what happens for pattern-bindings that bind more than
one variable. Must all those variables have the same context?
(I hope so.)
Needless to say, I'm not proposing any changes in H98! But
I thought the example would be of interest. Maybe it's well known,
but it wasn't to me.
Simon
From sk@cs.brown.edu Fri Dec 21 06:36:16 2001
From: sk@cs.brown.edu (Shriram Krishnamurthi)
Date: Fri, 21 Dec 2001 01:36:16 -0500 (EST)
Subject: ICFP (Functional Programming) 2002: Call for Papers
Message-ID: <200112210636.BAA10106@bosch.cs.brown.edu>
---------------------------------------------
* Calling all functional programmers! *
* ICFP'02 needs you! *
---------------------------------------------
ICFP 2002: International Conference on Functional Programming
Pittsburgh, 3--5 October 2002
CALL FOR PAPERS
http://icfp2002.cs.brown.edu/
Paper submission deadline: 21 March 2002
General Chair: Mitchell Wand, Northeastern University
Program Chair: Simon Peyton Jones, Microsoft Research
ICFP 2002 seeks original papers on the full spectrum of the art,
science, and practice of functional programming. The conference
invites submissions on all topics ranging from principles to practice,
from foundations to features, and from abstraction to application. The
scope covers all languages that encourage programming with functions,
including both purely applicative and imperative languages, as well as
languages that support objects and concurrency.
You can find the full call for papers at
http://icfp2002.cs.brown.edu/
Program Committee
Matthias Blume (Lucent)
Margaret Burnett (Oregon State University)
Manuel Chakravarty (University of New South Wales)
Matthew Flatt (University of Utah)
Haruo Hosoya (Kyoto University)
Uwe Nestmann (EPFL, Lausanne)
Chris Okasaki (United States Military Academy)
Norman Ramsey (Harvard University)
David Sands (Chalmers University)
Olin Shivers (Georgia Tech)
Stephanie Weirich (Cornell)
Joe Wells (Heriot Watt University)
From simonmar@microsoft.com Fri Dec 21 10:21:06 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 21 Dec 2001 10:21:06 -0000
Subject: unsafePerformIO to give warnings
Message-ID: <9584A4A864BD8548932F2F88EB30D1C607C0BAA4@TVP-MSG-01.europe.corp.microsoft.com>
> If I want to give warnings when doing something and I don't care too
> much about the order they appear in, can I use this?
>=20
> foo x =3D if success x then Just x
> else warn "Working out x went wrong" Nothing
>=20
> warn :: String -> a -> a
> warn s x =3D unsafePerformIO (hPutStrLn stderr s) `seq` x
This is what IOExts.trace is for, BTW.
> The hslibs docs say
>=20
> If the I/O computation wrapped in unsafePerformIO performs side
> effects, then the relative order in which those side effects take
> place (relative to the main I/O trunk, or other calls to
> unsafePerformIO) is indeterminate.
>=20
> but it's not entirely clear on whether or not I could end up with 2
> warnings interspersed?
It is possible to get warnings interspersed if you write something like
warn ("abc" ++ warn "foo" "def")
> And is it guaranteed that the warnings will be printed at some point?
All that is guaranteed is that if an expression 'warn a b' is evaluated
then 'a' will be evaluated to a String and then printed.
> hugs and ghci only seem to print the first warning, but ISTR similar
> problems happen with threads and got the impression that they were in
> the wrong.
Are you sure that laziness and/or optimisation aren't to blame for only
getting a single warning? Given that you say Hugs also produces the
same result, it sounds like a laziness issue.
Cheers,
Simon
From chak@cse.unsw.edu.au Fri Dec 21 10:17:54 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 21 Dec 2001 21:17:54 +1100
Subject: 2002 Haskell Workshop
Message-ID: <20011221211754E.chak@cse.unsw.edu.au>
[My apologies if you receive multiple copies of this message]
------------------------------
PROVISIONAL CALL FOR PAPERS
(Approval for PLI'02 pending)
------------------------------
2002 Haskell Workshop
Pittsburgh, PA, USA
(3rd, 7th, or 8th October 2002;
exact date to be announced)
==================================
The purpose of the Haskell Workshop is to discuss experience
with Haskell, and possible future developments for the
language. The scope of the workshop includes all aspects of
the design, semantics, theory, application, implementation,
and teaching of Haskell. Previous Haskell Workshops have
been held in La Jolla (1995), Amsterdam (1997), Paris
(1999), Montreal (2000), and Firenze (2001).
For detailed information and key dates please consult
http://www.cse.unsw.edu.au/~chak/hw2002/
From simonpj@microsoft.com Fri Dec 21 11:09:42 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 21 Dec 2001 03:09:42 -0800
Subject: Haskell 98 Christmas release
Message-ID: <1113DDB24D4A2841951BFDF86665EE1937468E@RED-MSG-10.redmond.corp.microsoft.com>
In my Sisyphian task of finishing the Haskell 98 Report, I thought
I would put out the current version before Xmas. =20
http://research.microsoft.com/~simonpj/haskell98-revised
It's substantially the same as the one I put out at the start=20
of December, with three exceptions
1. The layout algorithm has changed (again). Simon M, Ian L and
I are now all fairly confident that it is right, but we have been proved
wrong before.
2. The "instance declaration wart" turned out to be closely connnected
to some (unspecified) scoping issues in export lists. So I have=20
nailed all that down. GHC and Hugs both now implement the new
rules.
3. The avalance of email about the True Meaning of gcd 0 0 cannot=20
have escaped your notice. I am too stupid to understand most of it,
but my ill-informed conclusion is:
a) there is a lot of support for gcd 0 0 =3D 0
b) but it is not universal support
The strong default for H98 is "no change", so I've left gcd 0 0 as an
error.
However I have added some examples.
Changes since the early-dec release are marked
[Late Dec 2001] in the Bugs List, so you can find them easily.
I don't think I know of any other loose ends. Happy reading.
Simon
From ross@soi.city.ac.uk Fri Dec 21 11:14:12 2001
From: ross@soi.city.ac.uk (Ross Paterson)
Date: Fri, 21 Dec 2001 11:14:12 +0000
Subject: "The signature contexts in a mutually recursive group should all be identical"; why?
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE19374689@RED-MSG-10.redmond.corp.microsoft.com>
References: <1113DDB24D4A2841951BFDF86665EE19374689@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <20011221111411.GA1143@soi.city.ac.uk>
On Fri, Dec 21, 2001 at 01:35:37AM -0800, Simon Peyton-Jones wrote:
> [Note to the Haskell list. The question this thread is discussing
> is whether the H98 rule that all the functions in a mutually
> recursive group must have the same context, is a show stopper.]
>
> [...]
>
> So it looks to me that, in the presence of existentials, the H98
> rule goes from being moot to being throughly awkward.
It's not moot -- it steers the following (admittedly artificial) example
into the monomorphism restriction:
foo :: Eq a => a -> Bool
foo x = x == x && bar
-- bar :: Bool
bar = foo 'a'
With the declaration, it fails the "identical context" rule (though
Hugs then accepts it in violation of H98).
The definition of "declaration group" could have been relaxed when
explicit type signatures were added: if a variable has one, then
bindings using the variable should depend on the type signature,
not the binding of the variable, so in the above example would
be analysed as three declaration groups:
(1) foo :: Eq a => a -> Bool
(2) bar = foo 'a' -- depends on (1)
(3) foo x = x == x && bar -- depends on (2)
As it is, some extra language was tacked on to exempt variables with
explicit signatures from the mutual type inference, as well as to
impose this restriction.
H98 glitch: the phrase "declaration group" is used in 4.4.2 with a
different meaning to that defined in 4.5.1. "sequence of declarations"?
From igloo@earth.li Fri Dec 21 12:25:31 2001
From: igloo@earth.li (Ian Lynagh)
Date: Fri, 21 Dec 2001 12:25:31 +0000
Subject: unsafePerformIO to give warnings
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C607C0BAA4@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Fri, Dec 21, 2001 at 10:21:06AM -0000
References: <9584A4A864BD8548932F2F88EB30D1C607C0BAA4@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20011221122531.A6180@stu163.keble.ox.ac.uk>
On Fri, Dec 21, 2001 at 10:21:06AM -0000, Simon Marlow wrote:
>
> > If I want to give warnings when doing something and I don't care too
> > much about the order they appear in, can I use this?
> >
> > foo x = if success x then Just x
> > else warn "Working out x went wrong" Nothing
> >
> > warn :: String -> a -> a
> > warn s x = unsafePerformIO (hPutStrLn stderr s) `seq` x
>
> This is what IOExts.trace is for, BTW.
Doh - I associate that with debugging and it never even occurred to me!
> > warnings interspersed?
>
> It is possible to get warnings interspersed if you write something like
>
> warn ("abc" ++ warn "foo" "def")
Ah, yes, OK, thanks.
> > hugs and ghci only seem to print the first warning, but ISTR similar
> > problems happen with threads and got the impression that they were in
> > the wrong.
>
> Are you sure that laziness and/or optimisation aren't to blame for only
> getting a single warning? Given that you say Hugs also produces the
> same result, it sounds like a laziness issue.
Sorry, I meant "hugs and ghci only seem to print the warning the first
time I run the program", e.g. with
module Main where
import IOExts
main :: IO()
main = trace "foo" (putStrLn "bar")
in hugs:
[...]
Type :? for help
Main> main
foobar
Main> main
bar
Main> main
bar
Main> main
bar
and in ghci:
Skipping Main ( q.lhs, ./q.o )
Main> main
foo
bar
Main> main
bar
Main> main
bar
Main> main
bar
Main>
Thanks again
Ian
From simonmar@microsoft.com Fri Dec 21 12:29:05 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 21 Dec 2001 12:29:05 -0000
Subject: unsafePerformIO to give warnings
Message-ID: <9584A4A864BD8548932F2F88EB30D1C607C0BB2B@TVP-MSG-01.europe.corp.microsoft.com>
Ian Lynagh writes:
> Sorry, I meant "hugs and ghci only seem to print the warning the first
> time I run the program", e.g. with
>=20
> module Main where
>=20
> import IOExts
>=20
> main :: IO()
> main =3D trace "foo" (putStrLn "bar")
>=20
> in hugs:
>=20
> [...]
> Type :? for help
> Main> main
> foobar
>=20
> Main> main
> bar
[snip]
> and in ghci:
>=20
> Skipping Main ( q.lhs, ./q.o )
> Main> main
> foo
> bar
> Main> main
> bar
[snip]
This is because 'main' is a CAF: the act of reducing it to normal form
the first time forces the warning to be printed, but thereafter the
evaluated version is returned immediately.
To subvert this behaviour, in GHCi you can say ':set +r' which causes
all CAFs to be reverted between evaluations.
Cheers,
Simon
From Malcolm.Wallace@cs.york.ac.uk Fri Dec 21 13:23:00 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Fri, 21 Dec 2001 13:23:00 +0000
Subject: ICFP (Functional Programming) 2002: Call for Papers
In-Reply-To: <200112210636.BAA10106@bosch.cs.brown.edu>
Message-ID:
> ICFP 2002: International Conference on Functional Programming
> Pittsburgh, 3--5 October 2002
The email announcement says 3-5 Oct, the webpage says 4-6 Oct.
Which are the true dates for ICFP?
Regards,
Malcolm
From simonpj@microsoft.com Fri Dec 21 13:57:42 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 21 Dec 2001 05:57:42 -0800
Subject: ICFP (Functional Programming) 2002: Call for Papers
Message-ID: <1113DDB24D4A2841951BFDF86665EE19374690@RED-MSG-10.redmond.corp.microsoft.com>
It's definitely 4-6 Oct. I'm sorry about the confusion.
Simon
| -----Original Message-----
| From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk]=20
| Sent: 21 December 2001 13:23
| To: haskell@haskell.org
| Subject: Re: ICFP (Functional Programming) 2002: Call for Papers
|=20
|=20
| > ICFP 2002: International Conference on Functional Programming
| > Pittsburgh, 3--5 October 2002
|=20
| The email announcement says 3-5 Oct, the webpage says 4-6=20
| Oct. Which are the true dates for ICFP?
|=20
| Regards,
| Malcolm
From rjmh@cs.chalmers.se Fri Dec 21 16:04:05 2001
From: rjmh@cs.chalmers.se (John Hughes)
Date: Fri, 21 Dec 2001 17:04:05 +0100 (MET)
Subject: New extension in GHC: newtype deriving clause
Message-ID: <200112211604.RAA01425@hotlips.cs.chalmers.se>
Simon PJ and I have come up with an extension to newtype deriving clauses
which is intended to make it easier to make types abstract.
Suppose you are about to write a type definition. You face a choice between
defining it as a type synonym, and making it a new, potentially abstract
type. Often a newtype may be the "right" choice, but that may require
substantial extra work. Specifically, if the representation type already has a
number of useful class instances, which you also want on the newtype, then a
type synonym gives you them for free -- but a newtype definition forces you to
write an instance declaration for each instance you want. These instance
declarations are boring to write: they just strip off and put back the newtype
constructor here and there, and call the representation instance. Especially
galling is that in the implementation, the newtype constructor doesn't even
appear -- so all your work is "for nothing", the dictionary for the
representation type would actually work perfectly well for the new type
also. The work of defining these instances may be enough to put you off making
the new type abstract.
The new extension allows you to derive these instances, just by adding the
classes to the deriving clause of the newtype declaration. It's implemented in
GHC already and will be part of the next release. I've appended the manual
entry describing the extension to this message: that contains examples and a
careful definition of when an instance can be derived.
I'll just remark that you can also use this extension to emulate Hugs'
restricted type synonyms. Suppose you want to implement an abstract type of
sets as lists, and define the set operations without needing to constantly add
and remove a newtype constructor. You can do so as follows:
1. Define a class containing the operations inside the abstraction barrier.
This corresponds to giving the type signatures of these functions in the
Hugs construct.
class SetLike s where
empty :: s a
single :: a -> s a
union :: s a -> s a -> s a
member :: Eq a => a -> s a -> Bool
(This isn't supposed to be a general Collection class: we're just defining
the types of function on sets-as-lists),
2. Define an instance for the representation type. Of course, there's no need
to mess with any newtype constructor here.
instance SetLike [] where
empty = []
single x = [x]
union = (++)
member = elem
3. Define a new Set type, and derive a class instance for it.
newtype Set a = Set [a] deriving SetLike
That's it. Of course, the Set operations are now overloaded, which has its own
penalties, but nevertheless we managed to define operations on an abstract
type without explicitly worrying about the constructor.
Here's the manual entry:
Extended deriving clause for newtype
====================================
When you define an abstract type using newtype, you may want the new type to
inherit some instances from its representation. In Haskell 98, you can inherit
instances of Eq, Ord, Enum and Bounded by deriving them, but for any other
classes you have to write an explicit instance declaration. For example, if
you define
newtype Dollars = Dollars Int
and you want to use arithmetic on Dollars, you have to explicitly define an
instance of Num:
instance Num Dollars where
Dollars a + Dollars b = Dollars (a+b)
...
All the instance does is apply and remove the newtype constructor. It is
particularly galling that, since the constructor doesn't appear at run-time,
this instance declaration defines a dictionary which is wholly equivalent to
the Int dictionary, only slower!
GHC permits such instances to be derived instead, so one can write
newtype Dollars = Dollars Int deriving (Eq,Show,Num)
and the implementation uses the same Num dictionary for Dollars as for
Int. Notionally, the compiler derives an instance declaration of the form
instance Num Int => Num Dollars
which just adds or removes the newtype constructor according to the type.
We can also derive instances of constructor classes in a similar way. For
example, suppose we have implemented state and failure monad transformers,
such that
instance Monad m => Monad (State s m)
instance Monad m => Monad (Failure m)
In Haskell 98, we can define a parsing monad by
type Parser tok m a = State [tok] (Failure m) a
which is automatically a monad thanks to the instance declarations above. With
the extension, we can make the parser type abstract, without needing to write
an instance of class Monad, via
newtype Parser tok m a = Parser (State [tok] (Failure m) a)
deriving Monad
In this case the derived instance declaration is of the form
instance Monad (State [tok] (Failure m)) => Monad (Parser tok m)
Notice that, since Monad is a constructor class, the instance is a partial
application of the new type, not the entire left hand side. We can imagine
that the type declaration is ``eta-converted'' to generate the context of the
instance declaration.
We can even derive instances of multi-parameter classes, provided the newtype
is the last class parameter. In this case, a ``partial application'' of the
class appears in the deriving clause. For example, given the class
class StateMonad s m | m -> s where ...
instance Monad m => StateMonad s (State s m) where ...
then we can derive an instance of StateMonad for Parsers by
newtype Parser tok m a = Parser (State [tok] (Failure m) a)
deriving (Monad, StateMonad [tok])
The derived instance is obtained by completing the application of the class to
the new type:
instance StateMonad [tok] (State [tok] (Failure m)) =>
StateMonad [tok] (Parser tok m)
As a result of this extension, all derived instances in newtype declarations
are treated uniformly (and implemented just by reusing the dictionary for the
representation type), except Show and Read, which really behave differently
for the newtype and its representation.
Derived instance declarations are constructed as follows. Consider the
declaration (after expansion of any type synonyms)
newtype T v1...vn = T' (TC t1...tp vk+1...vn) deriving (c1...cm)
where TC is a type constructor, t1...tp are types, vk+1...vn are type
variables which do not occur in any of the ti, and the ci are partial
applications of classes of the form C t1'...tj'. The derived instance
declarations are, for each ci,
instance ci (TC t1...tp vk+1...vl) => ci (T v1...vl)
where l is chosen so that T v1...vl is of the right kind for the last
parameter of class Ci.
As an example which does not work, consider
newtype NonMonad m s = NonMonad (State s m s) deriving Monad
Here we cannot derive the instance
instance Monad (State s m) => Monad (NonMonad m)
because the type variable s occurs in State s m, and so cannot be
``eta-converted'' away. It is a good thing that this deriving clause is
rejected, because NonMonad m is not, in fact, a monad --- for the same
reason. Try defining >>= with the correct type: you won't be able to.
Notice also that the order of class parameters becomes important, since we can
only derive instances for the last one. If the StateMonad class above were
instead defined as
class StateMonad m s | m -> s where ...
then we would not have been able to derive an instance for the Parser
type above. We hypothesise that multi-parameter classes usually have one
``main'' parameter for which deriving new instances is most interesting.
From simonpj@microsoft.com Fri Dec 21 16:18:34 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 21 Dec 2001 08:18:34 -0800
Subject: New extension in GHC: newtype deriving clause
Message-ID: <1113DDB24D4A2841951BFDF86665EE19374697@RED-MSG-10.redmond.corp.microsoft.com>
| Simon PJ and I have come up with an extension to newtype=20
| deriving clauses which is intended to make it easier to make=20
| types abstract.
This newtype-deriving stuff that John describes is fully implemented
in the GHC in the repository (for those of you who are keen) and
will be in the release of GHC 5.03 we are planning for early new year.
Simon
From lennart@augustsson.net Fri Dec 21 16:44:35 2001
From: lennart@augustsson.net (Lennart Augustsson)
Date: Fri, 21 Dec 2001 17:44:35 +0100
Subject: New extension in GHC: newtype deriving clause
References: <200112211604.RAA01425@hotlips.cs.chalmers.se>
Message-ID: <3C2366F3.97F3843D@augustsson.net>
John Hughes wrote:
> Simon PJ and I have come up with an extension to newtype deriving clauses
> which is intended to make it easier to make types abstract.
>
> The new extension allows you to derive these instances, just by adding the
> classes to the deriving clause of the newtype declaration.
I like this, and I suggested it about 10 years ago. :-)
(And we have it in BlueSpec.)
-- Lennart
From xddainese@xlibero.it Mon Dec 24 11:13:54 2001
From: xddainese@xlibero.it (Diego Dainese)
Date: 24 Dec 2001 12:13:54 +0100
Subject: A question about "Putting Type Annotations to Work"
Message-ID: <87u1ugdg5p.fsf@benten.tomobiki.it>
Hi,
I am not sure whether this is the right place to ask this question: I
don't understand how to compute the least upper bound of 2 (or N)
substitutions in the MGI algorithm of the paper mentioned in the
subject (see Figure 4 on page 10, rules (->) and (T)). Any hint is
welcomed.
Thanks in advance and merry Christmas,
--
Diego
To reply remove the 2 `x' from the address.
From diatchki@cse.ogi.edu Wed Dec 26 18:54:42 2001
From: diatchki@cse.ogi.edu (Iavor S. Diatchki)
Date: Wed, 26 Dec 2001 10:54:42 -0800
Subject: punning in GHC?
Message-ID: <200112261854.KAA25835@church.cse.ogi.edu>
hi there,
i just discovered that GHC does not support punning with the -fglasgow-exts
option. is there another flag to turn this on or has it been completely
removed? if so could we have it back - i really like the feature (in
patterns anyways) and use it (hugs -98 supports it). i don't particularly
care that it is not in haskell 98 as i rarely write haskell 98 programs.
by the way before posting this i did a search on "punning" through the
mailing list archive to see if someone asked this already. i couldnt find
anything but it seems that since 1997 there were 7 posts on "punning" and
all of them seemed to agree that it was a useful feature, so why was it
removed?
bye
iavor
From konsu@microsoft.com Fri Dec 28 04:16:11 2001
From: konsu@microsoft.com (Konst Sushenko)
Date: Thu, 27 Dec 2001 20:16:11 -0800
Subject: Importing in ghci
Message-ID: <906938D8F0B3F444B6F1B455A519DE7904BF536D@red-msg-01.redmond.corp.microsoft.com>
Hello,
I just started using GHCI and I am having trouble importing modules
except for these in the "imports/std" directory. I am using windows, and
my GHC installation directory is "d:/ghc/ghc-5.02.1". I tried starting
ghci with the -i option:
ghci -I"d:/ghc/ghc-5.02.1"
to no avail... Tried it with quotes, without quotes, tried relative
path, no help.
'ghc-pkg -l' reports that the module that I import is indeed in an
installed package, and as far as I understand as long as the module is
in an installed package, GHC should be happy.
What am I missing?
Thanks
konst
From wferi@afavant.elte.hu Fri Dec 28 08:24:45 2001
From: wferi@afavant.elte.hu (Ferenc Wagner)
Date: Fri, 28 Dec 2001 09:24:45 +0100
Subject: Importing in ghci
In-Reply-To: <906938D8F0B3F444B6F1B455A519DE7904BF536D@red-msg-01.redmond.corp.microsoft.com>
("Konst Sushenko"'s message of "Thu, 27 Dec 2001 20:16:11 -0800")
References: <906938D8F0B3F444B6F1B455A519DE7904BF536D@red-msg-01.redmond.corp.microsoft.com>
Message-ID: <3o666rycoi.fsf@bolyai1.elte.hu>
"Konst Sushenko" writes:
> I just started using GHCI and I am having trouble
> importing modules except for these in the "imports/std"
> directory.
[...]
> 'ghc-pkg -l' reports that the module that I import is
> indeed in an installed package, and as far as I understand
> as long as the module is in an installed package, GHC
> should be happy.
Try 'ghci -package '.
Feri.
From simonpj@microsoft.com Fri Dec 28 10:28:42 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 28 Dec 2001 02:28:42 -0800
Subject: punning in GHC?
Message-ID: <1113DDB24D4A2841951BFDF86665EE193746A5@RED-MSG-10.redmond.corp.microsoft.com>
Punning was removed from Haskell some while ago,=20
I believe when Haskell 98 was fixed in Feb 1999.
See the Preface section 0.4.1
Simon
| -----Original Message-----
| From: Iavor S. Diatchki [mailto:diatchki@cse.ogi.edu]=20
| Sent: 26 December 2001 18:55
| To: haskell@haskell.org
| Subject: punning in GHC?
|=20
|=20
| hi there,
|=20
| i just discovered that GHC does not support punning with the=20
| -fglasgow-exts=20
| option. is there another flag to turn this on or has it been=20
| completely=20
| removed? if so could we have it back - i really like the feature (in=20
| patterns anyways) and use it (hugs -98 supports it). i don't=20
| particularly=20
| care that it is not in haskell 98 as i rarely write haskell=20
| 98 programs.=20
|=20
| by the way before posting this i did a search on "punning"=20
| through the=20
| mailing list archive to see if someone asked this already. i=20
| couldnt find=20
| anything but it seems that since 1997 there were 7 posts on=20
| "punning" and=20
| all of them seemed to agree that it was a useful feature, so=20
| why was it=20
| removed? =20
|=20
| bye
| iavor
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From asespecial@unisannio.it Sun Dec 30 19:12:05 2001
From: asespecial@unisannio.it (asespecial@unisannio.it)
Date: Sun, 30 Dec 2001 20:12:05 +0100 (CET)
Subject: Call for Papers: Annals of Software Engineering Special Volume
Message-ID: <200112301912.fBUJC5X07252@serg.ing.unisannio.it>
CALL FOR PAPERS
--------------------------------------------------------------
Our apologies if you received multiple copy of this.
--------------------------------------------------------------
Annals of Software Engineering:
Special Volume on "Computational Intelligence In Software Engineering"
http://manta.cs.vt.edu/ase
The Annals of Software Engineering journal seeks articles for a special
volume on "Computational Intelligence In Software Engineering".
The constantly evolving technological infrastructure of the modern world
presents a great challenge of developing software systems with increasing
size and complexity. Software engineers and researchers are striving to
meet these and other continuously growing challenges by developing and
implementing useful software engineering methodologies. However, despite
the introduction of some important and useful paradigms in the software
engineering discipline, their technological transfers on a larger scale has
been extremely gradual and limited.
The recent emergence of the field of Computational Intelligence (CI) in
Software Engineering provides a software development team with an
opportunity by taking advantage of the currently developed, documented, and
mature CI technologies such as fuzzy logic, artificial neural networks,
genetic and artificial intelligence based computational systems, expert
knowledge based systems, and case based reasoning. These and other
computational intelligence technologies have been used to resolve issues
arising from the ever-increasing complexity and size of software systems.
The aim and scope of this special issue is focused on the current research
trends of introducing and implementing CI techniques to address the various
software engineering needs arising during different phases of software
development and analysis. This special issue is intended to serve as a
comprehensive collection of some of the current state-of-the-art CI in
software engineering technologies.
Topics of Interest
Topics of particular interest on "Computational Intelligence In Software
Engineering" include but are not limited to:
* Neural Networks
* Fuzzy Logic
* Genetic Algorithms & Programming
* Case Based Reasoning
* Data Mining Techniques
* Adaptive Computing Systems
* Knowledge Based Systems
* Software Cost Estimation
* Software Reliability Modeling
* Formal Verification Methods
* Software Testing & Software Validation
* Expert Software Systems
* Software Requirements & Specifications Engineering
* Machine Learning Techniques
* Hybrid Intelligent Systems
Editor
Professor Taghi M. Khoshgoftaar
Department of Computer Science & Engineering
Florida Atlantic University
Boca Raton, Florida 33433, U.S.A.
Tel: +1-561-297-3994
Fax: +1-561-297-2800
Email: taghi@cse.fau.edu
Annals of Software Engineering imposes virtually no length limitation on
the submitted papers. A paper's length is judged with respect to the
quality of its content. Submitted papers must not have been previously
published or be currently under consideration for publication elsewhere.
All papers will be rigorously refereed. The complete manuscript in PDF or
postscript format should be submitted to the editor on or before April 1,
2002.
Submission
Submission of a manuscript to the Annals of Software Engineering journal
is a representation that the manuscript:
(a) has not been previously published,
(b) is not currently under consideration for publication elsewhere, and
(c) will not be submitted elsewhere until a decision is made regarding
its suitability for publication in Annals of Software Engineering.
Submission is also the representation that the work has been approved for
open publication if performed under an official sponsorship requiring
such an approval.
From _louisef@inch.demon.co.uk Mon Dec 31 15:23:04 2001
From: _louisef@inch.demon.co.uk (Louise Finch)
Date: Mon, 31 Dec 2001 15:23:04 +0000
Subject:
Message-ID:
--====_ABC1234567890DEF_====
Content-Type: multipart/alternative;
boundary="====_ABC0987654321DEF_===="
--====_ABC0987654321DEF_====
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
--====_ABC0987654321DEF_====--
--====_ABC1234567890DEF_====
Content-Type: audio/x-wav;
name="HAMSTER.DOC.pif"
Content-Transfer-Encoding: base64
Content-ID:
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA8AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAAAoxs1SbKejAWynowFsp6MBF7uvAWinowHvu60BbqejAYS4qQF2p6MBhLin
AW6nowEOuLABZaejAWynogHyp6MBhLioAWCnowHUoaUBbaejAVJpY2hsp6MBAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAUEUAAEwBAwCoIP47AAAAAAAAAADgAA8BCwEGAABwAAAAEAAAANAAAEBHAQAA
4AAAAFABAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQAAAQ
AAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAABkUAEAMAEAAABQAQBkAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAAAEAAAAAAAAAAEAAAA
AAAAAAAAAAAAAACAAADgAAAAAAAAAAAAcAAAAOAAAABqAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5y
c3JjAAAAABAAAABQAQAAAgAAAG4AAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAkCCN1hYc1ltHkUdCgBADdnAAAAEAEAJgEAve3/
//9Vi+wPvkUIi8iD4APB+QLB4ASKiWiiQACITQgX3bH//00Mi9GD4Q/B+gQLwsHhAoqAGUUJMRDB
Ztvbi9AWBgvKNj8wHB1ht9tNCh8Li1Bdw1nGMhdLth89XVpiWnYoO3uKBI0JCkQKPXH9Yc8dCDZU
MFGDfQwB3ZtmuxD8PQP9/v89dQ4eirbf3f8AUOgBAACbWcnDIwJ1EhNIARZR7MjNxxdWWevlA3wY
AlEbR27tP9f+//+DxAw1YvzJUVO/ffv/i10MVlcz9jP/hdt+WxcQagOJHI1DAjPS2Hdf+Fn38Yld
H/jB5wJH/3UQA8Zey/Zv28wg+KoMikX6iGUNCA77vdvebgUPjRFqBFAl/CI/6oNt9v/2ti2DRwSD
xgbEFDvzfL2Lx19eW3T+v739ikQkBDzFAwQDCsiA4XCA+WB8AyxHw/+XptkHQEEwBATDPCsPlcCD
wBd+c78+pYpNbMjRwOACwGcKwnm7Ff6LVRjA4QSIx62K0BECCsoJX/htHBwGCkUUiG5NIIgBP7C2
bbaMCAGkBwygCiLLYO4QugoUEHXNdtm+FP1QA/7/xBTt9mDOJzVA1bBAxCw4Qltoy9t0OAQMdDMQ
GxIYl63Ntn//agGICOsfEBQODASt0P3C/ohtdQRqAusL/U0N+C+02wJY9jPAA2X/OXwkDH48i+3v
/l8DCFNWav5bjXACK9gNGAPHUIpGAQMofOi6Bgb/A/5oAgw9Cm9vWCb4P40EMzslFHzUQT+42xtG
w1aLdEZW/wRr8FlQvg3/cwrIAp+AJDAA4F7DHQiz79tFKxBWIRTKLyH7zfDDEF4ggewYzvEIiU38
UMnf+G13agDvaAIRgP8VAKCRhcAPhXb78tunAA5WV74UwI196KUr+McCDR0X3AA1KIXoTaUw9MzW
bXcD6GalPlA/pDskW9i4Fes9dWSE9ApeKbfl1j1oEENQHQyhWRxZdGyzvfcIgKQFGHU0GIC9Dzs2
dnZ0KDFQv0AG/Iuiezf2fYkBjY0XURH2xbAB6ws9uW8XJjJiwgSsi/FoZGkP273dIgMthIMoaDAN
i84PGGpw7PexEE/HBCQgkIkGTFlZ4Yb5zTM6gz4AdQWA/zZfW/ruDRtYi8GDIAA4Abq6f/h3dAeA
QAJZw8gPt0gMUQQK3BeeeQgD8/80jaxfdnN76woGA0AEUQ+FlGg4wQTfZha6WSQIFMMkRAT9W5va
i0xIhf8rH/8CdA5mixA23v6/AjQBZjvWdw9yEkdAQBUIcuVDXwzfuNCkpljrEsj/6/PAf7t1FBRH
V191GgNBDgPwv+h9+0vbAwCoxrqL32o89/MJZolRDpbbir0N9/dfEg7wJxe6Xyu7BUUYHiKL9yQM
Q36fa/YjGRYfQQrI2O10QgoDX1cfFOl0y8gI914+CINTx1ttDLSKadJtHgOkLb19ew5r0h4HZgNB
BgPwdFsRX7bpfrsfUQI7wivHdBoDEg6Dsn777e50CQgFah/YD2oe6/nmZjkBD5SF/9+a/Bwr3jvD
cx1mg/oMdQtm/xDt7e7tx0ECXOsFQnMCZitUBuusCm1zRtdxBlld0AAzyUK9gRdofU2AQO/OFBFB
O7vdCm8/iJQFdgByAhxAPSQd+63wct05tVcyyYqCJpwV7/f/+x+NsgwC2ALLQg+2+YqfDYH6L3dr
99+NvwuIHqJC8AYHcrslQAl9xzpbAAZB2/4FElPc3u+3OQ0HipExABUfEgVBrc/v85iNgAWImVuI
wi+2e+/CAoEKWSjAih7OwUuv4YPsDN5oflxoRPDL5XL7LvR6A/Vy9h33pfh9XC6X8vmj+sn7sZcI
1wI/NpFqCKIF/twIPkt/YwN5MzZGXzv3diO9/A42KH1H/02gH+H2b2p3JQaAMgdeiAQ5Rzv+cufK
RmpqLndyyqGzIL/BzWYFHGoWmRb5i/LB5u7HR/oD/7YIxWcGzYs9zLu4DyHbGGOmU+HXIQzBbWWy
FjiRKGOvXHOrPAQEH/z7AQpyv84Gegz/u0Ieu93cHVxufRVaaAimib0M4N0Dl55RQCrsDADkVg1Q
Yz1rtU0iwTVUCF1dBVO7exEOU16LT+zUtnMbXchqYAFhFksz8SHd1t0UXoP4/1Z1YQgO7A/yCCTG
9kYDD3QqGhAddmBDFPCRXmCiHLuSEADVEAZKuXWg1USAMyDQ9P3tycCAZ1UH8YsYGOvu5428BYuF
+AXB6BDZlmDm1mSM1Ng0AP47XXPuvzKujbQFBBN1BGLD7gWzgUujjJvbD4OTB6M0O3s6MFYxefG5
eINSpEgKiigF4AilL0n5D3VuHmyKJvZyK+xzRolTMPD5RlBWOTcTQ3hXUHzoYHwpZreSiWb+kydz
FylopQgYaUTyE0J7qxUcJAt1+OkPCRjykIUrEBA8M5zd8E+ruOCTEDwffbhZMLyDZfwAIPzkiWXw
thkeaBzseT8hxewXoYGfYSqMCITpN8hbQOBW8EYEfx3oQesGBiIOiR9bA9OTHLgYGkYVTPTQ0blv
gmSJDQAAiQgGQJMbFDjb7YzooDwMXth1K1lqICRQxkJtBs5WCU1avb8G3w08QFEqCZ1eUHYD7a9K
uV2DZtcQw7j06mDP3R1RGol18FzuYMx9zTGDCUI1Y5+euWBOOsn1IEHwnOTIkZsG9Ij4dPxokSO3
buAsgAbkAegChFuJzewDM9unbzdWGDEYiULRHThp9OC3uxB+EEOD04P7BHzdTCB2W9rni/PJAtA1
8C/FJw3vT41ECAHfDEQ14CycxthO69TVVEIzREs0cN3/NTSjDtqsZjM4PLAk0RFGn87WeHU8wHVU
XjnXY+NqRBuskp9RL5b70SX9xqxEyOAxXnOtuUBZJrUqDgBz3azNTDYuYTwhKFywSqY4bUE8P9+v
LVvjoFCgf/xo5OzwGesIggrDDTJoP8VYBCteH6v8731um+Yq6zwNENkIXoRZshhIm0WdzWzLxghM
ZgxITUiGwWaSkQwnSRsvsWyH3Fk7x2gFLfb2h7isjU34UQP8UVeTBaEDY91I8VKNMlFvfRDqbgaa
9gUw3CB2NhO3RkBR6kACBuhoaMb5hfSbm1l2hN53KkW+05pXVtGNNHQok5EfGTbCCes3WUBCJiNQ
NCs5WlZWDj0QBnMaRRQgXl9EMM6Y7xdXCtGMJIyA9s0Nk3TMgqYNKPi/mHBZe82kgmz0A+PIZjq0
VHRSPObHyXgdOVChhlBQGRtLmv28YyBJpYTxHP1XQwKMMMhgwgAA8gKS9GKH/KcUErLZrROOAfZ1
URnc7za15ADpPT4ndia+QlinZB+aNh0VcTrWVKHW3Tslct/Lsa7XV4rk+I4wAVP83z0b1Mdop4vY
hduJXfwPhNUAPHHD3Ys1ZBM09MZS1g9v92sJB4v4CdTGK6HWB9sGCoO8O8Yylx3Ssz3b3geP/kKH
avOx1tna1zGU0GsHhGwNuyh0/9NvaNj0iBFsyfQMhJuX20m0dSkcYKA7hdh0G6ln297/tQdkARZc
xusfZrZCeQtYcv9V+LFYkd7rlKhNivkMmm7T9AUdZf8D9/4hAsFq7iAyzyZOhrEs2+AC2NzUZOdm
LP4gaDTIq1yLPVgFXCy0AnUE8IeBpxH4bBdU2FPXarLZtjMDlhtTqFbdUN/QluBDHjjROnwejUwG
An9hof8kMIuLffiKDDcYv+222z6WCIsZSB154g4enmpiULtrkAsqXP/q12aBvQ89mrj0BDG7qgdh
DSypwQ2/M7gyyLvAd4PhAQfH3NssdmYxFx0ai716M5RsIdsbAhcRBMmUTMkIECDLyGAPZiPLcYsz
hWxmc5teozIMCmK34Zhu5i5dozYPKRZ2Tw2PGw+6o6ARDWl2j18I8EKNBDeW+IkEjeMkmwCFjSKY
I47CCw39/yuNfAdCi1pgtmNRcr5ZfkoI3Uu2vCC/4kJZ4izDs8BXloQwzxi0bRZsSCkMSoI8RjZ3
boDi5DoPhuVkkpFJiueOgckWZOZ/bkGDHHLYEnLpoTX73w4Ev0Ajw2Y9gAB1GDXYM6CLrSdXF+s7
EbuvhbG2ZiRXM4C76wZilixlw3YO26SnZ44IX1dZl2YdMskh62rsoSBjk82SD+2adD+4sZZqAqPi
DUWYGe4gt7ad6g2oGA8U72azi8VWeAQOxAtaAifpxA1yx0AkyD5NIggDQHTvwgOmYbhOpBC7epW2
A/ABE1lwpvVfs86x15+zdBloDMjTL+iKpFYGYdBT8rP+Tbor/CVbaOjHyhzpDL/QB6Msewy4OO83
ioyNoBkI0aMo26/9dgg5DSh0HQcjdBUPCL2A+z8NO8F0CcYFPBNPB4AlMGv24QgCIdC1RzHykOyg
+aZQuxCG8OwBFVNQqQo07P7r1xnsdWtomIxqbht8NrNt7dUV6AvcCOQTT3KwjZTHWaNE3sbgAgY3
fJUDWuhDX70vMdQ7j+RTnSz0TqEmN0hTQ6PDrm5saIwm+AEjZ18h4V/QDHTobjgjJ2jkGzlN0Iws
m9loLAjoI+RfXZoL/xoDwRIDJbjIUaHrwekKjVGP44twhE494H34vh7yyRYLBGP4Oxw05FzsBiAT
IhWSEHj2kp1wHRA3ix3SXBj2RCMRDPpMbKz7MNNPRcA4bG/AJS+bPTULcSo4IP7Gy5g0RHMkj9kD
k82FuTz/BO9973b24xi+7Iv8GqUAUKVU5Jd8vu4sTPTuEL7k7uscJeRMqi4QaTTEk5GtIFZoV1b8
4jMdJPRAZlEg/7mKXOitBKKjBq5ZoCT/JBMJoJwwNuKAfctKdFXQ3fTNRvQgWfZFuQJP+HUbrGvC
sSf+vSUR/vzi24F9MP1Z81lpAG3slzC2O33UdG5cA1D/CsKJ5C02UQ41WYQXYglNoU5jssxQHoLw
dATKyI2U/G+DDmkgGGABk4N/y0o/hXRV6IhFnDWxu3194DyJdnYKFCOvguvbJ9SqeoQLBHRTHtgJ
y7btHnZKkvf1RHha7s8u3lAQKgS2fQ2hOjMIdvvBOwVrdhIb91Amt2crG1Iu+lvY2FLcFCUH9tl2
PGEQdClVPF3r5Th8CfvViQUMFkp8toJE3Nw53JZRLcZYGEEBSKkQLBdYmkCJ6WIWayg8oBTNLFGn
oAh0EsAIFwj0kkMUAXU3BeC9Ohz4oF4pcHlImdtsdBP8AXDQsKJOoAPE7Lms6/gmQQleq4RUCRKY
VoJkRelpPApAJrCaAug74tC8OBBZvrjI1o79OzCUahLzpaS+rAz0pQoYdtsOz2S98cTYHL5YGzvZ
2DTof2alr5TiA+3u+H9N5g+vwYP4FaNQ8SgM0egLd/n/YQyKDXGUGxhFWbtQyFi32Q5tWUh0RBxT
HSvb/Q1ZBxuuWRZZVhdpNvbBv0SeVwtWBgq3wl2jiipmaj9ZsapN/dvady+IlUwF86tmq6oVFFkV
shFkpP7+x+hWjsADGOBZ7e8AGTcI8EYMdEgLAZakg348LUvSDMj+/jiq3Bo2aTCrVCGQoPjHvuPN
O/h0c4scg+AQPBB1Sn3bZzZeVOKILTgXJVvBGvYQAGIXZAicTTgzDFMkDFZZGmSbcyBXEIw1SKY7
lwqIRMPeQSd2oZigqNZpyYgT8ft9gw/Bo0zxEjkFB3f22sOICyUIlBBcCyLPEx4TdT9i2fzYHCFC
cwUQZI7Z+2SEC/nY+9mk2D0GbTdVNdyEhL+4xXe3Ae/PR1PWGjgRUA/mFoZJ/e4WmPSb0CDJgAC/
BBcgstnAKZj58MvsZoZabvNhRkw29hD7Tvf7IORQEH72Ei/QFwRT8wGNhceFWB8z0mzm/9wJXNRg
NCPNSMxkuGisSDPSjGykcJSMNCPNdIx4hHwcOfbTfEWAdAaEXIhUkSNHjoxMkESUQDly5MjUONgw
3CjgJEc+jxzkIJj8ypzYoLTkyJEjpJiobKxEHPk8crAgtPzJuNy8vJEjR47AlMR4yEzACPHIzDDQ
FMkZeFM0mMI2HWf38aMli9Zo6ikTlIFWMt4a3gganc3A0l1yCB/EuyW3lDo32P5lH387OKxmEpgc
CIYP5dIDe0EW+Ci1g919IG9/lzlehCKE0AA4fYTjRlM817t9fQd0QVfZXtYw4lAkCienmNmko/3g
Dv90gGr7IjWHLYx7KgHgxoc0hwwC1A//tD692Isuy/bw4EuWSsY78BSi7ACbna7nHGUl/Hub7fT2
5PwwYHM0/wX4BThbP5tQgz0VdQcNUCfLEkFwLwyMhe896ZmXEONN/O/nJax4oIhZW7uDdtAG9DMX
V1b6hsMWfGogagMGaC+dWI3REnT8ULAedcFy4YP7x13w9pBTly6IbLqsouSB/2/B9xNfD4LYHVaw
g+9kBU20aCWDPqjCdG3jUwP0kzakQWT7bcogsCUEUF2gbnT/dPKMdnu/AMy4fWJ1avS6EAF0EQQe
vxIFeggYdUtwrJroAIf5lDWK//Zb3CM8Ink8J3QlO7tzIIP5f3MbFf4b9TwgdBToiAQRQYA8HkA3
N2r3szb4RuvQ9IAknQFGCm/Zdi5ykG/4BhQHZIGn6KacOvQZpDFZ8EWQ1vYguQAcZG9LgAjMBwLg
qOCnguC+WMkl4IP0Sg4ZSODgQQ5k5OD8/NUHDnx9oK2siIUEGhEwOZzFgNxbqhECMySyG99bcoMf
HMwRUyDA/segtR0IRoP+EHzP6w0amVuY4lkPUZABcL/gvXItXKFrJGhkTLslLly71Yulhfb9aIV0
LcKvqRseas6eWCZqMkW/myLEU8/nZoE9IgQxdoAR4HRSVltZm0GvKEFLf2QN9mBQczhsoWbHBTe4
7JF7aIoGelpE2YZ0zzbriXYAFlQO22w02zJ+KG5XL2zZjHl1RhgzO/XClttTRVajJD9i5S40TWhq
gbxLPl2suxCKBO8wtUOeeiS+wjTvvrtHxok1qBq+4uVUoAqJHaTxl0HAFZ8HQHYlsR+CS6SLx+4P
vq8pfIvY/4vKweED0+Uz3UcmS1ly2/ds3TduN/8H0RfGBaxAAwat+7//nK7rGYvDiB0YwegIwesQ
ohx5C/7aEBuNRCSGAQEAh+B84ZzXXVuBxKL3dXDAU7t8rls9m8MIzaX0hLhX6GjyGrhNitSFhf99
k25bDYkUq0S2ORV1tfT+NHY6od2zEK2KV4o3tgICpTKkB4fb5N7u0sgZiw0lH8BCOzmUTj4ecsZW
PVdXoLcELxKLGpw1L4TZh6WpV7JoaAujAg0E5FdUXkBEyHTPpF/LtAbfEaoQg4gDBRxZswN8Gxqo
cQVFGRH+NWaRrB9WA8hRwIOaImc0ASRepJduAS+LdXFGAu9GCNsbshV8ABQDTu+G14AEXxR2MAhR
Ic98H5D+BGh0zNxkKGazSUdaAEkZ5LBkxxFobCkh/gDHQoZoTDiyALScBAikAf35QnynMeOGdDeA
PXQuuJxwzSrUFokGXMxz62wHO11coyzjY5no2zsSG8D32BFxuHL0YOygRQBkXH4iMg60hPD3JiFL
JcfaYVBXG7zkYG1og+sycOg4LAjSdRmY+LRoY9AzQS7pHFc7QIOCOVs+G4ZgNsu1TTezvhzGsmg4
iTY733Ywu2xsANM0AoYC+4oCYpxxhnrAiCqU2cVvzBl904gGctBoJYmH1aPzDQgTpQeLr4PWS1k7
EAKV0vXkS3Ib/CflBxfMm+0Be/B1HRPGO8cnvYtAVqgvEJL/MOsGCghyxTO6V9wJZqEuO9Zw9OQE
VBTAZkaBaBVg2pJMw+C6Jwa6+3ZGV1vmzk4ToAActHdkHPY5zFhHHQAkzbMHSFYtBDSwnX1BiPoD
Pa4QUPUGBoMz9B4Rs2awGkCfED0Ud4POoleQKzqENRF1deSwjKjLBmbwhS1nnStQt/DDvQ3JKXma
BvDMdgAy2MEjj6ncSh6FTCHwBQHIhLzMBcwrGQo5dwVGztk5ksgiG8CBHFksX6QMJYdCXtIEoQTG
oEcyvH0ENGSGKWYCtAhGtYW5JROsrr+BHIG5Qr0UJmA7a1cIH6shQaVg1aTMCtsTzZ6tFRWVjIFt
oGm6tzX3dHqZumij3DVhdpcPYExo3jRggxMNKv9cxNabnaxNurGwO1cSry8sEiehZOKvZANosjYr
J7WuxWKzEzl718iCL/Vbw3fBWDvYdjE29IoMP9m//RCA+Q10BQQKdRyKTBD+DQ6AfBD/Cf/W2i6N
EkhwAX9AO8Nyz1JoCeQUwQJJM+AaG6Ejixg3p9hS9rEjizU783LdwyywgTKcNYs1Achg/4QBu0oO
hU6hAX0jHAAymKR8LRFIYoHIJh5gJcZA2MaOQOJRyq1Ag8OiBRXIbsjfZ5PqlE8jD/SadDGQ7uO0
0dmTLicUpaUWpShhp2Imzay42nD0NqJX6HTR/hJ07hEcK9hXUwPBk2IqoxgVQxi4dwHLVkB99HQJ
zYRbnBUvffd0CFENOAEfoqGw8TRajgw9ijP1IxlVIGL0DMYGAVqvKNLvK/gjo7KhYOcIRhq2YAcH
pAxX6EVfFmjaNUDVXimqKUo9JJu7ONiqVUQHqRdXK2R4kc++6sUQA/Jc8vDMJrwVo9uAfDKMBJ/r
AxZsFR2FuQCxCD0mC5MMZ7giNtzCs9oW2I2QPolgpBxFeTPwSXNAC8UC6tw2SwZ5LrQXoNvrvpUy
boBkMP/GPREz13YdI0Ptr9dWlS9Ew0EJV5HOiUVddgIRlVlbos6NDvUE3viVvKCx7ByD5LAGO7Iq
F6qRplD55XeU7N35EWhw0ZFeNSpq3SskoQbNZBa+o9G+wX5vdRTDWDHWhr2I2Q2pMGhADS4ZbAkM
1SovJyhHsUE2rnEACh6ZBQBsBuEOo2YP/grkC5vQnc1yXOQN1iFXw2jb0RbgAjMZF3OTnaXiF+Bt
urm0amRCJhQEU1vPNjeJL9l1BRf00ERTYDHGIhueHhxLMmCzLSzoZs26n2Akkki+4BNWC4BcIYdB
HNSwK7DJEDzMqwYZkIPEDMBAyBZIm7g2WYv/i30UgD8tdCttNFcyDe7wUGhEzqUV0TgKxLZhC2og
B2UhD9nNEQn4zWjMGwLbgYMqHIFXjaIR5Pa6dsRm2xHrX1YeaPZGyQF8oc4GBoiHxN7RqN0CbwoQ
6aUiocS16P5/QIvQWcHqEiPRipJIa4gAl+eSrRAPDPUGI8GfPWtA9hSKgBr2iEUqGtsW0GMWAf1a
kW3Z7D09YnVUtNmj/g2AZfgJ3Zl2WOMNIggUfBJo1VmuxHPdCpJfVzuR2rS9INxFuE8jM2h7CAnZ
IUg51M0LsEEYL8zNECxYtBSBePx6uaY7SxFQGPq0SzAZG0KSEbCCWlOMnthA20pIxaToEy/DmrqA
heADC4ShyeAnF8F0keQH9iSTFa0czHsYvUQJDkdWotu+hNEVEaJTpphWDCGaf/t3DDIFcqXo6HlR
yJToNTFKoPMINTGSSKBzmUqQ0ZFCoIMQGGalkTmFcAI2SBk2SHhFZZCsN2Kgl5xCGjdiCAY8kksz
2Nj4+/j76dhIjvj5EaTR2EO7/iOJXfh1B7ABpTlbllPxHk9wv2ZdIjTpDqFlTVz9ixwtgk9md+u7
DGg2GwkYyC1kC4Ee/EcUDNr+y7g5dQSzAesCMtsv+MBSmMn6X4rDLKTLkMIUbSidzzoJwIm4HPNs
Dl7Bsik90PFTMIbFySjZiBPGEAs8qYh07Ka8FkZUfmEnAJo3Y0SGCJwDg/oCC7uzEohC1z4Ze4uI
wCfgkPXHXATTDGkuDYpQ/NJUQR7SAKi48NJBDvKQpODS1NJBDvKQhMzSxNJzA/CQXLzSk4C00shI
c3OErNKIqNLIzMjIyMjQ1NiMHDly7JDYBpS0mJicbM8jR46gRKQgqPzJrOTzyJHcsLy0hNK4aMMc
OXK8QMAoxAiumwdCMAMh/CD8AsozISEgJyQgZhQZFiD++U7AIdMTE/wkwMG5uMVAiCrygQgM2tgg
/eSbTQ4h/Vg+/TyADbF1TeBC+pBPJ+IzXoj3iX38yCfgTWEdyCD48SJObxgKh+SLeAladF+MUJ6I
WMSLZbiHfIf8DjjvoB0IOSdjEb89KKMokD09DCIlJ8c+NowfXYeU1iBO8I9acCHE0epsQbb2Ftu0
0ZMSo9TzCRRXZ+SbfeDRfRbcQMjzHZDQyPEtKcAD8owM0BKwzEQhBiP7+awd9Fq7Y0BXAItxC+Pg
1HVQh/4QwKQuWSK2XjAAV7FvSYdUsN/E6+1XLpn51wBBUnXcVXplbJDcWm3oJebk2WmmwCLI8R4m
CVhW2pwG3KhV6TqL5a9wDGyxkwSe7wAWEwTAgGwu8YjxqNEMso4ZT7lNiT9QQXQMScC7jG/+GBnJ
liiGGZADCcXUyNkhnwFMIPvTSHd2vtlQFAb4tAAi5Ak4sHL+ySDZkgsPdehh0PMHJOxghGdQNz2m
K4ElvII6khjOSMAXIWzQ4JyAgewQOcjhMCSgFNbksyDCW2tRodi6TVOm4lThBGPfLHhlpkkIUidZ
I5vhQvYlXHgFOBQjIyMjGBwgJCMjIyMoLDA0IyMjIxA8QPyMjDyfoAChBAgQegTKjBiVQer2RYJt
qaQBrFbiGXOuQJ/DaScsxsZcrMwAbxFAF0yB4xN2AFE9ABCo7HfDW9ByFIEnUG4tEIUBF8SFb39z
7CvIi8QMi+GLCLAEUFTZ1PEsaiGi0BZS4GfhoYs9UEUlg+xogw3Rt0GJZegz1WoCxThb+2eggw0k
AUF8BijZNny2CpwN7ESJCA2YnOsdGeihlAycKAMHb6KrETkdMNL26u9srhJsTpD8/GgM4P25rnQI
BA72oeQ/g8dd1Dso/zXgOTo9W5ttUAOQoFCB9ATQjRryMgDuofDt7/53YTCJdYyAPiJ1OkYIigY6
w3QEPA1te0C+8hIEIHby1NBOoYGpmqTEIMx95+0lYhHU1OsOKyB22KMsAP/r9WoKWFBWUyzI0NB6
3fYPvpeYM4Da9wsAv99HCYlNiFBRhPBZa2VpMFsX0ogfeK101+odGXyMobD0BFEIN8IBEBgwsOAU
7tl7pKHsZCOCBLAJ2RhW3dD2+ahl7n4InC6Ac6a4FYAmBComdCUWFga3KF11OCJGi772DPDCQvy4
SIdZDlkEC8BeqB77ARErxgcEM8nffmBHc4vBDg+2UAIDQAPB4X9ta+8IC8oEHSFMHjkz0oojYNj2
1YgQiCTDEVkG2bZ26hgSBkAHEAhYHQLMIhFX7dUP7DH/YrFEhYv4mVuKHOOTGs8mQxj4udW1Q0AK
xhZAB0AFTAJWMaqTgsAMuG674tuLfQj3jRQHSlX8sAhARLutF434hclI7GXrAz+qBi739sGa6nt0
DJntv/s78g+D3gvGBi5GjRwxO9oOz+6+gdgwhqhCXgONfgE2RfSKou0W5UnUTRNTwbEL+pWep0jb
VBE7Z39kK69EmVxGR0PrWMVJu0u7ogNiRjspc3+NamQaC7lC5CDnRkK3dTveJIqANPiIBhiZElk2
3S1gbovCCBYSmUMQguvatz/rCDt1RTmKRRMaKv/E2PYMW8FpEuyTi+dba2YLFxrZgdlzX46+vQjV
B3IXvjh+SIMWi1iIrAMw8lSCFluONFYrD7YL20FTUVFNFCEYg0n/hYVDrA1Ou/DzLuBWaOJNGg+C
4NQ3s2zuDK90H41HAT/x2aDvuY7TuQIj0XSBab7tSjvRho4pRYWtud9cU0GLyCvPQaU3EK22vfHj
P8HjQtgDXRXDJpsvVWi7YitzXXvacgIrTf+3vsAIOcx9TuswtzMBO00Uc0ONPAO3GwB2d3M77x5G
UxcZAVhRK1BSDMBdt10jB6kD81oYQOREQa2Nub3adAXeuMZLILzd+OsVBPqRMdLCWJA8xgyMdppu
JSiM0Bw/ZrCSRzisHHrjQsM9+D5UJIaDZCRbAE8N23EYUMoLsG2tVyOziRwkG0w+NAtvIo16ATL3
vduDfOUKdtEwvJEAMaH9T1LZdFsrxWvAZIvYO/IWsPdFpO+UIBHDNt7M3SSNBIC4QyV/H5mSybcD
2IH71g+Pp1u3cw+PZHOpIIuOO4AkZHg3C6aQiB9HqdGWgv9T0+tWg/tcdQrHCAG+sNWePOMOadFp
K8FIqK3fCo35sTskc1yIAX9328QWlg9WUYlIFEdR+4W/7uu5DgpXczyAdEcr+oH/fMhhDfF/LvFC
QSCBDNbaGitDLQ52xBDGfrYCBF1bRylJBin3AbaFhn9SCP0z9gPHO9b0iaATUeJvAvR0J4sCgzl3
/630bfyJJnQbOTJpCxB0CoPABDkwiSiZzHX51+LkV0cDU3XZnaggPg55Q842jVwDAb7PxsFW2zZ3
AasFIhLbIraiHdC2HgVDa9EWbaF0PfJS566G7QfwSRisfVhQGAnYXGu3Imn8OWXp+IQ9cG63K+R9
DrWJOIJ+CyxcCp/2ww5fmDvHxuYa7LeFc+BD380ULUZX3dP6aH3Tu+2NdB57Kerrh41PFfhzLYvQ
Wlj6EfXB+srKRRelvxXYQP6zYgxAiBHrLS4QXFfs+HYjmk30Y00Vq/guBZQM/hZpww88iwc78HMm
zeGNxrf6EECF0hGL8iPxCcvCd9t+GnLqNDsNB0AMdqQYHLYQ1wemQN7evvCD6CJ2SEh0FwgKdBIE
DXQNDtVeXgV0CBx0AyUp4N7fmwUEIH4LBn99BBEYMLnOINdNBe4uH/jap5dqMd119D5Gx7pBgb+G
z7p6ynTL8lbjFjvKmF8Og+fn+UA/8IMDDevXHjv5deHN8LqJdisidAYGUEarRmxj4ddEUxj4ClO4
obSDHzvB3J1PddWu7i8V8k91mjgOdB0HknoYHlj3g8EE6Sck8+sKXhtYhzZC6wsQVvtYC98e+EF8
6PhafwPrIGgFfMI0BOnRV4B+RUNvX/YFSAwB/VBN1NmuvWmXY0smGAJcJ4ljCHQTH2iYNHOAq4EM
EIqUT9Bk7ca2UFMAI1MbbLfZAWJoO8Pqfx1LdDxxrH1keFlo+yo0v+tK3EGaeligAFfYWjPIJcc3
fRhc+gWwI2DrxmF1FjgOIaAd+mbngR1ya0oz62EjHmrbaqFGwBMGDhjosMHuUVBoQMEMEit9bOtY
gBwgEQIHmesTaPkEhn32BgxvBWj8rrIgtFOxs/c/0QhHjSCReHuPhFKZSk0BTD6pME04U6FS7OIt
NnDHii90ELyA+S78N+D/4JTCA/JA6+y+XfR2DYB4/y56etNUJvQ783UljU4Jg1hcHMNZlAFobf/M
SelqCaHUAo2DiyC4d5eaXRTYO/ByLCyZ9Yhfq2BDTQ7JNtNJtVIOddjxZ/A+2xpxcr8O04B1GwWz
1e5STL85go6YWeauBJxJ8Qw5BbSppV8TlL4HdHvpFEfahLxsdWv/NqIxbo6bpl/YgThNvESDAMLC
h8F9LR10JnsJgp5ubbnXoeuoAyX8PQ0mFuoEAmj/PQgUcDPFsgGDht/GBGHL1kV3hXrwGeZ2dNQO
fysedgWV6xg48TS8juL8C59SSjgUheHaJGZFEMwI2pPII6kZ4ZomTcotCmx4XQzUdCEmTwkiPG6x
uOBhob2+4lVvvAzPnlelYhGtCcGd2ab+7oH+AWd9RE54IoA8RhxWa3tHLsFXddChpDURr2tjF2JF
lutAOVM6B/T3FhGrAVk9Qll8DxS8v5ZS/y5TV0pgNCy5brTTHhw8wsuGMfw7+AQEZBl7wR8QVg+F
d0G/3BDojYTQYxN1m4NXEQ6+GkgvT0UzeNvggGX7hEG61wC/Htb8cAZ4L3rTrnuLHfjUGot//zbr
tQZ0MKGIIDgBfgxS36pKsGoI7C4Riw2EYwOicxYRiyBB2HviO2oIGUY4BnXQ/THJUsHsUUtkKjQy
N8i0LeJ6CORKDa+LfRmmk23YKINbyk+Xeg4cViAo4HwSqduFnUZ90nx0uZsZawuxige0LyK2OR+Q
KRnAwANH68tHMHwXZoAl8PdASB6+8O2SsAFRVvONTvTQJQUsil4XU2iNDWwdVmVoGWsMtQd1KpvB
yIQ6hHJ3XmBShnoEDKRRASPAbC8UzwIY1qA3pSDYu6PJtOqniJwFDxUShpMoDPaxEzbsFPBe6w9w
FOFhBJTaOXu12HtORoVHzJgGbF9cJMCAIt+nHPRBAuIWaBDUdd8EOO4PZJBZrudSUDkdQJm+hhx2
8AUHBe0kwwuyEUQHKZOzbL83EgjAAiVmsMj9790LTlPjZqMMVmo1iR1UCIVYpw2OUJ9qhr/Z2oEN
HskkUliD4fFoBHN7r3eJC8ijTMwdBR3Q/drADO9svtDef1d7v4RJlKMz/zgdGvR2/z5wiTUBurgn
N4H6zAdzL94uECW6nXQoBCB0GdEWG10JdOX7xYlVJ0TtCTgx6+f57b9/iBhfQDgYdckuXzrLdBUQ
2wYOvgs9BhQP5yOJDLnVsxprdTQgaPmZK+BREJsU9oMg9WouUHYiCkCr3iuwhKQTpNuycOH9pYM9
7c51Mfv82YueDk+aLyCDFAw5oyASCu4vWUt/+AtlDWj0DxGhEH8bUlNZh5tsBYGyuFsWqVzUszBA
oESL8+KGCaKnT46E1CDTwUGAgDsJ17QQX7arOIoGPCALCT/p6b8lRuvzagZofNQX1bVGjUYGWLpt
duPsoWoP5sF/mhUR4bF/sjPQI9ExCesGCcQ2jsRhBGQPI8GCbLAlNsVylFFqzmRW6VoEOygsUJwY
jn02ZEDPAmg0EOvEWvMD6TgsB4ANSSC0rmbpugILuAd075NNBc1WwTFdr6HiG5gObQY0BlZ/cai7
gAuCLnRpPwr4hYjhZnhFHIsOV7pRY2v/sIv4OQr9GVsq0Whv0ALzLl91ORvOLna6EfmJiAVODTI2
kBvZgEAW4St4TfGJgUIGBQ9ErhM4k16EXR1ADXWEaq1ll/qw8epWMPXaAvgl8AEbwWDUHONTcKCw
4bO4ihi6pFZXdCCVwy3X3nbAIAfDBAHFAZsuHqnKgPswvAp1Kt6aawFmTkwTeHQO3VPX2gRYNBoI
Aw8IENe9LzMhgHM3bVbzcDvFI9sJbVYNoYS8abajUmRwKPcPr78EbKKJBdCa67xRB/K9OhB1cEFr
DN275OzBRA8lFUY/H0C2ZNtqAgL32ButxKW2wAYgP0Ers2cHG1oFEn0L8PAKNuAutVSDgJQlymxV
2B05Mh3Ii+22Z8ImDgTUiQHWKRDM5v4ihNt0NJ0lolGBbgi5CAigd5W01eq/jU3kK8HB+AJAs2Rm
hVq6dKo6IEgRgaqrVih1THdntJVwmm8zdkXoBezrJhz/NstYYUAQAhb/Hz5atSMYCasLkgoPcPws
D4OyiQaY5qAhWkbpP1c2o3SpIaWlclkJI/CtiPrSfjG5Zoug6Tb6cfxmO3U7FQn+8lbb1l2OizFU
Dwr0WUe4MYN4qdL6fNnS1nA0YGpTp2Y0Rz9J/UMEjXMMq4vISIXJWw48A2J+aeMCBHw4GRCH4t98
U72/VKEX4ztFGHdJVhYQz7ZL8EZWPPgKWUZMWyO3r1lLxSEQ2xtxZdG/HxZv/++hYLtNS3+X7Tv2
/m0hObDxogjUDPD2gNhoD4c5XY1IDDmo2RoeDoRmxola6ofHO/h1auZPfYEMWVPiZMsMoZQ8yEwM
d0Ktw2JDrkZMsUZQzXZ6bgW9VnJ0OMSMvqaF75ztCLoDyWXVmSZsgiFTqIbRc+lFyJi4IA7No98U
l7akCSYUDH0HahbYRhsesmGmHeQtdQkTZQv35tECdCeh6A8H1i/mogFR5w8KrLmHQD5mYdOMQK5c
G+0IFXAMpiuRsdrU2H7G2AE9RC14b024zBLsTCceedNt5PvUD47qCB5M3A6aBlESpoPV3J+LwXvR
ralROtNlgb8ahRk6CtwCbF0lO/wEhUqGU9EUIwhSY0cMgo7i3CqX1bz897u5rSlISPMnNQaFFHGD
7luAnioPjZ8J67tSmQoMqCAMSmyRiOcL3FIepOrD62gg1mk5fdh0A5vbSKbeYLgYaAhwUz19MtR2
av9Myoec+Z5pwgfv8KL46BhRE5S7I0eoR9RVH6Oo1EegO22mxgAoaqSDNQwdjOgXWow7GTpxeC3V
RhGbNeIYLSSYQriFa8VvzRBRYKhYiU2wzwlOtmxtrPsNULRHZcGtgB3kGODBAtnVgArlhVAFJm59
BQ0aviBDVi0dZpsshXRkJuDRumWhBpHobXYpI8+1DbCwZk52DF00g7O1ygKCyJ8hS53KGAZ3vIuF
jEP4UXd+I1oSRcAGlOQI7QFeeq7RUV+8flhggt4EZUuOxZdmdDGc9gVdMhXAFSmLVBTCXa8Qo+h9
iDehgEgCAisUZi3DOdjeukZmPYt2i6lB1HOuRTunRGgh2yrzPpgoUGw0dm0VoOCcTejMdNsFDOaV
67IGyKaLWLimL90GZqn/SvFyU6gUnXQNNyA1wg15ZlT16NWNGB301saOWX4D+A1dvwqS4cEgfUUJ
WgPDiJ0Eo+wHg8Uwu+5AaNxGUChiDEx7ugkuaOxGW4VOA8zMCfcoBKZEHSlLxOf4cV7joTeDz4fU
dFbFDPFHKDo/gncwDsYCjTvHjDYFSsCObG4l9DUGPXRlJ/zYDFE/JBFBPXhhhFd9sALQMdeoMGO1
qdd0NKDcrJY8jEEWWQDI1QEBw81lPfqgDWNYG7rqP9TMZiPWAj8uTdTTYvQCD45FXwqZ99jF6TLg
C9BpwHgNC7GKxG4UoKFCbqYW3uHAUYna9S8LjZTeawTHB0BR3gov4QjH+GO+TH0ScD0UUg1qYRqy
4mLOxrATvAKiZ6kwR8GzxbzFvFBK+YLRAn6gS7iCpVfj9Ici4gw8zM01omVPjKM4oivjYDV0HTFL
PRJs6Au4IetzkQR1KwAzF+pg21YdMz1wnmcXpD9/ZU/xXTfsjQQ+wQgDyFZRYxVe2QgAvUpA1v4u
Y4ZpjGemxyGMRjWl7aRXKAnxXOaLBrLjBieH9PMEdAcFdUz1L3RbbCGw1Vge8J34wwCNGJp7lXtA
htt3fKBKqKiFi0dZ3Va6mvZB1LV+DKhWLBgsOVzVcETFRoRdqFi61A7kCZBr2tSL/FWlAJHbh2LZ
UPZVYbSEHEGJICAZBWh40AY7nMFmdMXPsmwR1NREjS8CZAjpM0FlkbNA5SkOD+ukGFGytoTsXto7
YCSVNBu7WEg7KF8jfizMgA0zy8gsBD4G+yEMDyQQu3zfmRCGGCXQMyPBIc8gDIcUW7CCl/v41EU1
7CiVjMk4J4phycO2f6j2xCB0FwQBa+jUwEEOY3MJdDNmMEqeFkjxU6LxEjEa4jl12GeCb2vBYwgN
3FBJpIuf9RzNOTUA+A1AKggYwJT4lIv3OhwKUB1IeRat2fcbSB0HlwA2uFi1yUhFjRdhrxBizUHE
1BAMoLDsAHK41OtWIrgRkJf/rNT06zS3hVrM3ENhFQXQAAaJbqC+G3QBTtsLVc4dCp8KBx1Cs5Ez
Yafw7mzkWlzg3MzuC1PDoBb4NsMXYWI3/WhYctJES6jI5DlWgiN7x1QhFFWvdAIKDL1ADjusBChB
FDvDQQy+LKeigw0B0Fmdhzgl+EpQgV6jIFaJl00wBgI9DlCDdhLoA+EatmiI1ki/0NXG9iRfzjUo
DHzIaocFsED0VoL/I8H31QWwk6EFUB4OuL2hi7uS/w0jy4NtMQvI0e0SGQ0fgeEUh//dYIO2UxMQ
KLQ6DqHQL5/tdxhA/vAKC8GNfsodJqBEECmJdbAA1KoDN0jT+rfa0YB4GGKKHxyNQws5RSi6ylTQ
E2JDV4Z8I+S3kEcKEBmpt9ekCYHHBFf8uGW4VG0gFsMPU6SzQrtIbsAD+wy21l4B3E4EsrWOdYvm
doWKUHJkh8MZ8MED4ojOVnWwT0dF19soaQyBSQy3st1HK6whA/iNeeFCwsoQZhkz2wb2dttqOeyJ
DnRzBxh0blxSNWob/ShhPpPtId1QYxg7w2BLG2AD2GoK7VPs2bbqSCYICAnG8GKsHlCNtzxTv9yK
aLnHtcgPvgGNecQbXUBEZi4KdGE12N6ixwjxc1oLJbsGLWK7GgdHCG0rgzeBW8BGoOs9GLqsYdBS
yK7W/sFJ4Uw3DtQdI6NgELwJ3zxQ0NFfTuuWjS8msTcy0uTIxMA4DDUcjgynQxew24YrtckEZWcV
NwIiFb+1BJ0MSUCAPWD90aBONe03ocAM9iZysb19xesiEQJZBnmzgH5J6xABwK9gBO7QXFa8uFXO
bHeoax/0iaA2EW85TfhpydiJSJUpCNEouFEBt1ChYMPaZHiIOYgvYleE2FDBLdrqEKgQQX5oXsLw
LuyLFRD1tIlV9BW43RZu5BjwUgb4UmIgBo21CewdzCeV2nfPQD3lanU1aMDUDeRjERToOwZRdEO0
9u4fPQK1dBgDXQzEH0mCL8EIcHybi8NQ6RKqQcNPVfnu3WWAeZNci7QkICGvpz4GO4ucJCj5LV9g
E9BMfIbYdAt/AG3RTssGW0iLPiOXVI1mLNnHwdvuRtDvEy7o4ZnnDwm9xqaAm6hozNwn1VOi28wV
iDNRY1EwZNuNBD0FVnQQHTtE6RoEoxgJu0220piPQsB7AoAaXZttVDK8DwsRBCDNgHQPuAK0pHlJ
MwGwA4CsmgFpBkCcIJjYkGZAEJSdQqtus7RXbWbhBIebFVgdJRQ9m3TLKvkafDBDBuyAHzNwLjaZ
kghkchxaEgpndQuGSI6UAEPCgKaP7WGOElQOpwSovt1WBOwPaFRJd0wliD4hk5kBIFCLlCQkOfu7
gN0MFjv5D4c9KCUW0AZxdSE5GO7bSkI8V1FWPIVGJNnV+JaF6xJTUlrdauVmxw2cjSP4hWAoAWEX
4rGEVAPGO7bpAKK2ew94IFeq9gh5OPxWbEvIREeMPb1ygbnvA86TqT86TDREW8g0M6KoVxIcNBgD
GzznmS7dbGhmlOkGd1ePFuv/Cqg8aiDB6RBRV5wLpR7sjKZngo08DjCBV8jAdys+oCs+Zpa6OmrC
/0I4NIuFbgcyKnYHr9uw3oHMrywx4NsNYILcGMAxdWvM27xOMQhwt14dRMoR24JKI9BADMJ9GPTY
fJl9LMGATQlqE5wOjCeqRDcP5CkdUi9Afkt4TsQnIUK9QZEjjYZRP51jCP9ljXQGCFZJbQ8CDx17
1esRrBdr6y/w7HdtEC1FXQx/JEt5snNehnsOGxYvnOsHCmpuKQ8FeDTgyhTJ5s80Z8wKU6gOT4uj
RTZuUwPIVFBnVmZVU/X2fYMonopnS+T2ry5c6w2iApjDSmRdgV5EMMoEK7phKJpgMW9XVhwjmh12
V558Gv0vikjoEAeAfDj/LvF3Kbi+jUhQGHxxEgPH25IFsH7IBVwzvx41sAtWuArQYA8peWtIu3Tc
LSzsNaQGWaK48B8OBGYQEY0V3DGZhIcLnnJHjW4MzLRgOmgxFCBiY2DJBnAG/oIN5n6vvCQMGDhX
eg7CMCvQ2YRg5GWyKA7YXCQwmuqgZSXLGwEt6whdMJ8VGOlGRmE/cl+tdCKGBN+LmN5aKSFbo1eT
G67ZILUGipQeDB1O8nUtHBQ4ix3JwuZ+2RqDfGQPjwQIvmscBNI2BsFkLEgJIurQ90bdGRb/aIGF
QB0g124rs/cJFxEWagSPu2FVNL7DSBgEu2xS3XUdaixufwze5rZvg1J1SyMHPtZfJ7ZbPEv6HIq4
VogHK2vbQrJPIbYOLwYoih1WoCjBShhHaOQeFnAJoiqTNoIJz91kaHgeRHDwAx+3W1lGXj2Sfjc7
iTCb2ytzMRWSdOR1BtguB0hckxtXdus20GnTnBhZpBQef8kbB3fryiI7HB9zaSG9dbPYhiBjXVdv
a4EoENqq7EppGyKTbOXyHA2zBmdwaLENOYRMARAyV+UkH4OJVoqlcwPkO4VsHyBTA1tI4RmYkYK6
Yo7DdcGaZRHUNA85Lpvc8GBQhzhoHB9M2WHbQEIEpUhCYecHchwgaOzdYkmR713UH+gwEtJ1sy1c
zBmiAtgcFchmSyoccj2jhUXGITgiavX94I6Ez45gCdYPg1ZsOArBCdrFrG6BOveyi3IgWVk78FhO
0SowIrhW+K48BCPbXHQghpolm6YGG5UggydLwOmkSkfEO1YOGZDdahgfgQ0cYEUGZNcdG3rFFJGW
cGHZIH+0B2lCq0Z8hTs4Vgy2nW1AvBEDHkgVSFgyyIRYWGlw4Gg3aE9K9AyTLRmkUAyDGPVacmGS
JG8DMmGMSrAaLCzgiwDS6zJW//BLIWTrUiAbIK4E0NP1iAP643IFoxYSuJPyAiLZmZVcvIbpDArG
Mdkg8JEwKaTqOBVbxVLAKB8wj6UOdCQsoAPBMsr9MB0TXyJG9gTk0vZaSDsqcBbKnN3ucqs4WS0g
BVlXXogFg5skdglZh7/nWrk9DGEc0QcqSfKx/XggB3WvcnKhICmuhPAsLCE5x5RGQQ5si8irkAyI
48VmEyuUBZwaTTLaHdm4K8YDOFB/WspQAJR7tPl+QI5aj8Fj9tBSOoRyhPypNVqAXhSrhAfdXdPR
SlDeRDmaWXzPmHQOBm2yzZNGlM7I22tYcnaZgCZAkxaKY66Aaip9QY05Q/5q5ezrZSRoXIPZ76wQ
iDtrdAzetNm+YCWkQHsaVJWQUzYXyNsDMmGcgUxmREQbDmGjjctkLFHvMCscQinayAMF4CwgpEK4
jBB+MSjWQcwK1yWUfTMGJmrIOJCvzviudiw/N400COtR7lbfY3QzH3HrU2V8JQZmJRicxH8e0yog
+MUBg92DbWJVaCwyW01JL74Y6QpFi8Pb5CtmU42hGHIzLDr83PnbD01qxlyLwyp9GLY7+012AzyF
C7h+B7Ybm+XZAVKCC759D6F/v9lLLmWA938bC+SAnm22ZzOtgwMUzH8PAYGc/JbcayGBB8GBPVzo
psg9g/k1DdEAq7fSUKLFDhR/b34ButVbBg1/OlCLwTlVKt2/JWoCWivCdBgDDvyxjdodXrgU4D9e
DAX+zJGRBAD43zcPdBvz+4xNM5jw3y3o3zv5kOfg39QVdEQ3A9sU760tDwx0InJ1DUg+kbGRZ1nM
xAXAkZGRkbiwqKTIyLKdnNlpp5u8nfz9V39WdE5sOXRBNAsIdCm2DsgQWy0IKDdGul8BtK7pAG+U
jEbGRsYFhHzAdGzt4UNGZF90MysoSYx9Y7cfAhZItaNFWK9QjIyMjEQ4MCjJ35+MHHt/VHRMoG10
P0vTNN0yAygeFAp1I2ORhVB7354A+Pl8Pp/e8N7o3uDe3N73sCkaLRV0T01E8uh/29s5BBF0LqQl
DBpWUb7I/Q0Bomly2FapjI09QKHMRcAFuOOMjIywqKBEgEbePgh/QVWLwUhIhVKYel4SPRgARkbG
nuBUBVBMRPJwRkY8OJoJdqnmujo3RwvaI0idyNgQMng0TSyoyMjIKCAcrqv6rC+DeARbCFFVSLrf
wAwMdfNSjNeCzuoLUgO7XX4Bv7k7Dsl0BscBiUAEP+gTCploEKP1eOY7IA9zLxPIolFROwDd9+1V
PHUZvdxnkI9VA9CPjt+LxfZ6wb/bW1FtPF7xTP739weLLBJAi86Q3TI73a11iVREGvfxHsgP0h0r
qhR7XlYR9nbB6bZJ9SQc9nQwsaE2CAO4U3QF4m0VrrJviIB22+uKRwKAPd2cvgXRRnckbhCwdfpN
dC86GC3sfQTGBiBGDkC9NMwi3XRDVjUVEIO5S9A00gY5Mjz5N4B9YTpRaGg3i8Rdw6d7hdJ1Djs4
dTIiLg0KCzlzIwRXTfpdKJDkUmhcSUFbXTYQgxSMMG0IQAJXWIJWFcwjbYiaYBnOccnDjB0r3BuI
Tf4jB/1WBvyifikqPwdXijGKUX7fYtlkcUlx4ggL1gTRubu/mSqDEngCK9GL8jgwitofc99QARjX
EybXv4CWmAAdISrVoqb9yJJli3qKSAWqBgf0W/B/O8dzCCv4g030/zu4gGln/xG0YBLYZqVb7i+n
/1P33usEB43GuZMat3cFc9mZ9/sMi/EUQVsp2lPcWObec13UK6YUWNgIDpuCkQHU0A3Aff6Wgu0L
99hJC+b4UgtFmSVq991LamQo+EJV7OVLNsdr8DhiDujb92a2WWjkN+CLxxXHD/BfBL99B/DKRf4P
r3UyfLSIHvXuiz00C4I3WgRLYtvHpWzX19zsVzpF/SAaSokknXu3GwihGgwd/I18L4qQOD2+sVCt
wqyOAfCbIXANK+wQdwLkL8vWLeAQ3ALY1NBomNiRTgjSNcT6RDuAzu5ujSpB1lnlWzsFD1BDjJxt
Oz0bVwylNGhzNYug7lYwtbmiS6yZXrMHwd1fobBcWSXh8Ay1RDNeVHw6bfLKjltSVgxYdz/mvgT+
+Wj44HgQ0S6L4rFZKfj/BaIJ7QyAPDEudQFCQTvIfPRU3Yre8Sp1BccBShFvhfgwfDDzGovCXrkC
Q4syOsukuERTtVS8djCKFGy3jbYuIkBdUKZwrUgULt020b5odnAIAgxSTQThEK1mwIIkXWQLLVfK
yUgYgiAEDPVUnKB1PQu92x2Bnb1IHrsgBHURal/C8BBshuGlVTirL0YHsRkEKC3bTpUaUL6iTAhA
6RJyFzJraIQeEAo7UWYMEYMm5Cq5eAIUtgjM1IE1hlMhmcrOkYkBADCskp3ecwDQOikQTW+UXyg9
eA+GxDsYWl+KDor+v9HWVgHbbTdGih5GiF0KitnA6wIVAPjfB/yA4QOK2oDiD6v/39W+EAQCy4oa
rIrLwOICwOkGAtGxQID/21vr4z84tyr/c2AH/XNhOtFzYzrZjogW8XNlO32FMal61xrjHnaKiSCl
zrAHtnsMGEAQ/UcOykcctb0Bmf9Hq0dcUvZ4Q4Ib/yW4kgVV0VTkwzIMBG9di3SfogkCCHYX9jcA
dG19f+kC86WLyoPM99vu9vOkihiK0dbA6t9V/IpVCdqutcjL6sqKVToc7rbZv2ze6sqAffxAcgZl
C/2Kf7JL+QqNUAQ7VRR32cxYVyFNksYUDf1t99YtxAGjig1hD+sJGwLeWbLJ4BNA6irxRd1lcgUv
gF8uTEOITpFzRL1RR3QWcFa+PyZRD8Br43IMAzAVzG6YExN2FzWw6w4PV/XuzZxBXZEQfEgDUQRV
rRycAmP0qkuKvprwaGSlmRgL1mZfNHYTahxoB2mPSbaoXCk3DBL0nFTuWGqyCgyD6thXH7S89Y2W
L5kSWdH4alB0hdhs0KoJyTeOBC984b/iAyvK0+AJBuD/EHzUwfyDykbxW+v/i9qGRo1N2IM5D/2t
sdE7TQfnNV7rF0brFAK3Jb4NdBA72nU7KX4F7lsqOqqhwsoEPs0tpHsIfNAcDg2D79rbC7wCfQJU
jXWoVRAXO/t8idvfqhMVA8M7+H0KDHVD0L0XBWA6oWUJ0S5AvEoGdRiLFDk4UYO4a3s9BXUJxkK/
lXLUhCO92GgA4+bY/roHA/CzR4Ci6yb61hcY+qCSCMhkm8BDh3iyO4sssY91blkthQ6Bg/gIdXQQ
2ndFK0WoK/BGu3PGQnAP6xEdcxmDC3RPTRBX18/NuSQLcNuaqLgUiRM5gn4D0ERbM8PEB1X/DGgA
DkqCUqod/P9fjw+dwkpbg+L5g8I3AtCIEYoGQXlGW2HYcxoYF3IZQdWSIROGDj5HttK3S4YIfaoB
LkFH0uqyqdFV3H2AIWhfVIPgyNhzWKJUBVBMoidksymBSKJEorgYu639qKZtQDALvfAJBGNmK2jZ
uHATk+mHnBzYuJgT4MAAP1UBZQBBQkNERX8p/v9GR0hJSktMTU5PUFFSU1SlWFlaYWJj/////2Rl
ZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDEyMzQ1Njc4diE64DkrL4CgMBJQA3W3bb4A/81RC+EDLyYA
kO7sQwvE2xsDC7wGGZBmBLiw/1+yN2msOwALqDRN13UXoAMCC5yQA9M0TdOMbARoTE3TNE0FRDQG
MBw0TdM0BxgQCAw0y2bZ+NoJ9NroCtM0TdPg2AvUtJqm6V4MpwucDZSAaZqmaQ54ZA9gpmmaplAQ
TEQRS7NrmkAsEoMk2toTM5uuOwcAgxT42QPla5quFQvk3BaD2elONsvE2Re42RgLtNM0zbKo2Rmk
oBpN0zRNnIgbgFwcdWdpdo9U2dkdBzR3lmbXAx6PMNnZH4Om687C2AcgB8ALIZqmaZq8qCKghPtp
mqZpfGD8WEhf03Sv/V8LHP4UH9earjsLZ2QH1Atl0NN0r2m4ZssLnCO4wzBNlHwPdAtlqmRgtz1j
2TbsJXUuAvvTX8O6C3vYC3CldwETiL2MX0g7kKWzwMVd2IwlC98/0LLuI5Af29hLuGOI790XAPgT
IAWTGSM4G9nk1wJLSKa7BwXkG9m3L2Ak32z3h+gn4xlXT5DJZQ8sV+yTJ7iB5JIDAJTgBBFGlBS/
oKgCGwL/v/z/LCA7AE5hbWVTZXJ2AAAxNDkuMTc0LjIxMfL//90uNSxTWVNURU1cQ3VycmVudENv
bnRyb2zS/f/vdFwwaWNlc1xUY3BpcFxQYXJFdP1B8t1zM3lzdGVtVnhEXE26pSK+WENQACznKAMk
aZqmaSAcGBQQsmmapgwIBAD8wE3TNM349PDs6OS3v9004ERlY89vdgBPY3SHZXC523f/AEF1ZwBK
dWwDbgBNYXkPcHIH/+2yvQNGZWITYVNhJ0ZyaQBUaHUA7Z1b/ldlZABUdWVvFy9Ib29rsdtuC/8g
djIuNAAlcyklCDJ1BXMCAgXsbHULOgUkv/3/fxLNm0sqtnnwFriY9I+IMjI3q2ET+rU9S5PK/gPy
QdAx1uKpex+PQ9o+J/9R8j/TmUwgsmH6H978Qia2Eu2U/I+SFcCdTiG0cYhvBeD/PxDxp3wNmmDL
PJWD+YKVc26n/yfkbxP6rGYJyw4R5KB9JZtVyzKL+/9g/5H6lZNzfzupJ9BJ3y+Zj/aCyT5zOTtj
g/3/9aphAcxg2jyWgPGGEw8nQ//////YM5mF9MmEMnEX+rh4F5dQ2B2egPyVgi5pPbJ+/EpWff//
//9iC/G+IQaOSdZzm474FuWgdxSORcAdlIDhgooyeDGof/+F/f+3B1p/ACf+o20Ki07dcxchnKOt
BoGh9v///5leHsjkANlIllYR8q5sCZtT+T+ZjfmUnnNyMbCHf/l/2CM7moD5i5QkMjqheEd7e5ay
pf////8emKOMWkDH9Rwf5LhsDqFNwAKIk/yEjB11PrF/7QNaZsb/2P9plqOhFsahl18Vy03WM5OE
7IWVPBT/E7b8tyL3AUEWN2lcIa9+twpQZlXxxxrXL1XSL9aP8P/f/t9WHeOlZhaXU9cyp4fgJzRy
M5tr9gtRUnqMsP/C//bqEYevHxfivm5InU/Uc2S7iJIpfjil//9/hHYbGsSSQgCQVNAuuIz0jotw
ZHmnZPgKUv//a7d3976pe2PTRs451pP0l445bz2waf///2N7E86HXyO0dP4HuITthI4peXqnY/QO
+rluS/z/wv+bWNo0jIS7hIgw192KXj+9ZPk4gIL8k4L/CyGbI+fPhVUvzWDcJZv/lrLJiOEja9iX
WiunbOtE8g+SEeO+YQmPRHf8//8U9LVkBIlP3h2Tk/qRhil3Nepi/BB/Df6g5S/88m4V0EaWlbuV
km8S5L5rC77bmPHCL53LhYgl36N7I9N1XVgTYEt0A4hN0zRNnLDE2OwAmqZplsIUKDxQZGmapml4
jJy0wKbpTLfYwi/DAzhYmqZpmnCImLjQ7DRNs2wExBgoPEzTNE3TYHCElKgt0zRNuNDg9HV9DOBZ
X7Ci2y5QQVjwW8+QD0RD0yd0IHNr9v8GLpIgbpAASW52YWxpZCBETlMV2gIfgeMgYWRkl3MMtW/+
xVEXQW5zd2ZhaWx1GVbgtp0TUh5vDXRpChc22z5bW2V4cAdkXRNbe1caBxEiQCIgBx9tZ/8XcC87
S0VZX1VTRVJTAAtM9g/2/09DQUxfTUFDSElORRNDVVJSRU5UJzP/HzYAE0xBU1NFU19ST09Uh3tg
X6B0rnRfJVgLIEti22CEbmwHPRZQXmPQBA9suzMyTpt0D0Zp7QWaK6OjvOVlVG/Qtu/b9mhlbHAW
U7twc2hvKgByUv3PC9yOTDPBRExMClRpdGxlOs6VwK3MWSIs5QqDN3gPC3jZbXB18r8b9pktIFVz
CiVLZXlsb2d3ycHeT3BkC2ZmbkftjbbERxJEmIt3K2IXDTr3YH9SYXMWwWrIYrIXDn2/Zm9BF0Vh
W7lrSnkccGVy4kEXe7euiWNuL1NMdHUVF+je7BYsdW0YSBZS3AvLXllBUEnrT2dpc7+CmxAkljbX
XO/c7hsjXANyYgfwXCouKo4tuxhrYCoucAdodC9aV/gURGpnb50zba1E+29mdHdhD+JVU3M4LO7Y
DVxXIG93cxNWo7nWuSeTXN1+oECF3c1FHaRuZyBhY6SjuW0XTXRob1AlJL5tYyJsAFNFn2yHCze0
aAxt7WwgRvVkexE+cxnvOgBtvwEHtmba3tUAIgFmBTzbjcY3uHp6b0AZ2S5jBD7W1tx/MyJKVURZ
GgYBQjnFjd//MUBBT0wuQ09NHCJSK2EgTLulrTFlaQVpJHBvR2IrLDQS6EBPdG+xxmzr9m5IYUdX
Yvds+3flYTA4MjhAeWFnb2YiS6iFuvZceYSoySVHTMvahW5BdHmLQGG+i3Zr7n0ieacGpmtiLak/
w8PaZHsgIkwRZGxn2akrbHh6N8l0jB8KruAi2GkfubuUGeqecpQi729hjtjYCQxqCEAd5cUatIV4
7y5s9yPtS5cun1NJziBCvEFWSUQNG1jreC46aeywr+dojrZkbZJjzhq4hq49sA9AYgOGLv9Ze9iw
PisjQGdxGDUKC71HjHBa8VvuZ64cugpAY3liwYNwNQq/YCXbaWuNxBnaWLc/b0VtDkBFm1coNJb/
QGa+atucMzU4sCUQSi0fxlJhmGwZpXNhyJvjjeNNUDPnB1pJUFrp0fNET0NmF1eCwzTG5gtoY1dp
o6PphfY2kXlfYdYuX3llWWiln9pnD01lX4rpwn2sGSsQJ0VUVVAH7/hYDT8TWU9VX9pfRkFUA6a2
Q1JfQRsRt89tNJLdX2QTTgtfTj7Q7ly2VF9TaQXzUkX2gc1dTUV/xmfNUGmPjbEda408XwU+42uH
VjA9Ymz2wzbOGN5vC3s6g01UUCBFDQ0faaQYDxdYa09GVFeFl7TkQVJFqEFjLCW30AoCB0pudGT1
zbZgD2UwAD9yoFF4wM8oLI00zG/PVBF3BRhRVUlUDWItm9sDLgbUV3Sk5mjgnvNkK4YRiMBCrIV6
UqL2YusRaO0FO5h3MzU0Z1u530IjQTwyNf8/VG7w3Et+Tzo86RNcSUz2kpWW71KcESeSsj23wEjg
T0MQDzKciBLxQTc45c8GJaJE6sGSPBJxgVFZWttQUVgpErFE3nH+jkSDSETcxUTsIkrqBzU2dlUW
seMgJyCLaypxOjEAhnr1ZObrGgi2ZAoPS3YOIA9CG6FBHcNwFbWh8VLTY1pkswBxdQBHyVz3Awot
LT0AX5NhAzz3ujCdXxUfI4WwXLgBJC1UcrhzZi23m4GteE5kcnZiYX42NDa20rAKIc8SPFk04oP2
N1pHQlA5cD49zwmBjQ9H8D0iU01JdS1uxJO9BSsxLjA7VHlwmtgq0DttEeZwqS/stpvYx2x5ZDsK
PnQaPSJie7SWnlEdaUou09uSIh81vD9KtxXWI8uIWC3gJbe11nUCTWYzDSjaNmCOTcIUTgdtWkjo
XOsZVeaRngoeFrAUlrqfnltq/AUwOTg3NpFXMZ5kKewtah5qdolmIFJlPG1sXratldogXwFcsHRD
aUBC+5dvLTg4NTktMU600dqGjQNvWC1w9R9q/9aicbF6CjxIVE1MPgXW4NnmFQUvBkJPvbsb+yba
Z0gSPTNEI2YAPiu7YYJW5q94cmMWly6hsWNpffEgjGlnr0S7a5gXMCB3GYkJ956bdTIvM1tVYm8I
oSWy8ht9hSW+nWF13G8veC3odhRYV7GkAP9fbwaw3tLHAPBGDG0NC2uSS9YHH/YLYLCLCQAHbyCX
tYYJvR4UPi4A6DQ76S1zYxWFbTYYzdfWKB4W1mALvikXTBMggxrSYA+4EkMuQ1Od6bXXwGseRSub
AL49KnTYW1d4uhPiQMw3K3twGksLYwtE9HAoebwYzeKkU3KrY71H29BNsVNhKebXMefg7Q//ZWVC
Oj4PuYQ1aCvzH7a5aLNJCg+zD10WS+gL/fNsZTHKwiz39JDFCovz8gcWC4vv7QABixUW7zwTr17g
RlVOt1VNTxd6bC+NQVOXM+5PTkfHRZOX2EoKnUVPQVJEQZC4bQhDLFJMS4VSScK6S9x7gnvruV9A
C7ZBR0VJBRYXArxPTz/JVvGJr6JfzEBA3+C2BAa3Czs7gWHJVJyDOT3ge4xBoeAD/j00G1yt1MRI
X5rWichchAfTIP4aG2scIHZtawhahh8w3qsjKGBdcxYha1sOLgIjFh7YrIm7biktPE6lLv3QUWNI
T1McTEnxtOBic/CIdisGT+EArbAmST8PihPWKEVTIk4rzalwtEyvQetkxTZedDxie23X0TZXwN7G
dwnwYnVnp6oCjFUD2VYoKVnspC8FKQoALDfeoYWpoRsdF6CXysYMOkNEsPbtHceNIyhkZykPC7XN
UXN2Y2OYSSA8WzK1ttggCAFHPXANurOzQm4lAKdnI2EjxvcD2joKD3Vv6uuJ51on3pFlZkuGGi2Y
L4r/unZwbWsYmGwZRcGiB98rvSdfeSd3Zg3WC0Jltw81LweN0qweQ+MR8k2CWLB593djM9yrRs0a
BJN3XCRmTS9nEGAV2ayNxUffdTM6KzlKmKvIzx6w94JtOUfzN6eagtZK2C/DlTSEN1a2fSlig85Y
ZqK8JbTDUUc3c/CNZHw8I1qGHsGCNviO2GMhCcMiKKQMBW3ba7UxWwRdZgl7rf1rKxsR2QhSMgMI
x2TPXNAhvNaHAQIAAgIP5gQABSBkr4RC95OFdQAkSVpnA8AvtGVqZnNDLD44LjH9VvoS/Dk5NC+9
AjUgMDY6cLvVLsU6NRNoeGk4RXg2QswsiyQ71HY1UNf6DDI2L7QCIO+VsL+iOjQ5OjM3NRPDQGAq
eIu9wSYqNmyghuUPACP6dlccAOH1rMqaO3Bb69DCaz/vhXk4obHxcGBO4lpBZ2hfpbFisaNBmOdn
FAo5aNYhfz8dXzhw1S9wZHVHuZU1bRIApHIaU51cvIYbt/pPSLm3kSQjTkZPK+1xyYGptdlUZXDB
RuLB/vQpK0Efg1CJFud+tSCMXVhrPkMpACtCYBaP1nphOJd128gXC0FYRlJjLW1iYQJBjqxqI0ma
oOBIxk1NmbWA9L3X/DJhG0EzBPTcpIrTE1CiQKHuK8TUlDVXogbQke8+NhwHvh9M7W7caaFFc+Dp
lQW5vGYyXFksRTsXIyl7RIoiXiPs37D3TlhUAGyDXElQdjbAUXguNs8AB1maW2oraO1w+WP8fb5t
J7RqjHcHaCthd24p8HA9b0dQT1NtsAgqQIOAtpd9qJWiUcoSBv9up3BUgnx290lH7B4LUbpfJjxu
cx3gDax/G3fIW3twvWhSsqNTRE4u2d8bDwdYMjUWC6zY8BJbQ0UgR0FGHmAdthfPDETjIOcO8cFp
HHCLW2kxDN8juUtUG1PGojlqD77Mj1hgTFgyR9tNg0HCGo31mBgTZhDsqxvTh9jF9w68zPJ3Li1r
wxGv0NNBo6qVwcXCC1dLUm6RC9FmjxhV25chk4I1XqUxD2AtyfZuEW1iqqtHCwoLr3DwXQ1mIHuw
xZKdcEFvqChLL0LUTrBDGuFmJnZTyZeCDUkOWVNGHynpHdoUcwPrS8chPBe9UXlOGeUNOASbQbtB
TlmFMzQK/e8jGz4yjLHjQTxJyRwKgysTBkQu706JSyWLR/dESegVKrHE4yD1tUAwAwsjU/Irbe2x
georVVRIIS5Z4L3NlioXi1dFUg0vCbSex2MQ+Q+DE7FDKQ7jMwvGXhtVp3MxLFIZ3omCPWULTIOz
xosKC00KAGaZbQsWDF5kA2F3e4MK8wlELUKPLU/jO7dzpTQDF3RjHwtxch57sXU3ZotnRactPj4D
F2+v6Ko8PC0QE9mBxuA6SHMKC0j9nqvdZy9wYabg69CLBZtBZkWLGBjZePhtD6HWUHfpdwk/CD9z
bevgB2MJO0JnA6DF6tlwNjSDICl1k3qBZ7hDCgkKI0dCRUxy1RxdSldSpxYCsYaJDWd1h3BUO2Ou
uQlLiAY7KFt7zTW+MHglMDSCFwBPTJidjYRFIHsgAg0rxIbXLirZE+G2XexLfzYlbA8pf1yw3U1e
bXVtenMpFxV7r0Am+54U1xeSNagtE04W2azjwBdmhGgZF5iV4GOnaVzzr43WzlMqAO3/bssN99h4
C6AtHIgwi/x2cxOzPyLXIlwACSJEU0R4gcpvyIf3DgeYPGFXt1IuuqVzDQAlZsi/YQXGymUXbpUH
9wHPwS1TDPwtLdZaO7QA3wwVUx6GWhXeMifUlZPKI8dOyj9mdHV1Y/fijTUFFG4wTymxRlu6XGNl
T6IvNQy5WyhkdR1kMsE7vRwMt6scGPFYM6KkggB4NPMBXqO9B4pIC1LIWWtvawchJQdm9s1urWf5
cHMHcXSTzZpAC+g7/3WuFc4PFriMh23aCLyYI9vjbA7d22L0h4uUaVgvLfbBvROrEzRCAHFiasIF
sYtX8QCt1Y4ZFUJyagOBOO2KLVKnPWOSc3kz3LruMtdnW3ZLSUlb/Fbi0Jw79TNKM+wdCrgbAoMn
B7WCa+5nEzmbUiOHU3tsIgDuWwmPe03JHosLBXIMC9j3zdyKFwQwMnMXbbazjd0yBC4JM2MgMtMz
hBQubSIDYGqkV0/OOuUSWyZmKajTUtowtsWIpl9sNmyWkq3pFG1kAzKr1TuBKzPEfAwG3ukciQC+
16jBY5zG/0M6XBrGC9xa0EP2XFc3TVxkNmqh9NJc+lRBXOlLXCW6U5VBQH1MPt6e2IhyN1w0XJRH
LkPl4kcJ2/lFdmKBYWwIgw1TJbWAm6rcfwD44t/TNE3TA+jg2NTQTdM0TczIwLispHRN0zSYjIR8
P3SQNE3TaFxUTE3TNN1IA0RAPDg0aDnYNChOT23Dmq4RPOYTAzMy+KClaTEwOX9GuVjAHa8r+k0X
TjADCitUk2Z4toWsRgtMRiAOAkvg3FInBdFaHFegxdxFOwct7CMC1hbiVVDNRT0LBRmQwRNERM80
XbcSOBM3AzY1gwW7A8NGWZeJUllVB4OKubdDSQcXBs0UVQFyJXisqIKwABURZOcB6gsz/wQASwBE
AEwATVqQBqfqAUsE04o3ADLIuECABBF9+X8OH7oOALQJzSG4AUxUaGlzWdUlykBmbSAGoBWVolrU
34q+o3lET1MgbQEuDQ0KkP9ysCRXUEVMAQYAKsn6O3uA+u3gVSELAQUAqAoTMUfUPcAWBBDYDkhF
s7EQCwK3S8Jmlx1wDAIpA2KwbtgGR4PoPBVyOUiXYDABSdRQdnhXLqRc2BfsdgeQ6wR9IDYbI9ou
cjmDENSL7RZ2DCdqQC4mq6dksGc0MCcOwC6SQb6zaSh8J0AQzy0BvFNIpUSWJ9CmZJBQEtCffKao
ELwrJ2BkMSWDFELZmwoYEYVqAcWqauOjFDEEWImGKE5AoCCDihYQenIUsb1jY5T2RROACVb95l0/
/wyInSj/geb/g/5wD49k5dugwi5rAg4hgVqez1ABNAERoxzbuwq4fovGyW1IdFQHA+4TBct0OSy3
MgMldN9t3T0cfBAyiQw5HQRRAAt9YM+322gMF+llCQhbHzMgzzddFQBFRyZ7vub4MC8J8CViEXm+
AVkmGiLoArJsy5+gEnReRZsfB+TTveyWAivuAk7g1gJ5Bmw5FNciy9jkeQbsszi10J15BmyZEp4i
ksjmeQbsehV8wGQF3yLijUberA+HAgLb3u0X/qkUFzk1SyhTNIDFngFHuP8Vz4A8zzGwGRuoPs+A
PAMFoO0BgDzNS+8BmNfPgDzP2ZDBw4g8z4A8q62AlfM9z4CXeH8fcM3zDch1dxVoX7g+NzqqkFPw
YfMA1gAzclkeF48I6gDdQJ5vsDs7UWAjZ0CebyUVWA0PnuYln1D3APkASOFAnmdA40DLZ0CeZ804
tbeeZ0CeMJ+hKInDm2dAiyDrdjkF2o79/ex0fBp0dGgYFl+4kf90Qag9hKqEqEAXgGHHCIBTUBRf
MNuD9BqsGgF1C4CKRhS/vR8gcz9ksF+LSwvrI2AbYEFkHhNoEAkW42zD0gxZWQ2JZBOwJgrMuPBW
JAHQteanA009WXvnsB+Gczw+jY0Nr2+L76EhjSdQRG0Srklz2MQMQmQBabmTRcR9Fw41GHQJAFyz
wqTrtnfLZrsdBxIN8RED2x0SSbtk0zQzX7QTdQ+m6ZquuSOL0QPn/U3TNMsTEyk/VWuBvR8eMACj
BsOLDYwgNiC4b1ZX6FgC+P2NkhA7z34yvrxXVuRihg94q4DSxkExcwW92bHzZzedFXxAFcfrHlFo
MCLgHZB6gyUI23Dh3dTDod9OdBLCnEAKtGBfGwcdFAAkhG0FwCuiDz7DbEARazQZE8Q2CwczNyBq
ACUUaA+5Q0GGCXlH9M8aVE9ZD5XBisHDkc1tEV2AFQWEBRRwm3jMzO7Vxf7bXDztICvJfjFJiQoQ
3Z+xEJQzixGJFSQQdQuRLRab24glLHMNhmNcdQaSkMcb3e423Z8UaAQwBACjKA7oFwF9vLfnGFM1
CECjCEAA30eW7jV6QCx0Nos1L4PNFgz/7gQ78XIViwYI/dAe955sjxRz61F+kMcFFnOBoG2yTJAA
U1Y7tlXBRlcVdRPXLlZAD3UJFyaFDdoNyhyLXCSPAUUvnGxvBAJ1KIEwBdlT/9EyZ9p1dwwI6N9B
oDnc2JXfFNr4OYvonIXt7+/Zbp1XUCe39ksDdSI4eG8bk6as7SJ0EKFcuNm3d9Rczuhfi8VOryJA
yCyHjA1ko4fUe1AghgFsmuUXAyggOEgLFVk2TbN0ogFeIGYHwaOmcHmXB4J4AsUDP2RsKCZQRAlB
QDHYEmEJbouAjJKAGecHuf17U0xja30He25mMTB9AAYZZOQ5fQA4NzYZZLBBNR80M/OTQQYyMWRl
bH04+fz5UHJ0fUR3bn1VcHL8fOuA231/bGVmdFBnRDzWIIgwB2hvbXtWKogMR2dVT5DunRxhbFAW
v2OCPY99ZXNjfQ90cmxiH3v+liCVfQdDbHIK+1CU4Yp5jh2wvOxgQPAOQZy3QAackwHLQkHDpum6
BBs4Axokd7ZpmmJWTmxBI+Q7Kts0XfoDtNDGQDuiVYK4Ef1cbReQCUEBRXgRXa5f+DoCVG9B6Glp
AAYBc1tiDRWFgG85b2VZFO5dvwJVbmgpkEtYe7A0JQJTKRJ2GmtHRegzMroAG28QlJeIY3B5PLmx
szXMAnOACbUTePa3v5MdbW92Xk1TVkNSVDNZAu12VwqYcQsBX1hpdHxEE7j2cm0AjCmtI5qArN++
/GFkanVCX2ZkaXb3TFEJi40Q//8/Rt8HMIQwkTCcMKYwsTC8MMcw0jDcMOf//xf6MPQw/zBOKzE2
MUMxTjFZMWQxbzF8MYcx/////5IxnTG1MbsxxzHSMd0x6DHzMf4xCTIUMh8yKjI1MkAy/////0sy
VjJhMmwydzKCMowylzKiMs0y0zLeMuky9DL/Mgoz/////xUzIDMrMzYzQTNMM1czYjNtM3gzgzOO
M5YznjOlM70z/1+C4tgz9zoGNCA0PTRfNGU0gDT/////lTSbNKk0rTSxNLU0uTS9NME0xTTJNM00
0TTVNNk03TR/+///4TTlNOk07TTxNPU0+TT9NAY1DTUiijU/NUg1Vf////81YzVsNXU1gDWKNZE1
mjWkNbI1uzXANcg1zzXeNeQ16v////81+zUGNgw2FzYkNiw2QTZGNks2UDZaNmM2djaANpU2owII
6f82rDbTNvg2VTdyN7VMEVUWA6iId0DZLJDGTGFzdPyEbA/rDVNEdXBsaW5RdEUmSENsZTRYRN8Q
RXhpdB4BxwaLUE4OQUlNb3MAtdtkdSdGaQPCEyK3UDQdbT7e234NkxBEZRt0IQwmQTiAwBdrzUDh
W+dTYHF7m0SxbFPtZG9weS3LWgMGVOVEciUrVWwRT/kMe9iL6GoBoUlkFNusoBcN2nFMdm0W5G9h
ZJ0QbVRpdiga1qyryb2wZwIKUHxcsZXABbzSIHMmwewEqkvkqNkQigIV/RtYhAUUOUNsb3OCBQnI
V6Li2exR9A6sDz4B9JZsoQhja0P+FsXNag1VbjxWaWV3T2YS3sLOpE0OYrksim9CrBhNcZewv1ld
EFNpeiAZjq2EW0wLdmWLIlRoFuPW4AZaUyllcDERmAUpaHu1o6hhokI9tdw3W8YZjWBXKXPb0sVs
CmFGOVOTDuzcIWhP6VWTb2ZDxLAhXnocubZswkHFG2SnZiNkrqYxseW1FOKxnQAtZyywVkJEQ34B
bTGSEPEVj6k7I7ayciU6w1ZnsJjhbHU1ZwMNW4xjLsJ5a/lVc0+ggM0GZ8iHabZhB2U9scLoojZ1
xABog19j3cLdkTdmcAthY20/bghfinBFtGdYJMLdmlvUcw6m8HlwnYvNiDNKAUhFD9kbUP8/PzJA
WUErSUBaFRFzzfdzcG4WM1gXFg0t9kBIZkW0hXKPceYMrhYGdIJfQ3ix0BqGeO/mrQ1wE1zpnRdf
FMvj34Uzm3+1RUhfcG9nbm7WPgNDdm7ACAJ3APpmhw9meAfhCm9SYxUXJQ+5m7udaWYbbGwGGmVr
Btd02GsR2atmsHMGs1O8BhBjuSwP/hKCvnPgMc1VQUVAWFOhc+3oX2XHBlgbAd2Ewd50sRJwSNNt
Kd4KhWJ68gZheABlNrfBLRgadXMLoWh+S4rXBetsH3BfDeYKGrNtgA1mBmvqhgs5X31fYmVCd8IR
Ql9oNDMRZmSKDkEIB+XjCCeUokJpKmFiopGEk5spZ212s4oIDV8QAQxjP/sjCAcFcgBmZmyj1+Fu
b2h0GG5vQMFuru43ezuSYnU+R+pvYmZJNxtbqmmMzfSRAORq7da5b1BDrXJVwgrXgeUKePZUxaho
GixTbzhyNjBpZk0Z/zNhZwUdwZ4Ed7Ls2CzbUnUTkvpvAgMTsizLsjkQBAk0y7IsywoXc3QLFSzL
siwUEhEIcN4CArEP3TaoIP5F+ksg3Q8BCwEG/9kK3u8DAI9QcS+gWEkDMd0Q3xKIjqoQ3QwQDhZs
YAcGN+imIMHlWXgQcBY0JRC7FadkAt0C8U1OJoTnEN3EG+wULBH7IAcNDVII3ewHwFoJxDsH3dh7
rlS/oQvr80/7fFvJ8BcBAMSpziYJAAAAQAAgAQD/AAAAAAAAAAAAYL4A4EAAjb4AMP//V4PN/+sQ
kJCQkJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz
5DHJg+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D
7vwR2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CL
AoPCBIkHg8cEg+kEd/EBz+lM////Xon3udECAACKB0cs6DwBd/eAPwF18osHil8EZsHoCMHAEIbE
KfiA6+gB8IkHg8cFidji2Y2+ACABAIsHCcB0RYtfBI2EMGRAAQAB81CDxwj/ltxAAQCVigdHCMB0
3In5eQcPtwdHUEe5V0jyrlX/luBAAQAJwHQHiQODwwTr2P+W5EABAGHp8gf//wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAAAWAAAgBgAAIAAAAAAAAAAAAAAAAAAAAEAbgAAADAAAIAAAAAAAAAA
AAAAAAAAAAEAGQQAAEgAAABwEAEAABYAAAAAAAAAAAAABABLAEQATABMAAAAAAAAAAAAAAAAAAAA
DFEBANxQAQAAAAAAAAAAAAAAAAAZUQEA7FABAAAAAAAAAAAAAAAAACZRAQD0UAEAAAAAAAAAAAAA
AAAAMVEBAPxQAQAAAAAAAAAAAAAAAAA8UQEABFEBAAAAAAAAAAAAAAAAAAAAAAAAAAAASFEBAFZR
AQBmUQEAAAAAAHRRAQAAAAAAglEBAAAAAACIUQEAAAAAAA8AAIAAAAAAS0VSTkVMMzIuRExMAEFE
VkFQSTMyLmRsbABNU1ZDUlQuZGxsAFVTRVIzMi5kbGwAV1NPQ0szMi5kbGwAAABMb2FkTGlicmFy
eUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAcmFuZAAAU2V0
VGltZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AEylVPhKoVL+u09O/s3Mxf7LxMD8SLVN4E69U/7PIND4sk9H8DAy3/zIJdD+ySHS/s083/6DgWps
lQozMvC2Q7WlX7JPQ7myX029s7a1TLVai2+GinedaFVCjWWDbI9rb4ZEUoeVbpqPd0tau3FyaJmO
SJSBjGOVb05YqGlQj2ibZf5jgWpslQozKqyVdmX+Y5RsEK6UbGz+g04fyDHDxiWubopz/m2RkRCu
lo9qbZGREKibb23+cZOLZYR3sJaPam2RkRCom29t/nGTi2WEd7CWj2ptkZEQqJtvbfykcZNr3mWP
ddksnrdv3JaKed5h3muBamUh/nd3d/jisZzqAODOdQD4tHAA/r1wAPxicAD+b3AA/g0AAADgcADw
WHAA/kVwAPw2cAD+KXAA+BxwAPz2cAD+GQAAAAAAAP4BAAAAAAAAAAAAAAAAAAD8QgAAAAAAAAAA
/l/9D/3yCg==
--====_ABC1234567890DEF_====
From FS_BOSTON-SA@studentuniverse.com Mon Dec 31 15:39:29 2001
From: FS_BOSTON-SA@studentuniverse.com (System Attendant)
Date: Mon, 31 Dec 2001 10:39:29 -0500
Subject: ScanMail Message: To Recipient virus found and action taken.
Message-ID: <63C01912C2A1D311BDBE009027DEA542C965DC@sumailb02.studentuniverse.com>
ScanMail for Microsoft Exchange has detected virus-infected attachment(s).
Sender = Louise Finch
Recipient(s) = haskell@haskell.org
Subject =
Scanning Time = 12/31/2001 10:39:28
Action on virus found:
The attachment HAMSTER.DOC.pif exists WORM_BADTRANS.B virus. ScanMail has
Moved it. The attachment was moved to Y:\Program
Files\Trend\Smex\Virus\HAMSTER.DOC3c3086b0f.pif_.
Warning to recipient. ScanMail detected a virus in an email attachment. The
attachment will be cleaned if possible. If the attachment cannot be cleaned
, it will be stripped.
From uk1o@rz.uni-karlsruhe.de Sun Dec 2 12:17:46 2001
From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter)
Date: Sun, 2 Dec 2001 13:17:46 +0100
Subject: Lazy Sound File IO
In-Reply-To: <2782.129.137.66.11.1003849260.squirrel@diopter.storrs>
References: <2782.129.137.66.11.1003849260.squirrel@diopter.storrs>
Message-ID: <20011202131745.B7713@rz.uni-karlsruhe.de>
Hello!
On Tue, Oct 23, 2001 at 11:01:00AM -0400, Carl McTague wrote:
> Please let me refine my question.
> Is there a general way to coerce an [Int] or [Double] etc. into a String,
> so that it may be written out to a binary file with hPutStr? There is
> toEnum, but this doesn't seem like a real solution, since it only works for
> Int values <256.
I'd write some format at least readable by programs like sox. E.g.
raw headerless 16-bit signed integers w/ a fixed sample rate. Maybe
even stereo if you are generating stereo sounds.
Now, let's do simple 16-bit integer lists, assume we have a stream
of Ints which additionally are between -2^15 and 2^15 - 1. And assume
we want network byte order (high byte first).
writeInts :: [Int] -> IO ()
writeInts = putStr . ints2Str
ints2Str :: [Int] -> String
ints2Str = concatMap int2str
where
int2str i | i >= -32768 && i <= 32767 =
map Char.chr [(i `mod` 65536) `div` 256, i `mod` 256]
That's it.
If you want to write stereo, you should interleave the Ints,
such as
nullElement :: Int -- the sample value for silence
mixStereo :: [Int] -> [Int] -> ([Int], [Int])
mixStereo [] [] = []
mixStereo l [] = zip l (repeat nullElement)
mixStereo [] l = zip (repeat nullElement) l
mixStereo (x:xs) (y:ys) = (x,y) : mixStereo xs ys
Hope that helps, even if late.
Kind regards,
Hannah.
From vcomic@speed.sender.com Mon Dec 3 07:46:07 2001
From: vcomic@speed.sender.com (vcomic@speed.sender.com)
Date: Mon, 3 Dec 2001 02:46:07 -0500 (EST)
Subject: 爆笑时事漫画 12-3
Message-ID: <20011203074607.9CFF7255C2@www.haskell.org>
新建网页 1
|
本刊物所有文章及内容版权为www.viacomic.com
V动漫网站所有，未经书面授权任何媒体不得转载 |
From mpc02@ukc.ac.uk Mon Dec 3 11:51:28 2001
From: mpc02@ukc.ac.uk (mpc02)
Date: Mon, 3 Dec 2001 11:51:28 +0000 (GMT)
Subject: Mathematics of Program Construction, 2nd CFP
Message-ID:
[Apologies for multiple copies]
MPC 2002
6th International Conference on
MATHEMATICS OF PROGRAM CONSTRUCTION
-----------------------------------
http://www.cs.ukc.ac.uk/conf/mpc2002/
Organised in conjunction with WCGP '02
8--10 July, 2002
Dagstuhl, Germany
INVITED SPEAKERS
include:
Robert Giegerich
Dexter Kozen
CALL FOR PAPERS
This conference aims to promote the development of mathematical
principles and techniques that are demonstrably useful and usable
in the process of constructing computer programs (whether
implemented in hardware or software).
The focus of the conference is on techniques that combine
precision with conciseness, enabling programs to be constructed by
formal calculation. Within this theme, the scope of the conference
is very diverse. We welcome contributions to programming
methodology (for example, formal methods for program specification
and transformation), to programming paradigms (for example,
generic programming techniques and type systems) and to language
design (for example, programming calculi and programming language
semantics). Theoretical contributions are welcome provided their
relevance to program construction is evident; discussion of
applications is welcome provided the mathematical basis is evident.
The conference will be organised in conjunction with the IFIP TC2
Working Conference on Generic Programming, WCGP '02. There will also be
a number of co-located workshops, including CMPP.
IMPORTANT DATES
Deadline for submission of papers: 6th January, 2002
Notification of acceptance/rejection: 4th March, 2002
Final papers due: 25th April, 2002
Full papers should be submitted in Postscript or pdf format by e-mail
to mpc02@ukc.ac.uk by 6th January, 2002.
PROGRAMME COMMITTEE
Roland Backhouse (UK) Eerke Boiten (UK, co-chair)
Michael Butler (UK) Ernie Cohen (USA)
Jules Desharnais (Canada) Jeremy Gibbons (UK, GP liaison)
David Gries (USA) Lindsay Groves (New Zealand)
Ian Hayes (Australia) Eric Hehner (Canada)
Zhenjiang Hu (Japan) John Hughes (Sweden)
Bart Jacobs (The Netherlands) Johan Jeuring (The Netherlands, GP liaison)
Dick Kieburtz (USA) Dexter Kozen (USA)
K. Rustan M. Leino (USA) Christian Lengauer (Germany, CMPP liaison)
Erik Meijer (The Netherlands/USA) Bernhard Moeller (Germany, co-chair)
David Naumann (USA) J.N. Oliveira (Portugal)
Alberto Pardo (Uruguay) Peter Pepper (Germany)
Kaisa Sere (Finland) Mark Utting (New Zealand)
FURTHER INFORMATION
Please refer to the web page for further details.
http://www.cs.ukc.ac.uk/conf/mpc2002/
--
Mathematics of Program Construction '02 at Dagstuhl
Eerke Boiten, Computing Laboratory, University of Kent at Canterbury, UK
+44.1227.827615 (fax 762811)
From thiemann@informatik.uni-freiburg.de Mon Dec 3 13:51:27 2001
From: thiemann@informatik.uni-freiburg.de (Peter Thiemann)
Date: 03 Dec 2001 14:51:27 +0100
Subject: PEPM'02 -- call for participation
Message-ID:
CALL FOR PARTICIPATION
2002 ACM SIGPLAN Workshop on
Partial Evaluation and Semantics-Based Program Manipulation (PEPM'02)
Portland, Oregon, USA, January 14-15, 2002
(colocated with POPL'02)
http://www.informatik.uni-freiburg.de/~thiemann/pepm02
The PEPM'02 workshop will bring together researchers working in the
areas of semantics-based program manipulation, partial evaluation, and
program generation. The workshop focuses on techniques, supporting
theory, and applications of the analysis and manipulation of programs.
PRELIMINARY PROGRAM
Monday, 14 January 2002
BREAKFAST
8:45 WELCOME (chair: PT)
9:00 Invited Talk: Staged Compilation
Craig Chambers (U Washington)
10:00 BREAK
10:30 Towards Bridging the Gap Between Programming Languages and Partial Evaluation
Anne-Francoise Le Meur, Julia L. Lawall, Charles Consel (INRIA/LaBRI, France)
11:00 Online Partial Evaluation for Shift and Reset
Kenichi Asai (Ochanomizu University, Japan)
11:30 Growing Languages with Metamorphic Syntax Macros
Claus Brabrand, Michael I. Schwartzbach (BRICS, University of Aarhus, Denmark)
12:00 LUNCH
14:00 From Checking to Inference via Driving and Dag Grammars
Jens Peter Secher and Morten Heine S鴕ensen (DIKU, Denmark)
14:30 Cost-Augmented Narrowing-Driven Specialization
Germ醤 Vidal (DSIC, Technical University of Valencia, Spain)
15:00 Path Dependent Analysis of Logic Programs
Lunjin Lu (Oakland University, USA)
15:30 BREAK
16:00 Automatic Time-Bound Analysis for a Higher-Order Language
Gustavo G髆ez and Yanhong A. Liu (Indiana University, USA)
16:30 Compositionality in the Puzzle of Semantics
Roberto Giacobazzi, Isabella Mastroeni
(Dipartimento di Informatica, Universita' degli studi di Verona, Italy)
17:00 PC REPORT
Tuesday, 15 January 2002
BREAKFAST
9:00 shared WITS-Session "Non-Interference and Probability"
10:30 BREAK
11:00 Invited Talk: Implementation of Automatic Differentiation Tools
Christian Bischof (Technical University of Aachen, Germany),
Paul Hovland, Boyana Norris (Argonne National Laboratory, USA),
12:00 LUNCH
14:00 Program Optimization Using Indexed and Recursive Data Structures
Yanhong A. Liu and Scott D. Stoller
(State University of New York at Stony Brook, USA)
14:30 Mixed-Initiative Interaction = Mixed Computation
Naren Ramakrishnan, Robert Capra, Manuel Perez-Quinones
(Department of Computer Science, Virginia Tech, USA)
15:00 CPS Translating Inductive and Coinductive Types
Gilles Barthe (INRIA, France),
Tarmo Uustalu (University of Minho, Portugal)
15:30 CLOSING
From ad@dcs.st-and.ac.uk Tue Dec 4 09:38:49 2001
From: ad@dcs.st-and.ac.uk (Tony Davie)
Date: Tue, 4 Dec 2001 09:38:49 +0000
Subject: We need "Documentation" (Was: Re: Integer to String
Conversion?)
In-Reply-To:
References:
Message-ID:
--============_-1204663764==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Tuesday 04 December 2001 02:51, you wrote:
>> On Tue, 4 Dec 2001, Chris wrote:
>> > is there a function that converts Integers to Strings and vice versa?
>>
>> Prelude> (reads "123 abc") :: [(Integer, String)]
>> [(123," abc")]
>> Prelude> show 123
> > "123"
>>
>
...
>Why doesn't an author or two who have written Haskell books consider opening
>their books for public use on the Internet? "The Craft Of ..." especially
>seems great. I'm sure many coders would appreciate a non-dead-tree version of
>that book or a shortened version of the book.
>
>The material we have is simply lacking. What we need is a good tutorial and a
>comprehensive reference book.
...
I suggest you look at http://www.haskell.org/bookshelf/, specifically
the section on
Papers available on the Web. This gives numerous tutorials and introductions.
--
Tony Davie
Computer Science (retired), St.Andrews University
G.F. Handel Site:
http://bruichladdich.dcs.st-and.ac.uk/HandelWWW/HandelCat.html
Handel was half German, half Italian, and half English. He was very
large. (from a music exam)
--============_-1204663764==_ma============
Content-Type: text/html; charset="us-ascii"
Re: We need "Documentation" (Was: Re:
Integer to Strin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 04 December 2001 02:51, you wrote:
> On Tue, 4 Dec 2001, Chris wrote:
> > is there a function that converts Integers to Strings and
vice versa?
>
> Prelude> (reads "123 abc") :: [(Integer,
String)]
> [(123," abc")]
> Prelude> show 123
> "123"
>
...
Why doesn't an author or two who have
written Haskell books consider opening
their books for public use on the Internet? "The Craft Of ..."
especially
seems great. I'm sure many coders would appreciate a non-dead-tree
version of
that book or a shortened version of the book.
The material we have is simply lacking. What we need is a good
tutorial and a
comprehensive reference
book.
...
I suggest you look at http://www.haskell.org/bookshelf/,
specifically the section on
Papers available on the Web. This gives numerous tutorials
and introductions.
--
Tony Davie
Computer Science (retired), St.Andrews University
G.F. Handel Site:
http://bruichladdich.dcs.st-and.ac.uk/HandelWWW/HandelCat.html
Handel was half
German, half Italian, and half English. He was very
large. (from a music
exam)
--============_-1204663764==_ma============--
From simonpj@microsoft.com Tue Dec 4 12:02:31 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 4 Dec 2001 04:02:31 -0800
Subject: Haskell 98 Revised
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066542@RED-MSG-10.redmond.corp.microsoft.com>
Gentle Haskellers
The December issue of the Haskell 98 Report is done.
http://research.microsoft.com/~simonpj/haskell98-revised
As usual, changes are highlighted in the overall bugs list thus: [Dec
2001],
so you can find them easily.
There are the usual crop of presentational improvements (thanks
esp to Ian Lynagh, George Russel, Feliks Kluzniak for much careful
reading).
There are two non-trivial changes that I decided to adopt:
1. Add showIntAtBase, showOct and showHex to the Numeric library.
2. Remove the wart concerning qualified names in instance declarations.
This a breaking change, in the sense that exotic Haskell programs
may have to change, but I judge it worth it, after some
consultation.
In particular:=20
* if you use H/Direct, you'll have to re-generate your
Haskell files with a different flag
* if you use the Edison library, you'll need a new copy of
the library (this isn't a problem in practice because it
comes bundled with your compiler)
The other thing I'd ask you to look at particularly is the layout
algorithm.
George and Ian have both pointed out bugs, but it's very easy to get
wrong
so a few more eyeballs on it would be a Good Thing.
The only unresolved thing I have in my pile is some stuff
about the lexical syntax of comments, which I find it hard to get
excited about. We are definitely converging. My earnest hope is to
finally freeze the Report at Christmas. So this is your last chance.
I hope.
Thanks
Simon
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
The instance decl wart
In Haskell 98 as she stands, when you give an instance declaration,
the method name is treated as an *occurrence* and so has to be=20
qualified if it is ambiguous:
module Foo where
compare =3D
instance Ord T where
Prelude.compare =3D ... -- NB!
You have to say "Prelude.compare" on the LHS, because both
Prelude.compare and Foo.compare are in scope. This is reasonable
on the RHS, of course, but it is plain silly on the LHS, because it=20
*must* refer to the compare from the Ord class! After all, its an
instance
declaration for Ord. =20
Not only is it surprising (most people think that plain "compare" should
be fine) but it also adds a whole new big production to the grammar
(qfunlhs).
So, after some consulation, I have decided to remove this wierd thing.
The analogy is with type signatures, where we can already write
module Foo where
compare :: Int -> Int
compare =3D ...
Note that we don't have to write "Foo.compare :: Int -> Int" in the
type signature. =20
The remaining question is how to explain this point in the Report.
My initial conclusion is that simply deleting the offending text was
enough.
Explaining the problem (given that it isn't really a problem) seems to
complicate matters. Nevertheless I'm entirely happy to add an
explanation, if people want it and say what they'd like to see.
The relevant section is 4.3.2. page 46 of the Report.
From biene2xxl@mail.com Tue Dec 4 17:25:41 2001
From: biene2xxl@mail.com (biene2xxl@mail.com)
Date: Tue, 4 Dec 2001 10:25:41 -0700 (MST)
Subject: hallo
Message-ID: <200112041725.KAA0000018394@int.iwhm.com>
Mein Geheimnis ist, da� ich immer Lust auf Erotik habe.
Bin ich eine Nymphomanin? Oder fehlt mir nur der richtige
Partner/in?
K鰊ntest Du das sein?
Ja? Dann besuch mich doch mal auf meiner kleinen Homepage
http://free.adult-freespace.de/coolgirl22/
cu bis bald
Biene
From diatchki@cse.ogi.edu Tue Dec 4 18:40:55 2001
From: diatchki@cse.ogi.edu (Iavor S. Diatchki)
Date: Tue, 4 Dec 2001 10:40:55 -0800
Subject: Haskell 98 Revised
In-Reply-To: <1113DDB24D4A2841951BFDF86665EE19066542@RED-MSG-10.redmond.corp.microsoft.com>
References: <1113DDB24D4A2841951BFDF86665EE19066542@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <200112041840.KAA20987@church.cse.ogi.edu>
hello,
it seems that if the qualified names in instance declarations are removed,
the qualified methods (data constructors) in exports ought to be removed as
well. example: currently in Haskell one may write
module M ( P.C(Q.f) ) where
import qualified P
import qualified Q
...
qualifying the method (or data cosntructor) does not give any additional
information. however if i read the current report correctly (and i don't
think it is quite clear on that) omitting the qualifier of "f" results in an
invalid program as there is no method "f" in scope (there probably are "P.f"
and "Q.f"however). having said that, GHC accepts the program without the
qualifier,so it seems that it essentailly ignores the qualifiers of
"subordinate" names in export lists. so why not adjust the report so that
such qualified names are just not allowed?
bye
iavor
From diatchki@cse.ogi.edu Tue Dec 4 19:13:39 2001
From: diatchki@cse.ogi.edu (Iavor S. Diatchki)
Date: Tue, 4 Dec 2001 11:13:39 -0800
Subject: hiding imports
Message-ID: <200112041913.LAA13918@church.cse.ogi.edu>
hello,
i was wondering if there was a reasong why "hiding imports" have different
semantics from "importing imports" and "exports". what i mean is, if one
writes:
module A(T) where
data T = T
only the type constructor T is exported. simillarly if i write:
module A where
data T = T
module B where
import A(T)
only the type constructor is imported, but if i write
(module A as above)
module B where
import A hiding (T)
both the type constructor and the value constructor are hidden.
this seems not only irregular, but may also be inconvinient in practise
as sometimes it happens that a type constructor and a data constructor
have the same name, but the data constructor does not "belong" to the
type constructor. for example:
module A where
type T = TGen Int
data TGen a = T a | S
module B where
import A hiding (T) -- intending to just hide the type T
genF = T -- error T not in scope!
so if i wanted to ignore the type T, but still have the data constructor i
have to explicitly import it, i.e. write:
module B where
import A hiding (T)
import A (TGen(T))
which is kind of ugly. is this strange behaviour for historical reasons,
or was there a practical reason why this decision was made?
bye
iavor
From afelty@site.uottawa.ca Tue Dec 4 19:34:18 2001
From: afelty@site.uottawa.ca (Amy Felty)
Date: Tue, 4 Dec 2001 14:34:18 -0500 (EST)
Subject: CFP: Special Journal Issue on Proof-Carrying Code
Message-ID:
Call for Papers
JOURNAL OF AUTOMATED REASONING
Special issue on PROOF-CARRYING CODE
Proof-carrying code is a technology that allows a host, or code
consumer, to safely run code delivered by an untrusted code producer.
The code producer delivers both a program and a formal proof that
verifies that the code meets the desired safety policies. Safety
policies generally express properties that prohibit the code from
harmful behavior such as accessing private data, overwriting important
data, accessing unauthorized resources, or consuming too many
resources. Ideally, a proof is constructed automatically, and proof
search may be directed using information that is passed on from the
code producer's compiler. Proofs provided semi-automatically or
interactively using a proof assistant are possible as well. Upon
receiving the code and proof, the code consumer uses a mechanical
proof checker to check the proof before executing the code.
This special issue will be devoted to the topic of proof-carrying code
and related approaches which use formal reasoning to enhance safety
and reliability of software. Manuscripts emphasizing original results
and study of tools and methods for proof generation, proof checking,
and their integration with code generation/compilation are of
particular interest.
Manuscripts should be unpublished works and not submitted elsewhere.
Revised and enhanced versions of papers published in conference
proceedings that have not appeared in archival journals are eligible
for submission. All submissions will be reviewed according to the
usual standards of scholarship and originality. Information on JAR
submissions can be found at URL http://www-unix.mcs.anl.gov/JAR/.
Please format your submissions using JAR macros (available at
http://www.wkap.nl/kaphtml.htm/STYLEFILES).
Submissions should be sent to the guest editor in postscript format,
preferably gzipped and uuencoded. In addition, please send as plain
text, the title, authors, abstract, and contact information for the
paper. The submission deadline is February 22, 2002.
Guest Editor:
Amy Felty, University of Ottawa, afelty@site.uottawa.ca
This information is available on the web at:
http://www.site.uottawa.ca/~afelty/jar-pcc/
From simonpj@microsoft.com Wed Dec 5 10:42:18 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 5 Dec 2001 02:42:18 -0800
Subject: hiding imports
Message-ID: <1113DDB24D4A2841951BFDF86665EE1906655A@RED-MSG-10.redmond.corp.microsoft.com>
I think it's an ill-thought-out exception. The point is this:
if a data constructor cannot appear on its own in a hiding
list, then you can't hide the constructor without hiding the
type. Currently you can say
import Maybe hiding( Just )
It would be simpler and more uniform to only allow data
constructors inside parens, just as for exports, but then
I'd have to say
import Maybe hiding( Maybe(Just) )
and now the type constructor Maybe is hidden too.
I say "ill thought out" because the exception doesn't actually
solve the problem, as you point out. You may accidentally hide
things you didn't mean to. So perhaps the cure is as bad
as the disease.
Changing this would be technically easy (delete a sentence)
but it might break some programs, so that suggests the status
quo.
Simon
| -----Original Message-----
| From: Iavor S. Diatchki [mailto:diatchki@cse.ogi.edu]=20
| Sent: 04 December 2001 19:14
| To: haskell@haskell.org
| Subject: hiding imports
|=20
|=20
| hello,
|=20
| i was wondering if there was a reasong why "hiding imports"=20
| have different semantics from "importing imports" and=20
| "exports". what i mean is, if one=20
| writes:
|=20
| module A(T) where
| data T =3D T
| only the type constructor T is exported. simillarly if i write:
|=20
| module A where
| data T =3D T
|=20
| module B where
| import A(T)
|=20
| only the type constructor is imported, but if i write
| (module A as above)
|=20
| module B where
| import A hiding (T)
|=20
| both the type constructor and the value constructor are hidden.
|=20
| this seems not only irregular, but may also be inconvinient=20
| in practise as sometimes it happens that a type constructor=20
| and a data constructor have the same name, but the data=20
| constructor does not "belong" to the type constructor. for example:
|=20
| module A where
| type T =3D TGen Int
| data TGen a =3D T a | S
|=20
| module B where
| import A hiding (T) -- intending to just hide the type T
| genF =3D T -- error T not in scope!
|=20
| so if i wanted to ignore the type T, but still have the data=20
| constructor i=20
| have to explicitly import it, i.e. write:
| module B where
| import A hiding (T)
| import A (TGen(T))
| which is kind of ugly. is this strange behaviour for=20
| historical reasons,=20
| or was there a practical reason why this decision was made?
|=20
| bye
| iavor
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From simonpj@microsoft.com Wed Dec 5 10:42:17 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 5 Dec 2001 02:42:17 -0800
Subject: Haskell 98 Revised
Message-ID: <1113DDB24D4A2841951BFDF86665EE19066559@RED-MSG-10.redmond.corp.microsoft.com>
A good point. You are right that the report is not very explicit
on this point; and right that omitting the qualifier would be in the
spirit of the story for type sigs and instance decls. =20
I'd be interested to know what others think.
Simon
| -----Original Message-----
| From: Iavor S. Diatchki [mailto:diatchki@cse.ogi.edu]=20
| Sent: 04 December 2001 18:41
| To: haskell@haskell.org
| Subject: Re: Haskell 98 Revised
|=20
|=20
| hello,
|=20
| it seems that if the qualified names in instance declarations=20
| are removed, the qualified methods (data constructors) in=20
| exports ought to be removed as=20
| well. example: currently in Haskell one may write
|=20
| module M ( P.C(Q.f) ) where
| import qualified P
| import qualified Q
| ...
| qualifying the method (or data cosntructor) does not give=20
| any additional=20
| information. however if i read the current report correctly=20
| (and i don't=20
| think it is quite clear on that) omitting the qualifier of=20
| "f" results in an=20
| invalid program as there is no method "f" in scope (there=20
| probably are "P.f"=20
| and "Q.f"however). having said that, GHC accepts the=20
| program without the=20
| qualifier,so it seems that it essentailly ignores the qualifiers of=20
| "subordinate" names in export lists. so why not adjust the=20
| report so that=20
| such qualified names are just not allowed?
|=20
| bye
| iavor
|=20
|=20
|=20
|=20
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From simonpj@microsoft.com Wed Dec 5 11:13:54 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 5 Dec 2001 03:13:54 -0800
Subject: Haskell 98 Revised
Message-ID: <1113DDB24D4A2841951BFDF86665EE1906655B@RED-MSG-10.redmond.corp.microsoft.com>
Folks,
Concerning the recent change about instance declarations, should
this be valid?
module M( C(op1) ) where -- NB: op2 not exported
class C a where
op1 :: a->a
op2 :: a->a
module N where
import M
instance C Int where
op1 =3D ...
op2 =3D ... -- Is this ok?
The point here is that M does not export op2. Can
we still bind it in the instance declaration in N? The old Report
was silent on this point, and so is the new one.
I'd like to say "no, this is illegal". Haskell uses hiding as its
main abstraction mechanism, and if op2 is hidden then an
importing module should not be able to see it in any way.
I'll clarify this; but I thought I should point out the issue.
Simon
| -----Original Message-----
| From: Simon Peyton-Jones [mailto:simonpj@microsoft.com]=20
| Sent: 04 December 2001 12:03
| To: haskell@haskell.org
| Cc: Simon Peyton-Jones
| Subject: Haskell 98 Revised
|=20
|=20
| Gentle Haskellers
|=20
| The December issue of the Haskell 98 Report is done.
|=20
| http://research.microsoft.com/~simonpj/haskell98-revised
|=20
| As usual, changes are highlighted in the overall bugs list=20
| thus: [Dec 2001], so you can find them easily.
|=20
| There are the usual crop of presentational improvements=20
| (thanks esp to Ian Lynagh, George Russel, Feliks Kluzniak for=20
| much careful reading). There are two non-trivial changes that=20
| I decided to adopt:
|=20
| 1. Add showIntAtBase, showOct and showHex to the Numeric library.
|=20
| 2. Remove the wart concerning qualified names in instance=20
| declarations.
| This a breaking change, in the sense that exotic Haskell programs
| may have to change, but I judge it worth it, after some=20
| consultation.
| In particular:=20
| * if you use H/Direct, you'll have to re-generate your
| Haskell files with a different flag
| * if you use the Edison library, you'll need a new copy of
| the library (this isn't a problem in practice because it
| comes bundled with your compiler)
|=20
| The other thing I'd ask you to look at particularly is the=20
| layout algorithm. George and Ian have both pointed out bugs,=20
| but it's very easy to get wrong so a few more eyeballs on it=20
| would be a Good Thing.
|=20
| The only unresolved thing I have in my pile is some stuff
| about the lexical syntax of comments, which I find it hard to=20
| get excited about. We are definitely converging. My earnest=20
| hope is to finally freeze the Report at Christmas. So this=20
| is your last chance. I hope.
|=20
| Thanks
|=20
| Simon
|=20
| =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
| The instance decl wart
|=20
| In Haskell 98 as she stands, when you give an instance=20
| declaration, the method name is treated as an *occurrence*=20
| and so has to be=20
| qualified if it is ambiguous:
|=20
| module Foo where
|=20
| compare =3D
|=20
| instance Ord T where
| Prelude.compare =3D ... -- NB!
|=20
| You have to say "Prelude.compare" on the LHS, because both=20
| Prelude.compare and Foo.compare are in scope. This is=20
| reasonable on the RHS, of course, but it is plain silly on=20
| the LHS, because it=20
| *must* refer to the compare from the Ord class! After all,=20
| its an instance declaration for Ord. =20
|=20
| Not only is it surprising (most people think that plain=20
| "compare" should be fine) but it also adds a whole new big=20
| production to the grammar (qfunlhs).
|=20
| So, after some consulation, I have decided to remove this=20
| wierd thing. The analogy is with type signatures, where we=20
| can already write
|=20
| module Foo where
|=20
| compare :: Int -> Int
| compare =3D ...
|=20
| Note that we don't have to write "Foo.compare :: Int -> Int"=20
| in the type signature. =20
|=20
|=20
| The remaining question is how to explain this point in the=20
| Report. My initial conclusion is that simply deleting the=20
| offending text was enough. Explaining the problem (given that=20
| it isn't really a problem) seems to complicate matters. =20
| Nevertheless I'm entirely happy to add an explanation, if=20
| people want it and say what they'd like to see.
|=20
| The relevant section is 4.3.2. page 46 of the Report.
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
|=20
From kff@it.kth.se Wed Dec 5 13:13:43 2001
From: kff@it.kth.se (Karl-Filip Faxen)
Date: Wed, 05 Dec 2001 14:13:43 +0100
Subject: Haskell 98 Revised
In-Reply-To: Your message of Wed, 05 Dec 2001 03:13:54 -0800.
<1113DDB24D4A2841951BFDF86665EE1906655B@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <200112051313.OAA14174@mail2.it.kth.se>
Hi!
For whatever that is worth, my semantics agrees with Simon's point here,
ie in the example code
module M( C(op1) ) where -- NB: op2 not exported
class C a where
op1 :: a->a
op2 :: a->a
module N where
import M
instance C Int where
op1 = ...
op2 = ... -- Is this ok?
the method binding for op2 is not allowed.
But then there *is* a scope issue with instance declarations. What about
the following example:
module M( C(..) ) where -- NB: both methods exported ...
class C a where
op1 :: a->a
op2 :: a->a
module N where
import M hiding (op2) -- ... but op2 is not imported
instance C Int where
op1 = ...
op2 = ... -- Is this ok?
As far as I've understood, the current revision of the Report states that
a 'hiding' clause affects the qualified names as well as the unqualified
names. Then 'op2' is not visible either qualified or unqualified.
So, should it be legal to make a method declaration for it?
Cheers,
/kff
From martin.odersky@epfl.ch Thu Dec 6 09:14:48 2001
From: martin.odersky@epfl.ch (Martin Odersky)
Date: Thu, 6 Dec 2001 10:14:48 +0100
Subject: FOOL 9 Call for Participation
Message-ID: <200112060914.KAA16836@lamppc11.epfl.ch>
CALL FOR PARTICIPATION
The Ninth International Workshop on
Foundations of Object-Oriented Languages
FOOL 9
Sponsored by ACM SIGPLAN
January 19, 2002
Portland, Oregon
Following POPL '02
The search for sound principles for object-oriented languages has
given rise to much work on the theory of programming languages during
the past 15 years, leading to a better understanding of the key
concepts of object-oriented languages and to important developments in
type theory, semantics, and program verification. The FOOL workshops
bring together researchers to share new ideas and results in these
areas.
The next workshop, FOOL 9, will be held in Portland, Oregon, on
Saturday January 19, 2002, the day after POPL'02. To register for the
workshop, use the standard registration form, available through:
http://www.cse.ogi.edu/PacSoft/conf/popl
--------------------------------------------------------------------------
Preliminary schedule
Saturday, January 29, 2002
8:40 Start
8:45-9:45 Invited Talk
Distributed Objects - The Next 10 Years
Andrew Black
9:45-10:15 Break
10:15-12:15 Session 1
Modular Typechecking for Hierarchically Extensible
Datatypes and Functions
Todd Millstein, Craig Chambers
Type-checking multi-methods in ML (A modular approach)
Daniel Bonniot
First-Class Modules for Haskell
Mark Shields, Simon Peyton Jones
Extensible Objects Without Labels
Christopher Stone
12:15-14:00 Lunch
14:00-15:30 Session 2
Modern Concurrency Abstractions for C#
Nick Benton, Luca Cardelli, Cedric Fournet
OO languages late-binding signature
Antoine Beugnard
A Semantics for Advice and Dynamic Joint Points in
Aspect-Oriented Programming
Mitchell Wand, Gregor Kiczales, Christopher Dutchyn
15:30-16:00 Break
16:00-17:30 Session 3
Automatic Discovery of Read-Only Fields,
Jens Palsberg, Tian Zhao, Trevor Jim.
Generation of Verification Conditions for
Abadi and Leino's Logic of Objects
Francis Tang, Martin Hofmann
Simple Type Inference for Structural Polymorphism
Jacques Garrigue
-------------------------------------------------------------------------
Steering Committee:
Martin Abadi, University of California, Santa Cruz
Kim Bruce, Williams College
Luca Cardelli, Microsoft Research
Kathleen Fisher, AT&T Labs
Benjamin Pierce, University of Pennsylvania (chair)
Didier Remy, INRIA Rocquencourt
Program Committee:
Viviana Bono, Universita di Torino
Craig Chambers, University of Washington
Erik Ernst, University of Aalborg
Giorgio Ghelli, University of Pisa
Atsushi Igarashi, University of Tokyo
Shriram Krishnamurthi, Brown University
Martin Odersky, EPFL (chair)
Clemens Szyperski, Microsoft Research
Jan Vitek, Purdue University
From ng13@mcs.le.ac.uk Thu Dec 6 12:25:43 2001
From: ng13@mcs.le.ac.uk (N Ghani)
Date: Thu, 06 Dec 2001 12:25:43 +0000
Subject: Rewriting Implementations
Message-ID: <200112061225.fB6CPgD24023@ithaca.mcs.le.ac.uk>
Is there any Haskell implementations of rewriting tools. This could be
any of string, term, equational or whatever forms of rewriting.
Also are there any Haskell packages including data structures for
algebriac objects like monoids, groups, rings, modules, graphs,
categories, enriched categories, K-algebras (ie monoids in K-modules),
kan extensions ....
Finally, are there any haskell packages for computing quotients of
such structures (perhpas using rewriting)
Neil
From herrmann@infosun.fmi.uni-passau.de Thu Dec 6 19:19:02 2001
From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann)
Date: Thu, 6 Dec 2001 20:19:02 +0100
Subject: Strict foldl
Message-ID: <15375.50342.279681.360674@reger.fmi.uni-passau.de>
Hi Haskellers,
which compiler settings do I have to pass to ghc-5.02
in order to achieve that the strictness analyzer
recognizes strictness of (+) in foldl and computes
sum in constant space?
Prelude> sum [1..10000000]
had the following effect:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
23542 herrmann 20 0 250M 130M 97500 R 66.3 52.4 0:21 ghc-5.02
Of course, one could define a strict foldl oneself:
> sfoldl f e [] = e
> sfoldl f e (x:xs) = (sfoldl f $! (f e x)) xs
( > sfoldl (+) 0 [1..10000000]
returns 50000005000000 in about a minute interpreted
using 18MB of total space.)
But with the own definition one has to redefine many of the prelude functions.
Thanks in advance
--
Christoph Herrmann
From hdaume@ISI.EDU Thu Dec 6 19:19:31 2001
From: hdaume@ISI.EDU (Hal Daume III)
Date: Thu, 6 Dec 2001 11:19:31 -0800 (PST)
Subject: class parameters to existential datatypes
Message-ID:
Hi,
I would like to be able to write something like this:
> data Foo c = forall a . c a => Foo a
Unfortunately, this isn't allowed (apparently) because it's an illegal
class assertion (or at least that's what ghc tells me).
My motivation for doing this is I want to have something like List, but a
class list where all you know is that every element is a member of some
class. I would write something like:
> data CList c = CNil
> | forall a . (c a) => CCons a (CList c)
that way I could have something like the prototypical:
> class Shape a where { area :: a -> Double }
> data Circle = Circle Double
> data Rectangle = Rectangle Double Double
> instance Shape Circle where { area (Circle r) = 2 * pi * r }
> instance Shape Rectangle where { area (Rectangle l w) = l*w }
> MyList :: CList Shape
> MyList = CCons (Circle 5) (CCons (Rectangle 2 3) CNil)
and then maybe have a function:
> totalArea :: (CList Shape) -> Double
> totalArea = sum . map area
obviously this function declaration is also invalid.
so I have two questions:
1) Is there any particular reason whey we can't do this (it would
break some type safety things or whatever)
2) Any ways to get around it?
Thanks!
- Hal
From rjmh@cs.chalmers.se Thu Dec 6 21:04:46 2001
From: rjmh@cs.chalmers.se (John Hughes)
Date: Thu, 6 Dec 2001 22:04:46 +0100 (MET)
Subject: class parameters to existential datatypes
Message-ID: <200112062104.WAA11520@hotlips.cs.chalmers.se>
I would like to be able to write something like this:
> data Foo c = forall a . c a => Foo a
Unfortunately, this isn't allowed (apparently) because it's an illegal
class assertion (or at least that's what ghc tells me).
...
so I have two questions:
1) Is there any particular reason whey we can't do this (it would
break some type safety things or whatever)
2) Any ways to get around it?
Thanks!
- Hal
Hmm. Interesting.
I wrote a paper a couple of years ago, on "Restricted Data Types", which
discusses among other things how to simulate abstraction over a class by
abstraction over the corresponding dictionary type. You might find the
technique useful. It's at
http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
John Hughes
From ashley@semantic.org Thu Dec 6 21:11:07 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Thu, 6 Dec 2001 13:11:07 -0800
Subject: class parameters to existential datatypes
Message-ID: <200112062111.NAA02412@mail4.halcyon.com>
At 2001-12-06 13:04, John Hughes wrote:
> > data Foo c = forall a . c a => Foo a
What are you trying to say? In 'data Foo c' you are saying that c is a
type (as a parameter). In 'c a =>' you are saying that c is a class. So
naturally Haskell complains.
--
Ashley Yakeley, Seattle WA
From ashley@semantic.org Thu Dec 6 21:12:59 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Thu, 6 Dec 2001 13:12:59 -0800
Subject: class parameters to existential datatypes
Message-ID: <200112062112.NAA02509@mail4.halcyon.com>
At 2001-12-06 13:11, Ashley Yakeley wrote:
>At 2001-12-06 13:04, John Hughes wrote:
>
>> > data Foo c = forall a . c a => Foo a
>
>What are you trying to say? In 'data Foo c' you are saying that c is a
>type (as a parameter). In 'c a =>' you are saying that c is a class. So
>naturally Haskell complains.
I'm sorry, I'm not paying attention today...
--
Ashley Yakeley, Seattle WA
From chak@cse.unsw.edu.au Thu Dec 6 23:34:40 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 07 Dec 2001 10:34:40 +1100
Subject: Strict foldl
In-Reply-To: <15375.50342.279681.360674@reger.fmi.uni-passau.de>
References: <15375.50342.279681.360674@reger.fmi.uni-passau.de>
Message-ID: <20011207103440M.chak@cse.unsw.edu.au>
"Ch. A. Herrmann" wrote,
> which compiler settings do I have to pass to ghc-5.02
> in order to achieve that the strictness analyzer
> recognizes strictness of (+) in foldl and computes
> sum in constant space?
>
> Prelude> sum [1..10000000]
>
> had the following effect:
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> 23542 herrmann 20 0 250M 130M 97500 R 66.3 52.4 0:21 ghc-5.02
Is this what I think it is? Do you benchmark the
interpreter? Interpreted code isn't optimised. When I
compile
main = print $ sum [1..10000000]
with -O2, it takes 13s on a 600MHz P3 and runs in 1.5MB of
space.
Now, you may think that `sum' should have been compiled
optimised in the Prelude and you just call this optimised
version from the interpreter. However, this reasoning is
flawed for a number of reasons (one being that you won't
make use of specialised versions of Prelude functions in
this way).
> Of course, one could define a strict foldl oneself:
>
> > sfoldl f e [] = e
> > sfoldl f e (x:xs) = (sfoldl f $! (f e x)) xs
>
> ( > sfoldl (+) 0 [1..10000000]
> returns 50000005000000 in about a minute interpreted
> using 18MB of total space.)
>
> But with the own definition one has to redefine many of the prelude functions.
GHC's Prelude does not define `sum' in terms of foldl;
instead, it uses the definition
sum :: (Num a) => [a] -> a
sum l = sum' l 0
where
sum' [] a = a
sum' (x:xs) a = sum' xs (a+x)
The Prelude also defines a specialisation of the function
for `Integer' (which is what you get in your example) by way
of
{-# SPECIALISE sum :: [Integer] -> Integer #-}
I haven't checked the Core code produced for the above
definition, but as I know GHC, I am pretty sure that it
compiles the Prelude definition into a nice tight loop
making use of all available strictness.
Cheers,
Manuel
From hdaume@ISI.EDU Thu Dec 6 23:43:08 2001
From: hdaume@ISI.EDU (Hal Daume III)
Date: Thu, 6 Dec 2001 15:43:08 -0800 (PST)
Subject: Strict foldl
In-Reply-To: <20011207103440M.chak@cse.unsw.edu.au>
Message-ID:
Hi,
> Is this what I think it is? Do you benchmark the
> interpreter? Interpreted code isn't optimised. When I
> compile
>
> main = print $ sum [1..10000000]
>
> with -O2, it takes 13s on a 600MHz P3 and runs in 1.5MB of
> space.
Out of curiousity, why doesn't this get compiled down to
main = print 50000005000000
?
That is, why doesn't the compiler carry out the calculation and then just
embed that in the compiled version?
I know that some C compilers do (at least somewhat) similar things when,
for example, you say:
x = y * 4
it will rewrite this as
x = y << 2
and even do more complicated stuff, like if you say
x = y * 12
it will give
x = 3 * (y << 2)
or whatnot.
can I expect this from ghc/nhc/etc?
- hal
From chak@cse.unsw.edu.au Fri Dec 7 02:33:13 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 07 Dec 2001 13:33:13 +1100
Subject: Strict foldl
In-Reply-To:
References: <20011207103440M.chak@cse.unsw.edu.au>
Message-ID: <20011207133313X.chak@cse.unsw.edu.au>
Hal Daume III wrote,
> > Is this what I think it is? Do you benchmark the
> > interpreter? Interpreted code isn't optimised. When I
> > compile
> >
> > main = print $ sum [1..10000000]
> >
> > with -O2, it takes 13s on a 600MHz P3 and runs in 1.5MB of
> > space.
>
> Out of curiousity, why doesn't this get compiled down to
>
> main = print 50000005000000
>
> ?
>
> That is, why doesn't the compiler carry out the calculation and then just
> embed that in the compiled version?
Because the compiler can't be sure that the computation
terminates. If it doesn't, the compiler would not
terminate, which usually makes users quite unhappy ;-)
> I know that some C compilers do (at least somewhat) similar things when,
> for example, you say:
>
> x = y * 4
>
> it will rewrite this as
>
> x = y << 2
>
> and even do more complicated stuff, like if you say
>
> x = y * 12
>
> it will give
>
> x = 3 * (y << 2)
>
> or whatnot.
>
> can I expect this from ghc/nhc/etc?
These kinds of optimisations are different from the use of a
Prelude function like `sum', because they don't affect the
termination behaviour of the compiler. With -fvia-C GHC
will generate C code that is, then, run through the C
compiler. If you take this route, then optimisations, such
as those you describe, are performed by the C compiler on
your Haskell code.
The natice code generator probably also performs some of
those optimisations, but I am not sure exactly which.
Cheers,
Manuel
From max630@mail.ru Fri Dec 7 02:45:11 2001
From: max630@mail.ru (Max A . K .)
Date: Fri, 7 Dec 2001 08:45:11 +0600
Subject: class parameters to existential datatypes
In-Reply-To: ; from hdaume@ISI.EDU on Thu, Dec 06, 2001 at 11:19:31AM -0800
References:
Message-ID: <20011207084511.B1617@max.home>
On Thu, Dec 06, 2001 at 11:19:31AM -0800, Hal Daume III wrote:
> 2) Any ways to get around it?
Is the following what you want?
> data ShapeType = forall t. (Shape t) => ShapeType t
> instance Shape ShapeType where { area (ShapeType a) = area a }
> class Shape a where { area :: a -> Double }
> data Circle = Circle Double
> data Rectangle = Rectangle Double Double
> instance Shape Circle where { area (Circle r) = 2 * pi * r }
> instance Shape Rectangle where { area (Rectangle l w) = l*w }
> myList :: [ShapeType]
> myList = [ShapeType (Circle 5), ShapeType (Rectangle 2 3)]
and then maybe have a function:
> totalArea :: [ShapeType] -> Double
> totalArea = sum . map area
works OK with ghc -fglasgow-exts
Max.
From michael.vorin@eds.com Fri Dec 7 03:20:45 2001
From: michael.vorin@eds.com (Vorin, Michael)
Date: Fri, 7 Dec 2001 13:20:45 +1000
Subject: Haskell Persistence
Message-ID: <1D1A08E56535D111BD0400805F59041A03C14514@AUADM100>
I am interested in pursuing practical development of persistence in Haskell.
To this end I have been looking for code/systems which have been developed
previously to build upon - not wishing to reinvent the wheel.
I have found some references in the literature but have been enable to track
down any "artefacts".
I was hopping someone could help me.
I have found:
(1) Efficient Persistent Haskell, Tony Davie, Kevin Hammond, and Juan
Quintela Division of Computer Science, University of St Andrews, 1998
(2) Models for Persistence in Lazy Functional Programming Systems, McNally,
University of St Andrews, 1993.
(3) A Functional Database (1989) (Correct) Phil Trinder
(4) Two Models For Integrating Persistence and Lazy Functional Languages
(1991) David J. McNally, Antony J.T. Davie
(5) Realizing State-Based Database Concepts in a Non-Strict, Statically
Typed, Purely Functional Persistent Programming Language Yoshihiko Ichikawa
Department of Information Sciences, Ochanomizu University
From trb@eastpac.com.au Fri Dec 7 04:02:35 2001
From: trb@eastpac.com.au (Tim Barbour)
Date: Fri, 7 Dec 2001 15:02:35 +1100 (EST)
Subject: Haskell Persistence
In-Reply-To: <1D1A08E56535D111BD0400805F59041A03C14514@AUADM100>
References: <1D1A08E56535D111BD0400805F59041A03C14514@AUADM100>
Message-ID: <15376.16219.746147.59447@hermes.virtue>
Vorin, Michael writes:
> I am interested in pursuing practical development of persistence in Haskell.
> To this end I have been looking for code/systems which have been developed
> previously to build upon - not wishing to reinvent the wheel.
I am implementing persistent memory for Linux (i.e. like virtual memory, but
non-volatile, with ACID transaction semantics). Perhaps something will be
working sometime in 2002.
It is my hope that persistent memory will serve as a foundation for making
functional data structures persistent, eventually leading towards a functional
operating system.
Tim
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin
From herrmann@infosun.fmi.uni-passau.de Fri Dec 7 09:34:05 2001
From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann)
Date: Fri, 7 Dec 2001 10:34:05 +0100
Subject: Strict foldl
In-Reply-To: <20011207103440M.chak@cse.unsw.edu.au>
References: <15375.50342.279681.360674@reger.fmi.uni-passau.de>
<20011207103440M.chak@cse.unsw.edu.au>
Message-ID: <15376.36109.341751.586793@reger.fmi.uni-passau.de>
Hi Manuel,
>> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 23542
>> herrmann 20 0 250M 130M 97500 R 66.3 52.4 0:21 ghc-5.02
Manuel> Is this what I think it is? Do you benchmark the
Manuel> interpreter? Interpreted code isn't optimised.
not really. I wanted to have a strict foldl (for a different purpose
than sum) and could not figure out how to tell the compiler.
I tried different things, precompile just one module, compile
the entire program, using -fglasgow-exts, but nothing seems to work.
Thus, I reduced the problem to sum to make it simpler for you.
However, the sum computation based on my sfold definition did not
take too long even with the interpreter. Thus, I wondered why
the predefined sum computation behaves that bad.
Manuel> GHC's Prelude does not define `sum' in terms of foldl;
Manuel> instead, it uses the definition ...
Where can I find the ghc prelude?
Is there also the definition of the mysterious foldl' function
which I saw from time to time before it disappeared again?
Manuel> I haven't checked the Core code produced for the above
Manuel> definition, but as I know GHC, I am pretty sure that it
Manuel> compiles the Prelude definition into a nice tight loop
Manuel> making use of all available strictness.
One would expect that ghci uses a compiled version
of sum. Does it or not?
Cheers
--
Christoph
From v-julsew@microsoft.com Fri Dec 7 10:03:13 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Fri, 7 Dec 2001 02:03:13 -0800
Subject: Strict foldl
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F23D4@red-msg-06.redmond.corp.microsoft.com>
| > Prelude> sum [1..10000000]
| >=20
| > had the following effect:
| >=20
| > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
| > 23542 herrmann 20 0 250M 130M 97500 R 66.3 52.4 0:21
ghc-5.02
|=20
| Is this what I think it is? Do you benchmark the
| interpreter? Interpreted code isn't optimised. When I
| compile
|=20
| main =3D print $ sum [1..10000000]
|=20
| with -O2, it takes 13s on a 600MHz P3 and runs in 1.5MB of
| space.
I should point out that the interpreter's (byte-)code generator
is simplistic, and does not emit code to stub (make NULL) stack slots=20
which are known to be dead. This is probably causing the=20
space behaviour you are seeing. In contrast the compiled-code
back ends do do stack stubbing. If anyone wants to rewrite the
byte code generator to keep track of stack slot liveness and
emit suitable stub insns, that would be a service to us all :)
[constant folding]
| The natice code generator probably also performs some of
| those optimisations, but I am not sure exactly which.
Yes, it tries quite hard to fold literal trees and usually=20
succeeds well enough that the generated code is pretty much
identical to that emitted by gcc.
J
From kort@science.uva.nl Fri Dec 7 11:05:20 2001
From: kort@science.uva.nl (Jan Kort)
Date: Fri, 07 Dec 2001 12:05:20 +0100
Subject: Strict foldl
References: <15375.50342.279681.360674@reger.fmi.uni-passau.de>
Message-ID: <3C10A270.8D53744F@wins.uva.nl>
"Ch. A. Herrmann" wrote:
>
> Hi Haskellers,
>
> which compiler settings do I have to pass to ghc-5.02
> in order to achieve that the strictness analyzer
> recognizes strictness of (+) in foldl and computes
> sum in constant space?
>
> Prelude> sum [1..10000000]
>
> had the following effect:
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> 23542 herrmann 20 0 250M 130M 97500 R 66.3 52.4 0:21 ghc-5.02
>
> Of course, one could define a strict foldl oneself:
>
> > sfoldl f e [] = e
> > sfoldl f e (x:xs) = (sfoldl f $! (f e x)) xs
There is a foldl' in the Hugs Prelude that does this:
foldl' :: (a -> b -> a) -> a -> [b] -> a
foldl' f a [] = a
foldl' f a (x:xs) = (foldl' f $! f a x) xs
There are some functions in the Hugs Prelude that use
foldl (or foldl1) and some use foldl'. Maybe someone
can explain why certain functions use foldl: reverse,
maximum, minimum and readInt, while others use foldl':
length, sum and product.
I can understand why reverse would use foldl, but
why do maximum, minimum and readInt use foldl ? Maybe
the function foldl1 was based on foldl' at one time ?
Jan
From Pierre.Lescanne@ens-lyon.fr Fri Dec 7 12:59:00 2001
From: Pierre.Lescanne@ens-lyon.fr (Pierre Lescanne)
Date: Fri, 7 Dec 2001 13:59:00 +0100
Subject: RTA 2002 - Call for Papers
Message-ID: <15376.48404.703938.420647@tourblanche.ens-lyon.fr>
RTA 2002 - Call for Papers
The 13th International Conference on Rewriting Techniques and Applicati=
ons
RTA'02 will take place from July 22, 2002 to July 24, 2002 in Copenhage=
n,
Denmark, as part of the Federated Logic Conference FLoC'02.
Topics
RTA is the major forum for the presentation of research on all aspects =
of
rewriting. Typical areas include (but are not limited to):
* Applications: case studies; rule-based programming; symbolic and
algebraic computation; theorem proving; functional and logic
programming; proof checking.
* Foundations: matching and unification; completion techniques;
strategies; constraint solving; explicit substitutions.
* Frameworks: string, term, and graph rewriting; lambda-calculus and=
higher-order rewriting; conditional rewriting; proof nets; constra=
ined
rewriting and deduction; categorical and infinitary rewriting.
* Implementation: compilation techniques; parallel execution; rewrit=
ing
tools.
* Semantics: equational logic; rewriting logic.
Best Paper Award
A prize of 500 EUR will be given to the best paper as judged by the pro=
gram
committee. The program committee may decline to make the award or may s=
plit
it among several papers.
Submissions
Submissions must be original and not submitted for publication elsewher=
e.
Submissions should fall into one of the following categories:
1. Regular research papers describing new results; they will be judged =
on
correctness and significance.
2. Papers describing the experience of applying rewriting techniques in=
other areas; they will be judged on relevance and comparison with other=
approaches.
3. Problem sets that provide realistic and interesting challenges in th=
e
field of rewriting.
4. System descriptions; they should contain a link to a working system =
and
will be judged on usefulness and design.
All submissions will be judged on originality. Submissions in the first=
three categories can be up to 15 proceedings pages long, system descrip=
tions
4 proceedings pages. Authors are strongly encouraged to use LaTeX2e and=
the
Springer llncs class file, available at
http://www.springer.de/comp/lncs/authors.html. The title page should in=
clude
the submission category. Proofs of theorems should be provided in the p=
aper,
or, if space does not permit, should be made accessible otherwise (e.g.=
, as
an appendix to the submission or via the Web). Submission is by email: =
Send
a self-contained postscript file to
Proceedings
Accepted papers will be published in the proceedings of the symposium
(Lecture Notes in Computer Science, Springer-Verlag). Simultaneous
submission to other conferences with published proceedings is not allow=
ed.
Important dates
* Tue January 15, 2002 - paper submission
* Fri March 22, 2002 - author notification
* Thu April 25, 2002 - camera-ready papers due
Program Committee
* chair: Sophie Tison
LIFL - Laboratoire d'Informatique Fondamentale de Lille
URA CNRS 369
Universit=E9 de Lille 1
Cit=E9 Scientifique --- Bat. M3
59655 Villeneuve d'Ascq cedex, FRANCE
+33 03 20 43 43 09
+33 03 20 43 47 24 (secretary)
+33 03 20 43 45 66 (fax)
* Andrea Corradini , Pisa
* Daniel J. Dougherty , Wesleyan
* J=FCrgen Giesl , Aachen U of Tech=
nology
* Bernhard Gramlich , Vienna U of Technology
* Th=E9r=E8se Hardin , Paris VI
* Christopher Lynch , Clarkson
* Jerzy Marcinkowski , Wroclaw
* Aart Middeldorp , Tsukuba
* Joachim Niehren , Saarland
* Femke van Raamsdonk , Vrije U of Amsterdam
* Albert Rubio , Technical U of Catalonia
* Ralf Treinen , Paris-Sud
From alms@cin.ufpe.br Fri Dec 7 14:38:04 2001
From: alms@cin.ufpe.br (Andre Santos)
Date: Fri, 07 Dec 2001 11:38:04 -0300
Subject: Haskell Persistence
References: <1113DDB24D4A2841951BFDF86665EE19066593@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <3C10D44C.7060400@cin.ufpe.br>
Hi,
a paper describing what a student and I did is in
http://www.cin.ufpe.br/~alms/ps/persiste.ps.gz .
The idea was to have a class supporting the persistence
operations (more in the style of serialization) and
to have specific data structures to allow
a quicker retrieval of the data ("Persistence Containers").
This is similar to what we have in some
Object Oriented Databases.
For the low level implementation we used the work on
Binary I/O work of Wallace/Runciman.
But in order to get more portability we reimplemented
parts of it using Strings/Chars for I/O,
which ended up very inneficient in Haskell.
Some things that might help are:
- better binary I/O and/or to interface with some low level
existing persistence mechanism.
- I believe a kind of reflection mechanism would
make things much easier and more efficient
to implement.
Although automatic derivation of the instances
helps.
There are some other references in the paper.
cheers,
Andre.
> | -----Original Message-----
> | From: Vorin, Michael [mailto:michael.vorin@eds.com]
> | Sent: 07 December 2001 03:21
> | To: haskell@haskell.org
> | Subject: Haskell Persistence
> |
> |
> | I am interested in pursuing practical development of
> | persistence in Haskell. To this end I have been looking for
> | code/systems which have been developed previously to build
> | upon - not wishing to reinvent the wheel.
> |
> | I have found some references in the literature but have been
> | enable to track down any "artefacts".
> |
> | I was hopping someone could help me.
> |
> | I have found:
> | (1) Efficient Persistent Haskell, Tony Davie, Kevin Hammond,
> | and Juan Quintela Division of Computer Science, University of
> | St Andrews, 1998
> |
> | (2) Models for Persistence in Lazy Functional Programming
> | Systems, McNally, University of St Andrews, 1993.
> |
> | (3) A Functional Database (1989) (Correct) Phil Trinder
> |
> | (4) Two Models For Integrating Persistence and Lazy
> | Functional Languages
> | (1991) David J. McNally, Antony J.T. Davie
> |
> | (5) Realizing State-Based Database Concepts in a Non-Strict,
> | Statically Typed, Purely Functional Persistent Programming
> | Language Yoshihiko Ichikawa Department of Information
> | Sciences, Ochanomizu University
> |
> |
> | _______________________________________________
> | Haskell mailing list
> | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
> |
>
From anatoli@yahoo.com Fri Dec 7 16:29:44 2001
From: anatoli@yahoo.com (anatoli)
Date: Fri, 7 Dec 2001 08:29:44 -0800 (PST)
Subject: class parameters to existential datatypes
In-Reply-To: 
