7 ms·
Without knowing Haskell, it looks like there are bugs in the code. Specifically, there's no delay after LEDTurnOff in the first example, and you have the same f
by PennRobotics 5y ago
Without knowing Haskell, it looks like there are bugs in the code. Specifically, there's no delay after LEDTurnOff in the first example, and you have the same function name twice in the second example.
If those are bugs, I'd forgive that. If those AREN'T bugs, then keep me far, far away from FP!
Also, what is the point of i? Clearly, each LED should have its own index, but then i is never used again. (I understand this could be pseudocode or there's a lot of other code not included.)
And the ranges are inclusive in Haskell? I feel like a lot of friction between Matlab and Python involves how each language's indexing/slicing/ranges are represented, so it's interesting to see each language's approach (indenting like Python, lower camel case, delays in us, etc.) --- but with every language difference, I'm personally less inclined to want to learn something new without a great reason.
- dwohnitmok 5y agoAh yes you are totally right. I misread the initial example: turnOnThreeLEDs = for_ [1..3] (\led -> do turnOn led threadDelay (10^6) turnOff led ) It should be the above (i is changed to led), where I thought the original was automatically going to a new led and didn't realize that `led` was actually an integer and `turn_on` and `turn_off` are basically pseudo-methods (or extension methods). (The original code also only sleeps after turning an LED on, not off) Indeed the second example is a typo that should have on vs off. for_ [1..3] (\led -> do { turnOn led; threadDelay (10^6); turnOff led }) The joys of writing code on mobile and too much copy pasting. `i` is the same thing as `for i in...`. Also yes ranges are inclusive.
- PennRobotics 5y agoThanks for all the info. I want to give FP a proper try one day, and there are many different roads, but it's always a rocky start for me with a new language. Having a clear translation from one to the other is important, so I'm glad you updated this. True that this matches the original example. I guess my mind filled in the second delay automatically when it noticed, "this isn't gonna blink to the naked eye!"