Re: [sv-ec] Mantis 1857 - extern method types for parameterized classes

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Wed Jun 20 2007 - 21:15:21 PDT
Mark Hartoog wrote:
> Comments inline below. 
> 
>> -----Original Message-----
>> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
>>
>> So, given just the prefix:
>>
>>     function D#(C::T, C::P, E#(C::T), F#(C::P), C::T::T2)
>>
>> you want to deal with this as a pure lexical stream without
>> doing anything while parsing the type?
>>
>> You'll have to in order to do what you suggest since the
>> next tokens could either be "C::method" in which case all
>> of the "C" references are to unspecialized names or the
>> next token could be just "some_name" in which case the
>> names all refer to types within the default specialization.
>>
>> That is the kind of nasty case that I am trying to avoid since
>> I am not sure that this can even be done correctly in all
>> cases.
> 
> Well, I don't find this that nasty to parse. It seem straight forward
> to me. You interrept the 'C::' prefixes depending on what follows.
> 
> Why is that so hard?


Well, perhaps you understand all the interactions better
than I.  I am not convinced that all possible type/value
combinations parse in an unambiguous manner without knowing
what set of names are types as opposed to values, but I haven't
come up with a definite example of where they are not.

Given that there would have been ample chance for the closest
corresponding language (C++) to do what you are suggesting
and they have not suggests that there may be complexities
lurking that we haven't run into yet.  My conservative
approach to design leads me to an approach that most closely
follows something which has had a much more substantial
investment in terms of vendor experience and thorough
user community stressing.

I guess we'll just have to disagree on this.  I don't have
a compelling and provably ambiguous case so we're down
to primarily non-technical considerations.




>> This also implies that simple mistakes that could bind
>> to names in the context of C and also a parameter of C
>> might be very difficult to discover, particularly if they
>> denote the same type initially.  This could lead to very
>> odd errors if one of the types changes much later in
>> the development cycle.
>>
>> Finally, in non-trivial cases, this is much more ugly than
>> the other variants of syntax *in addition* to having the
>> special semantics for the name binding.
>>
>> All of this stuff is easy in the simple cases but gets
>> pretty nasty in the general cases and is made more
>> complex by the verbosity of the description.  I would
>> much prefer something like:
>>
>>     function #(type T, P) D#(T, P, E#(T), F#(P), T::T2)
>>
>> for the extern case and have a direct match with the
>> function return type since it is going to be really
>> nasty for the users (and the implementation) if we
>> don't.
> 
> I do not like this particular version at all. That looks like a
> parameterized
> function, which it is not at all. It is a highly misleading declaration.
> There is absolutely no reason to repeast the parameter declarations. 


Well, Jonathan and I both prefer the "C::function" form...

It was feedback from the user community that led to the
form I used above.  Both Neil and Mike (in the user community)
have expressed a definite preference for that form.  Perhaps
they would prefer the form that you are suggesting -- if so,
I'd definitely want to hear that feedback.


In a vote, I would vote against your approach.  Apparently
you are pretty opposed to the other alternatives that have
been suggested.  That leaves us in a bit of a tough place;
I don't really want to treat this as a "count the votes"
issue.  I think this is a pretty important issue on which to
reach consensus -- there are definite implications for future
work and impact on what can be expressed right now.  Vendors
clearly will need to do something something in this space
and, based on the discussions here, I suspect that there
may be divergence in what vendors choose to do if there is
no direction in the LRM.  That is certainly not a good end
result for the user community.


Anyone else want to proffer an opinion to sway either one of
us?  User input would be particularly useful here.


Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Jun 20 21:15:46 2007

This archive was generated by hypermail 2.1.8 : Wed Jun 20 2007 - 21:16:05 PDT