Invisible wrote:
> Haskell is a "pure" functional language, in the same way that Eiffel is 
> a "pure" OO language. It seems that most "functional" languages aren't 
> very pure. Conclude what you want about that...

Yeah, Haskell is pretty cool that way.

> Yeah, typically in Haskell you'd either do something like takeWhile to 
> grab just the data you want, or write a custom loop yourself.

But by writing the loop yourself, you've separated the logic of the loop 
from the logic the loop loops over.  I.e., your control isn't anywhere 
near (textually) your actions.

> Wanna pass more information around? Change the state data structure.

So you have it all wrapped up in some other data structure, and you're 
adding to that. You still have to track down places you created it, and 
add the additional information.

I.e., since looping requires recursion, every time you change what data 
persists between iterations, you have to change all the recursive calls. 
Maybe the state monad helps, and you could probably do the same thing by 
wrapping your stuff in a record in Erlang, but that's just really 
covering up the problem, in some ways.

> It's a parser library, and the usual way to implement a parser is with 
> some kind of state machine. However, Parsec uses a parser monad to 
> implement complex flow control (choice, iteration, back-tracking, error 
> handling, etc.)

Oh, Erlang has that sort of stuff. I guess I could write a turn-based 
video game as a finite state machine. That still doesn't clarify how the 
control flow flows. I.e., you can't just read off the steps for 
performing a turn. Stuff like
   Ask for a word
   While the word is not valid
     explain why, ask again
   Ask for a number
   while the number is invalid,
     explain why, ask again

That winds up being like ten separate functions in Erlang,
once you deal with stuff like "the thing the user typed isn't
a number" and so on. It becomes really unobvious to me reading
the code just what the control flow is.

I'll check out the Parser thing and see what it suggests.

>> Every time one you change one of those to track something new, you 
>> have to track down every call and pass the new thing.
> 
> In that case, it's probably best to define the information you're trying 
> to keep track of as a data type and just add/remove fields as required 
> when the design changes. That way you only pass around a single parameter.

Yeah, even more obscure, unfortunately. :-) Now you not only have 
hard-to-follow control flows, but you wind up passing a large record 
full of stuff to a function that really only needs one or two fields, or 
you wind up extracting just those couple of fields for that call at 
which point you're back to the same problem again.

-- 
Darren New / San Diego, CA, USA (PST)
  Helpful housekeeping hints:
   Check your feather pillows for holes
    before putting them in the washing machine.

Post a reply to this message