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: a problem with maps (aditya siram)
2. Re: [Haskell-cafe] For class Monoid; better names than
mempty & mappend might have been: mid (mident) & mbinop (Arlen Cuss)
3. Re: I wrote a state monad example - help me make it more
Haskellic (Rohit Garg)
----------------------------------------------------------------------
Message: 1
Date: Sat, 23 Jul 2011 19:13:16 -0500
From: aditya siram <[email protected]>
Subject: Re: [Haskell-beginners] a problem with maps
To: Ertugrul Soeylemez <[email protected]>
Cc: [email protected]
Message-ID:
<cajrreyjbknvga+syuoxjlejzv6vrwejsqfdesnm8_krjuna...@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Ertugul,
I admire your passion for rigor and discipline. It is not natural for
me but I am slowly coming to the same place.
I also feel that Haskell development is like learning to play music.
I've seen many a student (myself included) turn away from an
instrument because of an over-emphasis on scales, arpeggios etc. and
less on playing what sounds good. It is true that eventually to play
seriously some understanding of that theory is required but the
musician will come to that conclusion on their own.
They will hear a pattern over and over and wonder if it has a name -
then you show them the major scale and it will all make sense because
it will be a solution to a problem, not a solution waiting for a
problem.
In some ways I feel that the Haskell community because of their
expertise and enthusiasm gives users answers to questions they haven't
asked yet. When they do (inevitably) ask your awesome monad tutorial
(which helped me a great deal) will be there.
-deech
On Sat, Jul 23, 2011 at 6:39 PM, Ertugrul Soeylemez <[email protected]> wrote:
> David Place <[email protected]> wrote:
>
>> > Point taken, but to get serious with Haskell you will want to learn
>> > applicative functors and at least the function arrow anyway.
>>
>> Interesting thoughts, Ertugrul. ?I would argue that you can get very
>> serious with Haskell without understanding applicative functors and
>> the function arrow. ?The very basic aspects of the language (the type
>> system, higher-order functions, lazy evaluation, etc?) are already so
>> powerful, that you really don't need to add complexity to simple
>> programs by including some of the more obscure extensions. ?I could
>> see if it made the code substantially more compact. ?In this case, it
>> makes the code more verbose as you need to import the two modules to
>> do something which can be so trivially expressed as an abstraction.
>
> Haskell application development is more than just the language. ?The
> language itself is very powerful, yes, but serious applications I write
> usually have quite a few dependencies. ?If you want to reinvent the
> wheel for everything, then yes, I'm exaggerating. ?Personally I don't
> want to, because there are great libraries and design patterns out
> there, for which you simply need to understand more than just the
> language.
>
> It's as simple as this: ?To get serious with Haskell, you need to
> understand Haskell monads. ?Understanding them implies understanding
> applicative functors (not necessarily the applicative style). ?For many
> of the useful libraries you will want to go further and understand monad
> transformers and more.
>
> I'm not talking about any ideals here. ?I'm talking about real world
> application development, which is what I am doing.
>
>
>> When you write a program, do you think of it as a document only for
>> the compiler to understand, or might some other people need to
>> understand it someday?
>
> "It"? ?For me type signatures are specification for the compiler and
> documentation for humans, along with Haddock-style comments. ?My code is
> usually very well documented. ?In most cases Haddock shows me a coverage
> of 100% for all of my source files, and every top-level and
> 'where'-definition has a type signature. ?I'm very rigorous here.
>
> All of the power I get from Haskell itself, the base library and the
> many libraries I use I view as tools to get stuff done quickly, safely
> and elegantly. ?As said, there is always a simpler way to write stuff,
> but I have a certain style, which I follow consistently, and in that
> style I write 'second pure'. ?That's it.
>
> Why not '(:[])'? ?Simply because I hate it and find it confusing. ?Why
> not 'return'? ?Because I write my code reasonably general. ?Not that
> using 'return' would change the type signature in question, but it is
> just my style. ?In a do-block I use 'return'. ?Everywhere else I use
> 'pure'. ?Consistently. ?Why 'second'? ?Because it's convenient.
>
>
> Greets,
> Ertugrul
>
>
> --
> nightmare = unsafePerformIO (getWrongWife >>= sex)
> http://ertes.de/
>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
------------------------------
Message: 2
Date: Sun, 24 Jul 2011 11:54:58 +1000
From: Arlen Cuss <[email protected]>
Subject: Re: [Haskell-beginners] [Haskell-cafe] For class Monoid;
better names than mempty & mappend might have been: mid (mident) &
mbinop
To: Ivan Lazar Miljenovic <[email protected]>
Cc: [email protected], haskell-cafe <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 24.07.2011 08:20, Ivan Lazar Miljenovic wrote:
> On 24 July 2011 04:41, KC <[email protected]> wrote:
>> It would be easier for beginners to "grok".
I quite like mempty/mappend; they (f)map onto the [] instance as a mnemonic.
Similarly, MonadPlus (as a concept) maps to mzero/mplus quite well (and
it's distinguishing the sets of empty/append and zero/plus that helps me
remember which goes with what).
mid and mbinop seem a bit more arbitrary, and don't 'look' as nice to me
(though that's probably just because they're not as familiar as what we
already have).
------------------------------
Message: 3
Date: Sun, 24 Jul 2011 09:26:30 +0530
From: Rohit Garg <[email protected]>
Subject: Re: [Haskell-beginners] I wrote a state monad example - help
me make it more Haskellic
To: aditya siram <[email protected]>
Cc: [email protected]
Message-ID:
<cac1t7giidtortdhzea0ufbcj9g+7n477sbdmm5xpxmcqjjf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Aditya,
Your modifications are very nice. I didn't know about the modify
function. Now the code looks much better.
Thanks.
On Sun, Jul 24, 2011 at 12:55 AM, aditya siram <[email protected]> wrote:
> Hi Rohit,
> I've refactored your program a little bit. Hope you don't mind. The
> main change I made was, since there can only be four registers, to
> create explicit datatypes for each register and turn your RegisterFile
> datatype into a 4-tuple. The corresponding setter and getter,
> store_operand and get_operand have also been changed to reflect the
> new datatypes. This way there can never be errors with list indices
> etc.
>
> I've also used two new State monad functions of which you might be unaware:
> 1. modify :: modifies state with the given function.
> 2. mapM_ :: is like a "map" but takes a monadic action and applied it
> to the given ist.
>
> The output is stil the same as your code, but I've added a little type safety.
>
> I haven't covered every detail of the changes but if you're reading
> through it and get stuck, please let me know.
>
> -deech
>
> import Control.Monad.State
>
> type RegisterVal = Int
> data RegisterID = R1 | R2 | R3 | R4 deriving Show
> type RegisterFile = (RegisterVal, RegisterVal, RegisterVal, RegisterVal)
>
> get_operand :: RegisterFile -> RegisterID -> RegisterVal
> get_operand (r1,_,_,_) R1 = r1
> get_operand (_,r2,_,_) R2 = r2
> get_operand (_,_,r3,_) R3 = r3
> get_operand (_,_,_,r4) R4 = r4
>
> store_operand :: RegisterFile -> RegisterID -> RegisterVal -> RegisterFile
> store_operand (r1,r2,r3,r4) r v = case r of
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?R1 -> (v,r2,r3,r4)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?R2 -> (r1,v,r3,r4)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?R3 -> (r1,r2,v,r4)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?R4 -> (r1,r2,r3,v)
>
> eval_inst :: Instruction -> RegisterFile -> RegisterFile
> eval_inst inst rf = let store_op' = store_operand rf
> ? ? ? ? ? ? ? ? ? ? ? ?get_op' ? = get_operand rf
> ? ? ? ? ? ? ? ? ? ?in
> ? ? ? ? ? ? ? ? ? ? ?case inst of
> ? ? ? ? ? ? ? ? ? ? ? Add dest rid1 rid2 -> store_op' dest (get_op'
> rid1 + get_op' rid2)
> ? ? ? ? ? ? ? ? ? ? ? Sub dest rid1 rid2 -> store_op' dest (get_op'
> rid1 - get_op' rid2)
> ? ? ? ? ? ? ? ? ? ? ? Mov dest rid ? ? ? -> store_op' dest (get_op' rid)
> ? ? ? ? ? ? ? ? ? ? ? Movc dest v ? ? ? ?-> store_op' dest v
>
> --destination comes first
> data Instruction = Add RegisterID RegisterID RegisterID
> ? ? ? ? ? ? ? ? ? | Sub RegisterID RegisterID RegisterID
> ? ? ? ? ? ? ? ? ? | Mov RegisterID RegisterID
> ? ? ? ? ? ? ? ? ? | Movc RegisterID RegisterVal
> ? ? ? ? ? ? ? ? ? deriving (Show)
>
> initial_rf :: RegisterFile
> initial_rf = (0,0,0,0)
>
> insts = [Movc R1 231, Movc R2 (-42), Add R3 R2 R1, Sub R4 R2 R1]
>
> execute_program2 :: [Instruction] -> State RegisterFile ()
> execute_program2 = mapM_ (modify . eval_inst)
>
> main :: IO ()
> main = putStrLn $ show $ execState (execute_program2 insts) initial_rf
>
--
Rohit Garg
http://rpg-314.blogspot.com/
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 37, Issue 53
*****************************************
