Re: Problem space and solution space

["Robert I. Eachus" <rieachus@attbi.com>]

Alexandre E. Kopilovitch wrote:

> Most important thing here is that we should consider solution spaces with
> no less attention then problem spaces. This means that we should indeed treat
> them as spaces of some sort, and try to apply to them systematically the same
> approaches and notions that we routinely associate with various kinds of spaces.
>   With that understanding the whole chain looks (well, I admit, quite vaguely)
> as a process of construction of some sort of correspondence between the problem
> space and the solution space. The task of controlling that process has its own
> problem space, and this one is that I tried to tell about in my previous posting
> under this subject line.

I prefer to think of what you do as mapping existing/known solutions 
into the problem space.  When you can put together a collection of 
solutions that covers the problem space, now all you have to do is to 
realize that mapping.  In Ada a lot of that realization can be in the 
form of generic package instantiations, or calls to routines in library 
packages.

When attacking a new problem, you can often use both decomposition, 
breaking the problem into parts, and composition, putting together known 
solutions, to find a complete, usable mapping.  Once you have such a 
mapping, what happens is that at each level of abstraction, the 
architecture reflects some part of the 'actual' problem space, while the 
implementation can and should reuse existing code solutions.

But the reason I originally blurted it out, and why those few words turn 
out to be so powerful, is that when you attempt to modify the problem 
space to fit a solution model, you are almost always making a serious 
mistake.

An excellent example of when it is right to do so came up in the early 
days of Ada, when the language was still being defined.  There were some 
troubling implementation issues for Ada compilers.  Two examples were 
how to determine when an apostrophe is part of a character literal, and 
how to do overload resolution.  In both cases elegant algorithms were 
proposed that "almost" fit.  Rather than decide whether it would be 
possible to modify the solutions to fit the language, we were able to 
decide to legislate the difficulties out of existance.  (In both cases, 
the changes to the language were minor, and basically put a thumb on the 
scale where two otherwise equally acceptable language rules were being 
considered.  But opportunities like that are very rare. ;-)

I could probably spend all night listing cases where kludging solutions 
to solve problems that didn't quite match led to disaster.  But most 
readers here would say, that reminds me...   And we'd never get any work 
done.

(If you are interested, the apostrophe case was solved by making it a 
metarule that the sets of language tokens that could be followed by 
apostrophes and by character literals would be disjoint.  So a compiler 
has no problem breaking a line like String'(',',''',',')'Length into 
tokens, even though a novice Ada programmer might find it pretty 
puzzling.  The overloading resolution was solved by an elegant two pass 
algorithm with excellent bounds on complexity.  Once Ted proposed it, no 
language changes that would break the rule were taken seriously.  As I 
said, very unusual cases.)