>> Oh hell, I haven't even got that far. When the inputs to a gate change,
>> and its output changes, it has to notify everything connected to its
>> output. But to do that, you have to be able to somehow look up what it's
>> connected to... and be able to change it later... and check that you
>> don't have outputs connected to other outputs... and...
>>
> 
> Yup, been there .. still there .. still not exactly what I want. Mine is 
> a bit more weird than that. I start somewhere, and begin fanning out 
> looking at various pin states, If I see more than one output, I flag 
> it... and so on. It's a sucktacular process and has many, many failings. 
> Plus, it doesn't lend itself very well to being able to follow signals, 
> being able to step from gate to gate, being able to follow a particular 
> signal path into a subcircuit...

>>> You're coding it in Haskell, aren't you?
>>
>> You trying to imply there's a causality relationship there? :-P
>>
> 
> Oh, no ... But I did have to get a Haskell dig in somewhere ;)
> 
> I am interested in seeing what your Haskell implementation will be like.

Coding stuff in Haskell encourages you to try to make everything 
"perfect", which is possibly why I'm still designing and redesigning the 
thing rather than making it actually do stuff...

Small example: Different gates have different numbers of pins. Now in an 
OO language, you'd probably just have an array (or some other container) 
of pins and be done with it. You *could* do that in Haskell too, 
except... well... there's always the possibility of a gate ending up 
with the wrong number of pins. In an OO language, you'd probably just 
ignore that possibility, in which case the code will throw some kind of 
exception if the number of pins is wrong. But in Haskell, you're more or 
less forced to explicitly handle this possibility. And that tends to 
discourage you from ignoring it, since if this happens, there's 
basically no good way to recover. (You just throw an exception I guess - 
which is quite frowned - or you make your functions explicitly partial, 
which is quite a bit more work.)

The net result is that in Haskell, you take more notice of this problem. 
And it turns out that by using ADTs, it's quite simple to statically 
prevent the problem from ever occuring in the first place. So you can 
design your code so that there's this problem that might happen that you 
have to explicitly test for and explicitly deal with, or you can design 
your program so that the problem is guaranteed to never happen in the 
first place. Guess which option the typical Haskell programmer is going 
to go for. ;-)

Of course, making everything "perfect" like this requires quite a lot of 
think-time. Haskell strongly encourages this style of "think twice, code 
once". Anyway, I believe I'm closing in on a solution, but I'll believe 
it when the code actually runs properly!

Post a reply to this message