Re: [Haskell-cafe] One-element tuple

[Chris Wong]

> It seems to me that this is Identity given a different name.

Close. But Identity is declared using newtype (just like monad
transformers), whereas OneTuple is declared with data (like the other
tuples).

This may or may not matter, depending on your use case.

>
> On 20/08/2013 1:17 PM, "Ivan Lazar Miljenovic" 
> wrote:
>>
>> On 20 August 2013 11:07, AntC  wrote:
>> >> Daniel F  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 
>> > 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
>



-- 
Chris Wong, fixpoint conjurer
  e: lambda.fa...@gmail.com
  w: http://lfairy.github.io/

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

Re: [Haskell-cafe] One-element tuple

[AntC]

> Mike Ledger  gmail.com> writes:
> 
> 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" wrote:
> ...
>  isn't a single element tuple isomorphic to just that element ...?
>

Hi Mike, and Ivan, I'm not sure you're 'getting' it.

A one-element tuple distinguishes at type level between a container vs 
contents. It's not identity/not isomorphic. Try those instances I gave.
(What's worse, `Identity` is no fewer chars than `OneTuple` ;-)

If your application is not working with tuples/"for general usage", then 
no need to "introduce any new packages". You won't want OneTuple's (or 
whatever they're called).

Since I am working with tuples, I want the code to be clear where it's 
dealing with tuples vs the Haskell type infrastructure.

Thanks Ivan for the dependencies list. No surprise that Hlist is using 
OneTuple <==> HCons a HNil. That need is exactly what I'm talking about, 
not a joke. Lennart's `tuple` package likewise (but no use to me because 
it's using positional access, not Type-Indexed).


AntC

> >
> > 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.
> >



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

Re: [Haskell-cafe] One-element tuple

[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" 
wrote:

> On 20 August 2013 11:07, AntC  wrote:
> >> Daniel F  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 
> > 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

[Ivan Lazar Miljenovic]

On 20 August 2013 11:07, AntC  wrote:
>> Daniel F  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 
> 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

[AntC]

> Daniel F  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  
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)

[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  
> 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] Categories with associated constraints?

[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  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

[Haskell-cafe] Categories with associated constraints?

[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] Errors in non-monadic code

[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

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

[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] GHC and backwards compatibility

[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

[jabolopes]

> 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] Errors in non-monadic code

[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

[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

[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

[jabolopes]

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: 
> 
> References: 
> 
> 
> 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] librar...@haskell.org (was: GHC and backwards compatibility)

[Joe Quinn]

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

Joe Q  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

[Donn Cave]

jabolo...@google.com,
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
In-Reply-To: 

References: 

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] Errors in non-monadic code

[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"  wrote:

> On Mon, Aug 19, 2013 at 2:59 PM,  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

[Brandon Allbery]

On Mon, Aug 19, 2013 at 2:59 PM,  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

[jabolopes]

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] GHC and backwards compatibility

[Ketil Malde]

Joe Q  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

[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] Errors in non-monadic code

[Brandon Allbery]

On Mon, Aug 19, 2013 at 2:09 PM, Brandon Allbery wrote:

> 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

[jabolopes]

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,  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

[Haskell-cafe] wxHaskell mailinglist

[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

[Daniel F]

On Mon, Aug 19, 2013 at 9:48 PM,  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

[Brandon Allbery]

On Mon, Aug 19, 2013 at 1:48 PM,  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] Errors in non-monadic code

[jabolopes]

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] abs minBound < (0 :: Int) && negate minBound == (minBound :: Int)

[Brandon Allbery]

On Mon, Aug 19, 2013 at 11:43 AM, Kyle Miller  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

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

[Kyle Miller]

On Sun, Aug 18, 2013 at 8:04 PM, Richard A. O'Keefe 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.  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] GHC and backwards compatibility

[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"  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

[Haskell-cafe] GHC and backwards compatibility

[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] One-element tuple

[adam vogt]

On Mon, Aug 19, 2013 at 5:40 AM, AntC  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 . 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

Re: [Haskell-cafe] ordNub

[AntC]

> Richard A. O'Keefe  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

[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  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] One-element tuple

[AntC]

> Brent Yorgey  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] inv f g = f . g . f

[Nikita Danilenko]

Hi,

as for the nomenclature - mathematically the pattern

f^{-1} . g . f

is sometimes called "conjugation" [1]. One (trivial) type of occurrence is

data Foo a = Foo { unFoo :: a }
deriving Show

instance Functor Foo where

fmap f = Foo . f . unFoo

The under function from the lens library [2] allows expressing this as
follows:

instance Functor Foo where

fmap = under (iso Foo unFoo)

which is a very elegant way of capturing the essence of the pattern.

Best regards,

Nikita

[1] http://en.wikipedia.org/wiki/Conjugacy_class
[2]
http://hackage.haskell.org/packages/archive/lens/3.9.0.2/doc/html/Control-Lens-Iso.html#v:under

On 17/08/13 22:57, Dan Burton wrote:
> The lens docs even have an example of another helper function,
> "involuted" for functions which are their own inverse.
>
> >>> "live" & involuted reverse %~ ('d':)
> "lived"
>
> inv f g = involuted f %~ g
>
> http://hackage.haskell.org/packages/archive/lens/3.9.0.2/doc/html/Control-Lens-Iso.html#v:involuted
>
> -- Dan Burton
>
>
> On Sat, Aug 17, 2013 at 1:43 PM, Dan Burton  > wrote:
>
> This is indeed a job for lens, particularly, the Iso type, and the
> "under" function. Lens conveniently comes with a typeclassed
> isomorphism called "reversed", which of course has a list instance.
>
> >>> under reversed (take 10) ['a'.. 'z']
> "qrstuvwxyz"
>
> -- Dan Burton
>
> On Aug 17, 2013 10:23 AM, "Anton Nikishaev"  > wrote:
>
> Christopher Done  > writes:
>
> > Anyone ever needed this? Me and John Wiegley were discussing
> a decent
> > name for it, John suggested inv as in involution. E.g.
> >
> > inv reverse (take 10)
> > inv reverse (dropWhile isDigit)
> > trim = inv reverse (dropWhile isSpace) . dropWhile isSpace
> >
> > That seems to be the only use-case I've ever come across.
>
> And it's here only because reverse^-1 ≡ reverse, is not it?
> I only can see how f ∘ g ∘ f^-1 can be a pattern.
>
> > There's also this one:
> >
> > co f g = f g . g
> >
> > which means you can write
> >
> > trim = co (inv reverse) (dropWhile isSpace)
> >
> > but that's optimizing an ever rarer use-case.
>
>
> --
> lelf
>
>
>
> ___
> 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




signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe