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. fromIntegral (Russ Abbott)
2. Fwd: [Haskell-beginners] Applicative Composition (Antoine Latter)
3. Fwd: [Haskell-beginners] Applicative Composition (Antoine Latter)
4. Re: fromIntegral (Felipe Lessa)
5. Re: Applicative Composition (edgar klerks)
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 Sep 2010 20:54:50 -0700
From: Russ Abbott <[email protected]>
Subject: [Haskell-beginners] fromIntegral
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
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?
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.
-- Russ Abbott
______________________________________
Professor, Computer Science
California State University, Los Angeles
Google voice: 424-242-USA0 (last character is zero)
blog: http://russabbott.blogspot.com/
vita: http://sites.google.com/site/russabbott/
______________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20100930/55e36156/attachment-0001.html
------------------------------
Message: 2
Date: Fri, 1 Oct 2010 00:15:29 -0500
From: Antoine Latter <[email protected]>
Subject: Fwd: [Haskell-beginners] Applicative Composition
To: Beginners Haskell <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
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
------------------------------
Message: 3
Date: Fri, 1 Oct 2010 00:15:29 -0500
From: Antoine Latter <[email protected]>
Subject: Fwd: [Haskell-beginners] Applicative Composition
To: Beginners Haskell <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
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
------------------------------
Message: 4
Date: Fri, 1 Oct 2010 02:25:42 -0300
From: Felipe Lessa <[email protected]>
Subject: Re: [Haskell-beginners] fromIntegral
To: [email protected]
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
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.
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
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.
> 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.
--
I think it's correct to say that in the very end you have to pick
all the types of your program. However, that choice may be left
until the very very end: until the moment that 'main :: IO ()' is
compiled.
For example, Data.Map functions are all polymorphic. In fact,
most, if not all, functions in 'containers' package are
polymorphic. Yet we can compile that package just fine.
--
I think you may be mistaking the optimizer for the whole thing.
It is possible to compile optimized versions of all polymorphic
functions specializing them to specific choices of types. We
even have the SPECIALIZE pragma. However, polymorphic functions
don't *need* to specialized and can be compiled without knowing
what are the specific types at all. If that's efficient or not,
that's beside point.
Cheers! =)
--
Felipe.
------------------------------
Message: 5
Date: Fri, 1 Oct 2010 11:03:45 +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"
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/4839d027/attachment.html
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 28, Issue 1
****************************************
