From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,de98d0782a843079 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-13 21:37:28 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail Message-ID: <3EC1C7FB.4080806@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Problem space and solution space References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc54 1052887047 24.62.164.137 (Wed, 14 May 2003 04:37:27 GMT) NNTP-Posting-Date: Wed, 14 May 2003 04:37:27 GMT Organization: AT&T Broadband Date: Wed, 14 May 2003 04:37:27 GMT Xref: archiver1.google.com comp.lang.ada:37309 Date: 2003-05-14T04:37:27+00:00 List-Id: 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.)