[Patch, Fortran] F2003: More ASSOCIATE stuff

[Daniel Kraft]

Tobias Burnus wrote:
>  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.

Alright, I did the split and committed as rev. 163295.  Thanks for the 
fast review!

cheers,
Daniel

-- 
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri