Allow table.keyword rather than table['keyword']?

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Allow table.keyword rather than table['keyword']?

Xpol Wan
Is it possiable in future Lua version to allow table.keyword like  `promise:then()` .

Xpol Wan
Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Jonathan Goble
On Mon, Mar 14, 2016 at 12:57 AM, Xpol Wan <[hidden email]> wrote:
> Is it possiable in future Lua version to allow table.keyword like
> `promise:then()` .

Unless I'm missing something, this wouldn't result in any ambiguous
syntax. An identifier, followed by a . or :, followed by a keyword, is
never valid syntax under current rules, so treating the keyword in
that sequence of tokens as an identifier shouldn't cause problems.

So I'm +1 on this. It would be nice to have the ability to do things
like _G.end (or _ENV.end). Again, unless I'm missing something (which
I very well might be given that I'm currently recovering from a cold
that's screwing with my thinking a bit).

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Karel Tuma-2
Excerpts from Jonathan Goble's message of 2016-03-14 06:13:11 +0100:
> On Mon, Mar 14, 2016 at 12:57 AM, Xpol Wan <[hidden email]> wrote:
> > Is it possiable in future Lua version to allow table.keyword like
> > `promise:then()` .
>
> Unless I'm missing something, this wouldn't result in any ambiguous
> syntax. An identifier, followed by a . or :, followed by a keyword, is
> never valid syntax under current rules, so treating the keyword in
> that sequence of tokens as an identifier shouldn't cause problems.

It would slightly complicate the lexer/parser relationship - lexer
currently does not take into account current parser state. As for
ambiguity, things like accidentaly placed dot would not be detected
as syntax error anymore in some cases.

Personally, I just use capital letter to avoid collision with keywords.

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Dirk Laurie-2
In reply to this post by Xpol Wan
2016-03-14 6:57 GMT+02:00 Xpol Wan <[hidden email]>:
> Is it possiable in future Lua version to allow table.keyword like
> `promise:then()` .

1. Should the syntax highlighter in gvim, kate, etc treat 'then' as
an identifier or as a keyword?

2. What benefit, large enough to justify the considerable increase
of compilation complexity, is to be gained?

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Rain Gloom
Imho this wouldn't really make sense in a minimalistic language such as Lua. It may also slightly decrease readability for some.

On Mon, Mar 14, 2016 at 8:00 AM, Dirk Laurie <[hidden email]> wrote:
2016-03-14 6:57 GMT+02:00 Xpol Wan <[hidden email]>:
> Is it possiable in future Lua version to allow table.keyword like
> `promise:then()` .

1. Should the syntax highlighter in gvim, kate, etc treat 'then' as
an identifier or as a keyword?

2. What benefit, large enough to justify the considerable increase
of compilation complexity, is to be gained?


Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Luiz Henrique de Figueiredo
In reply to this post by Xpol Wan
> Is it possiable in future Lua version to allow table.keyword like
>  `promise:then()` .

If you want to try it, see
        http://lua-users.org/lists/lua-l/2012-03/msg00309.html

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Roberto Ierusalimschy
In reply to this post by Jonathan Goble
> Unless I'm missing something, this wouldn't result in any ambiguous
> syntax. An identifier, followed by a . or :, followed by a keyword, is
> never valid syntax under current rules, so treating the keyword in
> that sequence of tokens as an identifier shouldn't cause problems.
>
> So I'm +1 on this. It would be nice to have the ability to do things
> like _G.end (or _ENV.end). Again, unless I'm missing something (which
> I very well might be given that I'm currently recovering from a cold
> that's screwing with my thinking a bit).

If not causing ambiguity is a good enough reason, why stop at reserved
words? We could as well add all the other tokens, too. None of them
cause ambiguities:

  _G.*  _G.%  _G.>=  _G.<  _G.==  _G.(  _G.]  _G:)

And it would be even easier to implement...

(For '.', '..', '...', and numbers, we would need to add a space,
like here: '_G. .'   _'G. ..'  '_G. ...'  '_G. 34')

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Axel Kittenberger
Ideally in the "do it yourself" idea Lua is in, it would be possible to make this alternations to the parser/lexer from within in script code (including all other kind of syntactic sugar often asked)

Speaking of which, what happened to metalua?

On Mon, Mar 14, 2016 at 1:13 PM, Roberto Ierusalimschy <[hidden email]> wrote:
> Unless I'm missing something, this wouldn't result in any ambiguous
> syntax. An identifier, followed by a . or :, followed by a keyword, is
> never valid syntax under current rules, so treating the keyword in
> that sequence of tokens as an identifier shouldn't cause problems.
>
> So I'm +1 on this. It would be nice to have the ability to do things
> like _G.end (or _ENV.end). Again, unless I'm missing something (which
> I very well might be given that I'm currently recovering from a cold
> that's screwing with my thinking a bit).

If not causing ambiguity is a good enough reason, why stop at reserved
words? We could as well add all the other tokens, too. None of them
cause ambiguities:

  _G.*  _G.%  _G.>=  _G.<  _G.==  _G.(  _G.]  _G:)

And it would be even easier to implement...

(For '.', '..', '...', and numbers, we would need to add a space,
like here: '_G. .'   _'G. ..'  '_G. ...'  '_G. 34')

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Luiz Henrique de Figueiredo
> Ideally in the "do it yourself" idea Lua is in, it would be possible to
> make this alternations to the parser/lexer from within in script code
> (including all other kind of syntactic sugar often asked)

That was the idea in my token filters.

The link I posted earlier has a token filter written in C:
        http://lua-users.org/lists/lua-l/2012-03/msg00309.html

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Hisham
In reply to this post by Roberto Ierusalimschy
On 14 March 2016 at 09:13, Roberto Ierusalimschy <[hidden email]> wrote:

>> Unless I'm missing something, this wouldn't result in any ambiguous
>> syntax. An identifier, followed by a . or :, followed by a keyword, is
>> never valid syntax under current rules, so treating the keyword in
>> that sequence of tokens as an identifier shouldn't cause problems.
>>
>> So I'm +1 on this. It would be nice to have the ability to do things
>> like _G.end (or _ENV.end). Again, unless I'm missing something (which
>> I very well might be given that I'm currently recovering from a cold
>> that's screwing with my thinking a bit).
>
> If not causing ambiguity is a good enough reason,

I don't think it was ever stated as being a good enough reason, but
the converse is often argued as the show-stopper for _not_ allowing
keywords. In other words, it's not that it is a decisive pro, but its
negation is often considered a decisive con.

As for pros, not allowing keywords in these situations sometimes leads
to situations with contrived names (such as `bit32.band`...), and I
had to uglify my code in the past with `bla.["keyword"]` in situations
where all other uses of bla were nicely `bla.field`. On the other
hand, I wouldn't like the inconsistency of being able to use `x` to
write `bla.x`, `{ x = 123 }`, `function x()`, `x()`; but then being
able to use `and` to write `bla.and`, `{ and = 123 }`, `function
and()` but not `and()`.

I think a language with different whitespace rules (where `and(x)` ≠
`and (x)`) could get away with allowing keywords as identifiers
consistently, but that's not the case in Lua.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Etiene Dalcol
On the other hand, I wouldn't like the inconsistency of being able to use `x` to
write `bla.x`, `{ x = 123 }`, `function x()`, `x()`; but then being
able to use `and` to write `bla.and`, `{ and = 123 }`, `function
and()` but not `and()`.

I think a language with different whitespace rules (where `and(x)` ≠
`and (x)`) could get away with allowing keywords as identifiers
consistently, but that's not the case in Lua.


But doesn't this discussion apply only to indexed fields to a table?
I personally don't see any issues or inconsistencies in being able to do `table_name.and = blah` but not `local function and()`. 
They seem like very different contexts to me and perhaps I would enjoy the flexibility, but I agree it could decrease readability. 


--
Etiene Dalcol

Software Engineering student at ENSTA Bretagne and PUC-Rio
Sailor Developer http://sailorproject.org
Lua Ladies Founder 
http://lualadies.org

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Soni "They/Them" L.
In reply to this post by Roberto Ierusalimschy


On 14/03/16 09:13 AM, Roberto Ierusalimschy wrote:

>> Unless I'm missing something, this wouldn't result in any ambiguous
>> syntax. An identifier, followed by a . or :, followed by a keyword, is
>> never valid syntax under current rules, so treating the keyword in
>> that sequence of tokens as an identifier shouldn't cause problems.
>>
>> So I'm +1 on this. It would be nice to have the ability to do things
>> like _G.end (or _ENV.end). Again, unless I'm missing something (which
>> I very well might be given that I'm currently recovering from a cold
>> that's screwing with my thinking a bit).
> If not causing ambiguity is a good enough reason, why stop at reserved
> words? We could as well add all the other tokens, too. None of them
> cause ambiguities:
>
>    _G.*  _G.%  _G.>=  _G.<  _G.==  _G.(  _G.]  _G:)
>
> And it would be even easier to implement...
>
> (For '.', '..', '...', and numbers, we would need to add a space,
> like here: '_G. .'   _'G. ..'  '_G. ...'  '_G. 34')
>
> -- Roberto
>
For some reason I enjoyed this passive aggressivity. :)

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Jonathan Goble
In reply to this post by Hisham
On Mon, Mar 14, 2016 at 10:41 AM, Hisham <[hidden email]> wrote:

> On 14 March 2016 at 09:13, Roberto Ierusalimschy <[hidden email]> wrote:
>>> Unless I'm missing something, this wouldn't result in any ambiguous
>>> syntax. An identifier, followed by a . or :, followed by a keyword, is
>>> never valid syntax under current rules, so treating the keyword in
>>> that sequence of tokens as an identifier shouldn't cause problems.
>>>
>>> So I'm +1 on this. It would be nice to have the ability to do things
>>> like _G.end (or _ENV.end). Again, unless I'm missing something (which
>>> I very well might be given that I'm currently recovering from a cold
>>> that's screwing with my thinking a bit).
>>
>> If not causing ambiguity is a good enough reason,
>
> I don't think it was ever stated as being a good enough reason, but
> the converse is often argued as the show-stopper for _not_ allowing
> keywords. In other words, it's not that it is a decisive pro, but its
> negation is often considered a decisive con.

That was precisely the intent of my argument: that a common argument
against a change is not present in this case. The +1 vote was not
purely for a lack of ambiguity.

> As for pros, not allowing keywords in these situations sometimes leads
> to situations with contrived names (such as `bit32.band`...), and I
> had to uglify my code in the past with `bla.["keyword"]` in situations
> where all other uses of bla were nicely `bla.field`. On the other
> hand, I wouldn't like the inconsistency of being able to use `x` to
> write `bla.x`, `{ x = 123 }`, `function x()`, `x()`; but then being
> able to use `and` to write `bla.and`, `{ and = 123 }`, `function
> and()` but not `and()`.

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.

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Tomás Guisasola-2
Hi

>> As for pros, not allowing keywords in these situations sometimes leads
>> to situations with contrived names (such as `bit32.band`...), and I
>> had to uglify my code in the past with `bla.["keyword"]` in situations
>> where all other uses of bla were nicely `bla.field`. On the other
>> hand, I wouldn't like the inconsistency of being able to use `x` to
>> write `bla.x`, `{ x = 123 }`, `function x()`, `x()`; but then being
>> able to use `and` to write `bla.and`, `{ and = 123 }`, `function
>> and()` but not `and()`.
>
> 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.
But you could use "End" or "END", don't you?

Since I usually do something like:

local gsub = require"string".gsub

It would be natural to try:

local end = require"your_lib".end

Which would not be allowed, I suppose.  Also, I cannot feel comfortable
writing something like:

{
   start = function ()
     ...
   end,
   end = function ()
     ...
   end,
}

This seems weird!

Maybe it is just me, but I think Lua is better the way it is :-)

Regards,
Tomás

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Gary V. Vaughan
In reply to this post by Jonathan Goble

> On Mar 14, 2016, at 6:42 PM, Jonathan Goble <[hidden email]> 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'.

Cheers,
Gary
Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Jonathan Goble
On Mon, Mar 14, 2016 at 3:32 PM, tomas <[hidden email]> wrote:

> Hi
>
>>> As for pros, not allowing keywords in these situations sometimes leads
>>> to situations with contrived names (such as `bit32.band`...), and I
>>> had to uglify my code in the past with `bla.["keyword"]` in situations
>>> where all other uses of bla were nicely `bla.field`. On the other
>>> hand, I wouldn't like the inconsistency of being able to use `x` to
>>> write `bla.x`, `{ x = 123 }`, `function x()`, `x()`; but then being
>>> able to use `and` to write `bla.and`, `{ and = 123 }`, `function
>>> and()` but not `and()`.
>>
>>
>> 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.
>
> But you could use "End" or "END", don't you?
>
> Since I usually do something like:
>
> local gsub = require"string".gsub
>
> It would be natural to try:
>
> local end = require"your_lib".end
>
> Which would not be allowed, I suppose.  Also, I cannot feel comfortable
> writing something like:
>
> {
>   start = function ()
>     ...
>   end,
>   end = function ()
>     ...
>   end,
> }
>
> This seems weird!
>
> Maybe it is just me, but I think Lua is better the way it is :-)
>
> Regards,
> Tomás

In my case, what would be the "end" field isn't a part of the module
table, or a function at all. Rather, some matching functions in the
module table return a single table containing information about the
match, specifically the full match, all captures, and the start
position and end position of the entire match and every capture.

On Mon, Mar 14, 2016 at 3:35 PM, Gary V. Vaughan <[hidden email]> wrote:

>> On Mar 14, 2016, at 6:42 PM, Jonathan Goble <[hidden email]> 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'.
>
> Cheers,
> Gary

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.

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.)

[1] http://www.thesaurus.com/browse/start

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Dirk Laurie-2
In reply to this post by Tomás Guisasola-2
2016-03-14 21:32 GMT+02:00 tomas <[hidden email]>:

> Maybe it is just me, but I think Lua is better the way it is :-)

It isn't just you. Me too.

Reply | Threaded
Open this post in threaded view
|

Re: Allow table.keyword rather than table['keyword']?

Sean Conner
In reply to this post by Roberto Ierusalimschy
It was thus said that the Great Roberto Ierusalimschy once stated:

> > Unless I'm missing something, this wouldn't result in any ambiguous
> > syntax. An identifier, followed by a . or :, followed by a keyword, is
> > never valid syntax under current rules, so treating the keyword in
> > that sequence of tokens as an identifier shouldn't cause problems.
> >
> > So I'm +1 on this. It would be nice to have the ability to do things
> > like _G.end (or _ENV.end). Again, unless I'm missing something (which
> > I very well might be given that I'm currently recovering from a cold
> > that's screwing with my thinking a bit).
>
> If not causing ambiguity is a good enough reason, why stop at reserved
> words? We could as well add all the other tokens, too. None of them
> cause ambiguities:
>
>   _G.*  _G.%  _G.>=  _G.<  _G.==  _G.(  _G.]  _G:)

  My initial reaction was "Gaaaaah!  Nooooooo!" but upon further reflection,
this might be okay.  You could change the names of the metamethods:

        mt.+ = function(a,b) ... end -- __add
        mt.* = function(a,b) ... end -- __mul
        mt.[ = function(t,k) ... end -- __index
        mt.] = function(t,k,v) ... end -- __newindex
        mt.# = function(t) .. end -- __len
        mt.: = function(self,...) ... end -- __call
        mt.} = { ... } -- __metatable
        mt." = function(self) ... end -- __tostring
        mt.== = function(a,b) .. end -- __eq
        mt.{  = function(...) ... end -- __pairs
        mt.@ = "name" -- __name

  -spc (Yeah, that could work!)


Reply | Threaded
Open this post in threaded view
|

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

Gary V. Vaughan
In reply to this post by Jonathan Goble
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 <[hidden email]> wrote:
>
> On Mon, Mar 14, 2016 at 3:35 PM, Gary V. Vaughan <[hidden email]> wrote:
>>> On Mar 14, 2016, at 6:42 PM, Jonathan Goble <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Jonathan Goble
On Mon, Mar 14, 2016 at 4:42 PM, Gary V. Vaughan <[hidden email]> wrote:

> 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"

First, I am a native English speaker. ;-) Secondly, in casual
conversation, I generally would prefer "beginning" over "start" for
noun usage. But in programming, "beginning" is quite long for an
object attribute one might need to access multiple times. "start" is
only slightly over half as long and conveys the same meaning. As long
as the attributes clearly convey the appropriate meaning, they don't
need to be perfectly grammatically correct.

>> 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.

Well, the primary intent of the match table was to provide a more
familiar interface for people more used to Python re matching, so...
¯\_(ツ)_/¯

On Mon, Mar 14, 2016 at 4:42 PM, Gary V. Vaughan <[hidden email]> wrote:

> Luckily, Nicklaus Wirth used the terms correctly in Pascal:
>
> [snip]
>
> 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:
>
> [snip]
>
> 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:
>
> [snip]
>
> Many more…  and, no doubt there are counter examples too.
>
> Cheers,
> Gary

...all of which are verb usage, whereas Python and I use them as
nouns. And "begin" is not a noun; "beginning" is the noun, and I've
already pointed out why that's not a good idea.

(Of all the discussions I thought I might get into on this list, an
English grammar discussion was not one of them. :-)

12