From: "Melissa O'Neill" <oneill@cs.sfu.ca>
Subject: English Usage and Future Features
To: Karl Fogel <kfogel@red-bean.com>
Date: Thu,  8 Apr 1999 11:14:23 -0700

You wrote:
> Okay, it's out; I just sent an announcement to info-cvs.
>
> Thanks for all the patches; I've pretty much kept my grubby little
> paws off them and applied them as they were (see ChangeLog for
> details).
>
> In fact, I think the only change I reverted was the spelling fix
> "Insure" --> "Ensure".  :-) These seem to be synonymous in common
> usage and are also the same (in this sense) according to the
> OED... which is only an authority insofar as it reflects usage
> accurately, I guess, but I trust them to have done their research
> anyway.  Believe it or not, this exact question, involving these two
> words used in the same sense, came up in a paper I was editing
> recently.

I'd recommend you check out Lyn Dupre's _BUGS in Writing_. This is an
excellent book, aimed pretty squarely at Computer Science folks writing
papers (although much more widely applicable). It's funny, and very
readable, and has been very well received.

Segment 45, ``Ensure, Assure, Insure'' covers this very issue. Lyn writes

    The terms ensure, assure and insure have notably different denotations.
    To avoid embarrassment, you should distinguish among them.

    You should use ensure to mean to make sure of a state of affairs or to
    guarantee that an event occurs.

        BAD:	Jim was careful to insure that the project went smoothly.
	GOOD:	Carol was careful to ensure that the party went smoothly.

	BAD:	Using this software will assure that you pay your taxes on time.
	GOOD:	Using this software will ensure that you pay your rent on time.

    You should use insure to mean to take insurance out on

        BAD:	I need to ensure my car before I drive it
	GOOD:	I need to insure my car before I drive it

	BAD:	Max was disappointed to discover that assuring his hard-disk
		had not protected the company against an earthquake-induced
		crash.
	GOOD:	Max was delighted to find that he had insured his laptop
		computer before it was stolen.

    You should use assure to mean  give assurance or reassure.

	BAD:	To ensure yourself that all is well, turn on the lights and
		check under the bed.
	GOOD:	To assure yourself that the proof is correct, you should take
		the time to work through it.
	GOOD:	To insure yourself, call a reliable company such as Lloyds of
		London.

    SPLENDID:	Rest assured that I have insured your home to ensure your peace
    		of mind.
    SPLENDID:	Before I can insure your business, you must assure me that you
    		can ensure that your programmers do careful quality assurance.

I quoted (slightly cut down) a chunk of the book, not so much to show
this particular point, but more to give you a taste of Lyn's book.  Ever
since it was recommended to me by a reviewer of one of my papers (Chris
Okasaki), I've been recommending it to just about everyone.

Of course, you can find out answers to matters of English style on the
Web for nothing, but it's not nearly as fun as Lyn's book. Some other
resources would be:

The Guide to Grammar and Style by Jack Lynch <http://http://newark.rutgers.edu/~jlynch/Writing/index.html> writes:

    Assure, Ensure, Insure.

      While ensure and insure aren't quite so clear cut, assure is very
      different from both. You assure a person that things will go right by
      making him confident. Never use assure in the sense of "Assure that
      the wording is correct"; you can only assure somebody that it's
      correct.

      Ensure and insure are sometimes used interchangeably, but it may be
      better to keep them separate. Insuring is the business of an insurance
      company, i.e., setting aside resources in case of a loss. Ensure means
      make sure, as in "Ensure that this is done by Monday."

The Curmudgeon's Stylebook <http://www.theslot.com/part1.html> covers
similar ground:

    ASSURE, ENSURE, INSURE

      The words are close in meaning, but they're not interchangeable.
      Ensure is usually the correct word; it means to make sure: Before
      starting the car, I ensure the baby is buckled in. Assure doesn't
      work that way; you assure another person of something: After
      ensuring the baby was buckled in, I assured her mother things
      were fine. One meaning of insure is to ensure, but better
      publications use the word only in references to the business of
      insurance: Even if the baby isn't buckled in, her life is insured
      for $100,000.

Paul Brians' Common Errors in English <http://www.wsu.edu:8080/~brians/errors/>
is another good resource, which states:

    ASSURE/ENSURE/INSURE

	To "assure" a person of something is to make him or her confident
	of it. According to Associated Press style, to "ensure" that
	something happens is to make certain that it does, and to "insure"
	is to issue an insurance policy. Other authorities, however,
	consider "ensure" and "insure" interchangeable. To please
	conservatives, make the distinction. However, it is worth noting
	that in older usage these spellings were not clearly distinguished.

	European "life assurance" companies take the position that all
	policy-holders are mortal and someone will definitely collect,
	thus assuring heirs of some income. American companies tend to
	go with "insurance" for coverage of life as well as of fire,
	theft, etc.

All of these sites are good resources for settling questions about English
usage, as are the FAQs posted to alt.usage.english.

> It may just be a British vs. American spelling difference, now that I
> think about it.  Do you use British normally?

The only significant difference between UK and US usage here is that
Brits talk about `life assurance' (because you're going to die, one
day), and Americans talk about `life insurance' (because no one really
wants to believe they're mortal).

An an Englishwoman living in Canada, my spelling is annoyingly midatlantic.
I've always (even in England) initialized arrays, rather than initialised
them, but I use coloured pens rather than colored ones.  But most of my
professional writing is for US publications, so I have to adopt US
conventions most of the time.

>> - Spotting when a log message is applied to every file in the distribution.
>
> Ahh... so we could use a special string "all files: blah blah blah"
> for the log entry?

Yes, or even no files list at all.  For example, in the EGS changelog, there
is the following entry:

    Sun Mar 14 02:38:07 PST 1999 Jeff Law  (law@cygnus.com)

            * egcs-1.1.2 Released.


>> - Improving the formatting of ChangeLog entries. Long, carefully formatted,
>>   entries are currently rather trampled by the wrapping code. (Probably needs
>>   a command-line option.)
>
> I've just been thinking about this too.  May just modify some code
> from Text::Wrap.  I'll bet we can guess right w/o a command-line
> option most of the time.  I think a good strategy would be to only add
> newlines, never remove any.  So long lines get auto-wrapped, but then
> the next line (in the original) doesn't move up, it stays on its own
> line.  And of course, this only goes for the message portion, not the
> filenames.
>
> This way, text that tries to make lists would stay readable.  For
> example:
>
> (parse_options): parse the --fish option.
> (stirfry): if `fish' is set, behave appropriately.  Adjust call to allergies(), and lower cooking heat based on reference in heat_table.
> (allergies): adjust for fish if `fish' is set.
>
> would get turned into this:
>
> (parse_options): parse the --fish option.
> (stirfry): if `fish' is set, behave appropriately.  Adjust call to
> allergies(), and lower cooking heat based on reference in heat_table.
> (allergies): adjust for fish if `fish' is set.
>
> instead of this:
>
> (parse_options): parse the --fish option.  (stirfry): if `fish' is
> set, behave appropriately.  Adjust call to allergies(), and lower
> cooking heat based on reference in heat_table.  (allergies): adjust
> for fish if `fish' is set.

Yes, that seems like a good way to go.

    Melissa.

has only been tested by Melissa and myself.

Untabified, indented everything.

Modified algorithm and data layout to collect multiple ChangeLog
messages for a given author over a sliding window of time.

Fixed transposition in explanation (author and message were swapped).

Moved output of date and author up one loop level.  Now ChangeLog
entries can have multiple parts (different log messages for different
files).  The hash twisting/time merging code will almost never
generate data this way, however.

Oops.  Forgot seconds in parse_date_and_author.

Major rewrite of the core code. Now parse_date_and_author returns a
time (i.e., seconds since the epoch) and author, rather than an
textual date and author. The whole structure of what we store has been
changed. No more building keys from concatenated strings (i.e., D.A.M.
keys), instead we use multi-level hashes. This change should reduce
memory use.

Previously, $Max_Checkin_Duration had an effective granularity of 60
seconds, due to the dropping of seconds from dates in
parse_date_and_author. Because parse_date_and_author now groks dates
to the second, it would now be okay to set $Max_Checkin_Duration to ten
seconds, whereas previously that would be identical to setting it to
zero.

(Melissa, I made some mods to this patch, first to get it to apply,
then to get it to run.  The upshot is: everything is untabified now,
hunk #7 was applied by hand [this was from patch #15], and since
apparently can't do "my (undef,...)" on line 304, I changed it to "my
($ignore,...)"  instead.  Maybe the original way is legal in a higher
version of Perl or something?  -kff)

Modified output loop to use `each' instead of `keys'.

Eliminate $ignore_me.

Eliminated use of File::Copy in favor of rename.

Fixed various uses of "" that really meant `undefined' to use undefined.

Only work out names for temporary files if we will actually be using
them.

Converted logfile header to be a global variable (in future, we might
allow the header to be omitted or altered).  It now uses a `here
document' too.

Fixed pretty_file_list to use join rather than a home-grown equivalent.
(Doh!  Thanks, Melissa!  -kff)

Removed the last of the `_reffy' stuff and needless hash copying.

Use a `here document' for the help message.

Switched from using "" to mean undefined to using undefined to mean
undefined.  (Some other cases remain, we'll do them later.)

Removed some superfluous tests from conditionals (it's true that they
make it clear what is true at that point, but that could be expressed
in a comment, rather than in executed code).  (Unfortunately, this
meant that I outdented a fairly large chunk of code, making the diff
look like a more extensive change than it really is.)

Eliminated a test for /^$file_separator/o by saving the result from
the earlier test.

Simplified subhash code down to one line.

Added /o to separator regexps.

Avoid using Date::Parse. We now use timegm (from Time::Local) to do
date -> time conversions, and perform the time parsing ourselves
(given that dates are always in a pretty standard from).

Added support for checkins that are not on the same minute by adding a
new loop to detect nearby dates.

would be a very different program!

Added README in case anyone stumbles by chance upon this directory.

Added undocumented --debug flag and the debug() routine.

unknown options.
Also, restored "." prefix to bak files (oops).

Feel free to modify it and commit whenever you need to generate
another change message.

Time to run sanity tests.

implement.

Better var names too.