Invisible wrote:
>>> True, but there shouldn't be very many of those.
>>
>> It's still bad engineering. :-)
> 
> Abstract it out then. Make it a seperate function.

Of course. The problem there is that to make a complex control flow, you 
wind up with a dozen or two functions that really don't have an 
independent function, and they're all at the top-level of code. (You 
can't nest functions in Erlang, altho you can nest lambdas (of course), 
and the syntax is verbose enough you wind up with a dozen indents if you 
do something truly functional-style.)

I.e., it's bad engineering.

>> 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 bad engineering, the same way global variables are bad engineering. 
If the structure comes back with things changed that shouldn't have 
been, you have way more places to look. The whole point of "functional" 
is to limit the number of places you have to look to see what went wrong.

>> 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.

I'd more say it's thinking about control flow at all, rather than 
thinking about "meaning" or some such. It's more that I'm trying to 
describe it in a way that makes clear what I'm talking about than it is 
I normally think of the PC as "part of the global state".

I often, however, say "at this point in the program, I know the 
following things are the case..."  As in, "by the time I leave this 
loop, I know the loop condition is false, so I can count on the index 
not pointing to a whitespace character" or some such.

>> 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. 

It's not really that in Erlang. It's more that since it's dynamically 
typed, trying to convert an arbitrary return from a read (which may 
include end-of-file or some other read error) into an integer requires 
a layer of catching of errors. Not all that unusual, but yet another 
level of nesting.

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

I would consider something like that overkill for "read an integer from 
this file stream".

As I work on more projects with less interactivity and control flow, 
it's getting easier. Stuff where I'm just flogging files, or portions 
thereof, aren't excessively difficult. Maybe I'll go back and rewrite 
the interactive part of the program again and see if I've figured it out 
more.

(Another part of the problem, I suspect, is how I structured it. I'm 
trying to make it accessible in a variety of ways, in the sense that I 
rewrite as little as possible for different human languages, socket vs 
console vs web page, etc etc.)

-- 
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