View mode: basic / threaded / horizontal-split · Log in · Help
October 19, 2006
foreach, an analogy
I like analogies, so here goes one.  If you don't just skip it.  :-)

Say you've built a house and you're almost done, but you find one 
doorway with a door that's about an inch too narrow for the frame. 
You'd really like to cover that gap somehow.  You could just leave it 
as-is.  Sure.  You've got *most* of the doorway covered after all.  It's 
not like a criminal could sneak in through a one-inch gap.  Still, it 
could get pretty cold in the winter, so you'd really like to fix it.

Clearly the best solution long term is to get a bigger door.

But you don't have a bigger door.  You do, however, have a clever 
solution: take another door, identical to the first, and hang it on the 
*other side* of the frame to cover the gap.  Perfect!  The gap is covered!

But hmm.  Now there are two doors.  Either of them alone *almost* enough 
to cover the doorway.  You don't really _need_ two doors doing almost 
exactly the same thing.

It's not so bad, though.  At least in the summer, when you don't need 
it, you can just leave that second door open and out of the way. Even 
take it off its hinges and put it in the basement.

That second door, as I'm sure you've figured out, is foreach_reverse.

And really I do believe it's not so bad.  It's an ugly hack, like 
hanging a second door to fill a small gap, but if you don't want to 
iterate backwards over arrays as fast as possible, then you're free to 
ignore it, put that door in the basement, and use whatever technique you 
prefer.

However, I still hope the plan is to one day get a bigger door.

--bb
October 19, 2006
Re: foreach, an analogy
Bill Baxter wrote:

> And really I do believe it's not so bad.  It's an ugly hack, like 
> hanging a second door to fill a small gap, 

Sorry, my apologies to Walter.  Let me take that bit back.  "Ugly hack" 
is way too strong.  I should have said "it's a band-aid". 
foreach_reverse does solve a legitimate problem.  But just like a 
band-aid, you hope to be able to take it off eventually.

--bb
October 19, 2006
Re: foreach, an analogy
Bill Baxter wrote:

> I like analogies, so here goes one.  If you don't just skip it.  :-)
> 
> Say you've built a house and you're almost done, but you find one
> doorway with a door that's about an inch too narrow for the frame.
> You'd really like to cover that gap somehow.  You could just leave it
> as-is.  Sure.  You've got *most* of the doorway covered after all.  It's
> not like a criminal could sneak in through a one-inch gap.  Still, it
> could get pretty cold in the winter, so you'd really like to fix it.
> 
> Clearly the best solution long term is to get a bigger door.
> 
> But you don't have a bigger door.  You do, however, have a clever
> solution: take another door, identical to the first, and hang it on the
> *other side* of the frame to cover the gap.  Perfect!  The gap is covered!
> 
> But hmm.  Now there are two doors.  Either of them alone *almost* enough
> to cover the doorway.  You don't really _need_ two doors doing almost
> exactly the same thing.
> 
> It's not so bad, though.  At least in the summer, when you don't need
> it, you can just leave that second door open and out of the way. Even
> take it off its hinges and put it in the basement.
> 
> That second door, as I'm sure you've figured out, is foreach_reverse.
> 
> And really I do believe it's not so bad.  It's an ugly hack, like
> hanging a second door to fill a small gap, but if you don't want to
> iterate backwards over arrays as fast as possible, then you're free to
> ignore it, put that door in the basement, and use whatever technique you
> prefer.
> 
> However, I still hope the plan is to one day get a bigger door.
> 
> --bb

What is your "bigger door"?

-- 
~John Demme
me@teqdruid.com
http://www.teqdruid.com/
October 19, 2006
Re: foreach, an analogy
Bill Baxter wrote:
> I like analogies, so here goes one.  If you don't just skip it.  :-)
> 
> Say you've built a house and you're almost done, but you find one 
> doorway with a door that's about an inch too narrow for the frame. You'd 
> really like to cover that gap somehow.  You could just leave it as-is.  
> Sure.  You've got *most* of the doorway covered after all.  It's not 
> like a criminal could sneak in through a one-inch gap.  Still, it could 
> get pretty cold in the winter, so you'd really like to fix it.
> 
> Clearly the best solution long term is to get a bigger door.
> 
> But you don't have a bigger door.  You do, however, have a clever 
> solution: take another door, identical to the first, and hang it on the 
> *other side* of the frame to cover the gap.  Perfect!  The gap is covered!
> 
> But hmm.  Now there are two doors.  Either of them alone *almost* enough 
> to cover the doorway.  You don't really _need_ two doors doing almost 
> exactly the same thing.
> 
> It's not so bad, though.  At least in the summer, when you don't need 
> it, you can just leave that second door open and out of the way. Even 
> take it off its hinges and put it in the basement.
> 
> That second door, as I'm sure you've figured out, is foreach_reverse.
> 
> And really I do believe it's not so bad.  It's an ugly hack, like 
> hanging a second door to fill a small gap, but if you don't want to 
> iterate backwards over arrays as fast as possible, then you're free to 
> ignore it, put that door in the basement, and use whatever technique you 
> prefer.
> 
> However, I still hope the plan is to one day get a bigger door.
> 
> --bb

The bigger door is 'for'.  'foreach' is nothing but a convenient wrapper 
around 'for'.  And don't you OOphiles go telling me that your fancy 
class foo that has iteration /needs/ 'foreach':
  for (auto bar = foo.begin(); !(bar is null); bar = foo.iterate(bar))
Is it less pretty than foreach?  Yeah.  That's why foreach exists.  But 
don't go saying that the reverse foreach is a band-aid patch, because 
both forms are just convenience wrappers around the far more powerful 
and useful 'for'.  Your small door is actually the screen door.

 - Gregor Richards
October 19, 2006
Re: foreach, an analogy
John Demme wrote:
> Bill Baxter wrote:
> ...
>> However, I still hope the plan is to one day get a bigger door.
>>
>> --bb
> 
> What is your "bigger door"?
> 

I think it may be Ruby blocks.

But the point is "one day".  It can be a D 2.0 thing.

--bb
October 19, 2006
Re: foreach, an analogy
Gregor Richards wrote:
> Bill Baxter wrote:

> The bigger door is 'for'.  'foreach' is nothing but a convenient wrapper 
> around 'for'.  And don't you OOphiles go telling me that your fancy 
> class foo that has iteration /needs/ 'foreach':
>   for (auto bar = foo.begin(); !(bar is null); bar = foo.iterate(bar))
> Is it less pretty than foreach?  Yeah.  That's why foreach exists. 

:-)  Heh heh.

> But 
> don't go saying that the reverse foreach is a band-aid patch, because
> both forms are just convenience wrappers around the far more powerful 
> and useful 'for'.  

Yeh, for is like a piece of wood.  You can do anything with it. 
Including make a door.  But sometimes its better just to have the door 
pre-made.

> Your small door is actually the screen door.

Lots of little holes?  Maybe.  But screen doors have their uses too.
Much better for the summertime to help make the livin' easy. ;-)

--bb
October 19, 2006
Re: foreach, an analogy
Gregor Richards wrote:

> The bigger door is 'for'.  'foreach' is nothing but a convenient wrapper 
> around 'for'.  And don't you OOphiles go telling me that your fancy 
> class foo that has iteration /needs/ 'foreach':
>   for (auto bar = foo.begin(); !(bar is null); bar = foo.iterate(bar))
> Is it less pretty than foreach?  Yeah.  That's why foreach exists.  

Actually, you've got a point there, sort of.  Iterating over *arrays* 
with for is really really not that bad.

   for (int i=0; i<x.length; i++) {
      something(x[i]);
   }

That kind of thing never made me want to run screaming to find a new 
career while doing C++ programming.

But this:
  for (auto bar = foo.begin(); !(bar is null); bar = foo.iterate(bar))
  {   something(bar)
  }
would.  Yeh, the auto makes it a big improvement over current C++.  But 
still, it's annoyingly long for something that happens so frequently.

I really can't stand ugly STL for's anymore after working with Python 
for a while.   But Python doesn't do everything I need.  It's not fast. 
 That's why I'm here.

--bb
October 19, 2006
Re: foreach, an analogy
"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message 
news:eh6rva$1anj$2@digitaldaemon.com...

> I think it may be Ruby blocks.

They're just anonymous functions which happen to come after the function 
call's closing paren.. I wouldn't really say that they're incredibly 
earth-shattering or the answer to everything.  And D can almost do them 
already.  Instead of:

something.each do |item|
   puts item
end

You can have:

something.each((int item) {
   writefln(item);
});

In fact the "allowing a trailing function literal" has been proposed (by 
myself included), which would allow:

something.each()(int item)
{
   writefln(item);
}
// maybe there'd need to be a semicolon here?

Which is damn close if you ask me.
October 19, 2006
ruby blocks (Re: foreach, an analogy)
Jarrett Billingsley wrote:
> "Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message 
> news:eh6rva$1anj$2@digitaldaemon.com...
> 
>> I think it may be Ruby blocks.
> 
> They're just anonymous functions which happen to come after the function 
> call's closing paren.. I wouldn't really say that they're incredibly 
> earth-shattering or the answer to everything.  

We don't need the answer to everything, just the answer to how to 
generalize and make foreach more consistent.

> And D can almost do them
> already.  Instead of:
> 
> something.each do |item|
>     puts item
> end
> 
> You can have:
> 
> something.each((int item) {
>     writefln(item);
> });
> 
> In fact the "allowing a trailing function literal" has been proposed (by 
> myself included), which would allow:
> 
> something.each()(int item)
> {
>     writefln(item);
> }
> // maybe there'd need to be a semicolon here?
> 
> Which is damn close if you ask me. 

That does look pretty good.
How do you write an inorder traverser?  With Ruby:

def traverse
  left.traverse {|node| yield node }
  yield self
  right.traverse {|node| yield node }
end

Then you do:

atree.traverse()(Node node)
{
    writefln(item);
}


--bb
October 19, 2006
Re: foreach, an analogy
On Wed, 18 Oct 2006 20:43:13 -0700, Bill Baxter  
<dnewsgroup@billbaxter.com> wrote:

> Gregor Richards wrote:
>> Bill Baxter wrote:
>
>> The bigger door is 'for'.  'foreach' is nothing but a convenient  
>> wrapper around 'for'.  And don't you OOphiles go telling me that your  
>> fancy class foo that has iteration /needs/ 'foreach':
>>   for (auto bar = foo.begin(); !(bar is null); bar = foo.iterate(bar))
>> Is it less pretty than foreach?  Yeah.  That's why foreach exists.
>
> :-)  Heh heh.
>
>> But don't go saying that the reverse foreach is a band-aid patch,  
>> because
>> both forms are just convenience wrappers around the far more powerful  
>> and useful 'for'.
>
> Yeh, for is like a piece of wood.  You can do anything with it.  
> Including make a door.  But sometimes its better just to have the door  
> pre-made.
>
>> Your small door is actually the screen door.
>
> Lots of little holes?  Maybe.  But screen doors have their uses too.
> Much better for the summertime to help make the livin' easy. ;-)
>
> --bb


Don't screen doors keep the bugs out? ;)


-JJR
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home