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