www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - foreach ... else statement

reply Brian <digitalmars brianguertin.com> writes:
any chance we could see something like pythons else statement on 
iterative loops in D (Might be useful on regular for loops too but not as 
much)?

http://docs.python.org/tutorial/controlflow.html#break-and-continue-
statements-and-else-clauses-on-loops
Jan 03 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Brian:

 any chance we could see something like pythons else statement on 
 iterative loops in D (Might be useful on regular for loops too but not as 
 much)?
 http://docs.python.org/tutorial/controlflow.html#break-and-continue-
 statements-and-else-clauses-on-loops


It seems everyone has ignored this post, but this isn't a proposal coming from
a clueless alien. Such "else" has a little but true purpose, it helps avoid
gotos in some situations, and this in turn may help the optimizer, because I
think gotos aren't much well digested by modern C/D compilers.

More on the topic:
http://leonardo-m.livejournal.com/2008/08/07/

Bye,
bearophile
Jan 04 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gjqpt0$1lr5$1 digitalmars.com...

 Brian:

 any chance we could see something like pythons else statement on
 iterative loops in D (Might be useful on regular for loops too but not as
 much)?
 http://docs.python.org/tutorial/controlflow.html#break-and-continue-
 statements-and-else-clauses-on-loops


 It seems everyone has ignored this post, but this isn't a proposal coming 
 from a clueless alien. Such "else" has a little but true purpose, it helps 
 avoid gotos in some situations, and this in turn may help the optimizer, 
 because I think gotos aren't much well digested by modern C/D compilers.

 More on the topic:
 http://leonardo-m.livejournal.com/2008/08/07/

 Bye,
 bearophile


I had never heard of that before, but it certainly seems like something I'd 
find useful. Any time I'm using for or foreach to find something, I end up 
having to use some sort of "isFound" flag and check that after the loop. A 
for...else would be much nicer, for example:

bool isFound=false;
foreach(char[] key, Foo f; fooAA)
{
    if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
    {
        isFound = true;
        break;
    }
}
if(!isFound)
    Stdout.formatln("Missing!");

// vs:

foreach(char[] key, Foo f; fooAA)
{
    if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
        break; // found
}
else
    Stdout.formatln("Missing!");

This could also be good in conjunction with a couple things that have been 
discussed for the future of D:

- Non-nullable references:
In the above example, if I wanted to introduce a "Foo theFoo" to hold the 
Foo that was found, I could normally eliminate the "isFound" flag, and just 
encode that information into theFoo as null vs. non-null. But this means 
that there would be no excess variable that could be eliminated by using 
for..else (in fact, the *only* change made by using for...else in this case 
would be "if(!theFoo)" -> "else"). This would make it seem like for...else 
would be useless in his case, but what if we had non-nullables and you 
wanted theFoo to be non-nullable? Then you'd have to either reintroduce the 
"isFound" flag or make theFoo nullable...or use "for...else".

- Increased emphasis on functional programming:
Eliminating that "isFound" means one less bit (pardon the pun) of mutable 
state.

Granted, it's a very small improvement in any case, and there are certainly 
plenty of features that would make a far bigger difference, but this would 
still be nice to have.
Jan 04 2009
next sibling parent reply Daniel de Kok <me nowhere.nospam> writes:
On Sun, 04 Jan 2009 14:01:41 -0500, Nick Sabalausky wrote:

 bool isFound=false;
 foreach(char[] key, Foo f; fooAA)
 {
     if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
     {
         isFound = true;
         break;
     }
 }
 if(!isFound)
     Stdout.formatln("Missing!");

 // vs:

 foreach(char[] key, Foo f; fooAA)
 {
      if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
          break; // found
 }
 else
     Stdout.formatln("Missing!");


[...]

 - Increased emphasis on functional programming: Eliminating that
 "isFound" means one less bit (pardon the pun) of mutable state.


It's a common pattern indeed, but I am not sure if this is the prettiest 
solution. The slightly awkward idiom in the first example is needed 
because a for loop is not a function you can return from. Wouldn't it be 
more adequate to rewrite this as a function/method that takes a predicate?

if (range.exists(predicate)) {}

or

if (exists(range, predicate) {}

-- Daniel
Jan 04 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Daniel de Kok:

Wouldn't it be more adequate to rewrite this as a function/method that takes a
predicate?<


In my dlibs there are things that allow to do that, but the code is slower.

---------------

BCS:


Wait, that's not the way I would expect else to work.<


See the answer by Guido V. R. himself to that post I have given the URL.



I think your expectation would be a good feature but I can't really see else
being the right keyword to use.<


I agree, with a better naming it can be good feature to have. (I don't like its
naming in Python too).

Bye,
bearophile
Jan 04 2009
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Nick,


 I had never heard of that before, but it certainly seems like
 something I'd find useful. Any time I'm using for or foreach to find
 something, I end up having to use some sort of "isFound" flag and
 check that after the loop. A for...else would be much nicer, for
 example:
 


[...]


 // vs:
 
 foreach(char[] key, Foo f; fooAA)
 {
 if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
 break; // found
 }
 else
 Stdout.formatln("Missing!");


Wait, that's not the way I would expect else to work. You (and and it would 
seem python) would have the else clause run if the loop is terminated by 
the for/foreach rater than a break/goto. I would expect that the else clause 
would be executed if the loop is terminated before the first iteration.

I think your expectation would be a good feature but I can't really see else 
being the right keyword to use. How about "finally"? Or another option with 
scope(*) like "fallthrough"?
Jan 04 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 05 Jan 2009 01:11:34 +0300, BCS <ao pathlink.com> wrote:


 Reply to Nick,


 I had never heard of that before, but it certainly seems like
 something I'd find useful. Any time I'm using for or foreach to find
 something, I end up having to use some sort of "isFound" flag and
 check that after the loop. A for...else would be much nicer, for
 example:


 [...]


 // vs:
  foreach(char[] key, Foo f; fooAA)
 {
 if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
 break; // found
 }
 else
 Stdout.formatln("Missing!");


 Wait, that's not the way I would expect else to work. You (and and it  
 would seem python) would have the else clause run if the loop is  
 terminated by the for/foreach rater than a break/goto. I would expect  
 that the else clause would be executed if the loop is terminated before  
 the first iteration.

 I think your expectation would be a good feature but I can't really see  
 else being the right keyword to use. How about "finally"? Or another  
 option with scope(*) like "fallthrough"?


Same here, I expected the for/else pair to work similar to if/else, i.e. only
one of the branches to be executed.
Perhaps I could get used to the syntax, though.
Jan 04 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
BCS:

 I think your expectation would be a good feature but I can't really see else 
 being the right keyword to use. How about "finally"? Or another option with 
 scope(*) like "fallthrough"?


The good thing of "else" is that you don't need a new keyword. But it's not
intuitive. A better keyword may make the code much more readable. For example:

foreach (key, f; fooAA)
    if (f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
        break;
    unbroken
        writefln("Missing!");

It looks a little silly, but I think it's easy to understand the meaning :-)
Bye,
bearophile
Jan 05 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Nick Sabalausky wrote:

 bool isFound=false;
 foreach(char[] key, Foo f; fooAA)
 {
     if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
     {
         isFound = true;
         break;
     }
 }
 if(!isFound)
     Stdout.formatln("Missing!");


foreach (a, b; aa)
    if (weLike(a, b)) goto found;
// else:
assert (false, "nothing we like!");
found:


I think my coworkers would kill me if I tried that.
Jan 05 2009
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Brian:

 any chance we could see something like pythons else statement on 
 iterative loops in D (Might be useful on regular for loops too but not as 
 much)?
 http://docs.python.org/tutorial/controlflow.html#break-and-continue-
 statements-and-else-clauses-on-loops


 
 It seems everyone has ignored this post, but this isn't a proposal coming from
a clueless alien. Such "else" has a little but true purpose, it helps avoid
gotos in some situations, and this in turn may help the optimizer, because I
think gotos aren't much well digested by modern C/D compilers.


Actually Walter loves goto, so DMD copes really well with it.
Jan 05 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

 Actually Walter loves goto, so DMD copes really well with it.


When possible it's better to use structured programming and avoid gotos. That
construct can avoid gotos in some common situations.
And regarding the compiler back-end, I think it's also better to start thinking
what's good for LDC :-)

Bye,
bearophile
Jan 05 2009
next sibling parent reply grauzone <none example.net> writes:
bearophile wrote:

 Don:

 Actually Walter loves goto, so DMD copes really well with it.


 
 When possible it's better to use structured programming and avoid gotos. That
construct can avoid gotos in some common situations.
 And regarding the compiler back-end, I think it's also better to start
thinking what's good for LDC :-)


I don't know how relevant this is, but: LLVM uses SSA for registers, and 
it seems to be simpler to convert code to SSA if there are no gotos:

"We show that it is possible to generate SSA form in a single pass (even 
during parsing) if the program contains only structured control flow 
(i.e., no gotos). For such programs the dominator tree can be built on 
the fly, too."

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4503

I also think that almost all common uses of gotos could be replaced by 
introducing some new statements for structured control flow. Like 
allowing the programmer to jump to the begin or end of a block using 
break/continue, similar to loops. For example, in the Linux kernel, they 
do the following for error handling:

void somefunction() {
	do_stuff();
	if (error)
		goto error_exit:
	do_more_stuff();

	return;

error_exit:
	handle_error();
}

This could be replaced by something like this:

void somefunction() {
	error_exit: {
		do_stuff();
  		if (error)
			break error_exit;
		do_more_stuff();

		return;
	}
	handle_error();
}

D's scope can do the same thing.
Jan 05 2009
next sibling parent reply Don <nospam nospam.com> writes:
grauzone wrote:

 bearophile wrote:

 Don:

 Actually Walter loves goto, so DMD copes really well with it.


 When possible it's better to use structured programming and avoid 
 gotos. That construct can avoid gotos in some common situations.
 And regarding the compiler back-end, I think it's also better to start 
 thinking what's good for LDC :-)


 
 I don't know how relevant this is, but: LLVM uses SSA for registers, and 
 it seems to be simpler to convert code to SSA if there are no gotos:
 
 "We show that it is possible to generate SSA form in a single pass (even 
 during parsing) if the program contains only structured control flow 
 (i.e., no gotos). For such programs the dominator tree can be built on 
 the fly, too."
 
 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4503


It's possible to create grotesque configurations of 'goto' which are 
extremely difficult to analyze. But most uses of goto are simple.


 I also think that almost all common uses of gotos could be replaced by 
 introducing some new statements for structured control flow. Like 
 allowing the programmer to jump to the begin or end of a block using 
 break/continue, similar to loops. For example, in the Linux kernel, they 
 do the following for error handling:
 
 void somefunction() {
     do_stuff();
     if (error)
         goto error_exit:
     do_more_stuff();
 
     return;
 
 error_exit:
     handle_error();
 }
 
 This could be replaced by something like this:
 
 void somefunction() {
     error_exit: {
         do_stuff();
          if (error)
             break error_exit;
         do_more_stuff();
 
         return;
     }
     handle_error();
 }
 
 D's scope can do the same thing.
Jan 05 2009
next sibling parent "Danny Wilson" <bluezenix gmail.com> writes:
foreach(languageStatement; AllProgrammingLanguages)
   Stdout.format(
     "It's possible to create grotesque configurations of '{}' which are "~
     "extremely difficult to analyze. But most uses of {} are simple.",
     languageStatement
   ).newline;
Jan 05 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 It's possible to create grotesque configurations of 'goto' which are 
 extremely difficult to analyze.


For a human, yes. For well-known optimization algorithms, no.
Jan 06 2009
prev sibling next sibling parent reply Brian <digitalmars brianguertin.com> writes:
On Mon, 05 Jan 2009 11:13:49 +0100, grauzone wrote:

 void somefunction() {
 	do_stuff();
 	if (error)
 		goto error_exit:
 	do_more_stuff();
 
 	return;
 
 error_exit:
 	handle_error();
 }
 
 This could be replaced by something like this:
 
 void somefunction() {
 	error_exit: {
 		do_stuff();
   		if (error)
 			break error_exit;
 		do_more_stuff();
 
 		return;
 	}
 	handle_error();
 }
 
 D's scope can do the same thing.


neither of those seem necessary in that example, whats wrong with this:
void somefunction() {
	do_stuff();
	if (error)
		handle_error();
	else
		do_more_stuff();
}
Jan 06 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Brian wrote:

 [snip]
 
 neither of those seem necessary in that example, whats wrong with this:
 void somefunction() {
 	do_stuff();
 	if (error)
 		handle_error();
 	else
 		do_more_stuff();
 }


A few things I can think of:

1. You're mixing error handling code with the other code.  This breaks 
the flow and makes the logic harder to follow.

2. If you've got more than one point in the function where you need to 
do error handling, then you're going to be duplicating code; error 
handlers are very rarely just a single function call.

3. The point was that execution "fell out" after the handler.  If you 
want to use conditionals, you can end up with really deeply indented 
code which is a bugger to read.

It's rather ironic, but one thing that struck me going from Visual Basic 
to Python was that VB had much nicer error handling; instead of having 
error handling all over the place, it was all localised to the end of 
the function.  This is why I absolutely adore scope statements.

Of course, you're technically correct; in that specific example, you 
could do it either way.  :)

   -- Daniel
Jan 06 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Daniel Keep Wrote:

 It's rather ironic, but one thing that struck me going from Visual Basic 
 to Python was that VB had much nicer error handling; instead of having 
 error handling all over the place, it was all localised to the end of 
 the function.  This is why I absolutely adore scope statements.


Like "on error resume next"...? ;-P
Jan 06 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Robert Fraser wrote:

 Daniel Keep Wrote:

 It's rather ironic, but one thing that struck me going from Visual Basic 
 to Python was that VB had much nicer error handling; instead of having 
 error handling all over the place, it was all localised to the end of 
 the function.  This is why I absolutely adore scope statements.


 
 Like "on error resume next"...? ;-P


While not the best practice, I'd take that any day over Java's insane 
"OMG THIS MIGHT THROW!!!!111oneoneone" mentality.

Seriously, javac; some times, I just don't care.

   -- Daniel
Jan 07 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:

 bearophile wrote:

 Don:

 Actually Walter loves goto, so DMD copes really well with it.


 When possible it's better to use structured programming and avoid 
 gotos. That construct can avoid gotos in some common situations.
 And regarding the compiler back-end, I think it's also better to start 
 thinking what's good for LDC :-)


 
 I don't know how relevant this is, but: LLVM uses SSA for registers, and 
 it seems to be simpler to convert code to SSA if there are no gotos:
 
 "We show that it is possible to generate SSA form in a single pass (even 
 during parsing) if the program contains only structured control flow 
 (i.e., no gotos). For such programs the dominator tree can be built on 
 the fly, too."
 
 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4503


I don't know what they're talking about. The D optimizer has no trouble 
whatsoever building dominator graphs, no matter what rat's nest of gotos 
are used. This technology was well understood in 1980.

In fact, the front end deconstructs *everything* into gotos, and that's 
all the optimizer works with.
Jan 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 grauzone wrote:

 bearophile wrote:

 Don:

 Actually Walter loves goto, so DMD copes really well with it.


 When possible it's better to use structured programming and avoid 
 gotos. That construct can avoid gotos in some common situations.
 And regarding the compiler back-end, I think it's also better to 
 start thinking what's good for LDC :-)


 I don't know how relevant this is, but: LLVM uses SSA for registers, 
 and it seems to be simpler to convert code to SSA if there are no gotos:

 "We show that it is possible to generate SSA form in a single pass 
 (even during parsing) if the program contains only structured control 
 flow (i.e., no gotos). For such programs the dominator tree can be 
 built on the fly, too."

 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4503


 
 I don't know what they're talking about. The D optimizer has no trouble 
 whatsoever building dominator graphs, no matter what rat's nest of gotos 
 are used. This technology was well understood in 1980.
 
 In fact, the front end deconstructs *everything* into gotos, and that's 
 all the optimizer works with.


The challenge the paper addresses is constructing the SSA form in one 
shot. There are indeed algorithms that build the SSA in several passes.

My vague recollection from a compiler construction class is that there 
are a number of static analyses that need to do a fixed-point 
computation on loops. Such analyses can deal with any jumps except a 
particular one: jump forward from the outside of a loop in the middle of 
it. Does anyone know what analyses were those?


Andrei
Jan 06 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 The challenge the paper addresses is constructing the SSA form in one 
 shot. There are indeed algorithms that build the SSA in several passes.
 
 My vague recollection from a compiler construction class is that there 
 are a number of static analyses that need to do a fixed-point 
 computation on loops. Such analyses can deal with any jumps except a 
 particular one: jump forward from the outside of a loop in the middle of 
 it. Does anyone know what analyses were those?


The two-entry-points-to-a-loop is the essential characteristic of an 
"irreducible flow graph". Such can be transformed into reducible ones, 
but it is not worth the effort because such are fairly rare, even in 
spaghetti goto code.

<nose-in-air>I've known for 25 years that it's freaking easy to do 
optimizations if you can assume there are no goto's. But you wind up 
with a crippled compiler technology suitable only for toy languages. 
That's why real compilers aren't written that way.</nose-in-air>

I only read part of the paper, but I don't see the point of it.
Jan 06 2009
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Don:

 Actually Walter loves goto, so DMD copes really well with it.


 
 When possible it's better to use structured programming and avoid gotos.


Structured programming does not mean no gotos. You should really read 
the original paper "Goto considered harmful", you'll find it's actually 
about the evil of spaghetti code, such as in BASIC. In C 
family-languages, including D, there is no spaghetti goto. So actually 
it's nearly impossible to abuse goto in D in the way that the original 
paper was talking about.

I still avoid goto because I was told to. But eventually I realised that 
it's 100% propaganda. I actually think my code would be cleaner if I 
used it; it would allow lots of local flag variables to be eliminated.
But I still have this residual prejudice against 'goto' which is really 
hard to get rid of.


 That construct can avoid gotos in some common situations.



 And regarding the compiler back-end, I think it's also better to start
thinking what's good for LDC :-)


Yes, but I doubt any compiler would have a problem with goto.


 
 Bye,
 bearophile
Jan 05 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 I still avoid goto because I was told to. But eventually I realised that 
 it's 100% propaganda. I actually think my code would be cleaner if I 
 used it; it would allow lots of local flag variables to be eliminated.
 But I still have this residual prejudice against 'goto' which is really 
 hard to get rid of.


The problem with goto is it is easy to get into a human readability 
problem with it. No such problem exists for optimization algorithms.



 Yes, but I doubt any compiler would have a problem with goto.


The last time I even heard of a compiler that fell over and gave up 
optimizing if it saw a goto was in the early 80's. I have a hard time 
believing LDC has problems with it, but if it does, the authors should 
hit the books <g>.

I keep thinking I should put on a "Compiler Construction" seminar!

P.S. There are problems with goto'ing out of a finally block, and 
there's a problem in the optimizer with goto'ing from one try block to 
another, but that's not the issue here.
Jan 06 2009
next sibling parent Benji Smith <dlanguage benjismith.net> writes:
Walter Bright wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


Sign me up!
Jan 06 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Walter,


 I keep thinking I should put on a "Compiler Construction" seminar!
 


That would be fun. If I could, I'd show up.
Jan 06 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Don wrote:

 I still avoid goto because I was told to. But eventually I realised that
 it's 100% propaganda. I actually think my code would be cleaner if I
 used it; it would allow lots of local flag variables to be eliminated.
 But I still have this residual prejudice against 'goto' which is really
 hard to get rid of.


 The problem with goto is it is easy to get into a human readability
 problem with it. No such problem exists for optimization algorithms.

 Yes, but I doubt any compiler would have a problem with goto.


 The last time I even heard of a compiler that fell over and gave up
 optimizing if it saw a goto was in the early 80's. I have a hard time
 believing LDC has problems with it, but if it does, the authors should
 hit the books <g>.


goto's jump to a label, so it's not like the compiler has no idea where
entry points might be, anyway.  And in the extreme case of languages
with inline asm containing jump-to-address operations, I would think
that the address would have to be computed at run-time, which is
obviously after any optimization has been done.  I suppose I'm
failing to see the problem with goto's, assuming a structured language
like D (as opposed to goto's in BASIC).


 I keep thinking I should put on a "Compiler Construction" seminar!


You should.  The academic courses do a good job with theory and
general application, but that isn't quite the same as one based on
practical experience.


Sean
Jan 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


 
 You should.  The academic courses do a good job with theory and
 general application, but that isn't quite the same as one based on
 practical experience.


That's true. I learned the theory taking a compiler construction course 
at Standford, and then tried to apply it. It turns out that there's a 
lot they left out <g> that's needed to actually get those optimizations 
to work.

Loop induction variables was a big one, because the theory never takes 
into account the fact that you're replacing a signed loop index with an 
unsigned loop pointer. Oops!

It's like in physics class you're always dealing with frictionless 
brakes and pointless masses.
Jan 07 2009
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Sean Kelly wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


 You should.  The academic courses do a good job with theory and
 general application, but that isn't quite the same as one based on
 practical experience.


 That's true. I learned the theory taking a compiler construction course at
 Standford, and then tried to apply it. It turns out that there's a lot they
 left out <g> that's needed to actually get those optimizations to work.

 Loop induction variables was a big one, because the theory never takes into
 account the fact that you're replacing a signed loop index with an unsigned
 loop pointer. Oops!

 It's like in physics class you're always dealing with frictionless brakes
 and pointless masses.


You mean massless points?  Or was that deliberate?

--bb
Jan 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Sean Kelly wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


 You should.  The academic courses do a good job with theory and
 general application, but that isn't quite the same as one based on
 practical experience.


 That's true. I learned the theory taking a compiler construction course at
 Standford, and then tried to apply it. It turns out that there's a lot they
 left out <g> that's needed to actually get those optimizations to work.

 Loop induction variables was a big one, because the theory never takes into
 account the fact that you're replacing a signed loop index with an unsigned
 loop pointer. Oops!

 It's like in physics class you're always dealing with frictionless brakes
 and pointless masses.


 
 You mean massless points?  Or was that deliberate?


I think there were two jokes actually: frictionless brakes (used instead 
of e.g. frictionless pulleys) which is an oxymoron, and a pun on point 
masses (objects that can be approximated by a point).

Andrei
Jan 07 2009
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Jan 8, 2009 at 6:46 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Sean Kelly wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


 You should.  The academic courses do a good job with theory and
 general application, but that isn't quite the same as one based on
 practical experience.


 That's true. I learned the theory taking a compiler construction course
 at
 Standford, and then tried to apply it. It turns out that there's a lot
 they
 left out <g> that's needed to actually get those optimizations to work.

 Loop induction variables was a big one, because the theory never takes
 into
 account the fact that you're replacing a signed loop index with an
 unsigned
 loop pointer. Oops!

 It's like in physics class you're always dealing with frictionless brakes
 and pointless masses.


 You mean massless points?  Or was that deliberate?


 I think there were two jokes actually: frictionless brakes (used instead of
 e.g. frictionless pulleys) which is an oxymoron, and a pun on point masses
 (objects that can be approximated by a point).


Hmmm.  Oh yeh.  I'm gonna claim lack of my first morning cup o coffee
as my excuse for missing that.
Cute.

--bb
Jan 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 On Thu, Jan 8, 2009 at 6:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Sean Kelly wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


 You should.  The academic courses do a good job with theory and
 general application, but that isn't quite the same as one based on
 practical experience.


 That's true. I learned the theory taking a compiler construction course
 at
 Standford, and then tried to apply it. It turns out that there's a lot
 they
 left out <g> that's needed to actually get those optimizations to work.

 Loop induction variables was a big one, because the theory never takes
 into
 account the fact that you're replacing a signed loop index with an
 unsigned
 loop pointer. Oops!

 It's like in physics class you're always dealing with frictionless brakes
 and pointless masses.


 You mean massless points?  Or was that deliberate?


 I think there were two jokes actually: frictionless brakes (used instead of
 e.g. frictionless pulleys) which is an oxymoron, and a pun on point masses
 (objects that can be approximated by a point).


 
 Hmmm.  Oh yeh.  I'm gonna claim lack of my first morning cup o coffee
 as my excuse for missing that.
 Cute.


School physics problems always start out with "assume there is no 
friction, and the point has no mass."

Academic papers on compiler optimizations always start out with "assume 
there are no pointers, no references, no arrays, no exceptions, no 
threads, no aliasing, no overflows, no signed/unsigned, there are 
infinite registers available, registers are orthogonal, etc." Or they 
just go ahead and let you discover that they assumed that. Useful 
languages are a lot messier in the real world.
Jan 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 On Thu, Jan 8, 2009 at 6:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Sean Kelly wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


 You should.  The academic courses do a good job with theory and
 general application, but that isn't quite the same as one based on
 practical experience.


 That's true. I learned the theory taking a compiler construction 
 course
 at
 Standford, and then tried to apply it. It turns out that there's a lot
 they
 left out <g> that's needed to actually get those optimizations to 
 work.

 Loop induction variables was a big one, because the theory never takes
 into
 account the fact that you're replacing a signed loop index with an
 unsigned
 loop pointer. Oops!

 It's like in physics class you're always dealing with frictionless 
 brakes
 and pointless masses.


 You mean massless points?  Or was that deliberate?


 I think there were two jokes actually: frictionless brakes (used 
 instead of
 e.g. frictionless pulleys) which is an oxymoron, and a pun on point 
 masses
 (objects that can be approximated by a point).


 Hmmm.  Oh yeh.  I'm gonna claim lack of my first morning cup o coffee
 as my excuse for missing that.
 Cute.


 
 School physics problems always start out with "assume there is no 
 friction, and the point has no mass."
 
 Academic papers on compiler optimizations always start out with "assume 
 there are no pointers, no references, no arrays, no exceptions, no 
 threads, no aliasing, no overflows, no signed/unsigned, there are 
 infinite registers available, registers are orthogonal, etc." Or they 
 just go ahead and let you discover that they assumed that.


Well that should be taken with the traditional grain of salt.

Andrei
Jan 07 2009
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Jan 8, 2009 at 10:28 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 On Thu, Jan 8, 2009 at 6:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Sean Kelly wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


 You should.  The academic courses do a good job with theory and
 general application, but that isn't quite the same as one based on
 practical experience.


 That's true. I learned the theory taking a compiler construction
 course
 at
 Standford, and then tried to apply it. It turns out that there's a lot
 they
 left out <g> that's needed to actually get those optimizations to
 work.

 Loop induction variables was a big one, because the theory never takes
 into
 account the fact that you're replacing a signed loop index with an
 unsigned
 loop pointer. Oops!

 It's like in physics class you're always dealing with frictionless
 brakes
 and pointless masses.


 You mean massless points?  Or was that deliberate?


 I think there were two jokes actually: frictionless brakes (used instead
 of
 e.g. frictionless pulleys) which is an oxymoron, and a pun on point
 masses
 (objects that can be approximated by a point).


 Hmmm.  Oh yeh.  I'm gonna claim lack of my first morning cup o coffee
 as my excuse for missing that.
 Cute.


 School physics problems always start out with "assume there is no
 friction, and the point has no mass."

 Academic papers on compiler optimizations always start out with "assume
 there are no pointers, no references, no arrays, no exceptions, no threads,
 no aliasing, no overflows, no signed/unsigned, there are infinite registers
 available, registers are orthogonal, etc." Or they just go ahead and let you
 discover that they assumed that.


 Well that should be taken with the traditional grain of salt.


In my experience just about any academic paper has to be digest with a
large grain of salt.
Most of the ones I have become intimately familiar with have big
limitations not mentioned by the authors that only become apparent
once you start trying to repeat what they did.  But maybe graphics
papers are particularly susceptible to this phenomenon.   A typical
graphics paper shows three or four nice results, and says "see look!
it works!", but unfortunately that's no proof of general
effectiveness.  It just proves it works for those 3-4 images.

--bb
Jan 07 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 Walter Bright wrote:

 Academic papers on compiler optimizations always start out with 
 "assume there are no pointers, no references, no arrays, no 
 exceptions, no threads, no aliasing, no overflows, no signed/unsigned, 
 there are infinite registers available, registers are orthogonal, 
 etc." Or they just go ahead and let you discover that they assumed that.


 
 Well that should be taken with the traditional grain of salt.


Some are better than others, sure. I found out the hard way. But even in 
the paper cited in this thread:

"We do not deal here with alias problems caused by assignments to array 
elements, to parameters passed by reference, and to variables that are 
referenced via pointers. These problems can be dealt with in the same 
way as described in [5]."

and this:

"This is useful for languages such as Simula[3], Modula-2 [13] or Oberon 
[14] that lack goto statements at all."

Who uses Simula, Modula-2 or Oberon?
Jan 07 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Walter Bright wrote:

 Academic papers on compiler optimizations always start out with 
 "assume there are no pointers, no references, no arrays, no 
 exceptions, no threads, no aliasing, no overflows, no 
 signed/unsigned, there are infinite registers available, registers 
 are orthogonal, etc." Or they just go ahead and let you discover that 
 they assumed that.


 Well that should be taken with the traditional grain of salt.


 
 Some are better than others, sure. I found out the hard way. But even in 
 the paper cited in this thread:
 
 "We do not deal here with alias problems caused by assignments to array 
 elements, to parameters passed by reference, and to variables that are 
 referenced via pointers. These problems can be dealt with in the same 
 way as described in [5]."
 
 and this:
 
 "This is useful for languages such as Simula[3], Modula-2 [13] or Oberon 
 [14] that lack goto statements at all."
 
 Who uses Simula, Modula-2 or Oberon?


Without saying anything about this paper in particular, quality of 
research papers has a very top-heavy distribution. Outside a few 
conference proceedings and journals, where only a few institutions 
publish, the quality of research publications decreases drastically.

Andrei
Jan 07 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright

 It's like in physics class you're always dealing with frictionless brakes
 and pointless masses.


 
 You mean massless points?  Or was that deliberate?


I wondered if anyone would notice that (!). Yes, it's deliberate.
Jan 07 2009
parent BCS <ao pathlink.com> writes:
Reply to Walter,


 Bill Baxter wrote:
 

 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 

 It's like in physics class you're always dealing with frictionless
 brakes and pointless masses.
 


 You mean massless points?  Or was that deliberate?
 


 I wondered if anyone would notice that (!). Yes, it's deliberate.
 


OTOH test often have their share of red harring as well!
Jan 07 2009
prev sibling next sibling parent reply "Tomas Lindquist Olsen" <tomas.l.olsen gmail.com> writes:
Content-Disposition: inline

On Wed, Jan 7, 2009 at 6:07 AM, Walter Bright <newshound1 digitalmars.com>wrote:


 Don wrote:


 I still avoid goto because I was told to. But eventually I realised that
 it's 100% propaganda. I actually think my code would be cleaner if I used
 it; it would allow lots of local flag variables to be eliminated.
 But I still have this residual prejudice against 'goto' which is really
 hard to get rid of.


 The problem with goto is it is easy to get into a human readability problem
 with it. No such problem exists for optimization algorithms.


  Yes, but I doubt any compiler would have a problem with goto.


 The last time I even heard of a compiler that fell over and gave up
 optimizing if it saw a goto was in the early 80's. I have a hard time
 believing LDC has problems with it, but if it does, the authors should hit
 the books <g>.


It doesn't :P



 I keep thinking I should put on a "Compiler Construction" seminar!

 P.S. There are problems with goto'ing out of a finally block, and there's a
 problem in the optimizer with goto'ing from one try block to another, but
 that's not the issue here.





 Jan 07 2009



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Tomas Lindquist Olsen wrote:

 On Wed, Jan 7, 2009 at 6:07 AM, Walter Bright 
     The last time I even heard of a compiler that fell over and gave up
     optimizing if it saw a goto was in the early 80's. I have a hard
     time believing LDC has problems with it, but if it does, the authors
     should hit the books <g>.
 
 
 It doesn't :P


That's good to hear!



 Jan 07 2009



prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com>  writes:


Walter Bright wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


*cough* NWCPP *cough*



 Jan 07 2009



  parent reply Walter Bright <newshound1 digitalmars.com>  writes:


Robert Fraser wrote:

 Walter Bright wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


 
 *cough* NWCPP *cough*


I'd like to do a paid one <g>.

BTW, Bartosz has graciously offered the Jan NWCPP speaking engagement to 
me. I'll be talking about mixins and templates. All are welcome, of course.



 Jan 07 2009



  parent reply BCS <ao pathlink.com>  writes:


Reply to Walter,


 Robert Fraser wrote:
 

 Walter Bright wrote:
 

 I keep thinking I should put on a "Compiler Construction" seminar!
 


 *cough* NWCPP *cough*
 


 I'd like to do a paid one <g>.
 
 BTW, Bartosz has graciously offered the Jan NWCPP speaking engagement
 to me. I'll be talking about mixins and templates. All are welcome, of
 course.
 


Video! Video!   ?? (for those of us not in Seattle)



 Jan 08 2009



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


BCS wrote:

 Reply to Walter,
 

 Robert Fraser wrote:


 Walter Bright wrote:


 I keep thinking I should put on a "Compiler Construction" seminar!


 *cough* NWCPP *cough*


 I'd like to do a paid one <g>.

 BTW, Bartosz has graciously offered the Jan NWCPP speaking engagement
 to me. I'll be talking about mixins and templates. All are welcome, of
 course.


 
 Video! Video!   ?? (for those of us not in Seattle)


See www.nwcpp.org. Ask Bartosz!



 Jan 08 2009



prev sibling  parent reply "Rioshin an'Harthen" <rharth75 hotmail.com>  writes:


"Walter Bright" <newshound1 digitalmars.com> kirjoitti viestissä 
news:gk1dag$ptn$1 digitalmars.com...

 I keep thinking I should put on a "Compiler Construction" seminar!


A net-seminar, please, so that those of us who want to attend actually can. 



 Jan 08 2009



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


"Rioshin an'Harthen" <rharth75 hotmail.com> wrote in message 
news:gk4kfh$ri3$1 digitalmars.com...

 "Walter Bright" <newshound1 digitalmars.com> kirjoitti viestissä 
 news:gk1dag$ptn$1 digitalmars.com...

 I keep thinking I should put on a "Compiler Construction" seminar!


 A net-seminar, please, so that those of us who want to attend actually 
 can.


Yes :). Things like this never make their way out to Cleveland (or anywhere 
within a three-hour drive, which is about the max I could realistically do).

(Heck, *decent* programmers are never out this way.) 



 Jan 08 2009



  parent reply Walter Bright <newshound1 digitalmars.com>  writes:


Nick Sabalausky wrote:

 "Rioshin an'Harthen" <rharth75 hotmail.com> wrote in message 
 news:gk4kfh$ri3$1 digitalmars.com...

 "Walter Bright" <newshound1 digitalmars.com> kirjoitti viestissä 
 news:gk1dag$ptn$1 digitalmars.com...

 I keep thinking I should put on a "Compiler Construction" seminar!


 A net-seminar, please, so that those of us who want to attend actually 
 can.


 
 Yes :). Things like this never make their way out to Cleveland (or anywhere 
 within a three-hour drive, which is about the max I could realistically do).
 
 (Heck, *decent* programmers are never out this way.) 


When we did the Astoria Seminar in 2007, the consistent feedback was 
that what the attendees liked most was the ambiance and getting together 
with like-minded professionals and face time with experts. I do think 
that the one-on-one in person is an essential ingredient to making 
seminars a valuable experience.



 Jan 08 2009



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


"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gk6150$n63$1 digitalmars.com...

 Nick Sabalausky wrote:

 "Rioshin an'Harthen" <rharth75 hotmail.com> wrote in message 
 news:gk4kfh$ri3$1 digitalmars.com...

 "Walter Bright" <newshound1 digitalmars.com> kirjoitti viestissä 
 news:gk1dag$ptn$1 digitalmars.com...

 I keep thinking I should put on a "Compiler Construction" seminar!


 A net-seminar, please, so that those of us who want to attend actually 
 can.


 Yes :). Things like this never make their way out to Cleveland (or 
 anywhere within a three-hour drive, which is about the max I could 
 realistically do).

 (Heck, *decent* programmers are never out this way.)


 When we did the Astoria Seminar in 2007, the consistent feedback was that 
 what the attendees liked most was the ambiance and getting together with 
 like-minded professionals and face time with experts. I do think that the 
 one-on-one in person is an essential ingredient to making seminars a 
 valuable experience.


Agreed. Which is why it's dissapointing that any good programming-related 
stuff is usually too far for me. I know a lot of people travel large 
distances for many of these things, but I'm rarely able spend the money on 
the travel and lodging. But videos are better than nothing though. 



 Jan 08 2009