dmd 2.029 release

[Charles Hixson]

Georg Wrede wrote:
> Don wrote:
>> Georg Wrede wrote:
>>> Don wrote:
>>>> Georg Wrede wrote:
>>>>> Walter Bright wrote:
>>>>>> Lutger wrote:
>>>>>>> what the hell...this code can't be human.
>>>>>>
>>>>>> I was replaced by Colossus years ago.
>>>>>
>>>>> Michael A. Jackson wouldn't approve 1175 gotos in 113 files.
>>>>
>>>> It'd be really funny to pass it through one of those "code quality" 
>>>> metrics, one of the ones with a ridiculously heavy penalty for using 
>>>> goto. I think it'd tell you that DMD source is almost the 
>>>> lowest-quality code on the planet. <g>
>>>
>>> Yeah. But now I'm getting a bad conscience, this is beginning to look 
>>> like Walter-bashing... :-)
>>
>> I think those code quality metrics are ridiculous. The prejudice 
>> against 'goto' is really just brainwashing and totally without basis.
> 
> Well, at the time, they had no choice. Unstructured code was the norm, 
> and people who tangled themselves in spaghetti never noticed it's 
> because of goto usage. Instead they just preceived programming as hard.
> 
> The language on my first computer was old fashioned BASIC, with line 
> numbers and no named subroutines or structural elements. I felt that the 
> effort needed to program was exponential to the number of lines. In 
> hindsight, that must have been entirely because I'd had no higher 
> education in programming, no notion of structuring the code (in any 
> particular way), etc. But the absolutely worst thing was that one 
> couldn't pass parameters to subroutines. (gosub <lineNumber>) And all 
> variables were global.
> 
> In those days most programming was done in COBOL, by (essentially) 
> non-programmers. (The idea of COBOL was, after all, to be usable by 
> business people, not MSc programmers.) Jackson had to change not only 
> the methodology, but before that, the concept and the motivation for 
> using structured programming. That was the hard part, and it needed some 
> serious evangelising and brainwashing, to overcome the inertia.
> 
> Unfortunately, that meant murdering, dismembering, and pulverizing any 
> least hint of even thinking about using goto. And as with any paradigm 
> shift, the disciples took it to religious extremes.
> 
>> Here's a recent link from Andrew Koenig, who really should know better.
>>
>> http://dobbscodetalk.com/index.php?option=com_myblog&show=What-Dijkstra-said-was-harmful-about-goto-statements.html&Itemid=29 
>>
>> Can you see his fundamental mistake? He talks about "the program" 
>> (just as Dijkstra said), but it's just not relevant for 
>> C/C++/D/Pascal/...
>> or any other structured programming language. Wherever he says 
>> "program" you should substitute "function". And then the force of the 
>> argument totally disappears.
> 
> Yes.
> 
>> The problem with goto in an unstructured language is that when you see 
>> a label, you don't know where it came from. It could be anywhere in 
>> the entire program (maybe a million lines of code!) And that's a 
>> complete disaster. But in a structured language, you know it's from 
>> somewhere in the function.
>> And this is no different from any other control structure. You ALWAYS 
>> have to look at the whole scope you're in.
>>
>> void foo(){
>>  int n;
>> bool b = true;
>>   while (b) {
>>     if (n==4) {   /* when do we get here? You have to read the whole 
>> function to find out. Where does n get modified? */ }
>> :
>> :
>> :
>>   }
>> }
>>
>> Heck, even in inline ASM in D, you can't write the kind of spaghetti 
>> code Dijkstra was complaining about. You always have local scope.
> 
> OTOH, getting the algorithm may become tedious even in small snippets. 
> For example, here's Algorithm M, from /Fundamental Algorithms/, Knuth 
> 1969, page 95:
> 
>     M1: int j=n; int k=n; int m=X[n];
>     M2: if(k==0) goto M6;
>     M3: if(X[k] <= m) goto M5;
>     M4: j=k; m=X[k];
>     M5: k--; goto M2;
>     M6: ;
> 
> That's three gotos for six lines. How long did it take to fully figure 
> out what it's doing? Way longer than if it were written in structured D, 
> anyway.
> 
>> Yet, I personally have been so affected by anti-goto brainwashing that 
>> I've never used goto in C, C++, or D. But I gradually realised that it 
>> was just brainwashing. I've never experienced any problem with goto in 
>> ASM.
> 
> Same here. Last time I used it was in Pascal, and boy, did I have a bad 
> conscience. It felt like I was doing something Mom has forbidden.
> 
>>>> Actually, looking through the DMD source it becomes obvious that 
>>>> goto is really not a problem at all. The lack of comments is much 
>>>> more of a problem. (Especially with files with names like "e2ir.c". 
>>>> What the heck is "fltables.c", "cdxxx.c", "elxxx.c" ?). Even so, 
>>>> it's mostly not that difficult to understand.
>>>
>>> I guess Walter has to keep alternating between ASM, C and D. And a 
>>> lot of ASM coding is nothing more than a bunch of MOV and JMP stuff. 
>>> And file naming conventions here look like what one typically finds 
>>> in development code (before some pre-publishing guy has tidyed it up 
>>> with a lot of global search&replaces). And, after all, the C files 
>>> never were meant to be public anyway.
>>>
>>> Actually, the one interesting question might be, would rewriting this 
>>> code in a structured fashion (I mean, removing the gotos) make it 
>>> slower? (Not that I'd be suggesting Walter should do it. Just an 
>>> academic question.)
>>
>> I doubt it'd affect the speed at all. It'd probably make it longer. 
>> There are cases in DMD where it seems to make the control flow simpler.
> 
> Simpler, yes. Then again, I'd hate to see folks actually start using 
> goto in D!!!! If Walter uses it, it's different, he's qualified. :-)
> 
> 
> 
> Oh, (for interested readers,) here's the above code in a test bench:
> 
> import std.stdio;
> void main()
> {
>     enum {DUMMY};
>     int[] X = [DUMMY,2,3,4,19,18,17,5,1,6];
>     int n = X.length-1;
> 
>     M1: int j=n; int k=n; int m=X[n];
>     M2: if(k==0) goto M6;
>     M3: if(X[k] <= m) goto M5;
>     M4: j=k; m=X[k];
>     M5: k--; goto M2;
>     M6: ;
> 
>     writeln("max: ", m, " pos: ", j);
> }
> 
> The dummy and length-1 are needed because, in the old days, especially 
> text books had arrays 1-based. Also numbering things in general used to 
> be 1-based, because "computing culture" hadn't spread to the general 
> public yet. You didn't want to explain all over again the merits of zero 
> based indexing every time you chalked up an example.
> 
> The interesting part is, still today, this algorithm is essentially what 
> the computer ends up doing, no matter how "structured" our source code was.

Even for it's time Basic was a bad language.  Fortran was much better, 
and it existed before Basic was created.  (Basic was created as a 
"simple version" of Fortran.  The language was, but using it wasn't.)

I still believe, however, that the go to statement should be avoided. 
Even in small routines.  Because they may not stay small.  (Doesn't mean 
you shouldn't ever use it.  Sometimes it may actually simplify AND 
clarify the code.  But very rarely.  I've only found occasion to 
actually use it about four times since structured programming features 
were introduced in the various languages that I use.  Generally it can 
be replaced by a labeled break or continue statement...and even those 
I've rarely needed since I altered my style to accommodate structures. 
The one context I used to use the goto in is now handled by exceptions.

(Yes, one can argue that a labeled break or continue is effectively a 
goto, but it is very different in having much more local context.  It's 
limited to a nest of loops rather than to a function.)