"J-P. Rosen" wrote in message news:sj6k41$7i4$1@dont-email.me... > Le 01/10/2021 à 02:18, Randy Brukardt a écrit : >> "J-P. Rosen" wrote in message >> The ASIS design and definition is a mess (at least from the perspective >> of >> explaining what is expected). We tried to clean it up in the previous >> ASIS >> standardization update, but that was a lot of work and we probably didn't >> match implementations very well. > That was mainly an attempt to introduce more static and tagged typing, and > it failed due to the complexity involved (and that AdaCore said they would > never implement it). LibAdalang made the same error, and got the same > unnecessary complexity. No, the existing part also had major problems. Many of the terms were never defined, many possible effects were missing from the various lists of results, and loads of other things as well. That all would have had to be fixed even if the semantic interface was completely forgotten (indeed, it was kept pretty separate for that reason). >> The entire model of ASIS doesn't make much sense for static analysis >> purposes, it's way too focused on syntax rather than semantics. > It is a exact image of the program, from which you can derive all > information you need. Some higher level queries are needed, but they can > be provided as secondary queries or added to the standard. That's exactly the problem. You start with the source code, which is way too low a level for any useful analysis. At most, you want a simple connection to the source in the semantic information, not trying to preserve every punctuation mark and comment. (Janus/Ada discards all of that stuff as soon as parsing succeeds.) If you need to refer to the original source, say for error handling purposes, then do that, but don't waste vast amounts of space and time trying to keep loads of irrelevant material. >> And it >> doesn't work well for syntax analysis because it requires a compilable >> program. So it really has a very narrow use case (if any). > On the contrary. There is no semantic you can analyze in a non-compilable > program. And since it analyzes the output of a validated compiler, you can > trust it better than any custom analyzer without known pedigree. No sane compiler (validated or not) keeps all of the irrelevant syntactic detail required by ASIS. It ends up getting reconstructed solely for the use of ASIS, and how a rarely used interface is somehow more reliable escapes me. A true semantic interface on the lines of the one proposed for ASIS would make good sense (design of types), but the vast majority of the existing ASIS belongs in a rubbish bin. Good riddance. ... > But you didn't use it. True, a first approach or a casual reading of the > interface is not very friendly. But the more you use it, the more you > realize that it is very consistently defined, and allows you to do > whatever you need. I don't use it because implementing it would require adding loads of useless cruft to our Ada compiler. And even then, it doesn't make much sense based on our compilation model and our generic unit model. Supporting it would be like building a whole new Ada compiler. Ergo, it is a lie, it claims to be an "interface to a compiler", but it requires many things that most compilers would not waste time on. (I think it is a fairly close representation of the internals of early Rational compilers, which is probably why they were so slow and memory hogs. ;-) So what is it really? Just a very complex way to do stuff that you can easily do with a parser. No worth anyone's time, IMHO. I've assumed most people used it because it was there and because some people had spent a lot of time trying to define it as some sort of Standard. Just because people put a lot of work into something doesn't mean that it is a useful thing. Randy.