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: How best to do this? (emacstheviking)
2. Re: Segmentation fault (Michael Peternell)
3. Re: How best to do this? (Brent Yorgey)
4. Re: How best to do this? (David McBride)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Apr 2013 17:00:13 +0100
From: emacstheviking <[email protected]>
Subject: Re: [Haskell-beginners] How best to do this?
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Message-ID:
<caeieuul4tlf+_ezvn7shhwa5u7sarfnvhbct13e8gc5ja+o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I like / don't like the "Random things would probably blow" because this is
driving hardware as well!
Scary stuff!
Thanks again.
On 29 April 2013 16:57, David McBride <[email protected]> wrote:
> I think it is because that syntax is desugared directly to enumFromTo
> x y and enumFromTo 3 0 is []. Random things would probably blow up if
> you make that function work in reverse. But I would love it if ghc
> just checked whether the first was lower than the second and swapped
> them as a convenience.
>
> On Mon, Apr 29, 2013 at 11:44 AM, emacstheviking <[email protected]>
> wrote:
> > ROFLCOPTER indeed Batman!
> >
> > I had no idea of that... I just *assumed* (usual rules apply I guess)
> that
> > [3..0] was the "opposite" of [0..3] but sure enough a wuicj ghci session
> > reveals the bitter truth!
> >
> > Thanks again... i can see that it's not just me that is too lazy at
> times. I
> > guess writing [3,2..0] will do for now but is that a bug or is there some
> > other reasoning behind it?
> >
> > We live and learn, well, I live anyway...
> >
> > :)
> >
> >
> >
> > On 29 April 2013 16:37, David McBride <[email protected]> wrote:
> >>
> >> One other gotcha. I don't know why it is this way, but [3..0]
> >> evaluates to []. I have no idea why reverse notation is not allowed.
> >> But you can just manually reverse it or you can go [3,2..0].
> >>
> >> On Mon, Apr 29, 2013 at 11:26 AM, emacstheviking <[email protected]>
> >> wrote:
> >> > damn that lazy evaluation! LMAO ...a good point brent and yuo have no
> >> > doubt
> >> > saved me hours of head scratching this evening when I try out the "new
> >> > improved software". Oh dear oh dear oh dear...
> >> >
> >> > doOption dev (Forward n) = do
> >> > putStrLn $ "> STEP FORWARD " ++ (show n)
> >> > stepBits dev ioPORTA [3..0]
> >> >
> >> >
> >> > doOption dev (Backward n) = do
> >> > putStrLn $ "> STEP BACKWARD " ++ (show n)
> >> > stepBits dev ioPORTA [0..3]
> >> >
> >> > stepBits dev port = mapM_ stepIt
> >> > where stepIt bit = mapM_ (\s -> HW.setPortBit dev port bit s >>
> >> > stepDelay)
> >> > [0,1]
> >> >
> >> > I now have the above as my current "final" implementation... hopefully
> >> > that
> >> > *does* do what I think it does because mapM_ is driving it and will
> >> > cause
> >> > evaluation of the actions?
> >> >
> >> >
> >> >
> >> >
> >> > On 29 April 2013 15:56, Brent Yorgey <[email protected]> wrote:
> >> >>
> >> >> On Mon, Apr 29, 2013 at 02:59:29PM +0100, emacstheviking wrote:
> >> >> > I have built a library for using the Hexwax expandIO-USB chip and I
> >> >> > have
> >> >> > now got some code to drive a stepper motor:
> >> >> >
> >> >> > doOption :: HWHandle -> Flag -> IO ()
> >> >> > doOption dev (Backward n) = do
> >> >> > putStrLn $ "> STEP BACKWARD " ++ (show n)
> >> >> > let x = [ stepBit b | b <- [3..0]]
> >> >> > return ()
> >> >> > where
> >> >> > stepBit p b = setBit p b 0 >> setBit p b 1
> >> >> > where setBit p b s = HW.setPortBit dev p b s >> stepDelay
> >> >>
> >> >> The other posted solutions are good, but I also want to make a very
> >> >> important comment about the above code: it does not actually step any
> >> >> bits! All it does is print some stuff. x is simply a name for a
> list
> >> >> of IO actions; it is never used so it just gets garbage collected and
> >> >> the IO actions are never run.
> >> >>
> >> >> -Brent
> >> >>
> >> >> _______________________________________________
> >> >> Beginners mailing list
> >> >> [email protected]
> >> >> http://www.haskell.org/mailman/listinfo/beginners
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Beginners mailing list
> >> > [email protected]
> >> > http://www.haskell.org/mailman/listinfo/beginners
> >> >
> >>
> >> _______________________________________________
> >> Beginners mailing list
> >> [email protected]
> >> http://www.haskell.org/mailman/listinfo/beginners
> >
> >
> >
> > _______________________________________________
> > Beginners mailing list
> > [email protected]
> > http://www.haskell.org/mailman/listinfo/beginners
> >
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130429/0de46cce/attachment-0001.htm>
------------------------------
Message: 2
Date: Mon, 29 Apr 2013 18:30:12 +0200
From: Michael Peternell <[email protected]>
Subject: Re: [Haskell-beginners] Segmentation fault
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
thanks for all your help guys...
i currently don't have much time, but i will try version 7.6.2 and i will try
the 32-bit platform version and then i will report how it worked. the next
weekend i will find time, maybe earlier.
i have already tried the 7.6.3 version (mac,64bit) and it crashed on my
computer. downloaded from here (
http://www.haskell.org/ghc/download_ghc_7_6_3#binaries ).
------------------------------
Message: 3
Date: Mon, 29 Apr 2013 14:17:09 -0400
From: Brent Yorgey <[email protected]>
Subject: Re: [Haskell-beginners] How best to do this?
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
But then \x y -> [x .. y] would have to have the type
(Ord a, Enum a) => [a]
whereas now it just has the Enum constraint. Either that or else the
notation would work differently for literals vs. expressions but that
would be just awful.
-Brent
On Mon, Apr 29, 2013 at 11:57:38AM -0400, David McBride wrote:
> I think it is because that syntax is desugared directly to enumFromTo
> x y and enumFromTo 3 0 is []. Random things would probably blow up if
> you make that function work in reverse. But I would love it if ghc
> just checked whether the first was lower than the second and swapped
> them as a convenience.
>
> On Mon, Apr 29, 2013 at 11:44 AM, emacstheviking <[email protected]> wrote:
> > ROFLCOPTER indeed Batman!
> >
> > I had no idea of that... I just *assumed* (usual rules apply I guess) that
> > [3..0] was the "opposite" of [0..3] but sure enough a wuicj ghci session
> > reveals the bitter truth!
> >
> > Thanks again... i can see that it's not just me that is too lazy at times. I
> > guess writing [3,2..0] will do for now but is that a bug or is there some
> > other reasoning behind it?
> >
> > We live and learn, well, I live anyway...
> >
> > :)
> >
> >
> >
> > On 29 April 2013 16:37, David McBride <[email protected]> wrote:
> >>
> >> One other gotcha. I don't know why it is this way, but [3..0]
> >> evaluates to []. I have no idea why reverse notation is not allowed.
> >> But you can just manually reverse it or you can go [3,2..0].
> >>
> >> On Mon, Apr 29, 2013 at 11:26 AM, emacstheviking <[email protected]>
> >> wrote:
> >> > damn that lazy evaluation! LMAO ...a good point brent and yuo have no
> >> > doubt
> >> > saved me hours of head scratching this evening when I try out the "new
> >> > improved software". Oh dear oh dear oh dear...
> >> >
> >> > doOption dev (Forward n) = do
> >> > putStrLn $ "> STEP FORWARD " ++ (show n)
> >> > stepBits dev ioPORTA [3..0]
> >> >
> >> >
> >> > doOption dev (Backward n) = do
> >> > putStrLn $ "> STEP BACKWARD " ++ (show n)
> >> > stepBits dev ioPORTA [0..3]
> >> >
> >> > stepBits dev port = mapM_ stepIt
> >> > where stepIt bit = mapM_ (\s -> HW.setPortBit dev port bit s >>
> >> > stepDelay)
> >> > [0,1]
> >> >
> >> > I now have the above as my current "final" implementation... hopefully
> >> > that
> >> > *does* do what I think it does because mapM_ is driving it and will
> >> > cause
> >> > evaluation of the actions?
> >> >
> >> >
> >> >
> >> >
> >> > On 29 April 2013 15:56, Brent Yorgey <[email protected]> wrote:
> >> >>
> >> >> On Mon, Apr 29, 2013 at 02:59:29PM +0100, emacstheviking wrote:
> >> >> > I have built a library for using the Hexwax expandIO-USB chip and I
> >> >> > have
> >> >> > now got some code to drive a stepper motor:
> >> >> >
> >> >> > doOption :: HWHandle -> Flag -> IO ()
> >> >> > doOption dev (Backward n) = do
> >> >> > putStrLn $ "> STEP BACKWARD " ++ (show n)
> >> >> > let x = [ stepBit b | b <- [3..0]]
> >> >> > return ()
> >> >> > where
> >> >> > stepBit p b = setBit p b 0 >> setBit p b 1
> >> >> > where setBit p b s = HW.setPortBit dev p b s >> stepDelay
> >> >>
> >> >> The other posted solutions are good, but I also want to make a very
> >> >> important comment about the above code: it does not actually step any
> >> >> bits! All it does is print some stuff. x is simply a name for a list
> >> >> of IO actions; it is never used so it just gets garbage collected and
> >> >> the IO actions are never run.
> >> >>
> >> >> -Brent
> >> >>
> >> >> _______________________________________________
> >> >> Beginners mailing list
> >> >> [email protected]
> >> >> http://www.haskell.org/mailman/listinfo/beginners
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Beginners mailing list
> >> > [email protected]
> >> > http://www.haskell.org/mailman/listinfo/beginners
> >> >
> >>
> >> _______________________________________________
> >> Beginners mailing list
> >> [email protected]
> >> http://www.haskell.org/mailman/listinfo/beginners
> >
> >
> >
> > _______________________________________________
> > Beginners mailing list
> > [email protected]
> > http://www.haskell.org/mailman/listinfo/beginners
> >
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
Message: 4
Date: Mon, 29 Apr 2013 14:29:43 -0400
From: David McBride <[email protected]>
Subject: Re: [Haskell-beginners] How best to do this?
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Message-ID:
<CAN+Tr41MbL=5R7AR7XtjcjytvedqeZWAH+J4VcF4=o1+hf2...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Couldn't it just use fromEnum and compare the integers you get and
figure out which is bigger?
On Mon, Apr 29, 2013 at 2:17 PM, Brent Yorgey <[email protected]> wrote:
> But then \x y -> [x .. y] would have to have the type
>
> (Ord a, Enum a) => [a]
>
> whereas now it just has the Enum constraint. Either that or else the
> notation would work differently for literals vs. expressions but that
> would be just awful.
>
> -Brent
>
> On Mon, Apr 29, 2013 at 11:57:38AM -0400, David McBride wrote:
>> I think it is because that syntax is desugared directly to enumFromTo
>> x y and enumFromTo 3 0 is []. Random things would probably blow up if
>> you make that function work in reverse. But I would love it if ghc
>> just checked whether the first was lower than the second and swapped
>> them as a convenience.
>>
>> On Mon, Apr 29, 2013 at 11:44 AM, emacstheviking <[email protected]> wrote:
>> > ROFLCOPTER indeed Batman!
>> >
>> > I had no idea of that... I just *assumed* (usual rules apply I guess) that
>> > [3..0] was the "opposite" of [0..3] but sure enough a wuicj ghci session
>> > reveals the bitter truth!
>> >
>> > Thanks again... i can see that it's not just me that is too lazy at times.
>> > I
>> > guess writing [3,2..0] will do for now but is that a bug or is there some
>> > other reasoning behind it?
>> >
>> > We live and learn, well, I live anyway...
>> >
>> > :)
>> >
>> >
>> >
>> > On 29 April 2013 16:37, David McBride <[email protected]> wrote:
>> >>
>> >> One other gotcha. I don't know why it is this way, but [3..0]
>> >> evaluates to []. I have no idea why reverse notation is not allowed.
>> >> But you can just manually reverse it or you can go [3,2..0].
>> >>
>> >> On Mon, Apr 29, 2013 at 11:26 AM, emacstheviking <[email protected]>
>> >> wrote:
>> >> > damn that lazy evaluation! LMAO ...a good point brent and yuo have no
>> >> > doubt
>> >> > saved me hours of head scratching this evening when I try out the "new
>> >> > improved software". Oh dear oh dear oh dear...
>> >> >
>> >> > doOption dev (Forward n) = do
>> >> > putStrLn $ "> STEP FORWARD " ++ (show n)
>> >> > stepBits dev ioPORTA [3..0]
>> >> >
>> >> >
>> >> > doOption dev (Backward n) = do
>> >> > putStrLn $ "> STEP BACKWARD " ++ (show n)
>> >> > stepBits dev ioPORTA [0..3]
>> >> >
>> >> > stepBits dev port = mapM_ stepIt
>> >> > where stepIt bit = mapM_ (\s -> HW.setPortBit dev port bit s >>
>> >> > stepDelay)
>> >> > [0,1]
>> >> >
>> >> > I now have the above as my current "final" implementation... hopefully
>> >> > that
>> >> > *does* do what I think it does because mapM_ is driving it and will
>> >> > cause
>> >> > evaluation of the actions?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 29 April 2013 15:56, Brent Yorgey <[email protected]> wrote:
>> >> >>
>> >> >> On Mon, Apr 29, 2013 at 02:59:29PM +0100, emacstheviking wrote:
>> >> >> > I have built a library for using the Hexwax expandIO-USB chip and I
>> >> >> > have
>> >> >> > now got some code to drive a stepper motor:
>> >> >> >
>> >> >> > doOption :: HWHandle -> Flag -> IO ()
>> >> >> > doOption dev (Backward n) = do
>> >> >> > putStrLn $ "> STEP BACKWARD " ++ (show n)
>> >> >> > let x = [ stepBit b | b <- [3..0]]
>> >> >> > return ()
>> >> >> > where
>> >> >> > stepBit p b = setBit p b 0 >> setBit p b 1
>> >> >> > where setBit p b s = HW.setPortBit dev p b s >> stepDelay
>> >> >>
>> >> >> The other posted solutions are good, but I also want to make a very
>> >> >> important comment about the above code: it does not actually step any
>> >> >> bits! All it does is print some stuff. x is simply a name for a list
>> >> >> of IO actions; it is never used so it just gets garbage collected and
>> >> >> the IO actions are never run.
>> >> >>
>> >> >> -Brent
>> >> >>
>> >> >> _______________________________________________
>> >> >> Beginners mailing list
>> >> >> [email protected]
>> >> >> http://www.haskell.org/mailman/listinfo/beginners
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Beginners mailing list
>> >> > [email protected]
>> >> > http://www.haskell.org/mailman/listinfo/beginners
>> >> >
>> >>
>> >> _______________________________________________
>> >> Beginners mailing list
>> >> [email protected]
>> >> http://www.haskell.org/mailman/listinfo/beginners
>> >
>> >
>> >
>> > _______________________________________________
>> > Beginners mailing list
>> > [email protected]
>> > http://www.haskell.org/mailman/listinfo/beginners
>> >
>>
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/beginners
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 58, Issue 50
*****************************************
