Send Beginners mailing list submissions to
beginners@haskell.org
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
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Natural functions versus existential types (Darren Grant)
2. Re: Game of Life try (Darren Grant)
3. Re: Natural functions versus existential types (Brandon Allbery)
4. Re: Game of Life try (KC)
5. Re: Natural functions versus existential types (Darren Grant)
----------------------------------------------------------------------
Message: 1
Date: Sun, 13 Jan 2013 17:34:18 -0800
From: Darren Grant <therealklu...@gmail.com>
Subject: Re: [Haskell-beginners] Natural functions versus existential
types
To: Aleksandar Dimitrov <aleks.dimit...@gmail.com>
Cc: Haskell Beginners <beginners@haskell.org>
Message-ID:
<CA+jD6Sj1b_W=+=pwdvqv5wa+zlbh+j4zhynbm+gzxktstax...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Jan 9, 2013 at 1:45 PM, Aleksandar Dimitrov <
aleks.dimit...@gmail.com> wrote:
> On Sun, Jan 06, 2013 at 11:22:51PM -0800, Darren Grant wrote:
> > I've seen some cases where Haskell examples dive into existential types
> > instead of using natural higher order functions. For instance, the
> > "Existential type" wiki page [1] section 2.2 proposes existentials as the
> > solution to a heterogeneous list problem where a ray-tracer must
> evaluate a
> > trace function for different types of objects. Is there a good reason for
> > this, or is it just a case of prior language assumptions leading to
> > unnatural code? Why could I not just make the list homogeneous by
> supplying
> > a list of partially evaluated trace functions instead?
>
> I have never written a ray-tracer, so I don't know about the exact
> requirements,
> but depending on the code in question, partial evaluation might not be
> possible.
>
> Parametric types can only be instantiated with *one* specific type. A list
> [a]
> can only be either [Int] or [Bool], but not [Int,Bool] or so. [1]
>
> So whenever you'd like to have a collection of things that won't have the
> same
> type, but have a certain operation defined on them, existential types come
> in
> handy. A partial application only makes sense when you have a function of
> higher
> arity, but `hits` in the example on the Wiki has only one argument, namely
> the
> list. At some point, a *collection* of Renderables needs to pass by the
> function
> `hit`. This collection probably needs to be stored somewhere, presumably a
> list,
> that is then fed to `hits`.
>
> Of course, you might set up your types differently, so that everything
> that will
> need to pass by the function `hits` would also be of one certain type. You
> could, for example, instead of storing the heterogeneous Renderables in a
> list,
> just reduce the different shapes to a Renderable data type that contains
> the
> important fields. Then, whenever a geometric object gets created, a
> Rendereable
> also gets created, then stored in that list. But how *viable* that is, I
> don't
> know. My gut feeling says that it won't be viable at all.
Consider the following:
If I have a traceable data type like data Sphere, I can define it and a
trace function as follows:
data Sphere = Sphere { spherepos :: (Double,Double,Double), sphereradius
:: Double }
traceSphere :: Sphere -> Ray -> [Hit]
Where Ray is self-explanatory and [Hit] is a resulting list of hits where
ray intersects sphere. I can then define a list of traceable objects thus,
[Ray -> [Hit]]
Which can also be thought of as,
type Trace = Ray -> [Hit]
[Trace]
Now I am able to define a homogeneous list [Trace] of partially applied
functions like so,
[traceSphere $ Sphere (0,0,0) 20,
traceSphere $ Sphere (10,20,30) 40,
traceBox $ Box (0,0,0) (10,10,10) -- where traceBox is also
partially applied
]
You see what I mean? This is very natural in Haskell. I'm sure there must
be counter-examples, but I haven't the comprehension for these.
What do you think?
> Sometimes I read an argument that existentials are required due to unknown
> constraints at compile time, but do not have an intuition for this
> > situation yet. For instance, I read that IO requires existentials. Still
> > working on that one. :)
>
> Where did you read that? The *definition* of the IO type does not use
> existentials [2]. But I'm not very familiar with the internals.
You're right! I'm not sure what I saw, but I would guess that I conflated
some application of IO with the definition.
Cheers,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130113/dfbef124/attachment-0001.htm>
------------------------------
Message: 2
Date: Sun, 13 Jan 2013 17:36:46 -0800
From: Darren Grant <therealklu...@gmail.com>
Subject: Re: [Haskell-beginners] Game of Life try
To: KC <kc1...@gmail.com>
Cc: Haskell Beginners <beginners@haskell.org>
Message-ID:
<ca+jd6sjvs3csgwu---kyr9wzorsgkfdv5mrzgmpnntz9t4j...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Fri, Jan 11, 2013 at 5:19 PM, KC <kc1...@gmail.com> wrote:
> Thinking about Bird's handling of Sudoku; it may be efficiently
> possible to represent colonies as lists (or trees).
> Then one just has to consider the merging and splitting of colonies.
>
> Usually, all the space in a cell array is not used anyway. :)
This just blew my mind. :)
Cheers,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130113/7dd53610/attachment-0001.htm>
------------------------------
Message: 3
Date: Sun, 13 Jan 2013 20:50:38 -0500
From: Brandon Allbery <allber...@gmail.com>
Subject: Re: [Haskell-beginners] Natural functions versus existential
types
To: Darren Grant <therealklu...@gmail.com>
Cc: Aleksandar Dimitrov <aleks.dimit...@gmail.com>, Haskell Beginners
<beginners@haskell.org>
Message-ID:
<cakfcl4xr5bdxewy5g28y0d0vgmv2tfy93js2usho+2d4lhb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sun, Jan 13, 2013 at 8:34 PM, Darren Grant <therealklu...@gmail.com>wrote:
> On Wed, Jan 9, 2013 at 1:45 PM, Aleksandar Dimitrov <
> aleks.dimit...@gmail.com> wrote:
>
>> > Sometimes I read an argument that existentials are required due to
>> unknown
>>
> > constraints at compile time, but do not have an intuition for this
>> > situation yet. For instance, I read that IO requires existentials.
>> Still
>> > working on that one. :)
>>
>> Where did you read that? The *definition* of the IO type does not use
>> existentials [2]. But I'm not very familiar with the internals.
>
>
> You're right! I'm not sure what I saw, but I would guess that I conflated
> some application of IO with the definition.
>
The only thing I'm aware of offhand is that an existential is used to hide
the internals, not because this is in some sense necessary for IO to work,
but to allow the compiler to ensure that nothing is violating IO's
"contract": you can't do anything with something you don't know the type
of, so it's impossible for normal code to do anything out of bounds with an
IO type. You could just as well write an implementation of IO without any
existentials or magic internals, but it'd be trivial to "cheat". (GHC's,
with the magic stripped away, is just state: sequential execution is
guaranteed by passing a state "baton" between IO actions, and the magic
just makes sure you can't stash a copy of the baton or manufacture one
yourself. There's some slight additional magic that functions as an
optimization.)
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130113/fcf154e1/attachment-0001.htm>
------------------------------
Message: 4
Date: Sun, 13 Jan 2013 17:59:24 -0800
From: KC <kc1...@gmail.com>
Subject: Re: [Haskell-beginners] Game of Life try
To: Darren Grant <therealklu...@gmail.com>
Cc: Haskell Beginners <beginners@haskell.org>
Message-ID:
<camlkxymhztnj0gamkuw2zr3eixl8n_tjqgao-aopiemxv-9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
You're Welcome! :D
On Sun, Jan 13, 2013 at 5:36 PM, Darren Grant <therealklu...@gmail.com> wrote:
> On Fri, Jan 11, 2013 at 5:19 PM, KC <kc1...@gmail.com> wrote:
>>
>> Thinking about Bird's handling of Sudoku; it may be efficiently
>> possible to represent colonies as lists (or trees).
>> Then one just has to consider the merging and splitting of colonies.
>>
>> Usually, all the space in a cell array is not used anyway. :)
>
>
> This just blew my mind. :)
>
> Cheers,
> Darren
>
--
--
Regards,
KC
------------------------------
Message: 5
Date: Sun, 13 Jan 2013 18:53:52 -0800
From: Darren Grant <therealklu...@gmail.com>
Subject: Re: [Haskell-beginners] Natural functions versus existential
types
To: Brandon Allbery <allber...@gmail.com>
Cc: Aleksandar Dimitrov <aleks.dimit...@gmail.com>, Haskell Beginners
<beginners@haskell.org>
Message-ID:
<ca+jd6sg7pabyhaaim9n2-opksmqwqb+z-omf9ivcmxu4+yn...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Interesting. So is it the case that existentials are only meant to hide
internals? Is there another useful application for them?
On Sun, Jan 13, 2013 at 5:50 PM, Brandon Allbery <allber...@gmail.com>wrote:
> On Sun, Jan 13, 2013 at 8:34 PM, Darren Grant <therealklu...@gmail.com>wrote:
>
>> On Wed, Jan 9, 2013 at 1:45 PM, Aleksandar Dimitrov <
>> aleks.dimit...@gmail.com> wrote:
>>
>>> > Sometimes I read an argument that existentials are required due to
>>> unknown
>>>
>> > constraints at compile time, but do not have an intuition for this
>>> > situation yet. For instance, I read that IO requires existentials.
>>> Still
>>> > working on that one. :)
>>>
>>> Where did you read that? The *definition* of the IO type does not use
>>> existentials [2]. But I'm not very familiar with the internals.
>>
>>
>> You're right! I'm not sure what I saw, but I would guess that I
>> conflated some application of IO with the definition.
>>
>
> The only thing I'm aware of offhand is that an existential is used to hide
> the internals, not because this is in some sense necessary for IO to work,
> but to allow the compiler to ensure that nothing is violating IO's
> "contract": you can't do anything with something you don't know the type
> of, so it's impossible for normal code to do anything out of bounds with an
> IO type. You could just as well write an implementation of IO without any
> existentials or magic internals, but it'd be trivial to "cheat". (GHC's,
> with the magic stripped away, is just state: sequential execution is
> guaranteed by passing a state "baton" between IO actions, and the magic
> just makes sure you can't stash a copy of the baton or manufacture one
> yourself. There's some slight additional magic that functions as an
> optimization.)
>
> --
> brandon s allbery kf8nh sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130113/2a1c3d93/attachment.htm>
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 55, Issue 14
*****************************************
