Limber separators

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

Re: Scope of committee (can we do *new* things?)

Gershom Bazerman
On May 8, 2016 at 9:25:33 PM, Richard Eisenberg ([hidden email]) wrote:
>  
> I do absolutely think we should be cautious about addressing unimplemented behavior.  
> I would be strongly against a new type-system extension that hasn't been field-tested.  
> However, I do think pondering lexical/parsical changes (such as limber separators)  
> should be considered in scope.

While such changes should definitely be in scope, I do think that the proper mechanism would be to garner enough interest to get a patch into GHC (whether through discussion on the -prime list or elsewhere) and have an experimental implementation, even for syntax changes, before such proposals are considered ready for acceptance into a standard as such. But I also agree that discussion of things which may be in the pre-implementation phase are in scope — just that the next step is to get them past that phase before they’re considered for inclusion as such. There are enough traps in parsing that specification without an implementation is always a risky choice.  Recall for example the case of fixity resolution, finally fixed in Haskell2010 (https://prime.haskell.org/wiki/FixityResolution) where the behavior in the report was at variance with all implementations.

I would hope that if a segment of the prime committee wants to test-run an experimental syntax feature, then this would take sufficient precedence over concerns regarding “language fragmentation” that the GHC team would be open to guarding it behind a flag. Given the number of GHC developers involved in this effort, I think that’s not a bad estimation :-)

Cheers,
Gershom
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Scope of committee (can we do *new* things?)

John Wiegley-2
>>>>> Gershom B <[hidden email]> writes:

> While such changes should definitely be in scope, I do think that the proper
> mechanism would be to garner enough interest to get a patch into GHC
> (whether through discussion on the -prime list or elsewhere) and have an
> experimental implementation, even for syntax changes, before such proposals
> are considered ready for acceptance into a standard as such.

Just a side note: This is often how the C++ committee proceeds as well: a
language proposal with an experimental implementation is given much higher
credence than paperware. However, they don't exclude paperware either.

So I don't think we need to rely on implementation before considering a
feature we all want, but I do agree that seeing a patch in GHC first allows
for much testing and experimentation.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Scope of committee (can we do *new* things?)

Iavor Diatchki
I disagree that we should be standardizing language features that have not been implemented.

I think having an implementation is important because:
   1. the act of implementing a feature forces you to work out details that you may not have thought of ahead of time.  For example, for a small syntactic extension, the implementation would have to work out how to fit it in the grammar, and how to present the new feature in, say, error messages.
   2. having an implementation allows users to try out the extension and gain some empirical evidence that the extension is actually useful in practice (this is hard to quantify, I know, but it is even harder if you can't even use the extension at all).

If some feature ends up being particularly useful, it could always be standardized in the next iteration of the language, when we've gained some experience using it in practice.

-Iavor
 


On Wed, May 11, 2016 at 11:17 AM, John Wiegley <[hidden email]> wrote:
>>>>> Gershom B <[hidden email]> writes:

> While such changes should definitely be in scope, I do think that the proper
> mechanism would be to garner enough interest to get a patch into GHC
> (whether through discussion on the -prime list or elsewhere) and have an
> experimental implementation, even for syntax changes, before such proposals
> are considered ready for acceptance into a standard as such.

Just a side note: This is often how the C++ committee proceeds as well: a
language proposal with an experimental implementation is given much higher
credence than paperware. However, they don't exclude paperware either.

So I don't think we need to rely on implementation before considering a
feature we all want, but I do agree that seeing a patch in GHC first allows
for much testing and experimentation.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


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

Re: Limber separators

Iavor Diatchki
In reply to this post by Jon Fairbairn

On Sat, May 7, 2016 at 1:44 AM, Jon Fairbairn <[hidden email]> wrote:


The one this violates is “never make language design decisions
to work around deficiencies in tools” The problem is that diff
does its work in ignorance of the syntax and consequently
produces poor results.


I think that this is an excellent principle that we should uphold.

 


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

Re: Scope of committee (can we do *new* things?)

Andres Loeh-5
In reply to this post by Iavor Diatchki
I think we all agree that in general, we should focus on existing
language extensions that have an implementation, and expect language
extensions to be implemented for them to be seriously considered for
inclusion in the standard.

But I think it would be wrong to turn this into a hard rule. Language
extensions are usually looked at in isolation, whereas the standard is
supposed to be a whole. There may be things that fit in well, are
useful generalizations of extensions we want to adopt, and so on that
are worth discussing. Also, extensions should perhaps be modified or
changed in some cases. If we say in advance that we can only
standardize things that GHC already implements, and only in exactly
this way, then it is a bit too limiting, and this would be throwing
away the chance to clean up a few issues.

The other side of this is that if we really arrive at the conclusion
that something should be different from the current GHC
implementations in any significant way, we should at least try to get
it implemented during, and not just after, the standardization process
so that we can still get practical feedback, and to prevent ending up
with a standard that will never be implemented.

Also (I think I've said this before), we should keep in mind that the
whole process for Haskell 2020 can have more outputs than just the new
standard itself. We can make progress towards standardization of
features in future versions of Haskell even if they don't yet make it.
We can make statements that we would in principle like to see certain
features in the standard, and identify the issues that currently
prevent them from being included.

Cheers,
  Andres

On Thu, May 12, 2016 at 9:46 PM, Iavor Diatchki
<[hidden email]> wrote:

> I disagree that we should be standardizing language features that have not
> been implemented.
>
> I think having an implementation is important because:
>    1. the act of implementing a feature forces you to work out details that
> you may not have thought of ahead of time.  For example, for a small
> syntactic extension, the implementation would have to work out how to fit it
> in the grammar, and how to present the new feature in, say, error messages.
>    2. having an implementation allows users to try out the extension and
> gain some empirical evidence that the extension is actually useful in
> practice (this is hard to quantify, I know, but it is even harder if you
> can't even use the extension at all).
>
> If some feature ends up being particularly useful, it could always be
> standardized in the next iteration of the language, when we've gained some
> experience using it in practice.
>
> -Iavor
>
>
>
> On Wed, May 11, 2016 at 11:17 AM, John Wiegley <[hidden email]>
> wrote:
>>
>> >>>>> Gershom B <[hidden email]> writes:
>>
>> > While such changes should definitely be in scope, I do think that the
>> > proper
>> > mechanism would be to garner enough interest to get a patch into GHC
>> > (whether through discussion on the -prime list or elsewhere) and have an
>> > experimental implementation, even for syntax changes, before such
>> > proposals
>> > are considered ready for acceptance into a standard as such.
>>
>> Just a side note: This is often how the C++ committee proceeds as well: a
>> language proposal with an experimental implementation is given much higher
>> credence than paperware. However, they don't exclude paperware either.
>>
>> So I don't think we need to rely on implementation before considering a
>> feature we all want, but I do agree that seeing a patch in GHC first
>> allows
>> for much testing and experimentation.
>>
>> --
>> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
>> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>> _______________________________________________
>> Haskell-prime mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
>
>
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Scope of committee (can we do *new* things?)

Richard Eisenberg-2
I strongly agree with all the points Andres makes here:
 - Focus on existing extensions
 - Permit discussion and even modification of existing behavior
 - Allow possibility of discussing new behavior
 - Strive hard to (or even require) an implementation before standardization (at the moment, time is on our side here)
 - Plan to include an appendix / co-report describing aspects of Haskell that are not yet strictly standardized

Richard

On May 12, 2016, at 4:25 PM, Andres Loeh <[hidden email]> wrote:

> I think we all agree that in general, we should focus on existing
> language extensions that have an implementation, and expect language
> extensions to be implemented for them to be seriously considered for
> inclusion in the standard.
>
> But I think it would be wrong to turn this into a hard rule. Language
> extensions are usually looked at in isolation, whereas the standard is
> supposed to be a whole. There may be things that fit in well, are
> useful generalizations of extensions we want to adopt, and so on that
> are worth discussing. Also, extensions should perhaps be modified or
> changed in some cases. If we say in advance that we can only
> standardize things that GHC already implements, and only in exactly
> this way, then it is a bit too limiting, and this would be throwing
> away the chance to clean up a few issues.
>
> The other side of this is that if we really arrive at the conclusion
> that something should be different from the current GHC
> implementations in any significant way, we should at least try to get
> it implemented during, and not just after, the standardization process
> so that we can still get practical feedback, and to prevent ending up
> with a standard that will never be implemented.
>
> Also (I think I've said this before), we should keep in mind that the
> whole process for Haskell 2020 can have more outputs than just the new
> standard itself. We can make progress towards standardization of
> features in future versions of Haskell even if they don't yet make it.
> We can make statements that we would in principle like to see certain
> features in the standard, and identify the issues that currently
> prevent them from being included.
>
> Cheers,
>  Andres
>
> On Thu, May 12, 2016 at 9:46 PM, Iavor Diatchki
> <[hidden email]> wrote:
>> I disagree that we should be standardizing language features that have not
>> been implemented.
>>
>> I think having an implementation is important because:
>>   1. the act of implementing a feature forces you to work out details that
>> you may not have thought of ahead of time.  For example, for a small
>> syntactic extension, the implementation would have to work out how to fit it
>> in the grammar, and how to present the new feature in, say, error messages.
>>   2. having an implementation allows users to try out the extension and
>> gain some empirical evidence that the extension is actually useful in
>> practice (this is hard to quantify, I know, but it is even harder if you
>> can't even use the extension at all).
>>
>> If some feature ends up being particularly useful, it could always be
>> standardized in the next iteration of the language, when we've gained some
>> experience using it in practice.
>>
>> -Iavor
>>
>>
>>
>> On Wed, May 11, 2016 at 11:17 AM, John Wiegley <[hidden email]>
>> wrote:
>>>
>>>>>>>> Gershom B <[hidden email]> writes:
>>>
>>>> While such changes should definitely be in scope, I do think that the
>>>> proper
>>>> mechanism would be to garner enough interest to get a patch into GHC
>>>> (whether through discussion on the -prime list or elsewhere) and have an
>>>> experimental implementation, even for syntax changes, before such
>>>> proposals
>>>> are considered ready for acceptance into a standard as such.
>>>
>>> Just a side note: This is often how the C++ committee proceeds as well: a
>>> language proposal with an experimental implementation is given much higher
>>> credence than paperware. However, they don't exclude paperware either.
>>>
>>> So I don't think we need to rely on implementation before considering a
>>> feature we all want, but I do agree that seeing a patch in GHC first
>>> allows
>>> for much testing and experimentation.
>>>
>>> --
>>> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
>>> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>>> _______________________________________________
>>> Haskell-prime mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>>
>>
>> _______________________________________________
>> Haskell-prime mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>

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

Re: Scope of committee (can we do *new* things?)

Carter Schonwald


On Friday, May 13, 2016, Richard Eisenberg <[hidden email]> wrote:
I strongly agree with all the points Andres makes here:
 - Focus on existing extensions
 - Permit discussion and even modification of existing behavior
 - Allow possibility of discussing new behavior
 - Strive hard to (or even require) an implementation before standardization (at the moment, time is on our side here)
 - Plan to include an appendix / co-report describing aspects of Haskell that are not yet strictly standardized

Richard


I second this summary and thus Andres' remarks. 
 
On May 12, 2016, at 4:25 PM, Andres Loeh <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;mail@andres-loeh.de&#39;)">mail@...> wrote:

> I think we all agree that in general, we should focus on existing
> language extensions that have an implementation, and expect language
> extensions to be implemented for them to be seriously considered for
> inclusion in the standard.
>
> But I think it would be wrong to turn this into a hard rule. Language
> extensions are usually looked at in isolation, whereas the standard is
> supposed to be a whole. There may be things that fit in well, are
> useful generalizations of extensions we want to adopt, and so on that
> are worth discussing. Also, extensions should perhaps be modified or
> changed in some cases. If we say in advance that we can only
> standardize things that GHC already implements, and only in exactly
> this way, then it is a bit too limiting, and this would be throwing
> away the chance to clean up a few issues.
>
> The other side of this is that if we really arrive at the conclusion
> that something should be different from the current GHC
> implementations in any significant way, we should at least try to get
> it implemented during, and not just after, the standardization process
> so that we can still get practical feedback, and to prevent ending up
> with a standard that will never be implemented.
>
> Also (I think I've said this before), we should keep in mind that the
> whole process for Haskell 2020 can have more outputs than just the new
> standard itself. We can make progress towards standardization of
> features in future versions of Haskell even if they don't yet make it.
> We can make statements that we would in principle like to see certain
> features in the standard, and identify the issues that currently
> prevent them from being included.
>
> Cheers,
>  Andres
>
> On Thu, May 12, 2016 at 9:46 PM, Iavor Diatchki
> <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;iavor.diatchki@gmail.com&#39;)">iavor.diatchki@...> wrote:
>> I disagree that we should be standardizing language features that have not
>> been implemented.
>>
>> I think having an implementation is important because:
>>   1. the act of implementing a feature forces you to work out details that
>> you may not have thought of ahead of time.  For example, for a small
>> syntactic extension, the implementation would have to work out how to fit it
>> in the grammar, and how to present the new feature in, say, error messages.
>>   2. having an implementation allows users to try out the extension and
>> gain some empirical evidence that the extension is actually useful in
>> practice (this is hard to quantify, I know, but it is even harder if you
>> can't even use the extension at all).
>>
>> If some feature ends up being particularly useful, it could always be
>> standardized in the next iteration of the language, when we've gained some
>> experience using it in practice.
>>
>> -Iavor
>>
>>
>>
>> On Wed, May 11, 2016 at 11:17 AM, John Wiegley <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;johnw@newartisans.com&#39;)">johnw@...>
>> wrote:
>>>
>>>>>>>> Gershom B <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;gershomb@gmail.com&#39;)">gershomb@...> writes:
>>>
>>>> While such changes should definitely be in scope, I do think that the
>>>> proper
>>>> mechanism would be to garner enough interest to get a patch into GHC
>>>> (whether through discussion on the -prime list or elsewhere) and have an
>>>> experimental implementation, even for syntax changes, before such
>>>> proposals
>>>> are considered ready for acceptance into a standard as such.
>>>
>>> Just a side note: This is often how the C++ committee proceeds as well: a
>>> language proposal with an experimental implementation is given much higher
>>> credence than paperware. However, they don't exclude paperware either.
>>>
>>> So I don't think we need to rely on implementation before considering a
>>> feature we all want, but I do agree that seeing a patch in GHC first
>>> allows
>>> for much testing and experimentation.
>>>
>>> --
>>> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
>>> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>>> _______________________________________________
>>> Haskell-prime mailing list
>>> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Haskell-prime@haskell.org&#39;)">Haskell-prime@...
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>>
>>
>> _______________________________________________
>> Haskell-prime mailing list
>> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Haskell-prime@haskell.org&#39;)">Haskell-prime@...
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>

_______________________________________________
Haskell-prime mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Haskell-prime@haskell.org&#39;)">Haskell-prime@...
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

Re: Scope of committee (can we do *new* things?)

Henrik Nilsson-2
In reply to this post by Richard Eisenberg-2
Hi all,

I too basically agree with Andres's points and Richard's summary.

But there are a fair few existing extensions, and they are
not all equally compelling or urgent.

(Just to exemplify, multi-parameter type classes (which in practice
necessitates functional dependencies or broadly equivalent
functionality) and GADTs have been mentioned to me as particularly
urgent a fair few times.)

So, with risk of stating the obvious, a bit of care is needed to
decide just which existing extensions should be at the top of the
agenda.

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.

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

Re: Limber separators

Antonio Nikishaev
In reply to this post by Iavor Diatchki

> On 12 May 2016, at 23:48, Iavor Diatchki <[hidden email]> wrote:
>
>
> On Sat, May 7, 2016 at 1:44 AM, Jon Fairbairn <[hidden email]> wrote:
>
>
> The one this violates is “never make language design decisions
> to work around deficiencies in tools” The problem is that diff
> does its work in ignorance of the syntax and consequently
> produces poor results.
>
>
> I think that this is an excellent principle that we should uphold.


Personally I don't need this extension per se since I don't care about one excess diff line.
What I do care about however, is the horrendous style people invented to avoid “the diff problem”.
As an example

something = [ foo
            , bar
            , baz
            ]

So I’d really like to see this extension, even if only to conquer the aforementioned style.



PS    But this all is indeed a little bikeshedding before we finish the “Infrastructure & Communication” thread.



--
lelf

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

Re: Limber separators

Herbert Valerio Riedel-3
On 2016-05-31 at 15:42:14 +0200, Antonio Nikishaev wrote:

[...]

> Personally I don't need this extension per se since I don't care about one excess diff line.
> What I do care about however, is the horrendous style people invented to avoid “the diff problem”.
> As an example
>
> something = [ foo
>             , bar
>             , baz
>             ]

I'm not sure this style was invented to address the diff-problem, as it
actually doesn't solve the problem at all; it only shifts the problem
from the last entry to the first entry in the enumeration.

Moreover, why do you call this a "horrendous" style?

I actually see benefits for trailing separators as you avoid the
separator-alignment problem you'd have with trailing separators:

You either have to use a ragged alignment (and in this case the `,`s are
IMHO hard to see as they're visually attached to their entries; one can
add a whitespace before the `,` though)

 something = [
     one,
     thirteen,
     two,
     three
 ]

or if you align the `,`s on the same column to make move separators
visually out of the way, i.e.

 something = [
     one      ,
     thirteen ,
     two      ,
     three
 ]

you may run into a worse diff-problem, once you add an entry that is
longer and would require to realign all `,`s.

That's why I personally consider the "horrendous" style (and I even
catch myself sometimes using this in non-Haskell), i.e.

 something =
     [ one
     , thirteen
     , two
     , three
     ]

to have quit a few benefits in its own right. And while I don't *need*
this extension either, I've been tempted to implement such an extension
myself every now and then when I refactor code and fail to move the `,`s
around, resulting in an at least one additional edit-save-recompile
cycle.

> So I’d really like to see this extension, even if only to conquer the
> aforementioned style.

:-)

Well, I'd really like to see the grammar relaxed to allow for redundant
leading separators so I could finally use my personal ideal
diff-friendly style:

 something = [
     , one
     , thirteen
     , two
     , three
     ]
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Limber separators

Alexander Berntsen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/06/16 08:44, Herbert Valerio Riedel wrote:

> Well, I'd really like to see the grammar relaxed to allow for redundant
> leading separators so I could finally use my personal ideal
> diff-friendly style:
>
>  something = [
>      , one
>      , thirteen
>      , two
>      , three
>      ]
If your ideal style uses every entry on one line regardless of how
short it is (in terms of character count), then surely simply 'ENTRY\n'
is better than ', ENTRY\n'? At least my preference in that case would be
no comma, or a trailing comma.
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXTq2NAAoJENQqWdRUGk8BZJMQAL5CGwQyVUJJP/oMUw7DpnI2
gXb/3uYF+Od6GAKLHZnPB4G2+fq7xXvINENki2T6u0/Va4FeQ/xTLrccR7j3o++1
c4LtxctUjpEz321Hi/v4Zq3JZL5XY6z39dZwUx0cMcCmUXk1+aVzmQGh1S4Y+/3E
ICHyAOESUB6vlMeL492qVGtD6drkstuQaDTKn/kry/jTgnAabcIa9hJ5EWj4DMFW
jTcpkDD8kLFTPlKN+ky8bN02RmMVkC8jZe5n1+S4WhWVK7Fixsib5nE5qaYl73Wq
FCFf2b8FKkoCyAMTfJmdZt2yXgl30+/DAJa60E7I40uh98Ak1uH1V02cpOOVt3FU
dgH1TWP/TP36VZ+HpJ85vdrbdioG5aQar4aeFVosd6vbIQNhiCKjcfR4aLo6C1Bg
zfORQtpzqq11M6SHTZG91L4+Ti/y4vfFE/qnY1YhP5dpTblT7TJRP/s4eQwXnfYs
GmhCOeev43P6mNL9TXyz4OkLzxrgdEzYWgdlGn88gg8dHIj5+BOxJNw9uJgb4iRq
ovz+efoGGN3lk3prNeD6VO7BZ6WRu3mi7JJcX2nmjyfOGK2tQE9eYuFS/oevkJwE
zFI7RAwi/UecN9jJ1do+zq/DBjQo2bRJnlswhwAdLxqhyyhxNuMvQdklibhlWsrZ
Irj2614mavqB67f3Os7k
=ojRm
-----END PGP SIGNATURE-----
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
12