On Sunday, February 26, 2017 at 12:38:53 AM UTC, Eric G wrote:
>
> I like your step by step procedure Rupert, it kind of puts in words what 
> I've been doing, but in a more systematic way. I often do end up with "a 
> product of sums of little products", -- several things that each 
> have distinct states, each of which have some sets of fields in common and 
> some not.  In other words an attempt to deal with Brian's  "'this is like 
> that except for...' problem ... the core software design problem in messy 
> domains."  (And let's face it, *every* domain outside of general purpose 
> tools is 'messy').
>

Yeah, I think as a step by step procedure its working out ok. Of course, 
not everything fits this pattern (I have one model which is a tree, not a 
state machine, for example). What I am finding most useful in this approach 
is that it combines well with a paper design approach. I am tending now to 
get a piece of paper and start by sketching out a state diagram onto it, 
marking in which state transitions are possible, then scribbling on fields 
that are needed and in what states. A couple of quick iterations of this 
and then I am ready to write some code but with a much better plan than I 
was approaching it with previously. 

I think the function names I have come up with are a little too long. I 
need to come up with a better name than 'mapWhenWith'. 
'mapWhenWithCompose' is not really a compose combinator as it does not 
follow an (a->b)-(b->c)->(a->c) pattern, so I need a better name for it too.
I tend to be writing functions on the state machine that take one of three 
forms:

a->State->Maybe State -- When it might fail.
a->State->State -- When it will definitely succeed.
a->State->Maybe b -- When it gets optionally mapped to something else

Once the first arguments are supplied to these I end up with (State -> 
State) or (State -> Maybe State) or (State -> Maybe b) functions, or in the 
general case (a->b) and (a->Maybe b). Looking at Maybe and Maybe.Extra I 
don't think there are combinators for working with all permutations of 
these, so I think I will try and figure out what all the combinators are. 
Inline versions of the combinators are also very handy, but hard to think 
of good symbols for them that don't end up making the code harder to read.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to