Re: Re: Synopsis roadmap
Stefan Seefeld <[email protected]>
| Newsgroups | gmane.comp.documentation.synopsis |
|---|---|
| Message-ID | <[email protected]> |
Hi Gilles, Gilles J. Seguin wrote: >>As I'm working my way through the boost headers (with the synopsis >>parser, of course), I'm reminded that I do need at least some type >>analysis: I need to be able to do non-dependent symbol lookup in the >>presence of template specializations. >>I haven't really looked into the topic yet, but I would expect it to >>be comparably complex to overload resolution, i.e. with the evaluation >>of multiple conversion paths etc. >> >>Am I missing something here ? Or would you not call this 'semantic analysis' ? > > > Stefan, you seem to assume that the parser is only useful on validated > files. > > I think that the parser do not require ambiguities to be resolved to > produce a valid ptree on either overload and template specialization. > > That means, we must try to push the program analysis or validation has > far has we can from the ptree construction. I certainly agree that we should at least conceptually separate all analysis into stages so synopsis useres don't pay for something they don't actually need. However, the issue here is exactly the same that triggered my parser rewrite: Without knowing whether 'foo<bar>::baz' is a variable or a type, I may run into ambiguities. The only new aspect is now that the 'foo' class template may or may not be specialized for 'bar', and so the correct symbol 'baz' can only be looked up knowing what 'bar' actually is (this may involve type analysis, if it is a type argument, or constant integral evaluation if it is a non-type argument). > I see the produce ptree has a saved file > - that can be used as precompile headers, > - that can be used to produce what is necessary for documentation using > java comments for example. > - that can be used for programs transformation. > > Probably different levels of analysis are necessary depending of the > documentation required. May be more advanced documentation can be > postponed. Possibly, but I'm not even talking of any particular type of processing. The common first step for all the above is unambiguous parsing, which is all I'm aiming at right now. (Needless to say, I would love to be proven wrong.) Regards, Stefan