Re: [groff] hyphenation issues

[G. Branden Robinson]

At 2018-05-06T00:19:44+0100, Ralph Corderoy wrote:
> That was my point.  Though the widespread conventional method has that
> in its favour, it doesn't mean the more logical consistent one is wrong
> or misleading.  It mainly means the alternative hasn't been considered
> for its merits, just dismissed because it `looks odd'.  A knee-jerker.

There are a lot of jerking knees in software development.

> > Enjoy changing it all over place.
> 
> Sigh.  I made very clear: "I accept it isn't groff's style".
> I'm not trying to change groff, or anybody's style.
> I am trying to explain how C works because at least two experienced C
> programmers on this list thought they weren't equivalent and that
> Branden and I were therefore mistaken and creating errors in using it.

Yeah, I'm not interested right now in making a global change of this
sort to the groff codebase.

The idea of adding semantic macros to an-ext and making all the in-tree
man pages use them is much more exciting.  ;-)

> That's the one that *persuaded* me of its merits.  Before that, I'd just
> seen it and thought `Why write the equivalent thing in that odd way?'.
> I've seen its use growing.  I suspect more projects will switch.
> Branden was already using that style and that wasn't my influence.
> Perhaps you're in a bit of a silo?  :-)

I had first _heard_ of it some years ago, but the most significant bit
of prominent evangelism for it I'm aware of is from Ben Klemens's _21st
Century C_:

https://www.goodreads.com/book/show/14514281-21st-century-c

It has a lot of good ideas, and while taken together they clearly work
syergetically for Ben, they are mostly separable, so you can cherry-pick
what you like.  His enthusiasm for macros goes beyond what most people
care for--though I sure share a lot of his motives for using them as
aggressively as he does.  (A popular counterargument in actual practice,
more often seen than heard, is, "my code looks much cleaner if I don't
check the return values of library calls!" <wince, gnash>)

My personal declaration style is:

[storage_class] {type_name [type_qualifier ...]} ...

A storage class is only meaningful for a fundamental type so it makes
sense for it to go out front.

> I think you're wrong.  I'm adopting it.  I suspect over the medium term
> its use will grow.  Other aspects of C style have also changed over the
> decades.

> Again, I wasn't saying it does.  Many people claim to `know Python' but
> get caught by
>     l = [42, 314]; m = l
> not behaving as they expect.

Are you saying they expect l to be defined as a 42x314 array, or that
they expect m to be a copy of l instead of a reference to l?

-- 
Regards,
Branden

signature.asc
Description: PGP signature