
Oh, yes, I suppose it could. In any case, I am still in favor of the existing semantics -- it is simple and consistent (and sometimes even useful). "Do what I mean"-style semantics with special cases end up generating more pain than they solve. -Brent On Mon, Apr 29, 2013 at 02:29:43PM -0400, David McBride wrote:
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
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
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
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
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
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 > Beginners@haskell.org > http://www.haskell.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners