code that could be improved

code that could be improved

[Roland Illig]

Hi,

I'm currently translating gcc-3.4-b20040206 into German. Here is a list
of things I don't like in the current code:

- various quoting techniques: `foo', 'bar', "baz".
   => please use `foo' consistently
- inconsistent usage of `member' and `field'
   => does a struct have `field's or `member's?
   => What about unions?
   => What about C++ classes?
- some message patterns could be simplified for translation.
   for example "invalid %%f value" and "invalid %%H value" will
   always be translated with just replacing "f" by "H", won't it?
   So the code should look like

       sprintf(foo, "invalid %%%c value", 'f');

But there are also things I was happy to see:

- the new format for command line options using "-switch\tdescription"

I'll continue this list while translating further.

Roland

Re: code that could be improved

[Joseph S. Myers]

On Tue, 2 Mar 2004, Roland Illig wrote:

> I'm currently translating gcc-3.4-b20040206 into German. Here is a list
> of things I don't like in the current code:

Please report each issue as a separate bug to our bug database so that
they can be tracked.  <http://gcc.gnu.org/bugs.html>, as referenced in the
Report-Msgid-Bugs-To line of gcc.pot, makes clear this is preferred.

> - various quoting techniques: `foo', 'bar', "baz".
>    => please use `foo' consistently

Why that form?  'foo' is more correct for plain ASCII, unless and until we
develop some system for proper quotes (and likewise proper copyright
symbols) to be used when LC_MESSAGES=C if LC_CTYPE permits.  Translations
should use (consistently) whatever form of quotes is linguistically
correct for that language, as long as the character set supports it, and
this is unlikely to be any of the ASCII forms.

http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: code that could be improved

[Roland Illig]

Joseph S. Myers wrote:
> On Tue, 2 Mar 2004, Roland Illig wrote:
>>- various quoting techniques: `foo', 'bar', "baz".
>>   => please use `foo' consistently
> 
> 
> Why that form?  'foo' is more correct for plain ASCII, unless and until we
> develop some system for proper quotes (and likewise proper copyright
> symbols) to be used when LC_MESSAGES=C if LC_CTYPE permits.  Translations
> should use (consistently) whatever form of quotes is linguistically
> correct for that language, as long as the character set supports it, and
> this is unlikely to be any of the ASCII forms.
> 
> http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html

Well, that argument is nice. I just wondered about the various quoting 
techniques and had thought it would be best to stick to the old style.

Thanks for the link.

Roland

Re: code that could be improved

[Zack Weinberg]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

>> - various quoting techniques: `foo', 'bar', "baz".
>>    => please use `foo' consistently
>
> Why that form?  'foo' is more correct for plain ASCII, unless and until we
> develop some system for proper quotes (and likewise proper copyright
> symbols) to be used when LC_MESSAGES=C if LC_CTYPE permits. 

A batch conversion to the preferred form would be a good idea, I
think.  Now's a good time to do it, being stage 1...

zw

Re: code that could be improved

[Zack Weinberg]

Roland Illig <roland.illig@gmx.de> writes:

> - some message patterns could be simplified for translation.
>    for example "invalid %%f value" and "invalid %%H value" will
>    always be translated with just replacing "f" by "H", won't it?

Should be, yes.  But I find your suggested form harder to read, and I
don't see what it gains you...

zw

Re: code that could be improved

[Joseph S. Myers]

On Tue, 2 Mar 2004, Zack Weinberg wrote:

> > Why that form?  'foo' is more correct for plain ASCII, unless and until we
> > develop some system for proper quotes (and likewise proper copyright
> > symbols) to be used when LC_MESSAGES=C if LC_CTYPE permits. 
> 
> A batch conversion to the preferred form would be a good idea, I
> think.  Now's a good time to do it, being stage 1...

After tree-ssa merges might be better, as there are probably various new
messages involving various styles of quoting on tree-ssa.  (As doc
changes, simple quoting style changes could reasonably be done at least up
to the end of stage 3.)

I wonder whether %D and similar should default to being quoted (with some 
flag for the few places they aren't), and whether in general any such 
global diagnostics change should use special formats

%` for a left quote (' in C locale)
%' for a right quote (' in C locale)
%qs for quoted string
%qD for unquoted decl
... (I'd rather distinguish the flags for quoting strings and unquoting 
decls, but %Q is already used in the C++ front end; it could be 
reassigned.)

This would allow for future refinements to C locale quoting when the
character set permits.  It does however presume that each language has a
single left-quote string and a single right-quote string that are
appropriate in all cases of quoting.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: code that could be improved

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

| On Tue, 2 Mar 2004, Roland Illig wrote:
| 
| > I'm currently translating gcc-3.4-b20040206 into German. Here is a list
| > of things I don't like in the current code:
| 
| Please report each issue as a separate bug to our bug database so that
| they can be tracked.  <http://gcc.gnu.org/bugs.html>, as referenced in the
| Report-Msgid-Bugs-To line of gcc.pot, makes clear this is preferred.
| 
| > - various quoting techniques: `foo', 'bar', "baz".
| >    => please use `foo' consistently
| 
| Why that form?  'foo' is more correct for plain ASCII, unless and until we

Each time I've expressed that form, people have made the characterization
that I was being dense.  I suppose that if *you* make it, it would be more
acceptable <g>. 

Anyway,  actually, I think we need something more than just 'foo' for
proper handling in the pretty-printer.  There is at least one PR open
since ages that is better handled by such a clear qoute marker
understood by the pretty-printer (e.g. %"foo, %'foo, %whateverfoo).
The reason is that the line-wrapper needs to have a clear knowledge of
when it is in the middle of (or just starting a quote) so that it
"cuts" properly. 

-- Gaby

Re: code that could be improved

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

| I wonder whether %D and similar should default to being quoted (with some 

I don't think that default would be appropriate.  There are common
situations where we want to say

   "fubar '%D::%T' is foo and bar" 


| flag for the few places they aren't), and whether in general any such 
| global diagnostics change should use special formats
| 
| %` for a left quote (' in C locale)
| %' for a right quote (' in C locale)
| %qs for quoted string
| %qD for unquoted decl

I would prefer a simple

  %q for quoted tree or string

There is no conceptual difference when a tree  or string literal is
reported in diagnostics.

| ... (I'd rather distinguish the flags for quoting strings and unquoting 
| decls, but %Q is already used in the C++ front end; it could be 
| reassigned.)

I do believe that %Q should be reassigned -- I came to the same
conclusion when I wanted to solve properly PR 712 which is open since
ages.  It is fa better properly solved with a clear quote marker.

| This would allow for future refinements to C locale quoting when the
| character set permits.  It does however presume that each language has a
| single left-quote string and a single right-quote string that are
| appropriate in all cases of quoting.

Well, that is a good starting point.

-- Gaby

Re: code that could be improved

[Joseph S. Myers]

On Tue, 2 Mar 2004, Gabriel Dos Reis wrote:

> I don't think that default would be appropriate.  There are common
> situations where we want to say
> 
>    "fubar '%D::%T' is foo and bar" 

That seems quite rare; the bulk of uses are quoted on their own and there
are a few cases that are unquoted for no obvious reason.

decl.c:     error ("explicit specialization of %D after first use",
decl.c:         error ("duplicate initialization of %D", decl);
parser.c:    error ("%D redeclared with different access", decl);
pt.c:                 error ("specialization of %D after instantiation",

> | %` for a left quote (' in C locale)
> | %' for a right quote (' in C locale)
> | %qs for quoted string
> | %qD for unquoted decl
> 
> I would prefer a simple
> 
>   %q for quoted tree or string
> 
> There is no conceptual difference when a tree  or string literal is
> reported in diagnostics.

We need %` and %' for all the cases such as '%D::%T' you gave where more 
than a single format specifier is quoted.  But where a single specifier is 
quoted, there is a case for consistency in use of %q even if this does 
mean almost all uses of %D become %qD.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: code that could be improved

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

| On Tue, 2 Mar 2004, Gabriel Dos Reis wrote:
| 
| > I don't think that default would be appropriate.  There are common
| > situations where we want to say
| > 
| >    "fubar '%D::%T' is foo and bar" 
| 
| That seems quite rare; the bulk of uses are quoted on their own and there
| are a few cases that are unquoted for no obvious reason.
| 
| decl.c:     error ("explicit specialization of %D after first use",
| decl.c:         error ("duplicate initialization of %D", decl);
| parser.c:    error ("%D redeclared with different access", decl);
| pt.c:                 error ("specialization of %D after instantiation",

Those certainly are errors.

| > | %` for a left quote (' in C locale)
| > | %' for a right quote (' in C locale)
| > | %qs for quoted string
| > | %qD for unquoted decl
| > 
| > I would prefer a simple
| > 
| >   %q for quoted tree or string
| > 
| > There is no conceptual difference when a tree  or string literal is
| > reported in diagnostics.
| 
| We need %` and %' for all the cases such as '%D::%T' you gave where more 
| than a single format specifier is quoted.

I agree on that.

|  But where a single specifier is 
| quoted, there is a case for consistency in use of %q even if this does 
| mean almost all uses of %D become %qD.

this probably the piece I did not understand.  I thought the proposal
would be

   %`D%::%T%'  for '%D::T'

and

   %q%s or %q%D for  "%s" and '%D'

Could you reformulate, please?

-- Gaby

Re: code that could be improved

[Joseph S. Myers]

On Tue, 2 Mar 2004, Gabriel Dos Reis wrote:

> this probably the piece I did not understand.  I thought the proposal
> would be
> 
>    %`D%::%T%'  for '%D::T'
> 
> and
> 
>    %q%s or %q%D for  "%s" and '%D'
> 
> Could you reformulate, please?

I was thinking of q as a flag, so that %qs would be for '%s' and %qD would 
be for '%D'.  (I don't think there should be a distinction between them, 
and any single/double quote distinction wouldn't carry over well to 
non-English languages.  Further, there are still places using %s where %D 
could be used, and it would be odd for them to get different formatting - 
though they can easily be changed incrementally to use %D.)

Proposed specification:

%`      Opening quote
%'      Closing quote
(where strings output from the compiler will consist of whatever-language
text, an opening quote, decl name etc. from the source file, then a
closing quote and maybe more text - the decl name or whatever will be a
left-to-right oriented string even if the language is right-to-left, so
the clear specification of quotes as opening or closing rather than left
or right is relevant for RTL languages to set them so that the Unicode
bidirectional algorithm, applied to the compiler output (which is always
in logical rather than display ordering), yields proper results)

q       Flag in all formats other than %%, %`, %' to indicate that the 
format output is surrounded by quotes; thus, %qs, %qD, %#qD or %q#D 
(equivalent), %qd, ....

Implementing these formats doesn't require anything special to be done
about better quoting in C locale with UTF-8; that's separate (though while
the strings may be translated as _("`") and _("'") we do probably want to
arrange the default left quote, for C locale or no translation available,
to be "'" rather than "`").  If however formats in the compiler are
globally changed to this style before tree-ssa is merged, some track needs
to be kept of the various global changes and they need either applying to
tree-ssa as well or applying after the merge to new strings brought in
from tree-ssa.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: code that could be improved

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

[...]

| Proposed specification:
| 
| %`      Opening quote
| %'      Closing quote
| (where strings output from the compiler will consist of whatever-language
| text, an opening quote, decl name etc. from the source file, then a
| closing quote and maybe more text - the decl name or whatever will be a
| left-to-right oriented string even if the language is right-to-left, so
| the clear specification of quotes as opening or closing rather than left
| or right is relevant for RTL languages to set them so that the Unicode
| bidirectional algorithm, applied to the compiler output (which is always
| in logical rather than display ordering), yields proper results)

Absolutely.

| q       Flag in all formats other than %%, %`, %' to indicate that the 
| format output is surrounded by quotes; thus, %qs, %qD, %#qD or %q#D 
| (equivalent), %qd, ....

Hmm, I rather mandate thr flag q commint first, e.g. I would not like
the the funny %#qD.  It shoud be %q#D -- and when the C front-end
support the + location, it could be %q+D ( and %q+#D, ahem).

| Implementing these formats doesn't require anything special to be done
| about better quoting in C locale with UTF-8; that's separate (though while
| the strings may be translated as _("`") and _("'") we do probably want to
| arrange the default left quote, for C locale or no translation available,
| to be "'" rather than "`"). 

I agree.

| If however formats in the compiler are
| globally changed to this style before tree-ssa is merged, some track needs
| to be kept of the various global changes and they need either applying to
| tree-ssa as well or applying after the merge to new strings brought in
| from tree-ssa.

I think, we can implement the scheme and wait for the tree-ssa merge
before changing the quoting in the diagnostics.


Thanks!

-- Gaby