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