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:  Show for Parameterized Type (Hartmut)
   2. Re:  Where to put an experimental package? (Arlen Cuss)
   3. Re:  Identifying general patterns / typeclass     instances (yi huang)
   4. Re:  Conciseness question (Manfred Lotz)
   5. Re:  Identifying general patterns / typeclass     instances
      (Tim Cowlishaw)
   6. Re:  Conciseness question (David Virebayre)
   7. Re:  Conciseness question (Ertugrul Soeylemez)


----------------------------------------------------------------------

Message: 1
Date: Mon, 8 Aug 2011 00:09:14 +0200
From: Hartmut <[email protected]>
Subject: Re: [Haskell-beginners] Show for Parameterized Type
To: David Place <[email protected]>
Cc: [email protected]
Message-ID:
        <CAFz=tHE0=2pdm9noy+7next2kdsme7ny7-dp5zkcnrc+1tb...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

My early intention was to limit the EW data type to showable/readable
values. It wanted it to only accepting one of these.
Now I have even two alternatives to choose :-)
Thanks
Hartmut

On Mon, Aug 8, 2011 at 12:02 AM, David Place <[email protected]> wrote:

>
> On Aug 7, 2011, at 5:54 PM, Hartmut wrote:
>
> David,
> that was fast :-) Thank you for your help!
> Hartmut
>
>
> Your welcome.  ;-)  I needed the break from what I was doing.  I think I
> actually would like to add that normally i wouldn't put the class
> constraints in the data type definition.
>
> module Main where
>
> data EW a = EW a
>
> x01 = EW 20
> x02 = EW "Test"
>
> instance (Show a) => Show (EW a) where
>   show (EW x) = show "EW:" ++ show x
>
> instance (Read a) =>  Read (EW a) where
>     read (etc...)
>
> ____________________
> David Place
> Owner, Panpipes Ho! LLC
> http://panpipesho.com
> [email protected]
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.haskell.org/pipermail/beginners/attachments/20110808/1172bdc9/attachment-0001.htm>

------------------------------

Message: 2
Date: Mon, 08 Aug 2011 09:09:45 +1000
From: Arlen Cuss <[email protected]>
Subject: Re: [Haskell-beginners] Where to put an experimental package?
To: Tim Perry <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

8/08/2011 2:30 AM, Tim Perry kirjutas:
> Github perhaps?

+1



------------------------------

Message: 3
Date: Mon, 8 Aug 2011 11:25:55 +0800
From: yi huang <[email protected]>
Subject: Re: [Haskell-beginners] Identifying general patterns /
        typeclass       instances
To: Tim Cowlishaw <[email protected]>
Cc: [email protected]
Message-ID:
        <CAHU7rYYPj4h8efV29yR_jhjK0fXinv5msZHZnMqkP=SLtk=c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I'm wondering how you gonna `append' two state ?

On Sat, Aug 6, 2011 at 6:14 PM, Tim Cowlishaw <[email protected]>wrote:

> Hi there all,
>
> I've come up with the following sketch for a simple agent-based
> simulation program in Haskell. However, I'd be interested in knowing
> whether there are any obvious instances of more general typeclasses
> hidden in there that I haven't recognised!
>
> https://gist.github.com/1129216
>
> Some explanation: A simulation is comprised of a starting state, and a
> set of agents which take in a state and output an updated state. The
> particular simulation I'm working on has very specific timing
> semantics in that, for each 'step' of the simulation, all the agents
> must see the same state (so they cannot simply be composed and applied
> sequentially), and the resulting states must be applied to create the
> next state in a well-defined order (hence the monoid restriction on
> the SimState type). For this reason, I'm having trouble coming up with
> a monad instance (which would seem to me to imply that the 'agent'
> functions would be applied sequentially). However, are there any other
> more general typeclasses that might offer useful abstractions in this
> case?
>
> In addition, the 'building up' of a simulation from an initial state
> also looks to me like an anamorphism of some kind - is this correct?
>
> Many thanks,
>
> Tim
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>



-- 
http://www.yi-programmer.com/blog/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.haskell.org/pipermail/beginners/attachments/20110808/8efeb96d/attachment-0001.htm>

------------------------------

Message: 4
Date: Mon, 8 Aug 2011 06:02:52 +0200
From: Manfred Lotz <[email protected]>
Subject: Re: [Haskell-beginners] Conciseness question
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII

On Sun, 7 Aug 2011 16:27:11 -0400
David Place <[email protected]> wrote:

> On Aug 7, 2011, at 3:55 PM, Manfred Lotz wrote:
> 
> >> 
> >>    import Data.Map (Map, (!), lookup)
> >> 
> >>    lookup ConfigAppDir myDirs
> >>    myDirs ! ConfigAppDir
> >> 
> > 
> > This is the solution I like. I have to accept that here I cannot
> > reach the conciseness of which might be due to Haskell being
> > strongly typed.
> 
> In your original note, you mentioned that you have a small number of
> entries in your list of directories.  If so, you might find that
> association lists work just fine for you without needing to import
> Data.Map.  
> 
> > http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.html#v:lookup
> 

Yes, this is true. Assoc lists would do just fine.

What I found is that there is no real concise way of defining
something like this in Haskell. The shortest definition I found is
this:

([cAppDir, dAppDir, oAppDir],dirlist) = (l,l) where
  l = [ "app/config", "app/data", "app/other"]

which is ok. However, here I must be careful (when having 15
directories or so) to keep the sequence of variable names in line with
the sequence of directories in l. Additionally, if I have a different
number of directories in l than I have variable names in the beginning
of the definition list (cAppDir aso) I would only notice at runtime when
accessing any of those variables.


That is why a data type and then something like an assoc list is safer
to use (but more verbose).



-- 
Manfred





------------------------------

Message: 5
Date: Mon, 8 Aug 2011 08:18:23 +0100
From: Tim Cowlishaw <[email protected]>
Subject: Re: [Haskell-beginners] Identifying general patterns /
        typeclass       instances
To: yi huang <[email protected]>
Cc: [email protected]
Message-ID:
        <camuguelfcvbr3iqfm7tywdepq7gbgp6vbd98yhd8cj66dwg...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Aug 8, 2011 at 4:25 AM, yi huang <[email protected]> wrote:
> I'm wondering how you gonna `append' two state ?

Yeah - I've skirted round the details of this by specifying a monoid
restriction on the type of the simulation state, which is a pretty big
assumption (the associativity law is what's likely to be a problem I
think), However, I figured I could start with this restriction and
then try and generalise to the trickier case where the state type is
not a monoid later...

Thanks!

Tim



------------------------------

Message: 6
Date: Mon, 8 Aug 2011 09:42:03 +0200
From: David Virebayre <[email protected]>
Subject: Re: [Haskell-beginners] Conciseness question
To: Manfred Lotz <[email protected]>
Cc: [email protected]
Message-ID:
        <cam_wfvv-n3aepzhxkb1fq_z-vmnjfcby5rzu_sq+qyaqq62...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

2011/8/7 Manfred Lotz <[email protected]>:
> Hi David,
>
> On Sun, 7 Aug 2011 11:19:21 -0400
> David Place <[email protected]> wrote:
>
>> On Aug 7, 2011, at 11:07 AM, Manfred Lotz wrote:
>>
>> >
>> > What I don't want to do is to write a definition like valList
>> > because if I add a new value I have to remind myself not to forget
>> > to add it to valList too.
>>
>>
>> Hi, Manfred.
>>
>> I think we are having difficulty understanding what you are try to
>> do. ?Since, you are worried about conciseness, why not write out the
>> Haskell program that shows what you want to do without worrying about
>> conciseness. ?Then we can look for opportunities to improve it.
>>
>
> You may be right. Here is what I want to do.
>
> I have some 15 directories as Strings, where I want to do certain
> actions like to create those directories, or doing some other things
> to all of those directories.
>
> For doing this something like this would be good (for the sake of
> simplicity I do not write down all 15 entries)
>
> dirLst = [ "somedir", "otherdir" ]
>
> main = do
> ?map makeDir dirLst
> ?...
>
>
> Later on in the program I would need those directorie names to create
> (depending upon the context) new pathnames. Now something like this
> would be good.
>
> -- In my program instead of d1,...,d15
> -- I use meaningful names of course.
> d1 = "somedir"
> ...
> d15 = "otherdir"
>
>
> doSomething fls = do
> ? let pathname = d1 ++ "/bin"
> ? copyFiles2bin fls pathname
>
> ...
>

Why not

dirLst = [ ("somedir",doSomething fls),
           ("otherdir",doNothing),
           ("otherdir2",doNothing),
           ("otherdir3",doTheDance),
           ("otherdir4",doNothing)
           ("otherdir4",doDeeDooDa fls2 fls3)
         ]

doSomething fls d = do
? let pathname = d </> "bin"
? copyFiles2bin fls pathname

doTheDance d = do
  .....

doDeeDooDa f g d = do
  .....


doNothing _ = return ()

main = do
  mapM_ makeDir (map fst dirLst)
  mapM_ ((a,b) -> a b) dirLst


or even

main = do
  forM_ dirLst $ \(d,f) -> makeDir d >> f d


David.



------------------------------

Message: 7
Date: Mon, 8 Aug 2011 09:48:11 +0200
From: Ertugrul Soeylemez <[email protected]>
Subject: Re: [Haskell-beginners] Conciseness question
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII

Manfred Lotz <[email protected]> wrote:

> >     import Data.Map (Map, (!), lookup)
> >
> >     lookup ConfigAppDir myDirs
> >     myDirs ! ConfigAppDir
>
> This is the solution I like. I have to accept that here I cannot reach
> the conciseness of which might be due to Haskell being strongly typed.

Note that likely this solution is no different from the Lua solution.
You are just coding directly for what you have syntactic sugar in Lua.
After all the interpreter keeps a list (or more likely a map) of
variables and just does indexing and mapping.

Also I don't find it terribly less concise.  It's just the overwhelming
import stuff, which makes the code larger in such a small example.


> > The former is the safe variant giving you a Maybe String, while the
> > latter is the unsafe variant, which throws an exception, if the
> > directory in question is not present.
>
> Is the latter one really unsafe? I'm not quite sure how to code
> something that the compiler accepts and crashes at runtime because
> mydirs :: Map AppDir FilePath and I would believe that the compiler
> would detect if the values after the ! is not from AppDir.

The compiler cannot detect that, because you are essentially writing a
mini-interpreter.  Just like Lua cannot predetect the absence of a
variable at parse time.  To be safe you should use lookup:

    lookup :: Ord k => k -> Map k a -> Maybe a

This isn't too bad, because Maybe is a monad, and you have convenient
combinators like 'maybe':

    maybe (putStrLn "Configuration directory not specified")
          doSomethingWithConfigDir
          myAppDirs


Greets,
Ertugrul


-- 
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/





------------------------------

_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners


End of Beginners Digest, Vol 38, Issue 15
*****************************************

Reply via email to