Re: Re: Synopsis roadmap

David Abrahams wrote:
> Stefan Seefeld <[email protected]> writes:

>>Could you (or Doug) please summarize what you expect synopsis to do
>>when it encounters such code ?
> 
> 
> I think Synopsis needs to build AST for it, just like any other code.
> 
> 
>>Adding productions to accept the syntax is (almost) straight forward,
>>but doing even the least bit of semantic analysis is not.
> 
> 
> I don't think any semantic analysis is needed.  But maybe you're
> calling some things semantic analysis that I am not?

Well, to be able to disambiguate certain constructs, I have to be able
to do symbol lookup, at least non-dependent names.

That used to not be part of the parser, but now is.


>>While I feel I make good progress with the new parser, it definitely
>>isn't ready for prime time yet.
> 
> 
> What's missing?

A number of productions are just not yet implemented. No type analysis,
and thus no overload resolution (*), neither partial template specialization.
Also, no constant expression evaluation (as that requires type analysis, too).

On the other hand, I have switched to using boost.wave as preprocessor a week
ago, so I'm confident that I will be able to look into parsing boost again
soon.

>>And, neither the old nor the new parser have real overload resolution or
>>(partial) template specialization.
> 
> 
> What does it mean to not "have" real partial template specialization
> in a parser?  Or overload resolution, for that matter?  (Partial)
> specialization support in a parser is just a matter of being able to
> eat the syntax.  Overload resolution is a semantic analysis issue.
> No?

yeah, probably. May be those tasks can all be postponed until after the
parsing stage. I just hadn't thought about how useful the parse tree would be
without them, though obviously the parse tree itself doesn't care, only
the other representations do.

>>So, again, the answer to your question above depends on what kind of
>>support you expect. May be we could break down the task into distinct
>>chunks (parsing, analysis, etc.), to be able to estimate the efford
>>and prioritize a bit.
> 
> 
> Absolutely.  Let's break it down.  But I'm not sure how you're drawing
> those distinctions, so I need to hear more from you I think.

Ok. Thanks for forcing me to think about these subtasks, it seems as
if breaking down the parsing will also be useful for synopsis proper. :-)

It used to be the opposite: As OpenC++ did *no* semantic analysis during
the parsing at all, it failed to parse non-trivial code, so I started to
stop thinking in terms of stages...

Regards,
		Stefan

(*) The first steps of overload resolution may already be useful, i.e.
     eliminating non-'viable' functions. That may already be enough to
     disambiguate, at least in some cases.
     Chalky wrote some code that was at least able to figure out exact
     type matches, so this, too, should be doable. But it gets pretty
     complex when we have to start thinking about all the conversions,
     i.e. if there is no exact match.