groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] hyphenation issues


From: G. Branden Robinson
Subject: Re: [groff] hyphenation issues
Date: Sat, 5 May 2018 09:15:21 -0400
User-agent: NeoMutt/20170113 (1.7.2)

At 2018-05-05T14:01:00+0100, Keith Marshall wrote:
> On 05/05/18 12:40, G. Branden Robinson wrote:
> > At 2018-05-05T11:51:00+0100, Keith Marshall wrote:
> >> On 05/05/18 10:48, G. Branden Robinson wrote:
> >>> (Incidentally, I share your preference for putting type qualifiers
> >>> [as opposed to storage classes] _after_ the type name itself.  It
> >>> makes complex declarations easier to understand.)
> >>
> >> Personally, I consider that to be a poor choice ... especially if you
> >> are making it on purely stylistic grounds; conventionally:
> >>
> >>   const int foo;
> >>
> >> is more common than:
> >>
> >>   int const foo;
> > 
> > Yes, it's more common.  And ill-advised.
> 
> On the contrary; I consider your proposed style to be ill-advised,
> simply because it is potentially confusing.

Potentially, sure.  But yours is _actually_ confusing, to _you_!

Hence your own-goal of:

>>> For example,
>>> in C code, it is very common to see:
>>>
>>>   const char *foo;
>>>
>>> which means something very different from:
>>>
>>>   char const *foo;

Not that I mean to gloat (much).  The fact that we're having this
argument suggests that the problem lies with the design of the language.

An even more painful wart lies in the fact that, in C, the parser has to
feed information back to the lexer.

https://en.wikipedia.org/wiki/The_lexer_hack

> Okay, but that just reinforces my aversion to your style.  You suggest
> that it makes declarations easier to understand; I contend quite the
> opposite.  See, when I first learned C, close to 30 years ago -- when
> admittedly, "const" semantics were perhaps less clearly defined -- I was
> taught to:
> 
>   - find the symbol name
>   - look right, for parentheses
>   - look left, token by token, to find the type
> 
> By that rule:
> 
>   char const *foo;
> 
> would be read as:
> 
>   - foo is a variable (not function)
>   - foo is a pointer (to data of type not yet established)
>   - foo is constant
>   - foo is a constant pointer to data of type char
> 
> whereas:
> 
>   const char *foo;
> 
> *unambiguously* reads as:
> 
>   - foo is a variable (not function)
>   - foo is a pointer (to data of type not yet established
>   - foo is a pointer to data of type char
>   - foo is a pointer to data of type char, which is constant

...which is great until you want a constant pointer.  And you _should_
want constant (and, in function argument declarations, restricted)
pointers in every case that they will serve your needs as well as
mutable ones.

I was taught the same rule you were; the only difference is that one has
to recognize the difference between type qualifiers and type names.
Fortunately, C's keyword list is still fairly short even in C11 days, so
that's not a huge demand.

That we have to jump through these hoops to protect ourselves from the
language is regrettable.  But the 3 languages that have most recently
excited me have been Ada, Rust, and Haskell, so my taste might be called
into question.

-- 
Regards,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]