>> True, but there shouldn't be very many of those.
> 
> It's still bad engineering. :-)

Abstract it out then. Make it a seperate function.

>> Not sure what gave you that idea... Add a field to the data structure, 
>> and only the places that use that new field have to care about it. 
>> It's a lot less work than passing lots of parameters individually.
> 
> For one, you wind up passing everything in the record to every function, 
> whether it needs it or not.
> 
> Say I want a counter for how many times I call X. That goes in the 
> record, and X increments it.  But it also gets passed to Y and Z.

And this is bad because...?

> It's still not obvious when you're actually using the control flow 
> (i.e., the program counter) as part of your state how the control flows. 
> That's probably my problem - still used to using the PC as part of the 
> program state.

OK - well that's a fairly low-level way of thinking about flow control.

> Part of the problem is that you're supposed to crash out in Erlang if 
> you get an error. So saying "did you read an integer" at all is a mess.

Yeah, Haskell's default compiler-generated stuff for parsing expressions 
assumes the program will just crash if the string isn't valid. (There is 
a hack - you can ask it to parse a list of values, and if it's not 
parsable you'll get an empty list. But now how do you tell the 
difference between a parser error and an empty list?)

Fortunately, you can use Parsec to do "real" parsing with actual error 
messages and so forth if necessary.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message