date:20130819

 Brent Yorgey byorgey at seas.upenn.edu writes:
  
  data Oneple a = Oneple a   -- (or newtype)
  (Oneple $ CustId 47)   -- too verbose
  
 
 This is what the OneTuple package is for:
 

Thank you Brent, and Ivan made the same suggestion.

Apart from being more verbose (2 extra chars) than the approach I disliked 
as being too verbose, does OneTuple have any merit?

 Dan Burton danburton.email at gmail.com 
 Fri Aug 16 03:04:14 UTC 2013 
claims that 
 T(CustId 47) is just one character off from what you actually want ...

(Bare T is very likely to be used already.)

But not only do I want to construct Oneples, I also want to pattern match 
and discriminate on their type in instances:

f (T(CustId x)) = ...

instance C (Oneple (CustId Int)) ...


I'm sensing there must be a need (since OneTuple is claimed to be a 
solution for it).

Would double-parens be too wild an idea?:

... ((CustId 47)) `extend` (CustName Fred, Gender Male)

f ((CustId x)) = ...

instance C ((CustId Int)) ...

We'd have to avoid the double parens as in:

((meth obj) (double x))





___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] One-element tuple

2013-08-19 Thread Daniel F

Can you please elaborate why this inconsistency is annoying and what's the
use of OneTuple?
Genuine question,
thanks.


On Fri, Aug 16, 2013 at 5:35 AM, AntC anthony_clay...@clear.net.nz wrote:

 There's an annoying inconsistency:

 (CustId 47, CustName Fred, Gender Male)  -- threeple
 (CustId 47, CustName Fred)-- twople
 --  (CustId 47)-- oneple not!
 () -- nople

 (That is, it's annoying if you're trying to make typeclass instances for
 extensible/contractable tuples. Yes, I know I could use HLists.)

 I'm not happy with either approach I've tried:

 data Oneple a = Oneple a   -- (or newtype)
 (Oneple $ CustId 47)   -- too verbose

 type Oneple a = [a]
 [CustId 47]  -- at least looks bracket-y

 What do you do?

 AntC



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe




-- 
Sincerely yours,
-- Daniil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ordNub

 Richard A. O'Keefe ok at cs.otago.ac.nz writes:
 
 There are at least four different things that an Ord version might
 mean:
 
  - first sort a list, then eliminate duplicates
  - sort a list eliminating duplicates stably as you go
(think 'merge sort', using 'union' instead of 'merge')
  - build a balanced tree set as you go
  - having a list that is already sorted, use that to
eliminated duplicates cheaply.
 
 These things have different costs.  For example, ...
 
 What I want is more often ordNubBy than ordNub, though.
 

(ordNubBy you can get via a suitable Ord instance for the element type?)

The bigger problem is that you might not have a suitable Ord instance. 
After all, sets are defined by equality/equivalence relation, not 
necessarily by Ord.

There are many other things you might want to do with a set/collection 
than just remove duplicates.

I notice that Data.Set.map = fromList . (map stuff) . toList
That is, build two lists (to be GC'd), as well as the set result. 

So does the performane cost of from/to List outrun the benefit of 
Data.Set.union? Depends how much you're mapping vs inserting and checking 
membership.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] One-element tuple

2013-08-19 Thread adam vogt

On Mon, Aug 19, 2013 at 5:40 AM, AntC anthony_clay...@clear.net.nz wrote:
...
 Would double-parens be too wild an idea?:

 ... ((CustId 47)) `extend` (CustName Fred, Gender Male)

 f ((CustId x)) = ...

 instance C ((CustId Int)) ...

 We'd have to avoid the double parens as in:

 ((meth obj) (double x))


Hi Anthony,

This preprocessor I just threw together doesn't seem to suffers from
those issues http://lpaste.net/91967. This kind of approach probably
might let you steal T(..) while still allowing `T (..)' to refer to
whatever is the original, though I think that would require working
with the messier Annotated syntax tree.

Regards,
Adam

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GHC and backwards compatibility

2013-08-19 Thread Ketil Malde


I recently encountered the following problem:


$ cabal install
Resolving dependencies...
Configuring array-0.4.0.1...
Building array-0.4.0.1...
Preprocessing library array-0.4.0.1...

Data/Array/IArray.hs:1:14: Unsupported extension: Trustworthy
cabal: Error: some packages failed to install:
array-0.4.0.1 failed during the building phase. The exception was:
ExitFailure 1
asmeval-0 depends on array-0.4.0.1 which failed to install.
binary-0.7.1.0 depends on array-0.4.0.1 which failed to install.
biocore-0.3.1 depends on array-0.4.0.1 which failed to install.
biofasta-0.0.3 depends on array-0.4.0.1 which failed to install.
biopsl-0.4 depends on array-0.4.0.1 which failed to install.
biosff-0.3.3 depends on array-0.4.0.1 which failed to install.
bytestring-0.10.2.0 depends on array-0.4.0.1 which failed to install.
containers-0.5.2.1 depends on array-0.4.0.1 which failed to install.
deepseq-1.3.0.1 depends on array-0.4.0.1 which failed to install.
hashable-1.2.0.10 depends on array-0.4.0.1 which failed to install.
stringable-0.1.1 depends on array-0.4.0.1 which failed to install.
system-filepath-0.4.7 depends on array-0.4.0.1 which failed to install.
text-0.11.3.1 depends on array-0.4.0.1 which failed to install.
unordered-containers-0.2.3.1 depends on array-0.4.0.1 which failed to install.


The installed GHC is 7.0.4, and yes, that's many major versions ago, but
then again, it's only two years old, and from what I understand, it is
shipped by some conservative Linux distributions.

The problems here are that:

a) the installation tries to install array, but current array requires
the Trustworthy extension, which appeared in 7.2.1.  Ideally, packages
should try to be backwards compatible, e.g. by using conditional
sections.

b) the output isn't very helpful in tracking down the cause of this
problem, it claims that all these packages depend on array-0.4.0.1,
which is a lie.  Somewhere, somehow, somethings depends on this (or at
least a newer version), but I have no clue how to figure out which,
except examining each of these packages and their dependencies manually.
 
It is also possible that array shouldn't be upgraded like this, but then
that needs to be made clear to cabal somehow, so that I don't spend ages
trying to.

Are there any solutions to this?  Advice on how to proceed?

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC and backwards compatibility

2013-08-19 Thread Joe Q

This is definitely an issue with the array package not setting the right
minimum versions. You should email the maintainer.
On Aug 19, 2013 11:05 AM, Ketil Malde ke...@malde.org wrote:


 I recently encountered the following problem:


 
 $ cabal install
 Resolving dependencies...
 Configuring array-0.4.0.1...
 Building array-0.4.0.1...
 Preprocessing library array-0.4.0.1...

 Data/Array/IArray.hs:1:14: Unsupported extension: Trustworthy
 cabal: Error: some packages failed to install:
 array-0.4.0.1 failed during the building phase. The exception was:
 ExitFailure 1
 asmeval-0 depends on array-0.4.0.1 which failed to install.
 binary-0.7.1.0 depends on array-0.4.0.1 which failed to install.
 biocore-0.3.1 depends on array-0.4.0.1 which failed to install.
 biofasta-0.0.3 depends on array-0.4.0.1 which failed to install.
 biopsl-0.4 depends on array-0.4.0.1 which failed to install.
 biosff-0.3.3 depends on array-0.4.0.1 which failed to install.
 bytestring-0.10.2.0 depends on array-0.4.0.1 which failed to install.
 containers-0.5.2.1 depends on array-0.4.0.1 which failed to install.
 deepseq-1.3.0.1 depends on array-0.4.0.1 which failed to install.
 hashable-1.2.0.10 depends on array-0.4.0.1 which failed to install.
 stringable-0.1.1 depends on array-0.4.0.1 which failed to install.
 system-filepath-0.4.7 depends on array-0.4.0.1 which failed to install.
 text-0.11.3.1 depends on array-0.4.0.1 which failed to install.
 unordered-containers-0.2.3.1 depends on array-0.4.0.1 which failed to
 install.

 

 The installed GHC is 7.0.4, and yes, that's many major versions ago, but
 then again, it's only two years old, and from what I understand, it is
 shipped by some conservative Linux distributions.

 The problems here are that:

 a) the installation tries to install array, but current array requires
 the Trustworthy extension, which appeared in 7.2.1.  Ideally, packages
 should try to be backwards compatible, e.g. by using conditional
 sections.

 b) the output isn't very helpful in tracking down the cause of this
 problem, it claims that all these packages depend on array-0.4.0.1,
 which is a lie.  Somewhere, somehow, somethings depends on this (or at
 least a newer version), but I have no clue how to figure out which,
 except examining each of these packages and their dependencies manually.

 It is also possible that array shouldn't be upgraded like this, but then
 that needs to be made clear to cabal somehow, so that I don't spend ages
 trying to.

 Are there any solutions to this?  Advice on how to proceed?

 -k
 --
 If I haven't seen further, it is by standing in the footprints of giants

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] abs minBound (0 :: Int) negate minBound == (minBound :: Int)

2013-08-19 Thread Kyle Miller

On Sun, Aug 18, 2013 at 8:04 PM, Richard A. O'Keefe o...@cs.otago.ac.nzwrote:

 The argument for twos-complement, which always puzzled me, is that the
 other
 systems have two ways to represent zero.  I never found this to be a
 problem,
 not even for bitwise operations, on the B6700.  I *did* find abs x  0
 succeeding to be a pain in the posterior.  (The B6700 had two different
 tests:
 'are these two numbers equal' and 'are these two bit patterns equal'.)


I think a better argument for twos complement is that you're just doing all
of your computations modulo 2^n (where n is 32 or 64 or whatever), and
addition and multiplication work as expected modulo anything.  The idea of
negative and positive in a system like this is artificial, though.  The
standard convention follows from the observation that 0-1 should be -1, and
if you use the hardware that is for positive numbers, and assume that you
can always carry another 1 for the highest order bit, then 0-1 is
...111.  It's not that 2^n - 1 is actually -1, but that it acts like a
-1 would act.  It's only by convention that numbers which begin with a 1
are considered to be negative (that, and Intel has special hardware for
detecting if a number has its leading 1 set).

However, we could adopt the convention that you need two leading ones to
make a negative number, and everything would work out, except for the
inequality testing built into the CPU.  This would give us a lot more
positive numbers, and then abs wouldn't have this problem :-)

Or, three other options: 1) make MIN_INT outside the domain of abs, 2) make
the range of abs be some unsigned int type, or 3) use Integer (i.e., use a
type which actually represents integers rather than a type which can only
handle small integers).

Kyle
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] abs minBound (0 :: Int) negate minBound == (minBound :: Int)

On Mon, Aug 19, 2013 at 11:43 AM, Kyle Miller kmill31...@gmail.com wrote:

 Or, three other options: 1) make MIN_INT outside the domain of abs, 2)
 make the range of abs be some unsigned int type, or 3) use Integer (i.e.,
 use a type which actually represents integers rather than a type which can
 only handle small integers).


I think I would just document that Int is intended to represent a machine
word and therefore inherits the behavior of machine words, behavior at its
extrema is subject to the CPU behavior as a result, and if consistent
behavior is required then Integer should be used. (Indeed, it should
probably note that Int is a performance hack; but then you run into all the
Data.List etc. functions that use it.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Errors in non-monadic code

Hi,

What is the proper way to implement a non-monadic function that checks
whether a given value is correct and gives a proper error message
otherwise ? What is the recommended option ?

* Either String a

check val
  | valid val = Right val
  | otherwise = Left errorMsg


* Maybe String

check val
  | valid val = Nothing
  | otherwise = Just errorMsg


Cheers,
Jose

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

2013-08-19 Thread Daniel F

On Mon, Aug 19, 2013 at 9:48 PM, jabolo...@google.com wrote:

 Hi,


Hello!


 What is the proper way to implement a non-monadic function that checks
 whether a given value is correct and gives a proper error message
 otherwise ? What is the recommended option ?


I am not sure, what do you mean by non-monadic. Both (Either String) and
Maybe are monads.

You can pick up whatever option you like, depending on which option, in
your opinion, suits you better for your specific case.
There is also a helpful errors [1] package that provide convenient means of
converting between the results of the two approaches.

Control.Error.Util.hush :: Either a b - Maybe b
Control.Error.Util.note :: a - Maybe b - Either a b


 * Either String a

 check val
   | valid val = Right val
   | otherwise = Left errorMsg


 * Maybe String

 check val
   | valid val = Nothing
   | otherwise = Just errorMsg


 Cheers,
 Jose

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


[1] http://hackage.haskell.org/package/errors

-- 
Sincerely yours,
-- Daniil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

On Mon, Aug 19, 2013 at 1:48 PM, jabolo...@google.com wrote:

 What is the proper way to implement a non-monadic function that checks
 whether a given value is correct and gives a proper error message
 otherwise ? What is the recommended option ?

 * Either String a


Preferred, usually, since Nothing is regarded as an error condition of
sorts: the Monad instance for Maybe associates Nothing with `fail`, which
is invoked on failed pattern matches; likewise it's mzero for MonadPlus and
mempty for Monoid, both of which use it (differently) to reflect certain
failure scenarios).

If nothing else, it would be highly confusing to see Nothing associated
with success given its widespread association with failure.

Alternatively, have you considered using your own ADT? `data Validity =
Success | Failure String` would give you more readable / comprehensible
code without needing to worry about assumptions or common usage.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] wxHaskell mailinglist

2013-08-19 Thread Nathan Hüsken


Hey,

Anyone knows what the proper channel for reporting bugs and asking 
questions about wxHaskell is?
The github page https://github.com/wxHaskell/wxHaskell/wiki seems to 
have issues disabled, and when I post to the wxHaskell user mailinglist, 
it tells me that the list is moderated. But my post did not get accepted 
for the last 2 days.


Regards,
Nathan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

Yeah, non-monadic is not the best term... The problem is that it's
always so hard to communicate when you want to say a total function
that is not in the context of the IO monad. There should be a simple,
short name for these functions, so we can easily talk about them.

What ends up happening a lot of the times is that people on the
mailing list call these pure functions, and immediately they get an
email saying that Haskell is pure, so everything is a pure
function. In the end, it doesn't really help...

Jose

On Mon, Aug 19, 2013 at 10:09:13PM +0400, Daniel F wrote:
 On Mon, Aug 19, 2013 at 9:48 PM, jabolo...@google.com wrote:
 
  Hi,
 
 
 Hello!
 
 
  What is the proper way to implement a non-monadic function that checks
  whether a given value is correct and gives a proper error message
  otherwise ? What is the recommended option ?
 
 
 I am not sure, what do you mean by non-monadic. Both (Either String) and
 Maybe are monads.
 
 You can pick up whatever option you like, depending on which option, in
 your opinion, suits you better for your specific case.
 There is also a helpful errors [1] package that provide convenient means of
 converting between the results of the two approaches.
 
 Control.Error.Util.hush :: Either a b - Maybe b
 Control.Error.Util.note :: a - Maybe b - Either a b
 
 
  * Either String a
 
  check val
| valid val = Right val
| otherwise = Left errorMsg
 
 
  * Maybe String
 
  check val
| valid val = Nothing
| otherwise = Just errorMsg
 
 
  Cheers,
  Jose
 
  ___
  Haskell-Cafe mailing list
  Haskell-Cafe@haskell.org
  http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 
 [1] http://hackage.haskell.org/package/errors
 
 -- 
 Sincerely yours,
 -- Daniil

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

On Mon, Aug 19, 2013 at 2:09 PM, Brandon Allbery allber...@gmail.comwrote:

 Alternatively, have you considered using your own ADT? `data Validity =
 Success | Failure String` would give you more readable / comprehensible
 code without needing to worry about assumptions or common usage.


Or possibly Valid and Invalid as the constructors

This also means you can easily extend it later to include multiple errors,
or position information, or other annotations. You could also use it with
Monoid and/or the Writer monad to track success/failure in the most
appropriate way for your project, instead of being constrained to the
behavior of an existing instance.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

2013-08-19 Thread Tom Ellis

On Mon, Aug 19, 2013 at 02:20:23PM -0400, jabolo...@google.com wrote:
 Yeah, non-monadic is not the best term... The problem is that it's
 always so hard to communicate when you want to say a total function
 that is not in the context of the IO monad. There should be a simple,
 short name for these functions, so we can easily talk about them.

Why, what would be different in your question for a non-total function or
one in the context of the IO monad?

Tom

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC and backwards compatibility

2013-08-19 Thread Ketil Malde


Joe Q headprogrammingc...@gmail.com writes:

 This is definitely an issue with the array package not setting the right
 minimum versions. You should email the maintainer.

Yes, that would be the thing to do, except that the maintainer is
librar...@haskell.org, whom I believe does not accept emails from me.
:-(

But if you (or anybody else) subscribes to the list, perhaps you could
forward?

In any case, one of the dependencies uses Stringable, which means that a
newer GHC is probably still required.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

I'd say that if you were in the context of the IO monad, maybe you'd
prefer to use exceptions instead of 'Either' or 'Maybe'.

Jose

On Mon, Aug 19, 2013 at 07:41:48PM +0100, Tom Ellis wrote:
 On Mon, Aug 19, 2013 at 02:20:23PM -0400, jabolo...@google.com wrote:
  Yeah, non-monadic is not the best term... The problem is that it's
  always so hard to communicate when you want to say a total function
  that is not in the context of the IO monad. There should be a simple,
  short name for these functions, so we can easily talk about them.
 
 Why, what would be different in your question for a non-total function or
 one in the context of the IO monad?
 
 Tom
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

On Mon, Aug 19, 2013 at 2:59 PM, jabolo...@google.com wrote:

 I'd say that if you were in the context of the IO monad, maybe you'd
 prefer to use exceptions instead of 'Either' or 'Maybe'.


Even in IO, exceptions should be reserved for truly exceptional conditions
(of the program cannot safely continue variety), not merely for error
checking when this can be described as a normal flow of evaluation.
Exceptions are not simply alternative flow of control, even in procedural
languages; they are *disruptions* of flow of control.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

2013-08-19 Thread Tobias Dammers

Except that people generally don't seem to agree what constitutes
'exceptional', even when disregarding the python world...
On Aug 19, 2013 9:24 PM, Brandon Allbery allber...@gmail.com wrote:

 On Mon, Aug 19, 2013 at 2:59 PM, jabolo...@google.com wrote:

 I'd say that if you were in the context of the IO monad, maybe you'd
 prefer to use exceptions instead of 'Either' or 'Maybe'.


 Even in IO, exceptions should be reserved for truly exceptional conditions
 (of the program cannot safely continue variety), not merely for error
 checking when this can be described as a normal flow of evaluation.
 Exceptions are not simply alternative flow of control, even in procedural
 languages; they are *disruptions* of flow of control.

 --
 brandon s allbery kf8nh   sine nomine
 associates
 allber...@gmail.com
 ballb...@sinenomine.net
 unix, openafs, kerberos, infrastructure, xmonad
 http://sinenomine.net

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

2013-08-19 Thread Donn Cave

jabolo...@google.com,
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
In-Reply-To: 
CAKFCL4VfY-Dz3Xo9ZUZ_SmfRQ2nLGDLbovU=suf1-ssnqvs...@mail.gmail.com
References: CAKFCL4VfY-Dz3Xo9ZUZ_SmfRQ2nLGDLbovU=suf1-ssnqvs...@mail.gmail.com

quoth Brandon Allbery,

 Even in IO, exceptions should be reserved for truly exceptional conditions
 (of the program cannot safely continue variety), not merely for error
 checking when this can be described as a normal flow of evaluation.
 Exceptions are not simply alternative flow of control, even in procedural
 languages; they are *disruptions* of flow of control.

I think that would be debatable, especially as applied to procedural languages
in general.  It's very common to use exceptions in routine flow of control in
Python programs, if I remember right.  Meanwhile, the Haskell library in my
opinion somewhat weakens your case by making ordinary conditions into 
exceptions,
for example end-of-file.  

In the end it's a large grey area.  Ideally, what the program has to do, or
whether it can even continue at all, is determined by the program using
information reported by the function that encounters the error.  If there's
a good reason why exceptions should be used only when the program won't be
able to continue, it must be that the language's exception handling facililty
isn't very robust.

Donn

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] librar...@haskell.org (was: GHC and backwards compatibility)

2013-08-19 Thread Joe Quinn


On 8/19/2013 2:43 PM, Ketil Malde wrote:

Joe Q headprogrammingc...@gmail.com writes:


This is definitely an issue with the array package not setting the right
minimum versions. You should email the maintainer.

Yes, that would be the thing to do, except that the maintainer is
librar...@haskell.org, whom I believe does not accept emails from me.
:-(

But if you (or anybody else) subscribes to the list, perhaps you could
forward?

In any case, one of the dependencies uses Stringable, which means that a
newer GHC is probably still required.

-k


The libraries@ address is just a mailman list. Perhaps it should be set 
to allow non-subscribers to post. Not allowing the general public to 
email the posted maintainer of the standard library is ridiculous.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

I agree that whether to use exceptions or not is a very debatable
subject and it is a grey area.

Still, in your Python example, I would like to point out that just
because something is common, it does not mean it is the right thing to
do.  For example, something that some Java programmers were doing a
lot was to loop through an array and, instead of using a counter, they
were catching the array out of bounds exception. This is clearly not
the right thing to do!

But I would like to see more code move away from exceptions and into
types like Maybe or Either or other types defined for the
particular situation (as some people were suggesting in the beginning
of the thread). And the reason for this it is because when you program
against types you have to make a decision whether to handle the error
or let it bleed through: you can't ignore the choice because you can't
ignore the type. On the other hand, with exceptions, you can easily
forget to handle the exception if you're not looking at the
documentation at the time when you write the code.

Jose

On Mon, Aug 19, 2013 at 01:12:13PM -0700, Donn Cave wrote:
 jabolo...@google.com,
 MIME-Version: 1.0
 Content-type: text/plain; charset=UTF-8
 In-Reply-To: 
 CAKFCL4VfY-Dz3Xo9ZUZ_SmfRQ2nLGDLbovU=suf1-ssnqvs...@mail.gmail.com
 References: 
 CAKFCL4VfY-Dz3Xo9ZUZ_SmfRQ2nLGDLbovU=suf1-ssnqvs...@mail.gmail.com
 
 quoth Brandon Allbery,
 
  Even in IO, exceptions should be reserved for truly exceptional conditions
  (of the program cannot safely continue variety), not merely for error
  checking when this can be described as a normal flow of evaluation.
  Exceptions are not simply alternative flow of control, even in procedural
  languages; they are *disruptions* of flow of control.
 
 I think that would be debatable, especially as applied to procedural languages
 in general.  It's very common to use exceptions in routine flow of control in
 Python programs, if I remember right.  Meanwhile, the Haskell library in my
 opinion somewhat weakens your case by making ordinary conditions into 
 exceptions,
 for example end-of-file.  
 
 In the end it's a large grey area.  Ideally, what the program has to do, or
 whether it can even continue at all, is determined by the program using
 information reported by the function that encounters the error.  If there's
 a good reason why exceptions should be used only when the program won't be
 able to continue, it must be that the language's exception handling facililty
 isn't very robust.
 
   Donn
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

2013-08-19 Thread Tom Ellis

On Mon, Aug 19, 2013 at 05:15:39PM -0400, jabolo...@google.com wrote:
 But I would like to see more code move away from exceptions and into
 types like Maybe or Either or other types defined for the
 particular situation (as some people were suggesting in the beginning
 of the thread). And the reason for this it is because when you program
 against types you have to make a decision whether to handle the error
 or let it bleed through: you can't ignore the choice because you can't
 ignore the type. On the other hand, with exceptions, you can easily
 forget to handle the exception if you're not looking at the
 documentation at the time when you write the code.

This is /exactly/ the reason to avoid exceptions where possible.

Tom

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

2013-08-19 Thread Patrick Mylund Nielsen

On Mon, Aug 19, 2013 at 5:24 PM, Tom Ellis 
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:

 On Mon, Aug 19, 2013 at 05:15:39PM -0400, jabolo...@google.com wrote:
  But I would like to see more code move away from exceptions and into
  types like Maybe or Either or other types defined for the
  particular situation (as some people were suggesting in the beginning
  of the thread). And the reason for this it is because when you program
  against types you have to make a decision whether to handle the error
  or let it bleed through: you can't ignore the choice because you can't
  ignore the type. On the other hand, with exceptions, you can easily
  forget to handle the exception if you're not looking at the
  documentation at the time when you write the code.

 This is /exactly/ the reason to avoid exceptions where possible.

 Tom


And tangentially related, it's why Go uses error return values (with
functions being able to return multiple values), e.g.
http://blog.golang.org/error-handling-and-go
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

2013-08-19 Thread Jerzy Karczmarczuk


jabolo...@google.com :

I would like to see more code move away from exceptions and into
types like Maybe or Either or other types defined for the
particular situation (as some people were suggesting in the beginning
of the thread). And the reason for this it is because when you program
against types you have to make a decision whether to handle the error
or let it bleed through: you can't ignore the choice because you can't
ignore the type. On the other hand, with exceptions, you can easily
forget to handle the exception if you're not looking at the
documentation at the time when you write the code.


Tom Ellis:


This is/exactly/  the reason to avoid exceptions where possible.


I disagree.

Types which neutralize some particular conditions (whether you call them 
exceptional or not is conventional) and propagate Nothing etc. is not 
a panacea.
Some exceptions, e.g. in the traversal of deep structures may be and ARE 
used as escaping continuations. Calling all that not the right thing to 
do, or issuing other normative statements is, how would I express it... 
, is not the right thing to do. Now you can add here some dozen smileys...


More seriously, some people like exquisite continuations and will use 
them. Instead of fighting against exceptions it might be more fruitful 
to make them more robust, powerful, parametrable and sexy.



Jerzy Karczmarczuk

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

 Some exceptions, e.g. in the traversal of deep structures may be and
 ARE used as escaping continuations.

If I understand correctly, by escaping continuations you mean that
you can easily transfer control between the point where the exception
is raised and the exception handler.

If this is what you mean, you can achieve the same effect with monadic
code by chaining monads together, for example, you can have your
structure traversal code as several 'Maybe' functions.

And if I understand correctly the underlying technical details of
Haskell, because of continuation-passing style, the control transfer
should be simpler because it comes down to invoking the proper
continuation, so all of that code that compilers have to generate to
look into the stack and find the proper exception handler, and unwind
the stack and transfer control, is avoided.

Jose

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC and backwards compatibility

2013-08-19 Thread Albert Y. C. Lai


On 13-08-19 10:58 AM, Ketil Malde wrote:

b) the output isn't very helpful in tracking down the cause of this
problem, it claims that all these packages depend on array-0.4.0.1,
which is a lie.  Somewhere, somehow, somethings depends on this (or at
least a newer version), but I have no clue how to figure out which,
except examining each of these packages and their dependencies manually.


cabal install -v3 contains the complete record of deliberation. 
Although it's long, I know how to read it.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

2013-08-19 Thread Jerzy Karczmarczuk


Le 20/08/2013 00:19, jabolo...@google.com a écrit :

If I understand correctly, by escaping continuations you mean that
you can easily transfer control between the point where the exception
is raised and the exception handler.

If this is what you mean, you can achieve the same effect with monadic
code by chaining monads together


Yes.

José, this is mainly the question of efficiency. You don't need to 
establish contact between the distant stack frames, and you may 
propagate failures if this happens seldom. But if the escaping 
continuation is a frequent case, it might be more economic to jump. 
This is as simple as that.


Jerzy Karczmarczuk


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Errors in non-monadic code

2013-08-19 Thread Tom Ellis

On Tue, Aug 20, 2013 at 12:25:44AM +0200, Jerzy Karczmarczuk wrote:
 Le 20/08/2013 00:19, jabolo...@google.com a écrit :
 If I understand correctly, by escaping continuations you mean that
 you can easily transfer control between the point where the exception
 is raised and the exception handler.
 
 If this is what you mean, you can achieve the same effect with monadic
 code by chaining monads together
 
 José, this is mainly the question of efficiency. You don't need to
 establish contact between the distant stack frames, and you may
 propagate failures if this happens seldom. But if the escaping
 continuation is a frequent case, it might be more economic to
 jump. This is as simple as that.

That's all very well, in which case I wish implementors of such code would
wrap their possibly-exception-throwing values in a

newtype ThisMightThrowAnException a = ThisMightThrowAnException a

monad.  Then at least we'd all know.

Tom

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Categories with associated constraints?

2013-08-19 Thread Conal Elliott

Has anyone given a go at a Category class and friends (including cartesian
and closed) with associated constraints (presumably using the
ConstraintKinds language extension)? I gave it a try a while back and
wasn't able to keep the signatures from getting very complicated.

Thanks,   -- Conal
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Categories with associated constraints?

2013-08-19 Thread Carter Schonwald

I've not seen such, Mike Izbicki has something related for most of the
other standard classes (though i've not looked closely at it myself)

http://hackage.haskell.org/package/ConstraintKinds-1.1.0.0


On Mon, Aug 19, 2013 at 6:45 PM, Conal Elliott co...@conal.net wrote:

 Has anyone given a go at a Category class and friends (including cartesian
 and closed) with associated constraints (presumably using the
 ConstraintKinds language extension)? I gave it a try a while back and
 wasn't able to keep the signatures from getting very complicated.

 Thanks,   -- Conal

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] One-element tuple

 Daniel F difrumin at gmail.com writes:
 
 Can you please elaborate why this inconsistency is annoying and what's 
the use of OneTuple?
 Genuine question,

Hi Daniel, the main annoyance is the verbosity (of using a data type and 
constructor), and that it no longer looks like a tuple.

The inconsistency is because a one-element tuple is just as cromulent as a 
n-element, or a zero-element. (And that a one-element tuple is a distinct 
type from the element on its own/un-tupled.)

So if I have instances (as I do) like:

instance C (a, b) ...
instance C () ...

I can't usefully put either of these next two, because they're equiv to 
the third:

instance C (( a )) ...
instance C ( a )   ...
instance C a   ...   -- overlaps every instance

Similarly for patterns and expressions, the so-called superfluous parens 
are just stripped away, so equivalent to the bare term.

The use of OneTuple is that it comes with all Prelude instances pre-
declared (just like all other tuple constructors). I don't see that it has 
an advantage over declaring your own data type(?) I'd also be interested 
to know who is using it, and why.

What I'm doing is building Type-Indexed Tuples [1] mentioned in HList [2], 
as an approach to extensible records [3], on the model of Trex [4] -- all 
of which acknowledge one-element records/rows/tuples. And then I'm using 
the tuples as a platform for relational algebra [5] with natural Join (and 
ideas from Tropashko's 'Relational Lattice' [6]). 

Is there anybody using OneTuple 'in anger'?

AntC

[1] M. Shields and E.Meijer. Type-indexed rows. In Proceedings
of the 28th ACM SIGPLAN-SIGACT symposium on Principles
of Programming Languages, pages 261–275. ACMPress, 2001.
[2] http://hackage.haskell.org/package/HList
[3] http://www.haskell.org/haskellwiki/Extensible_record
[4] http://web.cecs.pdx.edu/~mpj/pubs/polyrec.html
[5] http://en.wikipedia.org/wiki/Relational_algebra#Natural_join_
[6] http://vadimtropashko.wordpress.com/relational-lattice/

 
 
 
 On Fri, Aug 16, 2013 at 5:35 AM, AntC anthony_clayden at 
clear.net.nz wrote:
 There's an annoying inconsistency:
     (CustId 47, CustName Fred, Gender Male)  -- threeple
     (CustId 47, CustName Fred)                -- twople
 --  (CustId 47)-- oneple not!
 () -- nople





___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] abs minBound (0 :: Int) negate minBound == (minBound :: Int)

2013-08-19 Thread Richard A. O'Keefe

On 20/08/2013, at 3:43 AM, Kyle Miller wrote:

On Sun, Aug 18, 2013 at 8:04 PM, Richard A. O'Keefe o...@cs.otago.ac.nz
wrote:
The argument for twos-complement, which always puzzled me, is that the other
systems have two ways to represent zero. I never found this to be a problem,
not even for bitwise operations, on the B6700. I *did* find abs x 0
succeeding to be a pain in the posterior. (The B6700 had two different tests:
'are these two numbers equal' and 'are these two bit patterns equal'.)

I think a better argument for twos complement is that you're just doing all
of your computations modulo 2^n (where n is 32 or 64 or whatever), and
addition and multiplication work as expected modulo anything.

To me, that's not a better argument. It isn't even a _good_ argument.
It amounts to saying if you do things wrong, you can justify it by
saying you're really doing something else right, and it's the programmer's
fault for wanting the wrong thing.

One great thing about the B6700 was that you were guaranteed
EITHER the mathematically correct answer in the numbers you were
thinking in terms of OR an exception telling you the machine couldn't
do what you wanted. When it comes to *applications* programming,
the number of times I have *wanted* arithmetic modulo 2^n (in the last
40 years) can be counted on the fingers of one ear.

You may call it multiplication work[ing] as expected when the product of two
positive numbers comes out negative; I call it a wrong answer.

Prelude let tens = 1 : map (*10) tens :: [Int]
Prelude take 19 tens
[1,10,100,1000,1,10,100,1000,1,10,100,1000,1,10,100,1000,1,10,100]
Prelude [x * x | x - take 19 tens]
[1,100,1,100,1,100,1,100,1,100,7766279631452241920,1864712049423024128,2003764205206896640,-2537764290115403776,4477988020393345024,5076944270305263616,-8814407033341083648,4003012203950112768,-5527149226598858752]

Yes, I know that Haskell has Integer.
If I want to do more arithmetic than a bit of simple counting,
I like to use it.
The gibberish that Int multiplication spewed out above is why.

Roughly speaking, there are three ways to handle integer
arithmetic: the Lisp way, the Ada way, and the Java way.
Lisp just gets it right (think Haskell's Integer type).
Java *defines* wrong answers to be right.
Ada recognises that sometimes you want modular arithmetic (so it offers you
modular types) and sometimes you don't (so it offers you bounded but
non-modular types, where overflow is trapped).

Even the C standard is careful to allow signed arithmetic to trap overflows.

When we tell our students that there is an integer N 0 such that N+1 0,
first they are shocked and confused, then they forget about it, and then
they are caught by it, and at last they remember it, but aren't sure what
they can _do_ about it in Java.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] One-element tuple

2013-08-19 Thread Ivan Lazar Miljenovic

On 20 August 2013 11:07, AntC anthony_clay...@clear.net.nz wrote:
 Daniel F difrumin at gmail.com writes:

 Can you please elaborate why this inconsistency is annoying and what's
 the use of OneTuple?
 Genuine question,

 Hi Daniel, the main annoyance is the verbosity (of using a data type and
 constructor), and that it no longer looks like a tuple.

 The inconsistency is because a one-element tuple is just as cromulent as a
 n-element, or a zero-element. (And that a one-element tuple is a distinct
 type from the element on its own/un-tupled.)

Why is it as cromulent (especially as I'm not so sure we could
really consider () to be merely a zero-element tuple)?

I can see what you're trying to do here, but for general usage isn't a
single element tuple isomorphic to just that element (which is what
newtypes are for if you need that distinction)?


 So if I have instances (as I do) like:

 instance C (a, b) ...
 instance C () ...

 I can't usefully put either of these next two, because they're equiv to
 the third:

 instance C (( a )) ...
 instance C ( a )   ...
 instance C a   ...   -- overlaps every instance

 Similarly for patterns and expressions, the so-called superfluous parens
 are just stripped away, so equivalent to the bare term.

 The use of OneTuple is that it comes with all Prelude instances pre-
 declared (just like all other tuple constructors). I don't see that it has
 an advantage over declaring your own data type(?) I'd also be interested
 to know who is using it, and why.

As far as I'm aware, it's just a joke package, but two packages
dealing with tuples seem to use it:
http://packdeps.haskellers.com/reverse/OneTuple


 What I'm doing is building Type-Indexed Tuples [1] mentioned in HList [2],
 as an approach to extensible records [3], on the model of Trex [4] -- all
 of which acknowledge one-element records/rows/tuples. And then I'm using
 the tuples as a platform for relational algebra [5] with natural Join (and
 ideas from Tropashko's 'Relational Lattice' [6]).

 Is there anybody using OneTuple 'in anger'?

 AntC

 [1] M. Shields and E.Meijer. Type-indexed rows. In Proceedings
 of the 28th ACM SIGPLAN-SIGACT symposium on Principles
 of Programming Languages, pages 261–275. ACMPress, 2001.
 [2] http://hackage.haskell.org/package/HList
 [3] http://www.haskell.org/haskellwiki/Extensible_record
 [4] http://web.cecs.pdx.edu/~mpj/pubs/polyrec.html
 [5] http://en.wikipedia.org/wiki/Relational_algebra#Natural_join_
 [6] http://vadimtropashko.wordpress.com/relational-lattice/




 On Fri, Aug 16, 2013 at 5:35 AM, AntC anthony_clayden at
 clear.net.nz wrote:
 There's an annoying inconsistency:
 (CustId 47, CustName Fred, Gender Male)  -- threeple
 (CustId 47, CustName Fred)-- twople
 --  (CustId 47)-- oneple not!
 () -- nople





 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] One-element tuple

2013-08-19 Thread Mike Ledger

It seems to me that this is Identity given a different name. A bonus of
using Identity is that it won't introduce any new packages to the majority
of installations.
On 20/08/2013 1:17 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com
wrote:

 On 20 August 2013 11:07, AntC anthony_clay...@clear.net.nz wrote:
  Daniel F difrumin at gmail.com writes:
 
  Can you please elaborate why this inconsistency is annoying and what's
  the use of OneTuple?
  Genuine question,
 
  Hi Daniel, the main annoyance is the verbosity (of using a data type and
  constructor), and that it no longer looks like a tuple.
 
  The inconsistency is because a one-element tuple is just as cromulent as
 a
  n-element, or a zero-element. (And that a one-element tuple is a distinct
  type from the element on its own/un-tupled.)

 Why is it as cromulent (especially as I'm not so sure we could
 really consider () to be merely a zero-element tuple)?

 I can see what you're trying to do here, but for general usage isn't a
 single element tuple isomorphic to just that element (which is what
 newtypes are for if you need that distinction)?

 
  So if I have instances (as I do) like:
 
  instance C (a, b) ...
  instance C () ...
 
  I can't usefully put either of these next two, because they're equiv to
  the third:
 
  instance C (( a )) ...
  instance C ( a )   ...
  instance C a   ...   -- overlaps every instance
 
  Similarly for patterns and expressions, the so-called superfluous parens
  are just stripped away, so equivalent to the bare term.
 
  The use of OneTuple is that it comes with all Prelude instances pre-
  declared (just like all other tuple constructors). I don't see that it
 has
  an advantage over declaring your own data type(?) I'd also be interested
  to know who is using it, and why.

 As far as I'm aware, it's just a joke package, but two packages
 dealing with tuples seem to use it:
 http://packdeps.haskellers.com/reverse/OneTuple

 
  What I'm doing is building Type-Indexed Tuples [1] mentioned in HList
 [2],
  as an approach to extensible records [3], on the model of Trex [4] -- all
  of which acknowledge one-element records/rows/tuples. And then I'm using
  the tuples as a platform for relational algebra [5] with natural Join
 (and
  ideas from Tropashko's 'Relational Lattice' [6]).
 
  Is there anybody using OneTuple 'in anger'?
 
  AntC
 
  [1] M. Shields and E.Meijer. Type-indexed rows. In Proceedings
  of the 28th ACM SIGPLAN-SIGACT symposium on Principles
  of Programming Languages, pages 261–275. ACMPress, 2001.
  [2] http://hackage.haskell.org/package/HList
  [3] http://www.haskell.org/haskellwiki/Extensible_record
  [4] http://web.cecs.pdx.edu/~mpj/pubs/polyrec.html
  [5] http://en.wikipedia.org/wiki/Relational_algebra#Natural_join_
  [6] http://vadimtropashko.wordpress.com/relational-lattice/
 
 
 
 
  On Fri, Aug 16, 2013 at 5:35 AM, AntC anthony_clayden at
  clear.net.nz wrote:
  There's an annoying inconsistency:
  (CustId 47, CustName Fred, Gender Male)  -- threeple
  (CustId 47, CustName Fred)-- twople
  --  (CustId 47)-- oneple not!
  () -- nople
 
 
 
 
 
  ___
  Haskell-Cafe mailing list
  Haskell-Cafe@haskell.org
  http://www.haskell.org/mailman/listinfo/haskell-cafe



 --
 Ivan Lazar Miljenovic
 ivan.miljeno...@gmail.com
 http://IvanMiljenovic.wordpress.com

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] One-element tuple