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

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

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

going to win
Jan 28 2009
parent reply 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
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
 


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

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

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

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

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



 lst[-2]



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.

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