digitalmars.D - Please vote once and for good: range operations

It looks like there is endless debate on the naming convention for the 
range operations. Few saw the obvious bugs in the documentation and 
examples :o).

So please let's vote once and for all. I will note that I disagree we 
should ignore what conventions other languages have. Provincialism is 
the appurtenance of the incult. To that end, I looked around at how some 
languages define some primitives.

LISP:
car
last
http://www.gigamonkeys.com/book/they-called-it-lisp-for-a-reason-list-processing.html

Scheme:
car
last
http://merd.sourceforge.net/pixel/language-study/syntax-across-languages-per-language/Scheme.html

ML:
hd
last
http://www.standardml.org/Basis/list.html

Ocaml:
hd
no last
http://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html
Apparently Ocaml programmers tend to define their own function called 
"last":
http://nodens.physics.ox.ac.uk/~mcdonnell/lab/code/code_ocaml/ocaml_fold/ocaml_fold.html
http://caml.inria.fr/pub/ml-archives/caml-list/2004/04/06d65a793fa0503218c06783be2facbe.en.html

Haskell:
head
last
http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/head.html
http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/last.html

C++:
front
back
http://support.microsoft.com/kb/158613

Scala:
head
last
http://www.scala-lang.org/docu/files/api/scala/List.html

C#:
Couldn't find after searching MS's asinine dox for 5 mins.

Java:
obj.get(0)
obj.get(obj.size-1)
http://java.sun.com/j2se/1.4.2/docs/api/java/util/AbstractSequentialList.html

Python:
lst[0]
lst[len(lst)-1]

So please let's vote once and for all. No choice will please everybody, 
but I want to settle for something that at least won't displease the 
most vehement ones :o).


Andrei

Jan 28 2009

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Jan 29, 2009 at 9:26 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 It looks like there is endless debate on the naming convention for the range
 operations. Few saw the obvious bugs in the documentation and examples :o).


Looking for bugs is too much like work.  :-P

 So please let's vote once and for all.


Yes.  Let's do.  Please post a list of options for voting on and rules
for the vote.  (Multiple votes ok, not ok, points, negative votes
allowed etc).

--bb

Jan 28 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Bill Baxter wrote:
 On Thu, Jan 29, 2009 at 9:26 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 It looks like there is endless debate on the naming convention for the range
 operations. Few saw the obvious bugs in the documentation and examples :o).


 Looking for bugs is too much like work.  :-P
 
 So please let's vote once and for all.


 Yes.  Let's do.  Please post a list of options for voting on and rules
 for the vote.  (Multiple votes ok, not ok, points, negative votes
 allowed etc).
 
 --bb


Oh. I thought voting would mean replying to my message with your vote.

Andrei

Jan 28 2009

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Wed, Jan 28, 2009 at 7:26 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Python:
 lst[0]
 lst[len(lst)-1]


Or more concisely, lst[-1].

 So please let's vote once and for all. No choice will please everybody, but
 I want to settle for something that at least won't displease the most
 vehement ones :o).


first/last would be my first choice.  head/last would also be fine,
and is in keeping with, uh pretty much everything else, it seems.

Jan 28 2009

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Jan 29, 2009 at 9:47 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 29, 2009 at 9:26 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 It looks like there is endless debate on the naming convention for the
 range
 operations. Few saw the obvious bugs in the documentation and examples
 :o).


 Looking for bugs is too much like work.  :-P

 So please let's vote once and for all.


 Yes.  Let's do.  Please post a list of options for voting on and rules
 for the vote.  (Multiple votes ok, not ok, points, negative votes
 allowed etc).

 --bb


 Oh. I thought voting would mean replying to my message with your vote.

 Andrei


You're just likely to get a much better voter turn-out if you make it
as simple as possible, multiple-choice style.

Free form is ok by me though.

I cast a vote for both:
first/last
and
head/toe

--bb

Jan 28 2009

dsimcha <dsimcha yahoo.com> writes:

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 It looks like there is endless debate on the naming convention for the
 range operations. Few saw the obvious bugs in the documentation and
 examples :o).
 So please let's vote once and for all. I will note that I disagree we
 should ignore what conventions other languages have. Provincialism is
 the appurtenance of the incult. To that end, I looked around at how some
 languages define some primitives.
 LISP:
 car
 last


 Scheme:
 car
 last


 ML:
 hd
 last
 http://www.standardml.org/Basis/list.html
 Ocaml:
 hd
 no last
 http://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html
 Apparently Ocaml programmers tend to define their own function called
 "last":




 Haskell:
 head
 last
 http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/head.html
 http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/last.html
 C++:
 front
 back
 http://support.microsoft.com/kb/158613
 Scala:
 head
 last
 http://www.scala-lang.org/docu/files/api/scala/List.html
 C#:
 Couldn't find after searching MS's asinine dox for 5 mins.
 Java:
 obj.get(0)
 obj.get(obj.size-1)
 http://java.sun.com/j2se/1.4.2/docs/api/java/util/AbstractSequentialList.html
 Python:
 lst[0]
 lst[len(lst)-1]
 So please let's vote once and for all. No choice will please everybody,
 but I want to settle for something that at least won't displease the
 most vehement ones :o).
 Andrei


To me the most important thing is that it's symmetrical, i.e. don't use first,
and
then toe or head, and then last.  My vote is for either front/back, first/last
or
head/toe (don't care which).  All of the others are pretty bad for the following
reasons:

Lisp, Scheme:  Car has absolutely no intuitive connection with the first part of
anything.  This terminology was probably invented by some 60's programmer who
was
seriously stoned.

ML, OCaml, Haskell, Scala:  Not symmetrical.

Python:  At least it looks nice, but anything that looks like array indexing
should be used strictly for random access ranges.

Java:  Worse yet than array indexing, it looks like a lame substitute for an
array
index because Java's too stupid to support operator overloading.

Jan 28 2009

Robert Fraser <fraserofthenight gmail.com> writes:

dsimcha wrote:
 Lisp, Scheme:  Car has absolutely no intuitive connection with the first part
of
 anything.  This terminology was probably invented by some 60's programmer who
was
 seriously stoned.


Only sort of... http://en.wikipedia.org/wiki/Car_and_cdr

 Java:  Worse yet than array indexing, it looks like a lame substitute for an
array
 index because Java's too stupid to support operator overloading.


Java's Deque class uses first() and last(). A Java iterator uses next(). 
So there's a bit of terminology.

Jan 28 2009

Chad J <gamerchad __spam.is.bad__gmail.com> writes:

Andrei Alexandrescu wrote:
 
 So please let's vote
 
 Andrei


As for voting rules, I suggest we all write down a list of pairs that
are acceptable to us on the aesthetic level.  Each pair counts as a vote
for that pair.  So people get multiple votes, but never for the same
pair.  At the end hopefully you have a good metric of which pair is most
acceptable.


I'll post my list in a few minutes.

Jan 28 2009

Sandeep Kakarlapudi <sandeep.iitkgpspammenot gmail.com> writes:

Not sure if this vote is meant for regular members only or not! Here's my
preference order anyways:

first-last > head-rhead > head-tail > head-toe

Jan 28 2009

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Sandeep Kakarlapudi" wrote
 Not sure if this vote is meant for regular members only or not! Here's my 
 preference order anyways:

 first-last > head-rhead > head-tail > head-toe


Please post with your official D fan club id number for your vote to be 
counted.

-Steve

Jan 28 2009

Sandeep Kakarlapudi <sandeep.iitkgpspammenot gmail.com> writes:

Steven Schveighoffer Wrote:

 "Sandeep Kakarlapudi" wrote
 Not sure if this vote is meant for regular members only or not! Here's my 
 preference order anyways:

 first-last > head-rhead > head-tail > head-toe


 Please post with your official D fan club id number for your vote to be 
 counted.
 
 -Steve 
 
 


Here's my id: 0xD

:)

Jan 28 2009

Chad J <gamerchad __spam.is.bad__gmail.com> writes:

These are all fine to my eyes:

begin/end
begin/terminus
current/last
current/rear
current/back
first/last
fore/aft
front/back
left/right
leftmost/rightmost
head/last
head/rear
head/back
start/end
start/last
start/terminus

If any more come up that I like, I'll post those too.

Jan 28 2009

Chad J <gamerchad __spam.is.bad__gmail.com> writes:

Chad J wrote:
 These are all fine to my eyes:
 
 begin/end
 begin/terminus
 current/last
 current/rear
 current/back
 first/last
 fore/aft
 front/back
 left/right
 leftmost/rightmost
 head/last
 head/rear
 head/back
 start/end
 start/last
 start/terminus
 
 If any more come up that I like, I'll post those too.


alpha/omega

Jan 28 2009

"Saaa" <empty needmail.com> writes:

 fore/aft +


going to win

Jan 28 2009

John Reimer <terminal.node gmail.com> writes:

Hello Saaa,

 fore/aft +
 


 isn't going to win
 



Probably not wise for me to quibble over these points, but...  to me, the 
main problem with fore/aft is that it implies a position of an object that 
occupies physical space.   Using something like head/last is just a little 
more abstract in the sense that it doesn't necessarily refer to physical 
position.  


Maybe it's time for me to stop thinking too hard on this. :D


-JJR

Jan 28 2009

"Saaa" <empty needmail.com> writes:

 Probably not wise for me to quibble over these points, but...  to me, the 
 main problem with fore/aft is that it implies a position of an object that 
 occupies physical space.   Using something like head/last is just a little 
 more abstract in the sense that it doesn't necessarily refer to physical 
 position.

 Maybe it's time for me to stop thinking too hard on this. :D


:D I have the same with 'head'

Jan 29 2009

John Reimer <terminal.node gmail.com> writes:

Hello Saaa,

 Probably not wise for me to quibble over these points, but...  to me,
 the main problem with fore/aft is that it implies a position of an
 object that occupies physical space.   Using something like head/last
 is just a little more abstract in the sense that it doesn't
 necessarily refer to physical position.
 
 Maybe it's time for me to stop thinking too hard on this. :D
 


 



Yeah, I guess it works both ways.   :)


-JJR

Jan 29 2009

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Andrei Alexandrescu"  wrote
 C#:
 Couldn't find after searching MS's asinine dox for 5 mins.


C# doesn't seem to have bi-directional ranges.  Only forward ones.  In any 
case, they are enumerated over using an IEnumerator (or IEnumerator<T>, 
depending on whether you want generic support).  In any case, the "head" 
element is the property "Current".

In a container, you can only get the last element of something that has an 
indexer, and in that case, its:

container[container.Count - 1];

So I'm not sure there's any point in listing C# as a viable candidate to 
steal property names from ;)  C# and .net in general I think suck in terms 
of standard containers/algorithms anyways.  It's one thing I don't like 
about it.

references:
http://msdn.microsoft.com/en-us/library/system.collections.ienumerator.current.aspx
http://msdn.microsoft.com/en-us/library/ewthkb10.aspx

In any case, I think front and back make the most sense to me.  I did come 
from C++ however...

I don't mind any of the normal choices (I don't count car as being 
'normal'), but if Walter insists on keeping foreach_reverse, let's all 
remember that whatever is chosen for the rear/toe/last element of a range is 
going to be embedded in the compiler/spec, and essentially set in stone.

-Steve

Jan 28 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Steven Schveighoffer wrote:
 So I'm not sure there's any point in listing C# as a viable candidate to 
 steal property names from ;)  C# and .net in general I think suck in terms 
 of standard containers/algorithms anyways.  It's one thing I don't like 
 about it.


While searching various language samples/standard libs, I couldn't stop 
noticing that .Net had the most childish concepts and the least 
appealing APIs and code samples. Looked like 21st century Visual Basic 
to me, only more verbose.

 I don't mind any of the normal choices (I don't count car as being 
 'normal')


Hey, I have an idea: car and trailer! :o)

 but if Walter insists on keeping foreach_reverse, let's all 
 remember that whatever is chosen for the rear/toe/last element of a range is 
 going to be embedded in the compiler/spec, and essentially set in stone.


Yah, I agree.

Andrei

Jan 28 2009

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 So I'm not sure there's any point in listing C# as a viable candidate to 
 steal property names from ;)  C# and .net in general I think suck in 
 terms of standard containers/algorithms anyways.  It's one thing I don't 
 like about it.


 While searching various language samples/standard libs, I couldn't stop 
 noticing that .Net had the most childish concepts and the least appealing 
 APIs and code samples. Looked like 21st century Visual Basic to me, only 
 more verbose.


It is a pain, when coming from C++ which has the very impressive STL.  One 
of the things I absolutely hated is you cannot enumerate the elements in a 
hashtable and remove them as you enumerate (technically, D's builtin AA has 
this issue as well, but I have that ability in dcollections, and hopefully 
there will be a builtin range with that ability in the future *hint hint*). 
I have this really stupid piece of code where I enumerate through a lookup 
cache for finished threads, adding them to a list, then after enumerating 
through the hashtable, I have to remove them one at a time from the table by 
using the values I stored in the list, using a lookup each time to remove 
each element, when I could have removed them all without any extra penalty 
while traversing.

-Steve

Jan 28 2009

Jason House <jason.james.house gmail.com> writes:

Andrei Alexandrescu wrote:

It looks like there is endless debate on the naming convention for the
range operations.

I had hoped that the endless debate on naming when you first proposed ranges
was enough. You were very good then about trying to find a reasonable
compromise. Obviously, few people got their preferred naming convention, but
at least we had a whole committee to decide on the color of the bicycle shed.

I'm not going to vote in a forum like this. There are online polls that you
can do which would do a better job. Personally, I think it'd be best to do
something like "please rate on a scale of 1 to 5 how much you like the
following terms representing 'toe' in the current range design"
(worst) (best)
toe 1 2 3 4 5
tail 1 2 3 4 5
last 1 2 3 4 5
back 1 2 3 4 5

Something like that would allow doing things like computing the average score
of all words.

Few saw the obvious bugs in the documentation and
examples :o).

And here I thought is was better to point out bigger things like questionable
API's ;)

So please let's vote once and for all. I will note that I disagree we
should ignore what conventions other languages have. Provincialism is
the appurtenance of the incult. To that end, I looked around at how some
languages define some primitives.

LISP:
car
last
http://www.gigamonkeys.com/book/they-called-it-lisp-for-a-reason-list-processing.html

Scheme:
car
last
http://merd.sourceforge.net/pixel/language-study/syntax-across-languages-per-language/Scheme.html

ML:
hd
last
http://www.standardml.org/Basis/list.html

Ocaml:
hd
no last
http://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html
Apparently Ocaml programmers tend to define their own function called
"last":
http://nodens.physics.ox.ac.uk/~mcdonnell/lab/code/code_ocaml/ocaml_fold/ocaml_fold.html
http://caml.inria.fr/pub/ml-archives/caml-list/2004/04/06d65a793fa0503218c06783be2facbe.en.html

Haskell:
head
last
http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/head.html
http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/last.html

C++:
front
back
http://support.microsoft.com/kb/158613

What about my favorite from C++ iterators? *

Scala:
head
last
http://www.scala-lang.org/docu/files/api/scala/List.html

C#:
Couldn't find after searching MS's asinine dox for 5 mins.

Java:
obj.get(0)
obj.get(obj.size-1)
http://java.sun.com/j2se/1.4.2/docs/api/java/util/AbstractSequentialList.html

Python:
lst[0]
lst[len(lst)-1]

So please let's vote once and for all. No choice will please everybody,
but I want to settle for something that at least won't displease the
most vehement ones :o).

Andrei

Jan 28 2009

"Tiago Carvalho" <merlin3000 c-core.org> writes:

"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:glqt38$14p2$1 digitalmars.com...
 It looks like there is endless debate on the naming convention for the 
 range operations. Few saw the obvious bugs in the documentation and 
 examples :o).

 So please let's vote once and for all. I will note that I disagree we 
 should ignore what conventions other languages have. Provincialism is the 
 appurtenance of the incult. To that end, I looked around at how some 
 languages define some primitives.

 LISP:
 car
 last
 http://www.gigamonkeys.com/book/they-called-it-lisp-for-a-reason-list-processing.html

 Scheme:
 car
 last
 http://merd.sourceforge.net/pixel/language-study/syntax-across-languages-per-language/Scheme.html

 ML:
 hd
 last
 http://www.standardml.org/Basis/list.html

 Ocaml:
 hd
 no last
 http://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html
 Apparently Ocaml programmers tend to define their own function called 
 "last":
 http://nodens.physics.ox.ac.uk/~mcdonnell/lab/code/code_ocaml/ocaml_fold/ocaml_fold.html
 http://caml.inria.fr/pub/ml-archives/caml-list/2004/04/06d65a793fa0503218c06783be2facbe.en.html

 Haskell:
 head
 last
 http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/head.html
 http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/last.html

 C++:
 front
 back
 http://support.microsoft.com/kb/158613

 Scala:
 head
 last
 http://www.scala-lang.org/docu/files/api/scala/List.html

 C#:
 Couldn't find after searching MS's asinine dox for 5 mins.

 Java:
 obj.get(0)
 obj.get(obj.size-1)
 http://java.sun.com/j2se/1.4.2/docs/api/java/util/AbstractSequentialList.html

 Python:
 lst[0]
 lst[len(lst)-1]

 So please let's vote once and for all. No choice will please everybody, 
 but I want to settle for something that at least won't displease the most 
 vehement ones :o).


 Andrei


First, Last simply make sense to me. Head would be nice to, but Toe just 
doesn't seems very straightforward.

Jan 28 2009

Robert Fraser <fraserofthenight gmail.com> writes:

In order of preference...
1. head/toe
2. front/back
3. first/last
4. top/bottom

Really, anything symmetrical would work... just not car/cdr!

Jan 28 2009

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

Andrei Alexandrescu wrote:

 So please let's vote once and for all.

 Andrei


Do let's. My first vote goes to first/last, with head/toe at second place.

--
Simen

Jan 28 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Simen Kjaeraas wrote:
 Andrei Alexandrescu wrote:
 
 So please let's vote once and for all.

 Andrei


 Do let's. My first vote goes to first/last, with head/toe at second place.
 
 -- 
 Simen


Ok, after looking at my code I discovered a huge problem with "first". 
("Last" is cool.) If all you do is implement them and use them with 
foreach, fine. But if you need to call them manually (which is the case 
sometimes), you get really badly interacting terms there. Look at this, 
taken from real code (the filter function):

while (!_input.empty && !pred(_input.first)) _input.next;

I can see the putative user scratching their head: "Ok, so I start 
iteration with the first element, then I move to the next one... but 
then why the heck am I looking at the first again?"

"First" must go.


Andrei

Jan 28 2009

John Reimer <terminal.node gmail.com> writes:

Hello Andrei,

 Simen Kjaeraas wrote:
 
 Andrei Alexandrescu wrote:
 
 So please let's vote once and for all.
 
 Andrei
 


 place.
 
 -- Simen
 


 ("Last" is cool.) If all you do is implement them and use them with
 foreach, fine. But if you need to call them manually (which is the
 case sometimes), you get really badly interacting terms there. Look at
 this, taken from real code (the filter function):
 
 while (!_input.empty && !pred(_input.first)) _input.next;
 
 I can see the putative user scratching their head: "Ok, so I start
 iteration with the first element, then I move to the next one... but
 then why the heck am I looking at the first again?"
 
 "First" must go.
 
 Andrei
 



It can walk the plank on the starboard side. :)


-JJR


-JJR

Jan 28 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Bill Baxter wrote:
 On Thu, Jan 29, 2009 at 1:25 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Simen Kjaeraas wrote:
 Andrei Alexandrescu wrote:

 So please let's vote once and for all.

 Andrei



 --
 Simen


 ("Last" is cool.) If all you do is implement them and use them with foreach,
 fine. But if you need to call them manually (which is the case sometimes),
 you get really badly interacting terms there. Look at this, taken from real
 code (the filter function):

 while (!_input.empty && !pred(_input.first)) _input.next;

 I can see the putative user scratching their head: "Ok, so I start iteration
 with the first element, then I move to the next one... but then why the heck
 am I looking at the first again?"

 "First" must go.


 Can't you just think of it as the first of the range, not the first of
 everything?


I could, if "next" weren't called "next". If the current is called 
"first", "next" means to move to another quantum universe in which the 
current "first" is forgotten and what was after "first" in the previous 
universe is now "first". That doesn't strike me as intuitive :o).

 If you ask me who is first in line, I'm going to tell you who is the
 first in line right now, currently.  Not who was first back when the
 line first formed.  This seems similar to me.  So not confusing at all
 if you think of it that way.  The range is not the container.


That's a good point, but... we are at liberty to choose ANY names we 
please. Is this weird "first"/"next" combo our best shot?


Andrei

Jan 28 2009

"Joel C. Salomon" <joelcsalomon gmail.com> writes:

Andrei Alexandrescu wrote:
 That's a good point, but... we are at liberty to choose ANY names we=20
 please. Is this weird "first"/"next" combo our best shot?



Has =93current=94 been suggested?

How many terms are needed? Of the ordinals {first, previous, current,=20
next, last}, however they are named, are any not needed? Are any more=20
needed? randomth? nth?

=97Joel Salomon

Jan 29 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Joel C. Salomon wrote:
 Andrei Alexandrescu wrote:
 That's a good point, but... we are at liberty to choose ANY names we 
 please. Is this weird "first"/"next" combo our best shot?


 
 Has �current� been suggested?
 
 How many terms are needed? Of the ordinals {first, previous, current, 
 next, last}, however they are named, are any not needed? Are any more 
 needed? randomth? nth?
 
 �Joel Salomon
 


Current and curr have been suggested. I was only looking at two terms 
for now, i.e. the front and back position in the range. "next" and 
"empty" remained less controversial and I was happy to reduce the scope 
of the vote.


Andrei

Jan 29 2009

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-01-29 00:02:20 -0500, Bill Baxter <wbaxter gmail.com> said:

 On Thu, Jan 29, 2009 at 1:51 PM, Andrei Alexandrescu
 
 That's a good point, but... we are at liberty to choose ANY names we please.
 Is this weird "first"/"next" combo our best shot?


 But unless you've got some new words to add, we've listed pretty much
 every reasonable pair, and they all have issues of similar magnitude
 (or at least which some fraction of people will declare is of similar
 magnitude...)


I think "first/last" goes well with "advance/retreat".

Note how "advance" is a natural word in this context... quoted from the 
"What's the deal with __buck?" thread, Andrei says: "Now consider I 
want to advance 10 steps in that range."... yet, he wants to name the 
function "next".

Not only that, but the word "advance" is used everywhere Andrei's 
documentation for std.range, whenever it talks about "next"... some 
quotes:

"isInputRange: r.next advances to the next element in the range."

"struct Radial(R): void next(); Range primitive operation that advances 
the range to its next element.

This one's funny:
"Range drop(Range)(size_t n, Range r): Eagerly advances a copy of r n 
times (by calling r.next n times)"

"struct SListRange(T,Topology topology = Topology.flexible): void 
next(); Range primitive operation that advances the range to its next 
element."

"struct Zip(R...): void next(); Advances to the next element in all 
controlled ranges."

Unfortunately there is no definition for "retreat" to compare with.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Jan 29 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Michel Fortin wrote:
 On 2009-01-29 00:02:20 -0500, Bill Baxter <wbaxter gmail.com> said:
 
 On Thu, Jan 29, 2009 at 1:51 PM, Andrei Alexandrescu

 That's a good point, but... we are at liberty to choose ANY names we 
 please.
 Is this weird "first"/"next" combo our best shot?


 But unless you've got some new words to add, we've listed pretty much
 every reasonable pair, and they all have issues of similar magnitude
 (or at least which some fraction of people will declare is of similar
 magnitude...)


 I think "first/last" goes well with "advance/retreat".
 
 Note how "advance" is a natural word in this context... quoted from the 
 "What's the deal with __buck?" thread, Andrei says: "Now consider I want 
 to advance 10 steps in that range."... yet, he wants to name the 
 function "next".


Hehe, this argument works in my favor. Advancing means making a number 
of steps. Next means taking one step.

Andrei

Jan 29 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Andrei Alexandrescu escribi�:
 Simen Kjaeraas wrote:
 Andrei Alexandrescu wrote:

 So please let's vote once and for all.

 Andrei


 Do let's. My first vote goes to first/last, with head/toe at second 
 place.

 -- 
 Simen


 Ok, after looking at my code I discovered a huge problem with "first". 
 ("Last" is cool.) If all you do is implement them and use them with 
 foreach, fine. But if you need to call them manually (which is the case 
 sometimes), you get really badly interacting terms there. Look at this, 
 taken from real code (the filter function):
 
 while (!_input.empty && !pred(_input.first)) _input.next;
 
 I can see the putative user scratching their head: "Ok, so I start 
 iteration with the first element, then I move to the next one... but 
 then why the heck am I looking at the first again?"
 
 "First" must go.


Shouldn't the user think the same with "head" or "front"?

I think the problem is "next" in this case: it should be "moveToNext" or 
something that shows that you are changing the input, not just 
requesting the next element in the range.

But keep "next". Once the user starts using ranges, he'll understand the 
terminology, which is pretty straightforward.

I vote for first/last.

Jan 28 2009

Yigal Chripun <yigal100 gmail.com> writes:

Andrei Alexandrescu wrote:
 Simen Kjaeraas wrote:
 Andrei Alexandrescu wrote:

 So please let's vote once and for all.

 Andrei


 Do let's. My first vote goes to first/last, with head/toe at second
 place.

 --
 Simen


 Ok, after looking at my code I discovered a huge problem with "first".
 ("Last" is cool.) If all you do is implement them and use them with
 foreach, fine. But if you need to call them manually (which is the case
 sometimes), you get really badly interacting terms there. Look at this,
 taken from real code (the filter function):

 while (!_input.empty && !pred(_input.first)) _input.next;

 I can see the putative user scratching their head: "Ok, so I start
 iteration with the first element, then I move to the next one... but
 then why the heck am I looking at the first again?"

 "First" must go.


 Andrei


I like the following from Chad's list:
begin/end
current/last
current/back
first/last
front/back
left/right
head/last
head/back
start/end
start/last

my preffered choice would be first/last.

regarding the above point:
_all_ ranges have a "head" but "tow" is optional, so maybe the desire 
for symetry is less important. how about current/last?

while (!_input.empty && !pred(_input.current)) _input.next;

also, I'd prefer to have a positive test instead of a negative one:

while (_input.more && !pred(_input.current)) _input.next;

but I could live with the current "empty".

Jan 28 2009

Brad Roberts <braddr puremagic.com> writes:

Andrei Alexandrescu wrote:
 Simen Kjaeraas wrote:
 Andrei Alexandrescu wrote:

 So please let's vote once and for all.

 Andrei


 Do let's. My first vote goes to first/last, with head/toe at second
 place.

 -- 
 Simen


 Ok, after looking at my code I discovered a huge problem with "first".
 ("Last" is cool.) If all you do is implement them and use them with
 foreach, fine. But if you need to call them manually (which is the case
 sometimes), you get really badly interacting terms there. Look at this,
 taken from real code (the filter function):
 
 while (!_input.empty && !pred(_input.first)) _input.next;
 
 I can see the putative user scratching their head: "Ok, so I start
 iteration with the first element, then I move to the next one... but
 then why the heck am I looking at the first again?"
 
 "First" must go.
 
 
 Andrei


Just to toss my 2cents into the hat, I'll introduce a new pair:

leading/trailing

Jan 28 2009

John Reimer <terminal.node gmail.com> writes:

Hello Andrei,

 It looks like there is endless debate on the naming convention for the
 range operations. Few saw the obvious bugs in the documentation and
 examples :o).
 
 So please let's vote once and for all. I will note that I disagree we
 should ignore what conventions other languages have. Provincialism is
 the appurtenance of the incult. To that end, I looked around at how
 some languages define some primitives.
 
 LISP:
 car
 last
 http://www.gigamonkeys.com/book/they-called-it-lisp-for-a-reason-list-
 processing.html
 Scheme:
 car
 last
 http://merd.sourceforge.net/pixel/language-study/syntax-across-languag
 es-per-language/Scheme.html
 ML:
 hd
 last
 http://www.standardml.org/Basis/list.html
 Ocaml:
 hd
 no last
 http://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html
 Apparently Ocaml programmers tend to define their own function called
 "last":
 http://nodens.physics.ox.ac.uk/~mcdonnell/lab/code/code_ocaml/ocaml_fo
 ld/ocaml_fold.html
 http://caml.inria.fr/pub/ml-archives/caml-list/2004/04/06d65a793fa0503
 218c06783be2facbe.en.html
 Haskell:
 head
 last
 http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/head.h
 tml
 http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/last.h
 tml
 C++:
 front
 back
 http://support.microsoft.com/kb/158613
 Scala:
 head
 last
 http://www.scala-lang.org/docu/files/api/scala/List.html
 C#:
 Couldn't find after searching MS's asinine dox for 5 mins.
 Java:
 obj.get(0)
 obj.get(obj.size-1)
 http://java.sun.com/j2se/1.4.2/docs/api/java/util/AbstractSequentialLi
 st.html
 Python:
 lst[0]
 lst[len(lst)-1]
 So please let's vote once and for all. No choice will please
 everybody, but I want to settle for something that at least won't
 displease the most vehement ones :o).
 
 Andrei
 



head/last.  I consider it symmetrical in the context of use, because in this 
case head implies "first", not a part of our anatomy.


Another option:  


head/stern... but, arguably, this is not perfectly symmetrical. 


Otherwise, I just go with whatever gets put in there, I guess. :)


-JJR

Jan 28 2009

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Jan 29, 2009 at 1:25 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Simen Kjaeraas wrote:
 Andrei Alexandrescu wrote:

 So please let's vote once and for all.

 Andrei


 Do let's. My first vote goes to first/last, with head/toe at second place.

 --
 Simen


 Ok, after looking at my code I discovered a huge problem with "first".
 ("Last" is cool.) If all you do is implement them and use them with foreach,
 fine. But if you need to call them manually (which is the case sometimes),
 you get really badly interacting terms there. Look at this, taken from real
 code (the filter function):

 while (!_input.empty && !pred(_input.first)) _input.next;

 I can see the putative user scratching their head: "Ok, so I start iteration
 with the first element, then I move to the next one... but then why the heck
 am I looking at the first again?"

 "First" must go.


Can't you just think of it as the first of the range, not the first of
everything?

If you ask me who is first in line, I'm going to tell you who is the
first in line right now, currently.  Not who was first back when the
line first formed.  This seems similar to me.  So not confusing at all
if you think of it that way.  The range is not the container.

--bb

Jan 28 2009

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Jan 29, 2009 at 1:51 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 29, 2009 at 1:25 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Simen Kjaeraas wrote:
 Andrei Alexandrescu wrote:

 So please let's vote once and for all.

 Andrei


 Do let's. My first vote goes to first/last, with head/toe at second
 place.

 --
 Simen


 Ok, after looking at my code I discovered a huge problem with "first".
 ("Last" is cool.) If all you do is implement them and use them with
 foreach,
 fine. But if you need to call them manually (which is the case
 sometimes),
 you get really badly interacting terms there. Look at this, taken from
 real
 code (the filter function):

 while (!_input.empty && !pred(_input.first)) _input.next;

 I can see the putative user scratching their head: "Ok, so I start
 iteration
 with the first element, then I move to the next one... but then why the
 heck
 am I looking at the first again?"

 "First" must go.


 Can't you just think of it as the first of the range, not the first of
 everything?


 I could, if "next" weren't called "next". If the current is called "first",
 "next" means to move to another quantum universe in which the current
 "first" is forgotten and what was after "first" in the previous universe is
 now "first". That doesn't strike me as intuitive :o).

 If you ask me who is first in line, I'm going to tell you who is the
 first in line right now, currently.  Not who was first back when the
 line first formed.  This seems similar to me.  So not confusing at all
 if you think of it that way.  The range is not the container.


 That's a good point, but... we are at liberty to choose ANY names we please.
 Is this weird "first"/"next" combo our best shot?


But unless you've got some new words to add, we've listed pretty much
every reasonable pair, and they all have issues of similar magnitude
(or at least which some fraction of people will declare is of similar
magnitude...)

--bb

Jan 28 2009

Sean Kelly <sean invisibleduck.org> writes:

head/last

It seems fairly popular and doesn't cause any confusion with 'tail' if 
we decide to use that later on.


Sean

Jan 28 2009

Kyle Furlong <kylefurlong gmail.com> writes:

Sean Kelly wrote:
 head/last
 
 It seems fairly popular and doesn't cause any confusion with 'tail' if 
 we decide to use that later on.
 
 
 Sean


This. +1

Jan 29 2009

"Nick Sabalausky" <a a.a> writes:

I'd be ok with any of these:

head/last
head/tail
front/back
current/last
curr/last
car_bonnet/car_boot (just kidding ;))

But beyond that, I'd sooner choose "head/foot" over "head/toe".

If array-style indexing were ever done, I'd be against using negative values 
to indicate distance from end. The semantics of a paramater should never be 
dependant on the paramater's value. (I think that classic book "Writing 
Solid Code" called that a "candy-machine interface", IIRC? Or maybe that as 
something different.)

Jan 28 2009

BCS <none anon.com> writes:

Hello Andrei,

 C++:
 front
 back
 http://support.microsoft.com/kb/158613


Wow I actuly like something C++ did. vote++

Jan 28 2009

Brian Hay <bhay construct3d.com> writes:

I don't agree that "first must go". I vote:

first/last

Jan 28 2009

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Jan 29, 2009 at 3:17 PM, BCS <none anon.com> wrote:
 Hello Andrei,

 C++:
 front
 back
 http://support.microsoft.com/kb/158613


 Wow I actuly like something C++ did. vote++


I could go for front/back too.
head/toe or first/last are also ok by me.

--bb

Jan 28 2009

BLS <windevguy hotmail.de> writes:

C++:
front
back

Jan 28 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

Ideally, I'd like to change all the names for the interface to be:

  front		-- first element in the range
  back		-- last element in the range
  advanceFront  -- advance the front element by one
  retreatBack   -- retreat the back element by one

And, tempting fate...

  nonEmpty	-- as Walter one espoused: negative = bad, positive = good :D

If I can't have my cake and eat it too, then front/back will suffice.

  -- Daniel

Jan 28 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

Daniel Keep wrote:
 And, tempting fate...
 
   nonEmpty	-- as Walter one espoused: negative = bad, positive = good :D


*ONCE*... as Walter ONCE espoused...

Jan 28 2009

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Jan 29, 2009 at 4:11 PM, Daniel Keep
<daniel.keep.lists gmail.com> wrote:


  nonEmpty      -- as Walter one espoused: negative = bad, positive = good :D


I think that's exactly the kind of thing he meant to avoid.  Now you have
     if (!nonEmpty)  { /* don't not do nothing here */ }

Hopefully you were just joking...

--bb

Jan 28 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

Bill Baxter wrote:
 On Thu, Jan 29, 2009 at 4:11 PM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:
 
  nonEmpty      -- as Walter one espoused: negative = bad, positive = good :D


 I think that's exactly the kind of thing he meant to avoid.  Now you have
      if (!nonEmpty)  { /* don't not do nothing here */ }
 
 Hopefully you were just joking...
 
 --bb


Thing is that most of the time, I'm more interested in testing to see if
a container/sequence has something in it rather than has nothing in it.

while( range.nonEmpty )
{
    doSomethingWith(range.front);
    range.advanceFront;
}

I admit that nonEmpty is probably a bad name; I just couldn't think of a
short and pithy way of saying 'has something in it.'  Then again, I
don't want to start another war of semantics; it's not the end of the
world :P

  -- Daniel

Jan 29 2009

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-01-29 03:33:13 -0500, Daniel Keep <daniel.keep.lists gmail.com> said:

 while( range.nonEmpty )
 {
     doSomethingWith(range.front);
     range.advanceFront;
 }


What I'd like is to place directly the range in the conditional 
expression and have it converted to a boolean (false if empty, true if 
not):

while (range)
{
	doSomethingWith(range.front);
	range.advanceFront;
}

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Jan 29 2009

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Jan 29, 2009 at 5:33 PM, Daniel Keep
<daniel.keep.lists gmail.com> wrote:
 Bill Baxter wrote:
 On Thu, Jan 29, 2009 at 4:11 PM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:

  nonEmpty      -- as Walter one espoused: negative = bad, positive = good :D


 I think that's exactly the kind of thing he meant to avoid.  Now you have
      if (!nonEmpty)  { /* don't not do nothing here */ }

 Hopefully you were just joking...

 --bb


 Thing is that most of the time, I'm more interested in testing to see if
 a container/sequence has something in it rather than has nothing in it.

 while( range.nonEmpty )
 {
    doSomethingWith(range.front);
    range.advanceFront;
 }

 I admit that nonEmpty is probably a bad name; I just couldn't think of a
 short and pithy way of saying 'has something in it.'  Then again, I
 don't want to start another war of semantics; it's not the end of the
 world :P


:-) Ok.    .more, .hasMore, .remains, .hasFront, something of that ilk
would do it then.

--bb

Jan 29 2009

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Daniel Keep" wrote
 Ideally, I'd like to change all the names for the interface to be:

  front -- first element in the range
  back -- last element in the range
  advanceFront  -- advance the front element by one
  retreatBack   -- retreat the back element by one

 And, tempting fate...

  nonEmpty -- as Walter one espoused: negative = bad, positive = good :D


That has a negative term right in it "non".  Why do people consider empty to 
be negative?  It's actually zero :P

-Steve

Jan 29 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

Steven Schveighoffer wrote:
 "Daniel Keep" wrote
 Ideally, I'd like to change all the names for the interface to be:

  front -- first element in the range
  back -- last element in the range
  advanceFront  -- advance the front element by one
  retreatBack   -- retreat the back element by one

 And, tempting fate...

  nonEmpty -- as Walter one espoused: negative = bad, positive = good :D


 That has a negative term right in it "non".  Why do people consider empty to 
 be negative?  It's actually zero :P
 
 -Steve 


Well, if someone were to call you "empty-headed" in an outrageous French
accent, you wouldn't be too happy about that, would you? :D

The only positive form of "empty" I can think of is "empty pit of
snakes," much preferable to any alternatives.

As it stands, I really wish I'd taken the time to think of a better
phrase than "nonEmpty."

  -- Daniel

Jan 29 2009

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Daniel Keep" wrote
 Steven Schveighoffer wrote:
 "Daniel Keep" wrote
 Ideally, I'd like to change all the names for the interface to be:

  front -- first element in the range
  back -- last element in the range
  advanceFront  -- advance the front element by one
  retreatBack   -- retreat the back element by one

 And, tempting fate...

  nonEmpty -- as Walter one espoused: negative = bad, positive = good :D


 That has a negative term right in it "non".  Why do people consider empty 
 to
 be negative?  It's actually zero :P

 -Steve


 Well, if someone were to call you "empty-headed" in an outrageous French
 accent, you wouldn't be too happy about that, would you? :D


I'd probably wait until they taunt me a second time, then sneek into their 
house inside a large wooden rabbit (which unbeknownst to them would be 
nonEmpty!)

 The only positive form of "empty" I can think of is "empty pit of
 snakes," much preferable to any alternatives.


Empty bathroom stall
Empty trash
Empty parking space

There's all kinds of "good" empties :)  Of course, I think when one thinks 
of avoiding negatives in programming, it's not to make us all feel more 
positive joy about our code, I think it's to avoid using terms that are 
negators like notDone, or nonEmpty.  The reason being that it looks and 
reads weird when you see !notDone.  Whereas, if it's just done, then you can 
have done or !done, and both read fine.

As for empty, you could use "done" or "hasNext" or whatever, but as far as 
I'm concerned, these are nitpicks.  empty and !empty describe the situation 
perfectly and read fine.

-Steve

Jan 29 2009

Rainer Deyke <rainerd eldwood.com> writes:

Daniel Keep wrote:
   advanceFront  -- advance the front element by one
   retreatBack   -- retreat the back element by one


I like this.  Verb instead of noun for action, unambiguous about which
end moves in which direction, and it's symmetrical.

   nonEmpty	-- as Walter one espoused: negative = bad, positive = good :D


I don't like this.  "!empty" reads better than "nonEmpty", and "empty"
reads much better than "!nonEmpty".


-- 
Rainer Deyke - rainerd eldwood.com

Jan 29 2009

Kazuhiro Inaba <kinaba is.s.u-tokyo.ac.jp> writes:

I'd like to vote for

1. head/tail

The pair is symmetric in its meaning,
 has the same length (4 letters) which sometimes gives better look for source
codes,
 has similarity with the Unix head(1) and tail(1) command, and
 also has in common with, say, J Programming Language
(http://www.jsoftware.com/help/dictionary/vocabul.htm).

I know that several languages already use 'tail' to mean 'except the head', but
I don't think that makes big confusion...

If I choose from the list you posted, I like

2. Haskell/Scala: head/last

Jan 28 2009

Max Samukha <samukha voliacable.com.removethis> writes:

On Wed, 28 Jan 2009 16:26:17 -0800, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

It looks like there is endless debate on the naming convention for the 
range operations. Few saw the obvious bugs in the documentation and 
examples :o).

So please let's vote once and for all. I will note that I disagree we 
should ignore what conventions other languages have. Provincialism is 
the appurtenance of the incult. To that end, I looked around at how some 
languages define some primitives.

LISP:
car
last
http://www.gigamonkeys.com/book/they-called-it-lisp-for-a-reason-list-processing.html

Scheme:
car
last
http://merd.sourceforge.net/pixel/language-study/syntax-across-languages-per-language/Scheme.html

ML:
hd
last
http://www.standardml.org/Basis/list.html

Ocaml:
hd
no last
http://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html
Apparently Ocaml programmers tend to define their own function called 
"last":
http://nodens.physics.ox.ac.uk/~mcdonnell/lab/code/code_ocaml/ocaml_fold/ocaml_fold.html
http://caml.inria.fr/pub/ml-archives/caml-list/2004/04/06d65a793fa0503218c06783be2facbe.en.html

Haskell:
head
last
http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/head.html
http://www.cs.chalmers.se/Cs/Grundutb/Kurser/d1pt/d1pta/ListDoc/last.html

C++:
front
back
http://support.microsoft.com/kb/158613

Scala:
head
last
http://www.scala-lang.org/docu/files/api/scala/List.html

C#:
Couldn't find after searching MS's asinine dox for 5 mins.

Java:
obj.get(0)
obj.get(obj.size-1)
http://java.sun.com/j2se/1.4.2/docs/api/java/util/AbstractSequentialList.html

Python:
lst[0]
lst[len(lst)-1]

So please let's vote once and for all. No choice will please everybody, 
but I want to settle for something that at least won't displease the 
most vehement ones :o).


Andrei


head/toe (I'm not a native speaker, so this sounds perfectly good to
me)
head/last (there is not much symmetry in the real world)
front/back 
face/nape

Jan 28 2009

bearophile <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:
 Python:
 lst[0]
 lst[len(lst)-1]


I have not read the whole thread so someone else may have already answered, but
that's not pythonic, the last item is represented as:

 lst = "abcde"
 lst[-1]






 lst[-2]







etc.

You can write those in D as:
lst[$-1]
lst[$-2]

Bye,
bearophile

Jan 28 2009

grauzone <none example.net> writes:

head/tail > first/last

Jan 29 2009

Derek Parnell <derek psych.ward> writes:

On Wed, 28 Jan 2009 16:26:17 -0800, Andrei Alexandrescu wrote:

 So please let's vote once and for all.


Before doing so, can I ask for a clarification, naming what *exactly* are
we voting for? I know we are talking about the /names/ of things but what
are the things we are naming here? (I assume we are only talking ranges
here BTW)

Do they include ...
(A) The first element
(B) The last element
(C) The leftmost set of elements that excludes the last element?
(D) The rightmost set of elements that excludes the first element?
(E) The set of elements that excludes both the first and last element.
(F) The /current/ element (assuming some sort of 'cursor' concept).
(G) The action of adjusting a range so that next (A) returns the element
that immediately follows the current (A) element.
(H) The action of adjusting a range so that next (B) returns the element
that immediately precedes the current (B) element.

My preferences are ...
(A)  first
(B)  last
(C)  firstpart
(D)  lastpart
(E)  midpart
(F)  current
(G)  dropfirst
(H)  droplast




-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Jan 29 2009

"Rioshin an'Harthen" <rharth75 hotmail.com> writes:

"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> kirjoitti viestiss� 
news:glqt38$14p2$1 digitalmars.com...
 So please let's vote once and for all. No choice will please everybody, 
 but I want to settle for something that at least won't displease the most 
 vehement ones :o).


I'll vote for

curr(ent)-last

Jan 29 2009

Don <nospam nospam.com> writes:

Andrei Alexandrescu wrote:
 It looks like there is endless debate on the naming convention for the 
 range operations. 


head/toe > front/back >> all the other suggestions >> car.

FWIW, I'd say start and end is the only pairing which is natural for 
English speakers. Once you reject them, I think you've committed to a 
pairing which is going to sound peculiar part of the time.

English idiom is interesting -- we talk about the "head of the queue" 
but never the "tail of the queue", rather the "end of the queue".

"start/end of the queue", "start/end of the list", "start/end of the 
range" (though "beginning" is more natural than start).
"head/end of the queue", "head/end of the list"
"front/back of the queue" (doesn't work for lists. Only solid objects 
have a front and a back).

Jan 29 2009

Brian Hay <bhay construct3d.com> writes:

Don wrote:
 FWIW, I'd say start and end is the only pairing which is natural for 
 English speakers.


I disagree. Start and end can be both nouns or verbs. First and last are 
less ambiguous in this context.

Jan 29 2009

Don <nospam nospam.com> writes:

Brian Hay wrote:
 Don wrote:
 FWIW, I'd say start and end is the only pairing which is natural for 
 English speakers.


 I disagree. Start and end can be both nouns or verbs. 


BTW I'm not saying that start/end is the best choice. I'm just saying 
that if you decision is based only on what sounds natural, you don't 
have very many choices at all. In particular, _none_ of the spatial 
pairings work.

First and last are
 less ambiguous in this context.


"First in the queue"/"Last in the queue".

Jan 29 2009

Gide Nwawudu <gide btinternet.com> writes:

front/back is my preferred, but first/last, head/tail are ok.

Gide

Jan 29 2009

Michel Fortin <michel.fortin michelf.com> writes:

I don't mind much about the names for head and toe. Anything that makes 
some sense of being the two ends of the range when you read it is fine 
by me. What I don't like is "next": should be "advance".

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Jan 29 2009

Brian <digitalmars brianguertin.com> writes:

 So please let's vote once and for all. No choice will please everybody,
 but I want to settle for something that at least won't displease the
 most vehement ones :o).
 
 
 Andrei


front/back
head/rhead
head/toe
jekyll/hyde

Jan 29 2009

Yigal Chripun <yigal100 gmail.com> writes:

Brian wrote:
 So please let's vote once and for all. No choice will please everybody,
 but I want to settle for something that at least won't displease the
 most vehement ones :o).


 Andrei


 front/back
 head/rhead
 head/toe
 jekyll/hyde


pinky/theBrain
<joking>

Jan 29 2009

"Vladimir Panteleev" <thecybershadow gmail.com> writes:

On Thu, 29 Jan 2009 06:25:58 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Simen Kjaeraas wrote:
 Andrei Alexandrescu wrote:

 So please let's vote once and for all.

 Andrei


 place.
  -- Simen


 Ok, after looking at my code I discovered a huge problem with "first".  
 ("Last" is cool.) If all you do is implement them and use them with  
 foreach, fine. But if you need to call them manually (which is the case  
 sometimes), you get really badly interacting terms there. Look at this,  
 taken from real code (the filter function):

 while (!_input.empty && !pred(_input.first)) _input.next;

 I can see the putative user scratching their head: "Ok, so I start  
 iteration with the first element, then I move to the next one... but  
 then why the heck am I looking at the first again?"

 "First" must go.


I don't think that "next" is an appropriate name here. Since it is an  
action, it should be named as one - "next" sounds more like a function  
(which doesn't modify the instance). Have you considered "forward"?

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com

Jan 29 2009

Rainer Deyke <rainerd eldwood.com> writes:

Andrei Alexandrescu wrote:
 So please let's vote once and for all.


1st pick: first/last
2nd pick: front/back


-- 
Rainer Deyke - rainerd eldwood.com

Jan 29 2009

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Andrei Alexandrescu wrote:
 So please let's vote once and for all.


first/last.

They're just the most sensible symbols to use for retrieving the first 
and last element :).


 LISP:
 car
 last
 http://www.gigamonkeys.com/book/they-called-it-lisp-for-a-reason-
ist-processing.html 


Common Lisp (the Lisp I'm most familiar with) also has 'first', which is 
equivalent to 'car' and the antonym of 'last'.

('car's antonym is 'cdr', 'car' and 'last' are not meant to be paired up 
like this)

Jan 30 2009

D Programming

C/C++ Programming

Other

digitalmars.D - Please vote once and for good: range operations