(j3.2006) Materials for 199

[Malcolm Cohen]

I wrote:
> They are already integrated.  Given the popularity of PDTs with vendors and
> users, we should not be thinking of doing anything more with them at this 
> stage
> in my opinion.

Van argued:
>They are not integrated.

This is absolutely wrong.  We spent considerable time integrating them and 
succeeded to a greater extent than I imagined when we started.  What's all the 
text in the standard supporting type extension and PDT's, chopped liver?

You might not like the way they are integrated, or you might want additional 
integration, but that does not mean that they are not integrated.

>  One can declare an object of a type using kind
>type parameters that are not supported by its type-bound procedures.

This is not universally the case.  If the kind type parameters are actually used 
for the purpose for which they were intended rather than as bogus type 
quibblers, the type-bound procedures can readily support all possible kinds.

>There is no standard-conforming portable way around this.

Contrariwise.

Furthermore, no-one is forcing anyone to use PDTs combined with type extension, 
in fact given the compiler support for PDTs, I suspect the number of users 
actually writing PDTs and combining them with type extension can be counted on 
the fingers of one foot.

Finally, the problem a user faces is not "how do we use feature X in style W 
with feature Y in style Z", but how does he solve his underlying problem.  One 
might reasonably conjecture that if W+X+Y+Z is a bit clumsy to use, the user 
might choose not to solve his problem using that particular combination of 
features and styles, but that does not *necessarily* mean that making W+X+Y+Z 
easier to use should be any kind of priority for us.

>> Unless this is "another
>> scheme" that is really**7 simple, we should not be thinking about it.  We can
>> start  thinking about "wart identification and removal".
>
>The scheme I'd like to propose is simpler than parameterized modules or
>macros.

Parameterised modules are ENORMOUSLY COMPLICATED so this says little (other 
perhaps than of your opinion of macros).

>  The problem between kind type parameters and type-bound
>procedures isn't a wart.  Is it OK to excise tumors in the next
>revision, or are we only allowed to identify warts and pop pimples?

Excise tumour would be to remove PDTs entirely.  Fine by me.  Others might 
differ.

Once again, unless this is really**7 simple, we should not even be considering 
it.  If it is not incredibly simple not only to describe in the standard but 
also to implement in practice, it will not fly.  But sure, if you think it is 
that simple, go ahead and make some suggestions.  I would be quite surprised if 
those suggestions turned out to be even close to simple enough for consideration 
in the quick revision that is proposed for F2015, but I am willing to read them 
at least once.

In any case, my point about popularity stands.  That has a pretty significant 
impact on priority, we should first be addressing the deficiencies that cause 
the most trouble and which can be fixed with the least effort.

I cannot believe we can seriously be considering making the least popular most 
complicated feature even harder to implement.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.