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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,184737148aef02ac X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Fixed point multiplication ambiguity Date: 1999/01/29 Message-ID: #1/1 X-Deja-AN: 438393002 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <78sojm$crk$1@plug.news.pipex.net> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1999-01-29T00:00:00+00:00 List-Id: Nick Roberts (Nick.Roberts@dial.pipex.com) wrote: : ... : What this means is that a compiler _deeply searches_ a complete context for : a single, unambiguous, interpretation: in this case, the one with all : Durations. I was simply assuming that Ada wouldn't be designed this way (I : wouldn't have :-). It doesn't actually need to search that far. For example, in a case like this, it is only concerned with directly visible operators, and that is a pretty well-defined set. The thing which makes it a bit more complicated in many Ada compilers is that all the predefined operators are not really inserted into the symbol table, but instead "spring" into existence when referenced. The one place where things can get truly exponential is in the following: (a,b) & (c,d) & (e,f) & (g,h) & ... The compiler is not "allowed" to look inside the aggregates until it has determined what composite type each must be, by using context. Because there are 4 predefined "&" operators for every array type, and in the case of an array-of-composite, you could legitimately use all 4 different operators in a single expression like the above, some sort of tree-pruning is necessary. As a little anecdote here, we had one user who rather than simply writing a large aggregate as: (a,b,c,d, e,f,g,h, i,j,k,l, ... [for several pages] They instead chose to write it as: (a,b,c,d) & (e,f,g,h) & (i,j,k,l) & ... [for several pages] It blew out several gourds... In all other cases, a "straightforward" (yeah, right) bottom-up enumeration of all possibilities, with removal of illegal combinations on the way up, is generally efficient enough. : Why? Because it means that the search space could, theoretically, end up : getting rather big. But, of course, in practice, it's very unlikely to get : _too_ big (especially considering the big search spaces modern compilers : cover in the name of optimisation). It also means that sometimes an : interpretation will be 'non-obvious' to someone reading the code. But that's : the way it is. Maybe a change needed for Ada 200X? I could see some change in the handling of fixed-point multiplication in Ada 200X. It has been a source of incompatibilities and surprises. Other than that, though, any significant change to the overload resolution rules is *extremely* unlikely in my view. : Okay, I'm a cheeky so-and-so (you may have noticed), so my next question is: : do you recommend I try developing 'tree pruning' techniques to cut down the : search space (searching for interpretations), or just search it all 'brute : force'? Are you building an Ada compiler? If so, I would suggest investing in head examination techniques ;-). : Again, thanks. : ------------------------------------------- : Nick Roberts : ------------------------------------------- -Tuck -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA