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: Pointfree expeiments (Stephen Tetley)
2. Re: Pointfree expeiments (Stephen Tetley)
3. Re: Question about data structures (Patrick LeBoutillier)
4. Re: Problem "grouping" a list (Hein Hundal)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Nov 2010 12:48:14 +0000
From: Stephen Tetley <stephen.tet...@gmail.com>
Subject: Re: [Haskell-beginners] Pointfree expeiments
Cc: beginners@haskell.org
Message-ID:
<aanlktikrknxhlurjwg4smjp4xsdwkpvp7=uzmrs3h...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Paul
Its Pointfree that's choosing `ap` - I've never got round to using it
myself but I assume it only re-writes using only "standard" functions
(Prelude + Base?). As there isn't a specific definition of Starling
available for the functional type it chooses Monadic ap. Nowadays it
could also choose (<*>) from Control.Applicative.
The monad instance for functions is the Reader monad without a newtype wrapper:
m x == (r1 -> x)
ap :: (Monad m) => m (a -> b) -> m a -> m b
Subsituting you get:
ap :: (r1 -> a -> b) -> (r1 -> a) -> (r1 -> b)
If you want you can knocking out the bracket of the last part...
ap :: (r1 -> a -> b) -> (r1 -> a) -> r1 -> b
Same with liftM2
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
Nicer var names:
liftM2 :: (Monad m) => (a -> b -> ans) -> m a -> m b -> m ans
Substituting, m x == (r1 -> x)
liftM2 :: (a -> b -> c) -> (r1 -> a) -> (r1 -> b) -> (r1 -> ans)
This matches the Phoenix combinator also known as Big Phi. I think it
was in the combinator set used by David Turner in the implementation
of SASL (SASL's abstract machine used combinators as its machine
code).
phoenix :: (a -> b -> ans) -> (r1 -> a) -> (r1 -> b) -> r1 -> ans
------------------------------
Message: 2
Date: Thu, 25 Nov 2010 12:50:45 +0000
From: Stephen Tetley <stephen.tet...@gmail.com>
Subject: Re: [Haskell-beginners] Pointfree expeiments
To: Stephen Tetley <stephen.tet...@gmail.com>
Cc: beginners@haskell.org
Message-ID:
<aanlktim32rqg8rpm9oqt32vsccpnx1emz7oor9naa...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 25 November 2010 12:48, Stephen Tetley <stephen.tet...@gmail.com> wrote:
>
> Substituting, m x == (r1 -> x)
>
> liftM2 :: (a -> b -> c) -> (r1 -> a) -> (r1 -> b) -> (r1 -> ans)
>
Apologies, there's an obvious typo, the correct version is:
liftM2 :: (a -> b -> ans) -> (r1 -> a) -> (r1 -> b) -> (r1 -> ans)
------------------------------
Message: 3
Date: Thu, 25 Nov 2010 09:17:37 -0500
From: Patrick LeBoutillier <patrick.leboutill...@gmail.com>
Subject: Re: [Haskell-beginners] Question about data structures
To: russ.abb...@gmail.com
Cc: beginners@haskell.org
Message-ID:
<aanlktims4q0+s7u3bukaofhkqd5q1cdlacw2_=fly...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Russ,
If I understand correctly KenKen is something like Sudoku except that
the (more complicated) "cages"
constraints replace the usual "square" constraints.
Have you seen these sudoku solvers: http://www.haskell.org/haskellwiki/Sudoku ?
Maybe you can get ideas there on how to attack the problem in a more
functional fashion.
Patrick
On Wed, Nov 24, 2010 at 9:58 PM, Russ Abbott <russ.abb...@gmail.com> wrote:
> My previous two messages suggest a Haskell coding principle: distinguish
> between fixed and (quasi-)mutable data structures. (I know values don't
> change, but I hope you understand what I mean. The cage and the cell in my
> previous example are quasi-mutable. They are conceptually mutable in the
> context of the problem.) The fixed data structures can be organized any way
> one wants. The quasi-/conceptually-mutable elements should be referred to
> symbolically and stored in a Map. The maps themselves should be stored at a
> global level of the system's data structure so that it is easy to replace
> them when values change.
>
> -- Russ
>
>
> On Wed, Nov 24, 2010 at 5:54 PM, Russ Abbott <russ.abb...@gmail.com> wrote:
>>
>> Actually using a Map does solve the problem. The Map has to be kept at the
>> level of the Tree rather than have each leaf node point to it. So instead
>> of just a Tree one has, say (Map, Tree). Then when one wants to change the
>> property of something associated with a leaf node, one can just change the
>> map. The Tree is unchanged.
>>
>> -- Russ
>>
>>
>>
>> On Wed, Nov 24, 2010 at 2:02 PM, Russ Abbott <russ.abb...@gmail.com>
>> wrote:
>>>
>>> OK. So putting a Map at Leaf nodes doesn't solve the problem.
>>> (Apparently I haven't been able to communicate what I see as the problem.)
>>> The problem that I'm trying to get to is the need to write excessive code
>>> for something that would require a lot less code in an OO world. It's not a
>>> matter of execution time or space. It's a matter of the amount of code one
>>> is required to write.
>>> -- Russ
>>>
>>>
>>> On Wed, Nov 24, 2010 at 1:52 PM, Daniel Fischer
>>> <daniel.is.fisc...@web.de> wrote:
>>>>
>>>> On Wednesday 24 November 2010 22:12:37, Russ Abbott wrote:
>>>> > Cool. I wasn't aware of that notation. It doesn't quite get to the
>>>> > issue though.
>>>> >
>>>> > The problem I'm concerned about is the need to define y in the first
>>>> > place. If one is chasing through a data structure and finds a need to
>>>> > change something buried within it, it seems necessary to rebuild
>>>> > everything that includes the changed thing.
>>>>
>>>> In general, values are immutable, so you can't "change something buried
>>>> within it". You have to build a new value containing some of the old
>>>> stuff
>>>> and a new part. Building the new value usually consists mostly of
>>>> copying a
>>>> couple of pointers (plus building the new part of course), so isn't too
>>>> expensive normally.
>>>>
>>>> You can have mutable values in the IO or (ST s) monads, if you need
>>>> them.
>>>>
>>>> > That is, I can't change a
>>>> > component of somethingNew without creating y. The point is there's
>>>> > nothing about x that changed,
>>>>
>>>> The thing with the changed component is not x anymore.
>>>>
>>>> > and there may be nothing about (var1 x)
>>>> > that changed, and there may be nothing about var11 . var1 $ x that
>>>> > changed, etc. Yet one is apparently forced to keep track of and
>>>> > reconstruct all those elements.
>>>>
>>>> The compiler takes care of that.
>>>>
>>>> >
>>>> > Another example is to imagine a Tree in which the leaves contain
>>>> > "objects." If I want to change a property of one of those leaf
>>>> > objects,
>>>>
>>>> You can't in general, the thing with a different property is a different
>>>> object.
>>>>
>>>> > I am forced to rebuild all the ancestor nodes of that leaf down to
>>>> > rebuilding the root.
>>>>
>>>> Yes (well, not you, the compiler does it), except if your tree contains
>>>> mutable objects (IORefs/STRefs for example).
>>>>
>>>> >
>>>> > One way to avoid that is for the leaves to refer to their objects
>>>> > through a Map. Then changing a leaf object requires only that the
>>>> > value
>>>> > associated with key represented by the leaf be (re-)inserted into the
>>>> > Map. The Tree itself need not change at all.
>>>>
>>>> Oh, it will. If you change a Map, you get a new one, thus you get a new
>>>> tree containing the new Map.
>>>>
>>>> >
>>>> > But that trick isn't always available. In the example we are talking
>>>> > about we can't make a Map where they keys are the instance variable
>>>> > names and the values are their values. That would seem to do the job,
>>>> > but since the values are of different types, we can't create such a
>>>> > Map.
>>>> >
>>>> > So now what?
>>>>
>>>> Well, what's the problem with the compiler copying some nodes?
>>>> Normally, that doesn't cost very much performance, if it does in your
>>>> case,
>>>> we'd need to know more to suggest the best way to go.
>>>>
>>>> > *
>>>> > -- Russ *
>>>> >
>>>
>>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
>
--
=====================
Patrick LeBoutillier
Rosemère, Québec, Canada
------------------------------
Message: 4
Date: Thu, 25 Nov 2010 07:02:44 -0800 (PST)
From: Hein Hundal <hunda...@yahoo.com>
Subject: [Haskell-beginners] Re: Problem "grouping" a list
To: beginners@haskell.org, joaopiz...@gmail.com
Message-ID: <812283.79303...@web34405.mail.mud.yahoo.com>
Content-Type: text/plain; charset=us-ascii
> From: Jo?o Paulo Pizani Flor <joaopiz...@gmail.com>
> OK, so my specific problem goes like this: I have a list of
> tuples
> :t myList
> [ (Float, Integer) ]
>
> And I want to "group" this list into a nested list
> groupAtoms :: [ (Float,Integer) ] -> [
> [(Float,Integer)] ]
>
> Of course, I want that the concatenation of the groups
> yield me the original
> list, i.e, (foldl (++) [] . groupAtoms == id), and
> the criterion that
> defines a group is that:
> "The sum of the first elements in the tuples comprising the
> list must be
> greater than or equal to 1.0".
Jo?o,
I am a beginner also and I liked Daniel Fischer's solution. Here is another
(less elegant) solution:
-- Start Code Here
-- foldfun takes an existing list of lists of pairs and decides
-- whether to append p to the current list, pl, or start a new
-- list of pairs.
foldfun done p (pl:pls) = if done pl then [p]:pl:pls else (p:pl):pls
foldfun done p [] = [[p]]
-- mygroup2 folds list of pairs, pl, using the foldfun, and then
-- puts all the lists in the correct order using reverse twice.
mygroup2 pl = map reverse $ reverse $
foldr (foldfun done) [] (reverse pl)
where done pl = sum (map fst pl) >= 1.0
-- End of Code
Cheers,
Hein
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 29, Issue 39
*****************************************
