www.digitalmars.com         C & C++   DMDScript  

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

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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


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
next sibling parent reply 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
parent reply 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
parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent reply 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


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

 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



  parent  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



prev sibling next sibling parent  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



prev sibling next sibling parent reply 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



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



  parent  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



prev sibling next sibling parent reply 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



 next sibling parent  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



prev sibling  parent reply "Saaa" <empty needmail.com>  writes:


 fore/aft +


head/toe seem different classes to me, rather head/back if fore/aft isn't 
going to win 



 Jan 28 2009



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


Hello Saaa,


 fore/aft +
 


 head/toe seem different classes to me, rather head/back if 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



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



  parent  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
 


 :D I have the same with 'head'
 



Yeah, I guess it works both ways.   :)


-JJR



 Jan 29 2009



prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


"Andrei Alexandrescu"  wrote


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



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];



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



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


Steven Schveighoffer wrote:



 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



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


"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:



 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



prev sibling next sibling parent  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
 

 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



prev sibling next sibling parent  "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


 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



prev sibling next sibling parent  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



prev sibling next sibling parent reply "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



  parent reply 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



 next sibling parent  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
 


 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
 



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


-JJR


-JJR



 Jan 28 2009



prev sibling next sibling parent  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



prev sibling next sibling parent reply 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



  parent reply 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


 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?


Andrei



 Jan 28 2009



 next sibling parent reply 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



  parent reply 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



  parent  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



prev sibling  parent reply "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



  parent  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



prev sibling next sibling parent  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



prev sibling next sibling parent  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



prev sibling  parent  "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


  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.


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



prev sibling next sibling parent  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

 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



prev sibling next sibling parent reply 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



  parent  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



prev sibling next sibling parent  "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



prev sibling next sibling parent reply 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



  parent  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



prev sibling next sibling parent  Brian Hay <bhay construct3d.com>  writes:


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

first/last



 Jan 28 2009



prev sibling next sibling parent  BLS <windevguy hotmail.de>  writes:


C++:
front
back



 Jan 28 2009



prev sibling next sibling parent reply 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



 next sibling parent  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



prev sibling next sibling parent reply 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



  parent reply 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



 next sibling parent  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



prev sibling  parent  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



prev sibling next sibling parent reply "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



  parent reply 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



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



prev sibling  parent  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



prev sibling next sibling parent  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



prev sibling next sibling parent  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


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



prev sibling next sibling parent  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]






'e'

 lst[-2]






'd'

etc.

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

Bye,
bearophile



 Jan 28 2009



prev sibling next sibling parent  grauzone <none example.net>  writes:


head/tail > first/last



 Jan 29 2009



prev sibling next sibling parent  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



prev sibling next sibling parent  "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



prev sibling next sibling parent reply 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



  parent reply 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



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


Yes. You can also "front up to something" and "back into somebody" <g>.
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.


True. I missed them.
"First in the queue"/"Last in the queue".



 Jan 29 2009



prev sibling next sibling parent  Gide Nwawudu <gide btinternet.com>  writes:


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

Gide



 Jan 29 2009



prev sibling next sibling parent  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



prev sibling next sibling parent  Denis Koroskin <2korden gmail.com>  writes:


Andrei Alexandrescu 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.
 
 [snip]
 
 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


I don't like first/last. Given a sequence, its first and last elements are
fixed (even if the sequence advances), i.e. first, head, toe and last have
strict ordering to me.

Head/Toe is acceptable, but I don't like it either. Head has a well-known and
unambiguous meaning, which is ok. But toe... (Being a non-native english
speaker) I didn't even know its meaning until I looked it up in a dictionary.
It sounds more like a head/bar pair to me (i.e. completely unrelated).
"Collection's toe element" doesn't tell anything and it takes some time to
recall term's meaning in this context (I got used to it a bit, though).

Other property I don't like about 'toe' is that it is shorter than its
counterpart - 'head' - I think it should be the same or slightly longer.

That said, best names for me are left(most) and right(most), but they are not
listed here :( May I vote for them?



 Jan 29 2009



prev sibling next sibling parent  Denis Koroskin <2korden 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


I don't think head/tail gives any confusion (it certainly doesn't to me).
I believe 'tail' (meaning 'everything but head') is misused in other languages,
the correct term for it is 'rest'.

head/tail - first and last elements
head/rest - first element and the rest.

Is there any ambiguity?



 Jan 29 2009



prev sibling next sibling parent reply 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



  parent  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



prev sibling next sibling parent reply Denis Koroskin <2korden gmail.com>  writes:


Vladimir Panteleev Wrote:


 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


  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.


 
 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


Agree, "advance" would be a better name, though (imo).



 Jan 29 2009



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


Denis Koroskin wrote:

 Vladimir Panteleev Wrote:
 

 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


  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.


 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


 
 Agree, "advance" would be a better name, though (imo).


Same, it seems BETTER.  Though, it seems like it's suboptimal as well.
As I understand it we aren't so much moving rightward a head that's
reading a tape, but instead we are incrementally chopping off the
leftmost elements until none are left.  So it is possible (though not
intuitive) to draw analogies and write metaphors:  we are advancing our
knife each time we chop off a bit of carrot.

Anyways, while technically incorrect as far as I can tell, it isn't
aesthetically displeasing to me, so in some odd way I am alright with
next.

Hmmm... maybe "chop" is a good word for this...

- Chad



 Jan 29 2009



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


Chad J wrote:

 Denis Koroskin wrote:

 Agree, "advance" would be a better name, though (imo).


 
 Same, it seems BETTER.  Though, it seems like it's suboptimal as well.
 As I understand it we aren't so much moving rightward a head that's
 reading a tape, but instead we are incrementally chopping off the
 leftmost elements until none are left.  So it is possible (though not
 intuitive) to draw analogies and write metaphors:  we are advancing our
 knife each time we chop off a bit of carrot.
 
 Anyways, while technically incorrect as far as I can tell, it isn't
 aesthetically displeasing to me, so in some odd way I am alright with
 next.
 
 Hmmm... maybe "chop" is a good word for this...
 
 - Chad


That's why I suggested "advanceFront" and "retreatBack."  I don't think
there's a single, short word to exactly express the concept "move the
front of a view of some sequence one element towards the end."

  -- Daniel



 Jan 29 2009



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


Chad J wrote:

 As I understand it we aren't so much moving rightward a head that's
 reading a tape, but instead we are incrementally chopping off the
 leftmost elements until none are left.  So it is possible (though not
 intuitive) to draw analogies and write metaphors:  we are advancing our=



 knife each time we chop off a bit of carrot.


<snip>

 Hmmm... maybe "chop" is a good word for this...


How about =93chomp=94 and =93regurgitate=94? ;)



 Jan 30 2009



prev sibling next sibling parent  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



prev sibling  parent  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