Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Applicative Composition (edgar klerks)
2. Re: Applicative Composition (David Virebayre)
3. Re: Applicative Composition (Daniel Fischer)
4. Re: fromIntegral (Russ Abbott)
----------------------------------------------------------------------
Message: 1
Date: Fri, 1 Oct 2010 11:11:23 +0200
From: edgar klerks <[email protected]>
Subject: Re: [Haskell-beginners] Applicative Composition
To: Antoine Latter <[email protected]>
Cc: Beginners Haskell <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
There was another small reason, I did ask it, because the applicative
interface isn't as rich as the monad interface. I have read, that is because
of historic reasons. They weren't in there at the beginning.
But I really like to use applicative functors, if possible and this one
seemed to be obvious, so I was a bit puzzeled, why it wasn't there.
Are there any plans to enrich the interface for applicative functors?
On Fri, Oct 1, 2010 at 11:03 AM, edgar klerks <[email protected]>wrote:
> Hi Brent and Antione,
>
> On Fri, Oct 1, 2010 at 3:41 AM, Brent Yorgey <[email protected]>wrote:
>
>> On Fri, Oct 01, 2010 at 01:47:09AM +0200, edgar klerks wrote:
>> > Hi All,
>> >
>> > I was wondering, why there isn't a composition operator for applicative
>> > functors. Of course it is rather trivial to implement, but it is a
>> useful
>> > feature:
>>
>> I think you've answered your own question: it's rather trivial to
>> implement. If we added every single useful function to the standard
>> libraries, we'd be up to our necks.
>>
>>
> Ah yes I understand that. '
>
>
>> > {-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
>> > module ApplicativeComposition where
>> > import Control.Applicative
>> >
>> > class (Applicative f) => ApplicativeComposition f where
>> > (<.>) :: f (b -> c) -> f (a -> b) -> f (a -> c)
>> >
>> > instance (Applicative f) => ApplicativeComposition f where
>> > (<.>) f g = pure (.) <*> f <*> g
>> >
>> > Can this be added to later versions of haskell?
>>
>> You can always make a formal proposal [1], although judging by past
>> discussions of similar sorts of things I doubt it would be accepted,
>> for the reasons I wrote above.
>>
>>
> Nopes I will refrain from that, I had to search first, before ask. My
> apologies for that, it was a bit late, when I posted it.
>
> And another thing is, that there are different implementations for such a
> operator. Better let the user create it themself.
>
> Thnx for the reply.
>
> Greets,
>
> Edgar
>
>
> On Fri, Oct 1, 2010 at 7:15 AM, Antoine Latter <[email protected]> wrote:
>
>> Forwarding to list - it looks like I forgot to reply-all.
>>
>>
>> ---------- Forwarded message ----------
>> From: Antoine Latter <[email protected]>
>> Date: Thu, Sep 30, 2010 at 7:17 PM
>> Subject: Re: [Haskell-beginners] Applicative Composition
>> To: edgar klerks <[email protected]>
>>
>>
>> On Thu, Sep 30, 2010 at 6:47 PM, edgar klerks <[email protected]>
>> wrote:
>> > Hi All,
>> >
>> > I was wondering, why there isn't a composition operator for applicative
>> > functors. Of course it is rather trivial to implement, but it is a
>> useful
>> > feature:
>> >
>> > {-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
>> > module ApplicativeComposition where
>> > import Control.Applicative
>> >
>> > class (Applicative f) => ApplicativeComposition f where
>> > (<.>) :: f (b -> c) -> f (a -> b) -> f (a -> c)
>> >
>> > instance (Applicative f) => ApplicativeComposition f where
>> > (<.>) f g = pure (.) <*> f <*> g
>> >
>> > Can this be added to later versions of haskell?
>> >
>>
>> Here's the last time this topic came up on the lists:
>> http://www.haskell.org/pipermail/libraries/2010-August/013992.html
>>
>> Here's the corresponding library proposal ticket:
>> http://hackage.haskell.org/trac/ghc/ticket/4189
>>
>> There were a few folks against it for a few different reasons.
>>
>> Antoine
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20101001/3a939ca6/attachment-0001.html
------------------------------
Message: 2
Date: Fri, 1 Oct 2010 11:48:19 +0200
From: David Virebayre <[email protected]>
Subject: Re: [Haskell-beginners] Applicative Composition
To: Brent Yorgey <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
2010/10/1 Brent Yorgey <[email protected]>:
> I think you've answered your own question: it's rather trivial to
> implement. Â If we added every single useful function to the standard
> libraries, we'd be up to our necks.
You mean like in the container libraries ? :-P
------------------------------
Message: 3
Date: Fri, 1 Oct 2010 13:08:26 +0200
From: Daniel Fischer <[email protected]>
Subject: Re: [Haskell-beginners] Applicative Composition
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On Friday 01 October 2010 11:48:19, David Virebayre wrote:
> 2010/10/1 Brent Yorgey <[email protected]>:
> > I think you've answered your own question: it's rather trivial to
> > implement. Â If we added every single useful function to the standard
> > libraries, we'd be up to our necks.
>
> You mean like in the container libraries ? :-P
Only much much worse 8-)
------------------------------
Message: 4
Date: Fri, 1 Oct 2010 08:08:08 -0700
From: Russ Abbott <[email protected]>
Subject: Re: [Haskell-beginners] fromIntegral
To: Felipe Lessa <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thanks, Filipe
I clearly over-stated my case. I'd like to break it into a number of
different question. Please see below.
On Thu, Sep 30, 2010 at 10:25 PM, Felipe Lessa <[email protected]>wrote:
> I'll try to clarify some concepts. Please correct me if I am
> wrong, and please forgive me if I misunderstood you.
>
> On Fri, Oct 1, 2010 at 12:54 AM, Russ Abbott <[email protected]>
> wrote:
> > In explaining fromIntegral, I want to say that it is really a collection
> of
> > overloaded functions:
> >
> > Integer -> Double
> > Int -> Float
> > ...
> >
> > When GHC compiles a line of code with fromIntegral it in, it must decide
> at
> > compile time which of these overloaded functions to compile to. This is
> in
> > contrast to saying that fromIngetral is a function of the type (Integral
> a,
> > Num b) => a -> b. In reality there is no (single) function of the type
> > (Integral a, Num b) => a -> b because (among other things) every function
> > must map between actual types, but (Integral a, Num b) => a -> b does not
> > say which actual types are mapped between.
> >
> > Is the preceding a reasonable thing to say?
>
> First of all, I do think that polymorphic functions are plain ol'
> functions. For example
>
> id :: a -> a
> id x = x
>
> is a function. Moreover, in GHC 'id' has only one
> representation, taking a thunk and returning a thunk, so even at
> the machine code level this is only one function.
>
Agree. I over stated my case. The same can be said for
length :: [a] -> Int
It doesn't matter what the type of element in the list is. length runs the
same way no matter what. So this is pure polymorphism.
>
> Now, maybe 'fromIntegral' has something more than polymorphism?
> Well, it has typeclasses. But we can represent those as
> data types, so we could write
>
> fromIntegralD :: Integral a -> Num b -> a -> b
> fromIntegralD intrDictA numDictB =
> fromIntegral numDictB . toInteger intrDictA
>
I'm afraid I don't understand this. Moreover, I couldn't get the preceding
to load without error.
>
> Better yet, the compiler could write this code for us internally.
> Now, using thunks we can get a single machine code for
> 'fromIntegralD' as well.
>
> In sum, I think all functions are really just that, functions.
>
> --
>
> You may call functions that have typeclass constraints
> "overloaded functions", but they still are functions.
>
> Functions that are polymorphic but do not have constraints are
> not really overloaded because of parametricity, which means that
> they can't change the way they work based on the specific choices
> of types you make.
>
I don't understand the preceding paragraph. Would you mind elaborating.
>
> > If so, can I say the same sort of thing about constants like 1 and []? In
> > particular there is no single value []. Instead [] is a symbol which at
> > compile time must be compiled to the empty list of some particular type,
> > e.g., [Int]. There is no such Haskell value as [] :: [a] since [a] (as
> > type) is not an actual type. I want to say the same thing about 1, i.e.,
> > that there is no such Haskell value as 1 :: (Num t) => t. When the symbol
> 1
> > appears in a program, the compiler must decide during compilation whether
> it
> > is intended to be 1::Int or 1::Integer or 1::Double, etc.
>
> Well, [a] *is* an actual type, a polymorphic one.
>
Here is the example that raised that issue for me. Let's say I define null'
as follows.
null' xs = xs == [ ]
If I don't include a declaration in the file, Haskell (reasonably) concludes
the following.
> :t null'
null' :: (Eq a) => [a] -> Bool
If I write the following at the top level, everything is fine.
> null' [ ]
True
But if I include the following in the file that defines null', I get an
error message.
test = null' [ ]
Ambiguous type variable `a' in the constraint:
`Eq a' arising from a use of `null'' at null.hs:6:17-24
Probable fix: add a type signature that fixes these type
variable(s)
Why is that? And how can it be fixed? I know I can fix it as follows.
test = null' ([ ] :: [Integer])
> :reload
> test
True
That's what suggested to me that [ ] had to be compiled into a concrete
value.
It seemed to me that similar reasoning applied to things like 1. How is the
following explained?
Prelude> 111111111111111111111111111111111111111111
111111111111111111111111111111111111111111
it :: (Num t) => t
Prelude> maxBound :: Int
2147483647
it :: Int
Prelude> 111111111111111111111111111111111111111111 - (1::Int)
-954437178
it :: Int
Does it make sense to say that the long string of 1's is really of type (Num
t) => t?
If so, what does the compiler think it's doing when it processes(?) it as an
Int so that it can subtract 1 :: Int from it? It didn't treat it as
maxBound :: Int. And yet it didn't generate an error message.
Thanks
-- Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20101001/e9fb2524/attachment.html
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 28, Issue 2
****************************************
