This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Consensus on MT-, AS- and AC-Safety docs.


On Wed, 2013-11-27 at 18:35 -0200, Alexandre Oliva wrote:
> On Nov 27, 2013, Torvald Riegel <triegel@redhat.com> wrote:
> 
> > On Tue, 2013-11-26 at 18:28 -0200, Alexandre Oliva wrote:
> 
> >> There, ân.â, âpl.â, âCf.â, âF.â are all non-English terms used for
> >> convenience throughout the dictionary
> 
> >> Why should that be a problem for us?
> 
> > are we building a dictionary here? No.
> 
> What is it that distinguishes our providing definitions for terms people
> look up from a dictionary's?

Because it's not?  It's not even an encyclopedia that would give brief
explanations.  Our documentation has full sentences, paragraphs, empty
lines between paragraphs.  Do you see that in a dictionary?

> > is space as scarce as in a traditional dictionary? No.
> 
> Are you not aware the FSF prints and sell printed copies of GNU manuals?

Then maybe they should get rid of the empty lines first, and replace
"error", "return value", "description" with "e.", "rv.", "d.", like you
might do in a dictionary?

> Anyway...  I'm glad to drop this discussion, since we appear to be
> converging on a set of short keywords.
> 
> >> >> Exactly!  They want to learn *exactly* what those odd combinations of
> >> >> letters mean!  Somehow when it's a function name among other made-up
> >> >> terms from C, that's perfectly readable,
> >> 
> >> > Why do you think those are perfectly readable?
> >> 
> >> Linguistics: because we're already used to them.
> 
> > That we're already used to them, and learned to deal with them, doesn't
> > mean at all that they are perfectly readable.
> 
> Heh.  I sense some circularity in the reasoning here.  Joseph's (and
> your, to a significant extent) argument was that he wanted English words
> because they are easier to read.  They are easier to read precisely
> because they're familiar, we're already used to them.  Words are
> arbitrary combinations of letters; what makes them easier or harder to
> read is not any inherent property, it's just that our brains develop
> circuits optimized to recognize the patterns we're used to.
> 
> So, for us who deal with this every other day, setpwent and cbrt and
> wcstok are familiar and easy to read; for a new user who's learning
> about C and POSIX and glibc, these are all new and hard to read.

And English words are easier to remember and read for those users
(assuming that most of our users are somewhat familiar with English, of
course).  And making that easier is good.

> Same goes for dictionaries, mind you.  Once we get used to n. and
> adj. and such stuff, it becomes second nature, but try to remember the
> first time you opened a dictionary to look a word up.  There is a *lot*
> of stuff that we learn to filter out over time so that we can focus on
> what we're looking for.  One of my concerns is that, the longer the
> portion about safety is at each function, the more threatening it will
> seem for a significant portion of our target audience.

Threatening because it's more verbose, and rather easy-to-speak and
easy-to-remember?

> > That's seems exactly the case of an existing word used as term/keyword,
> > yet people will look up what it means.
> 
> Unless they can guess what they mean and get in their head an idea about
> it that no amount of defining or showing or arguing will change.  Your
> assumptions about the meaning of MT-Safe are a perfect example of this
> phenomenon ;-(

Again, there are two things: (1) I asked you for a precise definition of
MT-Safe, and I claim that the current definitions aren't sufficiently
precise.  (2) I believe that something similar to sequential consistency
is easier for our users (and we would follow the choice made by C11 and
C++11).  Those are *separate* things.  You can do (1) without ever
agreeing with me about (2).  Don't try to put it like I can't
distinguish between both.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]