www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - I have a suggestion.

reply YonggangLuo <yonggangluo gmail.com> writes:
i think it's will be a good idea to replace "foreach_reverse" with  "frr".
"foreach_reverse" is too long as a keyword
May 16 2007
next sibling parent reply freeagle <dalibor.free gmail.com> writes:
YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  "frr".
 "foreach_reverse" is too long as a keyword


I find "frr" very cryptic.

consider this:

if(reverse)
{
	frr(int i, array)
	{
		...
	}
}
else
{
	foreach(int i, array)
	{
		...
	}
}

Those keywords doesn't seem related, but would in fact provide similar 
funcitonality.

I too would like to see this "foreach_reverse" solved in other way, but 
not with another keyword

freeagle
May 16 2007
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
freeagle wrote:

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  
 "frr".
 "foreach_reverse" is too long as a keyword


 
 I find "frr" very cryptic.
 
 consider this:
 
 if(reverse)
 {
     frr(int i, array)
     {
         ...
     }
 }
 else
 {
     foreach(int i, array)
     {
         ...
     }
 }
 
 Those keywords doesn't seem related, but would in fact provide similar 
 funcitonality.
 
 I too would like to see this "foreach_reverse" solved in other way, but 
 not with another keyword
 
 freeagle


I agree with you completely.  While I understand the goal behind
"foreach_reverse" is to put optimal 
array-traversal-loop generation in the hands of the compiler (read: faster than
opApply), the keyword itself remains the 
only real wart.  The keyword "rforeach" would have made a much better candidate
IMO.

-- 
- EricAnderton at yahoo
May 16 2007
next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
I do like foreach_reverse. It's a very explicity name, and it doesn't 
appear often. And I guess an editor could provide a template for it, so 
just typing "fore" and pressing the down arrow will be enough.

Pragma escribió:

 freeagle wrote:

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  
 "frr".
 "foreach_reverse" is too long as a keyword


 I find "frr" very cryptic.

 consider this:

 if(reverse)
 {
     frr(int i, array)
     {
         ...
     }
 }
 else
 {
     foreach(int i, array)
     {
         ...
     }
 }

 Those keywords doesn't seem related, but would in fact provide similar 
 funcitonality.

 I too would like to see this "foreach_reverse" solved in other way, 
 but not with another keyword

 freeagle


 
 I agree with you completely.  While I understand the goal behind 
 "foreach_reverse" is to put optimal array-traversal-loop generation in 
 the hands of the compiler (read: faster than opApply), the keyword 
 itself remains the only real wart.  The keyword "rforeach" would have 
 made a much better candidate IMO.
May 16 2007
prev sibling parent reply antonio <antonio abrevia.net> writes:
Pragma wrote:

 freeagle wrote:

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  
 "frr".
 "foreach_reverse" is too long as a keyword


 I find "frr" very cryptic.

 consider this:

 if(reverse)
 {
     frr(int i, array)
     {
         ...
     }
 }
 else
 {
     foreach(int i, array)
     {
         ...
     }
 }

 Those keywords doesn't seem related, but would in fact provide similar 
 funcitonality.

 I too would like to see this "foreach_reverse" solved in other way, 
 but not with another keyword

 freeagle


 
 I agree with you completely.  While I understand the goal behind 
 "foreach_reverse" is to put optimal array-traversal-loop generation in 
 the hands of the compiler (read: faster than opApply), the keyword 
 itself remains the only real wart.  The keyword "rforeach" would have 
 made a much better candidate IMO.
 


I think the more "algebraic" way could be something like

foreach(int i; reversed array)

compiler must act in the optimal way.
May 16 2007
parent reply BCS <BCS pathlink.com> writes:
antonio wrote:

 I think the more "algebraic" way could be something like
 
 foreach(int i; reversed array)
 
 compiler must act in the optimal way.
 


or we could take a hint from scope and do:

foreach(reverse)(i;arr)

that leaves the door open for things like

foreach(stride, 5)(i;arr) {}

and

foreach(heaptree)(i;arr) {}

the overloads could be something like

opApply(char[] : "reverse")(int delegate(inout int));
May 16 2007
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
BCS skrev:

 antonio wrote:

 I think the more "algebraic" way could be something like

 foreach(int i; reversed array)

 compiler must act in the optimal way.


 
 or we could take a hint from scope and do:
 
 foreach(reverse)(i;arr)
 
 that leaves the door open for things like
 
 foreach(stride, 5)(i;arr) {}
 
 and
 
 foreach(heaptree)(i;arr) {}
 
 the overloads could be something like
 
 opApply(char[] : "reverse")(int delegate(inout int));
 


Not that I havn't said it before, but there doesn't need to be any 
language changes at all. Removing foreach_reverse altogether doesn't 
remove any expressiveness -- just a special case.

If the compiler was smart enough to 1) be able to inline functions with 
loops, and 2) be able to inline const (at compile time known) delegate 
calls (which it possibly does already), there would be no need for this 
special case keyword.

foreach(i; arr), foreach(i; reverse(arr)), foreach(i; heaptree(arr)), 
and so on, could all be equally efficient.

/Oskar
May 16 2007
parent reply janderson <askme me.com> writes:
Oskar Linde wrote:

 BCS skrev:

 antonio wrote:

 I think the more "algebraic" way could be something like

 foreach(int i; reversed array)

 compiler must act in the optimal way.


 or we could take a hint from scope and do:

 foreach(reverse)(i;arr)

 that leaves the door open for things like

 foreach(stride, 5)(i;arr) {}

 and

 foreach(heaptree)(i;arr) {}

 the overloads could be something like

 opApply(char[] : "reverse")(int delegate(inout int));


 
 Not that I havn't said it before, but there doesn't need to be any 
 language changes at all. Removing foreach_reverse altogether doesn't 
 remove any expressiveness -- just a special case.
 
 If the compiler was smart enough to 1) be able to inline functions with 
 loops, and 2) be able to inline const (at compile time known) delegate 
 calls (which it possibly does already), there would be no need for this 
 special case keyword.
 
 foreach(i; arr), foreach(i; reverse(arr)), foreach(i; heaptree(arr)), 
 and so on, could all be equally efficient.
 
 /Oskar


I agree.  I still don't understand why the compiler can't have a special 
inbuilt reverse keyword as an attribute of arrays, that it can optimize 
away when it needs to.

-Joel
May 16 2007
parent Dave <Dave_member pathlink.com> writes:
janderson wrote:

 Oskar Linde wrote:
 
 I agree.  I still don't understand why the compiler can't have a special 
 inbuilt reverse keyword as an attribute of arrays, that it can optimize 
 away when it needs to.
 
 -Joel


There's array.reverse, but of course it modifies the data.

Instead of foreach_reverse, how about 'reveach' <g>

- Dave
May 16 2007
prev sibling next sibling parent reply Brian Byrne <bdbyrne wisc.edu> writes:
YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  "frr".
 "foreach_reverse" is too long as a keyword


I tend to side on being explicit, so I don't think "frr" would be that 
great of a name change. But I will agree that foreach_reverse looks 
fairly ugly (more than a keyword should).

Anyways, along your lines I think "fer" (ForEachReverse) would be a more 
appropriate abbreviation. I can give it association to hillbilly speech, 
"Fer dat dem dere list [insert mental image of a scraggly old man in 
overalls holding a list upside-down]..."

More seriously, I think a better keyword would be rforeach, revforeach, 
or something similarly parallel. Something about reading underscores in 
keywords (*cough* C++) makes me cringe at the sight.

Brian Byrne
May 16 2007
next sibling parent reply renoX <renosky free.fr> writes:
Brian Byrne a écrit :

 More seriously, I think a better keyword would be rforeach, revforeach, 
 or something similarly parallel. Something about reading underscores in 
 keywords (*cough* C++) makes me cringe at the sight.
 
 Brian Byrne


While_a_shorter_keyword_could_be_better_whats_wrong_with_underscores?

BasicallyThereAreTwoChoiceToLinkSeveralWordsTogetherEitherUnderscoreOrUsingCase.

Guess which one is easier one the eye with the two above sentence?

I *really* don't understand those who prefer CamelCase, it's harder to 
read, it doesn't work well with shortcuts such as IBM, etc, the only 
good point of CamelCase is that it is a little more compact, bah.

renoX
May 16 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
renoX wrote:

 Brian Byrne a écrit :

 More seriously, I think a better keyword would be rforeach, 
 revforeach, or something similarly parallel. Something about reading 
 underscores in keywords (*cough* C++) makes me cringe at the sight.

 Brian Byrne


 
 While_a_shorter_keyword_could_be_better_whats_wrong_with_underscores?
 
 BasicallyThereAreTwoChoiceToLinkSeveralWordsTogetherEitherUn
erscoreOrUsingCase. 
 
 
 Guess which one is easier one the eye with the two above sentence?
 
 I *really* don't understand those who prefer CamelCase, it's harder to 
 read, it doesn't work well with shortcuts such as IBM, etc, the only 
 good point of CamelCase is that it is a little more compact, bah.
 
 renoX


Yeh, underscores are good.  Just not in a keyword.  A camelCase keyword 
would be just as bad.

--bb
May 16 2007
prev sibling next sibling parent Brian Byrne <bdbyrne wisc.edu> writes:
renoX wrote:

 Brian Byrne a écrit :

 More seriously, I think a better keyword would be rforeach, 
 revforeach, or something similarly parallel. Something about reading 
 underscores in keywords (*cough* C++) makes me cringe at the sight.

 Brian Byrne


 
 While_a_shorter_keyword_could_be_better_whats_wrong_with_underscores?
 
 BasicallyThereAreTwoChoiceToLinkSeveralWordsTogetherEitherUn
erscoreOrUsingCase. 
 
 
 Guess which one is easier one the eye with the two above sentence?
 
 I *really* don't understand those who prefer CamelCase, it's harder to 
 read, it doesn't work well with shortcuts such as IBM, etc, the only 
 good point of CamelCase is that it is a little more compact, bah.
 
 renoX


I wasn't implying camel case would be better, rather I believe that 
would also be the wrong way to go. As you probably know, the C++ casts 
are big, long, and ugly for the sake of being big, long, and ugly (to 
discourage their use). I don't think that's so much the aim for 
foreach_reverse. It would just be nicer to shorten it, is all.

Brian Byrne
May 16 2007
prev sibling parent janderson <askme me.com> writes:
renoX wrote:

 Brian Byrne a écrit :

 More seriously, I think a better keyword would be rforeach, 
 revforeach, or something similarly parallel. Something about reading 
 underscores in keywords (*cough* C++) makes me cringe at the sight.

 Brian Byrne


 
 While_a_shorter_keyword_could_be_better_whats_wrong_with_underscores?
 
 BasicallyThereAreTwoChoiceToLinkSeveralWordsTogetherEitherUn
erscoreOrUsingCase. 
 
 
 Guess which one is easier one the eye with the two above sentence?
 
 I *really* don't understand those who prefer CamelCase, it's harder to 
 read, it doesn't work well with shortcuts such as IBM, etc, the only 
 good point of CamelCase is that it is a little more compact, bah.
 
 renoX


I find that camel case allows me to see things as one unit rather then 
several.  But that's just me.  I automatically see your first example as 
many different symbols rather then just one.

-Joel
May 16 2007
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
Well there is one that is
- no longer than "foreach"
- not a concatenation of words
- not an abbreviation
- rather illustrative

"hcaerof"

...It is also cryptic - you can't please everyone.

Just kidding.
Bastiaan.


Brian Byrne wrote:

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  
 "frr".
 "foreach_reverse" is too long as a keyword


 
 I tend to side on being explicit, so I don't think "frr" would be that 
 great of a name change. But I will agree that foreach_reverse looks 
 fairly ugly (more than a keyword should).
 
 Anyways, along your lines I think "fer" (ForEachReverse) would be a more 
 appropriate abbreviation. I can give it association to hillbilly speech, 
 "Fer dat dem dere list [insert mental image of a scraggly old man in 
 overalls holding a list upside-down]..."
 
 More seriously, I think a better keyword would be rforeach, revforeach, 
 or something similarly parallel. Something about reading underscores in 
 keywords (*cough* C++) makes me cringe at the sight.
 
 Brian Byrne
May 16 2007
parent "Anders Bergh" <anders andersman.org> writes:
Would be a perfect easter egg, but I guess those have no place in a
programming language.

On 5/17/07, Bastiaan Veelo <Bastiaan veelo.net> wrote:

 Well there is one that is
 - no longer than "foreach"
 - not a concatenation of words
 - not an abbreviation
 - rather illustrative

 "hcaerof"

 ...It is also cryptic - you can't please everyone.

 Just kidding.
 Bastiaan.


 Brian Byrne wrote:

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with
 "frr".
 "foreach_reverse" is too long as a keyword


 I tend to side on being explicit, so I don't think "frr" would be that
 great of a name change. But I will agree that foreach_reverse looks
 fairly ugly (more than a keyword should).

 Anyways, along your lines I think "fer" (ForEachReverse) would be a more
 appropriate abbreviation. I can give it association to hillbilly speech,
 "Fer dat dem dere list [insert mental image of a scraggly old man in
 overalls holding a list upside-down]..."

 More seriously, I think a better keyword would be rforeach, revforeach,
 or something similarly parallel. Something about reading underscores in
 keywords (*cough* C++) makes me cringe at the sight.

 Brian Byrne





-- 
Anders
May 17 2007
prev sibling next sibling parent Mikola Lysenko <mclysenk mtu.edu> writes:
YonggangLuo Wrote:


 i think it's will be a good idea to replace "foreach_reverse" with  "frr".
 "foreach_reverse" is too long as a keyword



I like this idea, but "frr" is downright inconsistent with the rest of the
language.  What if we do something like this:

~foreach( x; arr )

While reducing keystrokes, recycling a unary operator also cuts down keyword
bloat.  My only concern is that it might be too subtle.  I suspect that for
non-English users, there would be few tears shed over the death of
"foreach_reverse."

Ultimately, the best option might be to do as Tom S. and others have suggested
and simply axe it entirely.  Using a clever template you could actually
implement a very efficient reverse foreach within the standard library.

-Mik
May 16 2007
prev sibling parent reply Justin C Calvarese <technocrat7 gmail.com> writes:
YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  "frr".
 "foreach_reverse" is too long as a keyword


I agree that foreach_reverse is way too long for a keyword. Also, it has 
that unslightly underscore.

I think that frr is a little too short. Since it's a keyword that will 
be rarely used, newcomers to D will likely get confused.

I'm "voting" for foreachrev, but here's a whole list of decent 
alternatives to the current "foreach_reverse" mess:

1. foreachrev
2. rforeach
3. revforeach

-- 
jcc7
May 17 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Justin C Calvarese wrote:

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  
 "frr".
 "foreach_reverse" is too long as a keyword


 
 I agree that foreach_reverse is way too long for a keyword. Also, it has 
 that unslightly underscore.
 
 I think that frr is a little too short. Since it's a keyword that will 
 be rarely used, newcomers to D will likely get confused.
 
 I'm "voting" for foreachrev, but here's a whole list of decent 
 alternatives to the current "foreach_reverse" mess:
 
 1. foreachrev
 2. rforeach
 3. revforeach


I still like:

foreach - unordered?
foreach(fwd) - explicitly forward
foreach(rev) - explicitly reverse
foreach(any) - unordered


Sean
May 17 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

 Justin C Calvarese wrote:

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  
 "frr".
 "foreach_reverse" is too long as a keyword


 I agree that foreach_reverse is way too long for a keyword. Also, it 
 has that unslightly underscore.

 I think that frr is a little too short. Since it's a keyword that will 
 be rarely used, newcomers to D will likely get confused.

 I'm "voting" for foreachrev, but here's a whole list of decent 
 alternatives to the current "foreach_reverse" mess:

 1. foreachrev
 2. rforeach
 3. revforeach


 
 I still like:
 
 foreach - unordered?
 foreach(fwd) - explicitly forward
 foreach(rev) - explicitly reverse
 foreach(any) - unordered
 


Yep, or something of that ilk.  It's very D-like; it means we can get 
rid of the special-case keyword; and it leaves wiggle room for future 
innovation, like foreach(any), foreach(parallel), etc., without 
requiring more keywords.

The only thing better than that would be what Oskar said: to improve the 
compiler to the point that a construct like foreach(e; reversed(A)) 
could be as efficient as the current hard-coded foreach_reverse behavior.

--bb
May 17 2007
prev sibling next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 17 May 2007 10:58:36 -0700, Sean Kelly wrote:


 
 I still like:
 
 foreach - unordered?
 foreach(fwd) - explicitly forward
 foreach(rev) - explicitly reverse
 foreach(any) - unordered


I like this style of syntax for D too. The keyword "foreach_reverse"
doesn't go with the rest of D's style.

I also like the styles in which the order qualification is more visually
linked to the array reference itself. Something along the lines of ...

  foreach( elem, array.order.fwd)
  foreach( elem, array.order.rev)
  foreach( elem, array.order.none)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
18/05/2007 10:09:43 AM
May 17 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek nomail.afraid.org> wrote in message 
news:dabhxjbzr6ww$.1shkxsv5aswsm$.dlg 40tude.net...

 I also like the styles in which the order qualification is more visually
 linked to the array reference itself. Something along the lines of ...

  foreach( elem, array.order.fwd)
  foreach( elem, array.order.rev)
  foreach( elem, array.order.none)


I agree.

foreach(elem; array)(reverse)
{
    ...
}

Though that somehow looks a little disconnected.

foreach(elem; array; reverse)
{

}

Hm.

foreach(elem; array, "reverse")
{

}

oops, there's some MiniD.  ;)
May 17 2007
parent Pragma <ericanderton yahoo.removeme.com> writes:
Jarrett Billingsley wrote:

 Hm.
 
 foreach(elem; array, "reverse")
 {
 
 }
 
 oops, there's some MiniD.  ;) 
 


/me slaps Jarret with a trout labeled "shameless self promotion"

PS, try Enki. :p


-- 
- EricAnderton at yahoo
May 18 2007
prev sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
Sean Kelly wrote:

 Justin C Calvarese wrote:

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  
 "frr".
 "foreach_reverse" is too long as a keyword


 I agree that foreach_reverse is way too long for a keyword. Also, it 
 has that unslightly underscore.

 I think that frr is a little too short. Since it's a keyword that will 
 be rarely used, newcomers to D will likely get confused.

 I'm "voting" for foreachrev, but here's a whole list of decent 
 alternatives to the current "foreach_reverse" mess:

 1. foreachrev
 2. rforeach
 3. revforeach


 
 I still like:
 
 foreach - unordered?
 foreach(fwd) - explicitly forward
 foreach(rev) - explicitly reverse
 foreach(any) - unordered
 
 
 Sean


This has the additional benefit that when multi-processors 
become really common, D will have already built in a construct 
for parallelization...the any option.  I suppose that one 
*could* add a "parallelize" option, but that could *only* be 
advisory, and as such any is just as good.
May 18 2007
prev sibling next sibling parent "Jb" <jb nowhere.com> writes:
"Justin C Calvarese" <technocrat7 gmail.com> wrote in message 
news:f2i4gg$5op$1 digitalmars.com...

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with 
 "frr".
 "foreach_reverse" is too long as a keyword


 I agree that foreach_reverse is way too long for a keyword. Also, it has 
 that unslightly underscore.

 I think that frr is a little too short. Since it's a keyword that will be 
 rarely used, newcomers to D will likely get confused.

 I'm "voting" for foreachrev, but here's a whole list of decent 
 alternatives to the current "foreach_reverse" mess:

 1. foreachrev
 2. rforeach
 3. revforeach


4. reveach
May 17 2007
prev sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Justin C Calvarese Wrote:

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  "frr".
 "foreach_reverse" is too long as a keyword


 
 I agree that foreach_reverse is way too long for a keyword. Also, it has 
 that unslightly underscore.
 
 I think that frr is a little too short. Since it's a keyword that will 
 be rarely used, newcomers to D will likely get confused.
 
 I'm "voting" for foreachrev, but here's a whole list of decent 
 alternatives to the current "foreach_reverse" mess:
 
 1. foreachrev
 2. rforeach
 3. revforeach


The operator overloads use _r for the reverse version so there is precedent to
maybe reuse that here. eg.

opAdd and opAdd_r 

That said operator overloads never appear explicitly in code outside the class
definition so the 'ugly' underscore never gets seen.

foreach and foreach_r

I don't personally find the underscore ugly in the above case when it's only
followed by one letter 'r'.

Regan Heath
May 20 2007
parent reply Forest Ray <disto flying-guillotine.com> writes:
Regan Heath Wrote:


 Justin C Calvarese Wrote:

 YonggangLuo wrote:

 i think it's will be a good idea to replace "foreach_reverse" with  "frr".
 "foreach_reverse" is too long as a keyword


 
 I agree that foreach_reverse is way too long for a keyword. Also, it has 
 that unslightly underscore.
 
 I think that frr is a little too short. Since it's a keyword that will 
 be rarely used, newcomers to D will likely get confused.
 
 I'm "voting" for foreachrev, but here's a whole list of decent 
 alternatives to the current "foreach_reverse" mess:
 
 1. foreachrev
 2. rforeach
 3. revforeach


 
 The operator overloads use _r for the reverse version so there is precedent to
maybe reuse that here. eg.
 
 opAdd and opAdd_r 
 
 That said operator overloads never appear explicitly in code outside the class
definition so the 'ugly' underscore never gets seen.
 
 foreach and foreach_r
 
 I don't personally find the underscore ugly in the above case when it's only
followed by one letter 'r'.
 
 Regan Heath


I seriously doubt this keyword will ever change.  Personally, I would choose
the Algol-ish 'rofeach'.
There are many bigger issues with D right now, const-ness, AST, fixing the many
problems in the reference implimentation, creating a front end for gcc that the
FSF will accept as part
of the standard distribution, better language documentation (a correct,
COMPLETE BNF would be
nice), etc...  I appreciate all the hard work Walter is doing, but he was
really premature in calling the
language specification 1.0.  I am writing a real time embedded system
application using D and
often run into language deficiencies, const and volatile being the most
notable.  The reference
implimentation has many annoying problems, (issues with forward references not
working in all areas, offsetof not working in all areas, many others, yes I
submitted bug reports).  Submitted bug are not
addressed in a timely manner, I would recommend fixing existing problems before
creating new
features (with their own problems).  Compile time functions are cool, but
please fix some of the basic
problems first.  Walter has done a lot of great work and I appreciate it, but D
is no where near ready
for production use.  D is still too much of a risk for most companies to
consider using.

Forest
May 20 2007
parent Jeff <jeffrparsons optusnet.com.au> writes:
 a correct, COMPLETE BNF would be nice


Seconded. :)
May 21 2007