Re: Glasgow-haskell-users Digest, Vol 155, Issue 9

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Glasgow-haskell-users Digest, Vol 155, Issue 9

Ralf Hutchison
Well Iavor likes it. (see 2 below)

Anyway, you know I'm really puzzled with the question of how to spend time.

Maybe you can help me.

In any case, it's such a lucky thing to have some to spend.

Toshia and I are watching season 4 of Game of Thrones.  I'm so addicted.

I'm also addicted to speed chess in the same way. (I am ralf_ben_h at chess.com)

I think that we have some structure in our minds, in our brains or our spines or our hearts say, and any story or game illuminates and awakens this structure.  The addictive feeling or attachment is a fascination with this part of ourselves and a willingness to experience it.

You wrote me a note about music recently.  How are you feeling about music today?

Best,
Ralph

On Sat, Jul 9, 2016 at 2:36 AM, <[hidden email]> wrote:
Send Glasgow-haskell-users mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Glasgow-haskell-users digest..."


Today's Topics:

   1. layout was Re: Proposal: ArgumentDo (C Maeder)
   2. Re: Proposal: ArgumentDo (Iavor Diatchki)
   3. Re: Proposal: ArgumentDo (C Maeder)
   4. Re: Proposal: ArgumentDo (Bardur Arantsson)
   5. Re: Proposal: ArgumentDo (Henrik Nilsson)


----------------------------------------------------------------------

Message: 1
Date: Fri, 8 Jul 2016 14:37:04 +0200
From: C Maeder <[hidden email]>
To: [hidden email]
Subject: layout was Re: Proposal: ArgumentDo
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

Hi,

the layout language options are hard to find (at least in the user
guide). Therefore I try to give an overview here. The relevant options
I've found by using ghc-7.10.3 with option --supported-languages are:

NondecreasingIndentation
DoAndIfThenElse

RelaxedLayout
AlternativeLayoutRule
AlternativeLayoutRuleTransitional

I ignore the last 3 options since these seem to be candidates for
removal: https://ghc.haskell.org/trac/ghc/ticket/11359.

The default option is NondecreasingIndentation, that is

  do
  x
  do
  y

is legal and parsed as a single expression "do {x ; do y}". With
-XNoNondecreasingIndentation one gets an "Empty 'do' block" for the
second do (and this error would not change with ArgumentDo!).

DoAndIfThenElse is not switched on by default and requires the keywords
"then" and "else" to be further indented for an "if" within a "do".

So I believe these options do not interfere with ArgumentDo, but maybe
this should be discussed more and maybe mentioned on the wiki page.

Surely a single space (inserted before x or removed before the second
"do") makes a difference between one or two argument expressions in the
example below.

HTH Christian

Am 08.07.2016 um 11:20 schrieb C Maeder:
> Surely layout can bite you:
>
>   f
>   do
>   x
>   do
>   y
>
> and I'm having difficulties to find the documentation for the various
> layout options.
>
> But this is no argument against this proposal!
>
> Improper use of white spaces can always be used to obfuscate code!
> Style guides are important. Furthermore, a wrong/unintended parse tree
> (due to layout) will - in many cases - result in a typing error.
>
> Christian



------------------------------

Message: 2
Date: Fri, 8 Jul 2016 09:42:24 -0700
From: Iavor Diatchki <[hidden email]>
To: Aloïs Cochard <[hidden email]>
Cc: GHC users <[hidden email]>, Henrik Nilsson
        <[hidden email]>
Subject: Re: Proposal: ArgumentDo
Message-ID:
        <CAGK9nuo93t=-[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hello,

while  we are voting here, I kind of like this proposal, so +1 for me.

I understand that some of the examples look strange to Haskell old-timers
but, as Joachim points out, the behavior is very consistent.   Besides, the
"Less Obvious Examples" were selected so that they are, well, less obvious.
  The common use cases (as in ticket #10843) seem quite appealing, at least
to me, and not at all confusing.  But, then, I also like the
records-with-no-parens notation :-)

-Iavor



On Fri, Jul 8, 2016 at 5:03 AM, Aloïs Cochard <[hidden email]>
wrote:

> -1 for same reasons.
>
> On 8 July 2016 at 14:00, Henrik Nilsson <[hidden email]>
> wrote:
>
>> Hi all,
>>
>> Joachim Breitner wrote:
>>
>> > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:
>> > > I don't think so: https://ghc.haskell.org/trac/ghc
>> > /wiki/ArgumentDo#Bl
>> > [...]
>> > Where is the outer set of parenthesis coming from?
>> >
>> > This is all not related to the ArgumentDo notation. Note that [...]
>>
>> The very fact that that experts can't easily agree on how a small
>> Haskell fragment is parsed to me just confirms that Haskell already
>> is a syntactically very cumbersome language.
>>
>> The present proposal just makes matters worse. For that reason
>> alone, I don't find it compelling at all. (So -1 from me, then.)
>>
>> I will not repeat the many other strong arguments against that has been
>> made. But I must say I don't find the use cases as documented
>> on the associated web page compelling at all. Maybe there is a tacit
>> desire to be able to pretend functions are keywords for various
>> creative uses in supporting EDSLs and such. But for that to be truly
>> useful, one need to support groups of related keywords. Something
>> like Agda's mixfix syntax springs to mind. But this proposal does
>> not come close, so the benefits are minimal and the drawbacks large.
>>
>> As a final point, the inherent asymmetry of the proposal (the
>> last argument position is special as, for certain kinds of
>> expressions, parentheses may be omitted there but not elsewhere)
>> is also deeply unsettling.
>>
>> Best,
>>
>> /Henrik
>>
>> --
>> Henrik Nilsson
>> School of Computer Science
>> The University of Nottingham
>> [hidden email]
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.  Any views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
> --
> *Λ\oïs*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160708/f6d53261/attachment-0001.html>

------------------------------

Message: 3
Date: Sat, 9 Jul 2016 09:09:17 +0200
From: C Maeder <[hidden email]>
To: Henrik Nilsson <[hidden email]>,
        [hidden email]
Subject: Re: Proposal: ArgumentDo
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

The asymmetry that you mention is already apparent for (Haskell98) infix
expressions, i.e. when "composing" lambda- or if-expression:

 (if c then f else g) . \ x -> h x

Parentheses around the last argument of "." do not matter, but
parentheses around the first argument make a real difference (that the
type checker will not detect)!

Cheers Christian

Am 08.07.2016 um 14:00 schrieb Henrik Nilsson:
> Hi all,

[...]

> As a final point, the inherent asymmetry of the proposal (the
> last argument position is special as, for certain kinds of
> expressions, parentheses may be omitted there but not elsewhere)
> is also deeply unsettling.
>
> Best,
>
> /Henrik
>



------------------------------

Message: 4
Date: Sat, 9 Jul 2016 09:42:06 +0200
From: Bardur Arantsson <[hidden email]>
To: [hidden email]
Subject: Re: Proposal: ArgumentDo
Message-ID: <nlq9se$vem$[hidden email]>
Content-Type: text/plain; charset=utf-8

On 07/09/2016 09:09 AM, C Maeder wrote:
> The asymmetry that you mention is already apparent for (Haskell98) infix
> expressions, i.e. when "composing" lambda- or if-expression:
>
>  (if c then f else g) . \ x -> h x
>
> Parentheses around the last argument of "." do not matter, but
> parentheses around the first argument make a real difference (that the
> type checker will not detect)!
>

What I'm reading here is essentially

  "Parser already does non-obvious thing"
      ===> "Adding more non-obvious things is fine!"

This is simply bad reasoning, and I'm not sure why a number of people
are saying it. Am I missing something?

Regards,



------------------------------

Message: 5
Date: Sat, 09 Jul 2016 10:46:14 +0100
From: Henrik Nilsson <[hidden email]>
To: C Maeder <[hidden email]>,  Henrik Nilsson
        <[hidden email]>, [hidden email]
Subject: Re: Proposal: ArgumentDo
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi all,

On 07/09/2016 08:09 AM, C Maeder wrote:
> The asymmetry that you mention is already apparent for (Haskell98) infix
> expressions, i.e. when "composing" lambda- or if-expression:
>
>   (if c then f else g) . \ x -> h x
>
> Parentheses around the last argument of "." do not matter, but
> parentheses around the first argument make a real difference

But that has to do with how grammatical ambiguity related to
in this case "if" and "lambda" are resolved by letting
the constructs extend as far as possible to the right.

This the standard way of resolving that kind of ambiguity
across a very wide range of programming languages and parsing
tools (e.g. preferring shift over reduce in an LR parser).
(And also in principle how lexical ambiguities are typically
resolved, sometimes referred to as the "maximal munch rule".)

In contrast, the present proposal suggests treating
different argument positions in grammatically
different ways (different non-terminals). As far as I know,
that is unprecedented. And in any case, it manifestly
complicates the grammar (more non-terminals) and as
a consequence adds another grammatical hurdle to
learning the language.

I think we often tend to forget just how exotic
Haskell syntax can be to the uninitiated. Which is
the vast majority of the rest of the programmer world
as well as beginners. Only the other week I gave a
presentation to a group of highly skilled developers
at a tech-savvy London-based company. The emphasis of
the talk was not at all on Haskell as such, but small
Haskell fragments did feature here and there, which I
(naively) thought would be mostly self explanatory.
Well, let's just say I was wrong.

Now, we can't make Haskell syntax less exotic (not that I'd
advocate that: I think basic Haskell syntax for the most part
strikes a pretty good balance on a number of counts), but we can
certainly avoid making it even more complicated and exotic.
Which the present proposal would, in my opinion.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[hidden email]




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.



------------------------------

Subject: Digest Footer

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


------------------------------

End of Glasgow-haskell-users Digest, Vol 155, Issue 9
*****************************************************


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Glasgow-haskell-users Digest, Vol 155, Issue 9

Ralf Hutchison
continuing my thought,

There was a medical student, Jonathan,  working here at True North. 

He was really into macrobiotics and studied with the great Denny Waxman.

Jonathan told me legends of the great George Oshawa who traveled the world as a sort of super human meeting with people and inspiring and teaching people.

One thing that really stuck with me is the note that this Oshawa would wake very early (maybe 3?) and spend hours writing letters.

That sounds so nice!!

I am remembering with gratitude a letter you wrote me in Japan.

Best,
Ralph

On Sat, Jul 9, 2016 at 12:26 PM, Ralf Hutchison <[hidden email]> wrote:
Well Iavor likes it. (see 2 below)

Anyway, you know I'm really puzzled with the question of how to spend time.

Maybe you can help me.

In any case, it's such a lucky thing to have some to spend.

Toshia and I are watching season 4 of Game of Thrones.  I'm so addicted.

I'm also addicted to speed chess in the same way. (I am ralf_ben_h at chess.com)

I think that we have some structure in our minds, in our brains or our spines or our hearts say, and any story or game illuminates and awakens this structure.  The addictive feeling or attachment is a fascination with this part of ourselves and a willingness to experience it.

You wrote me a note about music recently.  How are you feeling about music today?

Best,
Ralph

On Sat, Jul 9, 2016 at 2:36 AM, <[hidden email]> wrote:
Send Glasgow-haskell-users mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Glasgow-haskell-users digest..."


Today's Topics:

   1. layout was Re: Proposal: ArgumentDo (C Maeder)
   2. Re: Proposal: ArgumentDo (Iavor Diatchki)
   3. Re: Proposal: ArgumentDo (C Maeder)
   4. Re: Proposal: ArgumentDo (Bardur Arantsson)
   5. Re: Proposal: ArgumentDo (Henrik Nilsson)


----------------------------------------------------------------------

Message: 1
Date: Fri, 8 Jul 2016 14:37:04 +0200
From: C Maeder <[hidden email]>
To: [hidden email]
Subject: layout was Re: Proposal: ArgumentDo
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

Hi,

the layout language options are hard to find (at least in the user
guide). Therefore I try to give an overview here. The relevant options
I've found by using ghc-7.10.3 with option --supported-languages are:

NondecreasingIndentation
DoAndIfThenElse

RelaxedLayout
AlternativeLayoutRule
AlternativeLayoutRuleTransitional

I ignore the last 3 options since these seem to be candidates for
removal: https://ghc.haskell.org/trac/ghc/ticket/11359.

The default option is NondecreasingIndentation, that is

  do
  x
  do
  y

is legal and parsed as a single expression "do {x ; do y}". With
-XNoNondecreasingIndentation one gets an "Empty 'do' block" for the
second do (and this error would not change with ArgumentDo!).

DoAndIfThenElse is not switched on by default and requires the keywords
"then" and "else" to be further indented for an "if" within a "do".

So I believe these options do not interfere with ArgumentDo, but maybe
this should be discussed more and maybe mentioned on the wiki page.

Surely a single space (inserted before x or removed before the second
"do") makes a difference between one or two argument expressions in the
example below.

HTH Christian

Am 08.07.2016 um 11:20 schrieb C Maeder:
> Surely layout can bite you:
>
>   f
>   do
>   x
>   do
>   y
>
> and I'm having difficulties to find the documentation for the various
> layout options.
>
> But this is no argument against this proposal!
>
> Improper use of white spaces can always be used to obfuscate code!
> Style guides are important. Furthermore, a wrong/unintended parse tree
> (due to layout) will - in many cases - result in a typing error.
>
> Christian



------------------------------

Message: 2
Date: Fri, 8 Jul 2016 09:42:24 -0700
From: Iavor Diatchki <[hidden email]>
To: Aloïs Cochard <[hidden email]>
Cc: GHC users <[hidden email]>, Henrik Nilsson
        <[hidden email]>
Subject: Re: Proposal: ArgumentDo
Message-ID:
        <CAGK9nuo93t=-[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hello,

while  we are voting here, I kind of like this proposal, so +1 for me.

I understand that some of the examples look strange to Haskell old-timers
but, as Joachim points out, the behavior is very consistent.   Besides, the
"Less Obvious Examples" were selected so that they are, well, less obvious.
  The common use cases (as in ticket #10843) seem quite appealing, at least
to me, and not at all confusing.  But, then, I also like the
records-with-no-parens notation :-)

-Iavor



On Fri, Jul 8, 2016 at 5:03 AM, Aloïs Cochard <[hidden email]>
wrote:

> -1 for same reasons.
>
> On 8 July 2016 at 14:00, Henrik Nilsson <[hidden email]>
> wrote:
>
>> Hi all,
>>
>> Joachim Breitner wrote:
>>
>> > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:
>> > > I don't think so: https://ghc.haskell.org/trac/ghc
>> > /wiki/ArgumentDo#Bl
>> > [...]
>> > Where is the outer set of parenthesis coming from?
>> >
>> > This is all not related to the ArgumentDo notation. Note that [...]
>>
>> The very fact that that experts can't easily agree on how a small
>> Haskell fragment is parsed to me just confirms that Haskell already
>> is a syntactically very cumbersome language.
>>
>> The present proposal just makes matters worse. For that reason
>> alone, I don't find it compelling at all. (So -1 from me, then.)
>>
>> I will not repeat the many other strong arguments against that has been
>> made. But I must say I don't find the use cases as documented
>> on the associated web page compelling at all. Maybe there is a tacit
>> desire to be able to pretend functions are keywords for various
>> creative uses in supporting EDSLs and such. But for that to be truly
>> useful, one need to support groups of related keywords. Something
>> like Agda's mixfix syntax springs to mind. But this proposal does
>> not come close, so the benefits are minimal and the drawbacks large.
>>
>> As a final point, the inherent asymmetry of the proposal (the
>> last argument position is special as, for certain kinds of
>> expressions, parentheses may be omitted there but not elsewhere)
>> is also deeply unsettling.
>>
>> Best,
>>
>> /Henrik
>>
>> --
>> Henrik Nilsson
>> School of Computer Science
>> The University of Nottingham
>> [hidden email]
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.  Any views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
> --
> *Λ\oïs*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160708/f6d53261/attachment-0001.html>

------------------------------

Message: 3
Date: Sat, 9 Jul 2016 09:09:17 +0200
From: C Maeder <[hidden email]>
To: Henrik Nilsson <[hidden email]>,
        [hidden email]
Subject: Re: Proposal: ArgumentDo
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

The asymmetry that you mention is already apparent for (Haskell98) infix
expressions, i.e. when "composing" lambda- or if-expression:

 (if c then f else g) . \ x -> h x

Parentheses around the last argument of "." do not matter, but
parentheses around the first argument make a real difference (that the
type checker will not detect)!

Cheers Christian

Am 08.07.2016 um 14:00 schrieb Henrik Nilsson:
> Hi all,

[...]

> As a final point, the inherent asymmetry of the proposal (the
> last argument position is special as, for certain kinds of
> expressions, parentheses may be omitted there but not elsewhere)
> is also deeply unsettling.
>
> Best,
>
> /Henrik
>



------------------------------

Message: 4
Date: Sat, 9 Jul 2016 09:42:06 +0200
From: Bardur Arantsson <[hidden email]>
To: [hidden email]
Subject: Re: Proposal: ArgumentDo
Message-ID: <nlq9se$vem$[hidden email]>
Content-Type: text/plain; charset=utf-8

On 07/09/2016 09:09 AM, C Maeder wrote:
> The asymmetry that you mention is already apparent for (Haskell98) infix
> expressions, i.e. when "composing" lambda- or if-expression:
>
>  (if c then f else g) . \ x -> h x
>
> Parentheses around the last argument of "." do not matter, but
> parentheses around the first argument make a real difference (that the
> type checker will not detect)!
>

What I'm reading here is essentially

  "Parser already does non-obvious thing"
      ===> "Adding more non-obvious things is fine!"

This is simply bad reasoning, and I'm not sure why a number of people
are saying it. Am I missing something?

Regards,



------------------------------

Message: 5
Date: Sat, 09 Jul 2016 10:46:14 +0100
From: Henrik Nilsson <[hidden email]>
To: C Maeder <[hidden email]>,  Henrik Nilsson
        <[hidden email]>, [hidden email]
Subject: Re: Proposal: ArgumentDo
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi all,

On 07/09/2016 08:09 AM, C Maeder wrote:
> The asymmetry that you mention is already apparent for (Haskell98) infix
> expressions, i.e. when "composing" lambda- or if-expression:
>
>   (if c then f else g) . \ x -> h x
>
> Parentheses around the last argument of "." do not matter, but
> parentheses around the first argument make a real difference

But that has to do with how grammatical ambiguity related to
in this case "if" and "lambda" are resolved by letting
the constructs extend as far as possible to the right.

This the standard way of resolving that kind of ambiguity
across a very wide range of programming languages and parsing
tools (e.g. preferring shift over reduce in an LR parser).
(And also in principle how lexical ambiguities are typically
resolved, sometimes referred to as the "maximal munch rule".)

In contrast, the present proposal suggests treating
different argument positions in grammatically
different ways (different non-terminals). As far as I know,
that is unprecedented. And in any case, it manifestly
complicates the grammar (more non-terminals) and as
a consequence adds another grammatical hurdle to
learning the language.

I think we often tend to forget just how exotic
Haskell syntax can be to the uninitiated. Which is
the vast majority of the rest of the programmer world
as well as beginners. Only the other week I gave a
presentation to a group of highly skilled developers
at a tech-savvy London-based company. The emphasis of
the talk was not at all on Haskell as such, but small
Haskell fragments did feature here and there, which I
(naively) thought would be mostly self explanatory.
Well, let's just say I was wrong.

Now, we can't make Haskell syntax less exotic (not that I'd
advocate that: I think basic Haskell syntax for the most part
strikes a pretty good balance on a number of counts), but we can
certainly avoid making it even more complicated and exotic.
Which the present proposal would, in my opinion.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[hidden email]




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.



------------------------------

Subject: Digest Footer

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


------------------------------

End of Glasgow-haskell-users Digest, Vol 155, Issue 9
*****************************************************



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users