headers
David Abrahams | 2 Dec 2005 21:15
Picon
Picon
Favicon
Gravatar

Re: Synopsis roadmap

Stefan Seefeld <stefan <at> fresco.org> writes:

> Douglas Gregor wrote:
>
>> The best reference for this is our Implementing Concepts paper,
>> available at:
>>   http://www.osl.iu.edu/~dgregor/ConceptGCC/papers/index.html
>> There's also an updated and much-improved version of the concepts
>> proposal there.
>
> Found it, thanks a lot !

So, how about it?  It is getting a bit urgent for us to have this
functionality.  If I can help in any way, I'd be willing.

Thanks,

--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Permalink | Reply | 18 comments |
headers
Stefan Seefeld | 2 Dec 2005 21:38

Re: Re: Synopsis roadmap

David Abrahams wrote:
> Stefan Seefeld <stefan <at> fresco.org> writes:
> 
> 
>>Douglas Gregor wrote:
>>
>>
>>>The best reference for this is our Implementing Concepts paper,
>>>available at:
>>>  http://www.osl.iu.edu/~dgregor/ConceptGCC/papers/index.html
>>>There's also an updated and much-improved version of the concepts
>>>proposal there.
>>
>>Found it, thanks a lot !
> 
> 
> So, how about it?  It is getting a bit urgent for us to have this
> functionality.  If I can help in any way, I'd be willing.

Could you (or Doug) please summarize what you expect synopsis to do
when it encounters such code ?

Adding productions to accept the syntax is (almost) straight forward,
but doing even the least bit of semantic analysis is not.

As you may know, the old parser has some trouble with slightly 'advanced'
C++ code, which made me start to rewrite it entirely. (Looking back now,
I wonder how it managed to produce any useable results on things like
boost's libraries at all.)
While I feel I make good progress with the new parser, it definitely
(Continue reading)

Permalink | Reply | 17 comments |
headers
David Abrahams | 2 Dec 2005 22:08
Picon
Picon
Favicon
Gravatar

Re: Synopsis roadmap

Stefan Seefeld <stefan <at> fresco.org> writes:

> David Abrahams wrote:
>> Stefan Seefeld <stefan <at> fresco.org> writes:
>> 
>>>Douglas Gregor wrote:
>>>
>>>
>>>>The best reference for this is our Implementing Concepts paper,
>>>>available at:
>>>>  http://www.osl.iu.edu/~dgregor/ConceptGCC/papers/index.html
>>>>There's also an updated and much-improved version of the concepts
>>>>proposal there.
>>>
>>>Found it, thanks a lot !
>> So, how about it?  It is getting a bit urgent for us to have this
>> functionality.  If I can help in any way, I'd be willing.
>
> 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?

> As you may know, the old parser has some trouble with slightly 'advanced'
(Continue reading)

Permalink | Reply | 16 comments |
headers
Stefan Seefeld | 2 Dec 2005 22:43

Re: Re: Synopsis roadmap

David Abrahams wrote:
> Stefan Seefeld <stefan <at> fresco.org> 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joel de Guzman | 3 Dec 2005 01:13
Picon
Gravatar

Re: Re: Synopsis roadmap

David Abrahams wrote:
> Stefan Seefeld <stefan <at> fresco.org> writes:

>>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?

Is it? What about the sizeof trick that depends on overload
resolution? We always use that trick in boost. Syntactic and
semantic analysis is always heavily intertwined in C++.

Regards,
--

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
Permalink | Reply | 1 comment |
headers
David Abrahams | 3 Dec 2005 14:14
Picon
Picon
Favicon
Gravatar

Re: Synopsis roadmap

Joel de Guzman <djowel <at> gmail.com> writes:

> David Abrahams wrote:
>> Stefan Seefeld <stefan <at> fresco.org> writes:
>
>>>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?
>
> Is it? What about the sizeof trick that depends on overload
> resolution? We always use that trick in boost. Syntactic and
> semantic analysis is always heavily intertwined in C++.

Being able to resolve the result of sizeof never affects how parsing
proceeds.  Types remain types, templates remain templates, and the
syntactic role of everything else remains as it was, too.

--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Permalink | Reply | 0 comments |
headers
Stefan Seefeld | 5 Dec 2005 16:49

Re: Re: Synopsis roadmap

David Abrahams wrote:

>>>So, how about it?  It is getting a bit urgent for us to have this
>>>functionality.  If I can help in any way, I'd be willing.

can you quantify that 'urgent' a bit ?

>>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.

[...]

> 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.

The obvious first step is to add an option to the lexer and the parser
to recognize the new tokens and generate appropriate parse tree nodes.

As you pointed out, this doesn't any additional semantic analysis,
and so shouldn't take very long (assuming the parser is able to deal
with the rest of the code, too).

The next step, then, is to extend the AST to support the new entities
and generate those from the extended PTree.

Correct ?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Doug Gregor | 5 Dec 2005 16:24
Picon
Gravatar

Re: Synopsis roadmap

Stefan Seefeld <stefan <at> fresco.org> writes:
> David Abrahams wrote:
> > 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.

Concepts would allow you to do a bit more disambiguation in
templates, but you can probably get away with doing very little
actual new work. A concept is can be handled much like a class
template, a model like a class template specialization (partial
or full).

Depending on how far you plan to go with name lookup, concepts
could introduce some complexities there. In particular, names can
be found inside concepts listed in the where clause, e.g.,

template<typename X>
concept Iterator
{
  typename reference;
  reference operator*(const X&);
};

template<typename T> where { Iterator<T> }
reference dereference(const T& x)
{ return *x; }

That 'reference' result type is found as Iterator<T>::reference.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Seefeld | 5 Dec 2005 17:11

Re: Re: Synopsis roadmap

Doug Gregor wrote:

> Concepts are pretty lightweight
> syntactically (mainly because they rely on existing syntactic
> elements for nearly everything), so parsing them for
> documentation purposes shouldn't be too hard.

Ok, so the purpose is documentation, right ?
(Just to be sure, as synopsis is trying to provide a platform for
  other source code introspection tasks as well...)

Thanks,
		Stefan
Permalink | Reply | 0 comments |
headers
Gilles J. Seguin | 6 Dec 2005 09:59
Picon

Rename TemplateDecl to TemplateDeclaration.

stefan,

you miss some in Cxx/ASTTranslator.[hh|cc]

have a good day
Permalink | Reply | 1 comment |

Gmane