Off-topic received English rant [WAS Re: Allow table.keyword rather than table['keyword']?]

["Gary V. Vaughan" <gary@...>]

Hi Jonathan,

Again, my apologies for the pedantry.  In my defence, I am running a
fever, hopped up on vaporub and lemsip, and will probably regret this
email tomorrow.

> On 14 Mar 2016, at 19:50, Jonathan Goble <jcgoble3@gmail.com> wrote:
> 
> On Mon, Mar 14, 2016 at 3:35 PM, Gary V. Vaughan <gary@vaughan.pe> wrote:
>>> On Mar 14, 2016, at 6:42 PM, Jonathan Goble <jcgoble3@gmail.com> wrote:
>>> 
>>> This is the main reason I support this change: because some keywords
>>> would otherwise be natural field names in a data table or object.
>>> "end" is one that I ran into while developing something for my
>>> matchext library, and instead of using "start" and "end" as fields for
>>> the start and end positions of a match, I ended up having to use
>>> "startpos" and "endpos". The ability to use "end" as a field name
>>> would be nice.
>> 
>> Forgive the grammar pedantry, but start & end do not go together anyway;
>> you should use either 'begin' & 'end' or 'start' & 'finish'.
> 
> Well, if we're going to get pedantic, Thesaurus.com [1] lists "end" as
> an antonym of "start". ;-) And this is about start of a match and end
> of a match; one would not say "begin of a match" (perhaps "beginning
> of a match", but that's unnecessarily long), nor "finish of a match"
> (perhaps when talking about the *event* of completing a match, but 1)
> "completion" would be clearer in that case and 2) not when talking
> about the numerical index of the last string position matched). In
> other words, they're being used as nouns here, not verbs.

I do not dispute that ‘start’ and ‘begin’ are synonyms, and thusly
‘end’ is indeed an antonym of both.  And you are also correct about the
noun/verb duality of start.

Nonetheless, to a native English speaker using the words ‘start' & ‘end’
in a single phrase sounds awkward: ‘start' implies a continuous action,
and one will normally talk about 'finishing' a continuous action, not
ending it. This flows relatively nicely for a contrivance:

  "I can start at the beginning of the race, and at the end I will have
finished”

The alternate is ugly:

  “I can begin at the start of the race, and at the finish it will have
ended"

> Also, the Python "re" module's match object uses "start" and "end" for
> this purpose. Good enough for me. :-) (Much of this "match table" was
> inspired by Python's match objects.)

An unfortunate choice that makes many people cringe a little each time they
encounter it.  It’s not Guido’s mistake though, he was following the
precedent of the ugly POSIX (nee BSD) regex(3) API.

Luckily, Nicklaus Wirth used the terms correctly in Pascal:

  program hello(output);
  begin
      write('Hello, world!')
  end.

Alfred Aho, Peter Weinberger and Brian Kernighan also chose the correct
pairing:

  awk -F: 'BEGIN{c=0} {c+=NR} END{print(c)}' /etc/passwd

A sample from Donald Knuth’s paper about literate programming:

  program print primes(output);
    const m = 1000;
      ⟨ Other constants of the program 5 ⟩
    var ⟨ Variables of the program 4 ⟩
      begin ⟨ Print the first m prime numbers 3 ⟩;
      end.

Larry Wall, who has done a lot of seriously weird stuff with programming languages,
is also a linguist and consequently correctly pairs begin and end:

	#!/usr/bin/perl
	# begincheck
	print         "10. Ordinary code runs at runtime.\n";
	END { print   "16.   So this is the end of the tale.\n" }
	INIT { print  " 7. INIT blocks run FIFO just before runtime.\n" }
	UNITCHECK {
	  print       " 4.   And therefore before any CHECK blocks.\n"
	}
	CHECK { print " 6.   So this is the sixth line.\n" }
	print         "11.   It runs in order, of course.\n";
	BEGIN { print " 1. BEGIN blocks run FIFO during compilation.\n" }
	END { print   "15.   Read perlmod for the rest of the story.\n" }
	CHECK { print " 5. CHECK blocks run LIFO after all compilation.\n" }
	INIT { print  " 8.   Run this again, using Perl's -c switch.\n" }
	print         "12.   This is anti-obfuscated code.\n";
	END { print   "14. END blocks run LIFO at quitting time.\n" }
	BEGIN { print " 2.   So this line comes out second.\n" }
	UNITCHECK {
	 print " 3. UNITCHECK blocks run LIFO after each file is compiled.\n"
	}
	INIT { print  " 9.   You'll see the difference right away.\n" }
	print         "13.   It only _looks_ like it should be confusing.\n";
	__END__

Many more…  and, no doubt there are counter examples too.

Cheers,
Gary