[Patch, Fortran] F2003: More ASSOCIATE stuff

Tobias Burnus burnus@net-b.de
Tue Aug 17 08:13:00 GMT 2010


  On 08/17/2010 09:58 AM, Daniel Kraft wrote:
> Tobias Burnus wrote: I also would expect an error for: The same 
> restrictions are valid for INTENT(IN) variables themselves or 
> PARAMETERs, for instance -- so I'd try to implement some general 
> concept of variable definition context in order to unify and fix 
> this.  If that's ok, in a seperate patch.

Yes, that's fine. I just wanted to mention it as you talked about using 
it as actual argument to "INTENT((IN)OUT)" - thus I wanted to make sure 
this usage case does not get forgotten.

>> OK, but I have one nit:
>>
>> +      gfc_error ("'%s' at %L associated to %s can not"
>> +             " be used in a variable definition context",
>> +             sym->name,&sym->declared_at,
>> +             (target->expr_type == EXPR_VARIABLE
>> +              ? "vector-indexed target" : "expression"));
>>
>>
>> Can you split this into two gfc_errors? I think we make the live for 
>> the translators much easier if we do not use %s + a string.
>
> I wondered about this, myself.  My rationale for why I thought it is 
> not too bad was that the expressions inserted are somewhat "complete 
> expressions" specifying "a thing" -- and thus it should be hopefully 
> possible to translate this constructions (or the individual strings).

Translating individual strings without context is difficult - it it 
might happen that, e.g., "expression" occurs twice. If you then need an 
article, you might be in trouble, e.g.
"... to an expression ..."  vs. "... to a vector-indexed target"
Where to place the article? In the long string you cannot as it is 
depends on the term which is in "%s". And for "expression" you only can 
do it if (a) you realize that it is used in the context above and (b) 
when "expression" is not used elsewhere.

I think in general, we do not give much help to translators with our 
strings. I think it is possible to annotate the strings and thus helping 
the translators to understand the terms, e.g. "dummy" or "parameter" 
might be wrongly interpreted by compiler/computer science translators 
without Fortran background.

Have a look at gcc/po/gcc.pot to see how it looks from a translator 
perspective and note (a) how many strings they have to translate (namely 
7865), how many terms are used multiple times (i.e. multiple files 
listed for a single mesgid), and how few strings have a comment above to 
help the translator (Answer: Essentially none; there are comments 
[search for "#."] but they are for the programmers and not for the 
translators). -- I think we should try to improve the translator 
comments ...

> So do you agree with committing when I've split the error message?

Yes.

Tobias



More information about the Fortran mailing list