"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhjruo$kd9$1@digitaldaemon.com...
> but like pointers there are other constructs that are more robust and
> perform the same task
> (bounded array and reference (unmovable pointer))
> even at a very low level, you only _need_ those two (well bounded array is
> enough as a length of one is a ref, but we all like a little syntactic
> sugar).
> movable pointer is just an efficient way to do both in one go. (well
> unbounded array)

You can always refactor the code to eliminate the need for a goto. That doesn't mean it's cost effective, especially when it results in a lot of diff's from one version to the next that makes it hard to verify just how the algorithm changed.


> we've not even dared to mention the double evil "setjump/longjump" which
use
> incorrectly allows you to go the wrong way along an already used stack.

Exception handling effectively replaces that.


> surely as a compiler writer, the simple fact that a goto can branch into a loop mush be reason enough to consider removing it, thus allowing the compiler to be able to do loop invariant detection without the worry that someone is going to "goto" the middle of a loop where 50% of the state has been moved outside it ?

What you're describing is called an "irreducible flow graph". However, the optimization algorithms I use work just as well regardless of whether the flow graph is reducible or not.


> I'll quote your own docs ...
> "D aims to reduce software development costs by at least 10% by adding in
> proven productivity enhancing features and by adjusting language features
so
> that common, time-consuming bugs are eliminated from the start."
> isn't goto one of the causes of unexpected programming errors due to the
way
> it allows you to "break the flow" of a program.

D allows an escape from every constraint it imposes. How D lives up to the rule you quoted is by not *requiring* one to use error-prone constructs to accomplish the vast majority of programming tasks.

> 
> 
> Write 6 goto's and 3 self-modifying loops, and you'll be absolved.
> 
> 

LOL

That's cruel punishment for heresy. I did goto spaghetti code thing in my BASIC days.  I never actually did the self-modifing loops part soI'm only half absolved!

I remember getting a big ugly grade on a project in my FORTRAN class because I carried over my BASIC programming skills by creating some really creative spaghetti.  I thought it was beautiful and clever... for some reason the instructor didn't share my opinion :).

Oh the days of messy programming in BASIC and 6502 assembler! It was soo fun!

Later,

John

"John Reimer" <jjreimer@telus.net> wrote in message news:bhkn6r$1ne2$1@digitaldaemon.com...
> >
> >
> > Write 6 goto's and 3 self-modifying loops, and you'll be absolved.
> >
> >
>
> LOL
>
> That's cruel punishment for heresy. I did goto spaghetti code thing in my BASIC days.  I never actually did the self-modifing loops part soI'm only half absolved!
>
> I remember getting a big ugly grade on a project in my FORTRAN class because I carried over my BASIC programming skills by creating some really creative spaghetti.  I thought it was beautiful and clever... for some reason the instructor didn't share my opinion :).
>
> Oh the days of messy programming in BASIC and 6502 assembler! It was soo fun!

I've always had a soft spot for self-modifying code. One example I thought was the cat's meow was when I figured out how the original ADVENT FORTRAN program initialized itself, and then rewrote its own executable.

I then used a similar technique to avoid configuration files in my own programs. They'd just patch the executable. That came to a halt when virus checking programs became common, as self-modifying exe files were supposedly a sure sign of virus activity. Then Microsoft killed it altogether by making it impossible for an exe to write to itself while running. Oh well.

I still enjoy writing x86 assembler.

So it's a statement that attaches itself to the next statement.

What exactly is the problem you see?

Sean

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:bhj56v$2ve6$1@digitaldaemon.com...
> Sean L. Palmer wrote:
>
> > Yeah, you have the solution:  label is a form of statement, that
generates
> > no code, just a place marker.
>
> This may impose a problem with labelled loops?
>
> -eye

Yes, there's ways to make it prettier, to make it a little easier to read, but you really can't beat the flexibility of goto.

Some people like imposing limitations on themselves.  That can be useful, if artificial, perhaps in a team environment.

Know when to exceed the limitations, and when not to.

This is a holy war in the making.  I'm just going to drop it.

I bet you may not be so against goto if the IDE drew a yellow dotted arrow from the goto to the label, so you can see the control flow.  ;)

Sean

"Frank D. Wills" <fdwills@sandarh.com> wrote in message news:bhj9tb$2m7$1@digitaldaemon.com...
> Sean,
> I don't care if people want to use goto. I don't think
> it's the best of choices. Assembler uses the jump statement
> because it does not have the facility of higher level
> languages, and it is necessary. All branching logic
> in higher level languages is implemented as jump statements
> in the object code because that is the limit of
> available control structures in object/machine code.
>
> Sean L. Palmer wrote:
> > It does.
> >
> > The goto statement is the direct equivalent of the assembler jmp opcode,
the
> > most fundamental control transfer structure bar none.
> >
> > Higher-level control constructs should be used when possible.  But goto exists to allow making of new control constructs (if we had some kind of macro facility, which we don't) and to get you out of pickles where the
nice
> > "high-level" control constructs don't work and aren't getting the job
done.
> >
> > Believe it or not, C does not provide all the control constructs you'll
ever
> > need, unless you count goto.
> >
> > Sean
> >
> > "Frank D. Wills" <fdwills@sandarh.com> wrote in message news:bhilbg$2hmo$1@digitaldaemon.com...
> >
> >>Matthew Wilson wrote:
> >>
> >>>"Frank D. Wills" <fdwills@sandarh.com> wrote in message news:bhh9ic$1853$1@digitaldaemon.com...
> >>>
> >>>
> >>>>I suppose the goto statement isn't a big issue, but it's the first thing I would want to remove from all languages except it's equivalent, the jump statement on assembler, where it's needed. Otherwise nothing worse or uglier than a goto statement.
> >>>
> >>>
> >>>Don't mean to offend, but this sounds terribly naive. Just because
> >
> > something
> >
> >>>is rightly deprecated in most circumstances does not mean it does not
> >
> > have a
> >
> >>>use. I rarely use it, probably a couple of times a year, but when I do
> >
> > it is
> >
> >>>the appropriate tool for the job in hand, so I use it.
> >>>
> >>
> >>The use of a goto statement is a hack, a kludge-fix for
> >>a lack of logic and structure. I hope that doesn't sound
> >>too terribly naive.
> >
> >
> >
>

Make a more convincing argument next time, grounded in real logic and not bad analogy, and learn how to deal with real people in the meantime.

Listen to yourself.  You are making too big a deal over this.   Goto holy wars are not the place to be if you can't take a flame or three.

We all know Walter busts his ass on this language.  But what has this to do with him, really?  He's probably laughing his ass off, or ignoring the whole thread.  ;)

Sean

"Frank D. Wills" <fdwills@sandarh.com> wrote in message news:bhjbbb$420$1@digitaldaemon.com...
> Ilya,
>
> You really like to jump in there when there
> is conflict, don't you? You enjoy fanning
> the flames because you like to see conflict,
> fighting, and discord. I've known people like
> you. You like to see things and people torn
> by discord and destruction. This is just what
> I hope does not happen to this newsgroup and
> project.
>
> Considering all that Walter has put into this
> effort, I do not think that it is a fitting
> response to turn this group into a bunch of
> bickering children.
>
> I think calling me names, and degenerating
> into personal attacks on me, just because I
> express an opinion about an aspect common to
> many languages is just the kind of thing that
> will destroy the good spirit that has been
> enjoyed in this newsgroup.
>
> And again, I think it is a very poor thank-you
> to Walter to cause the degeneration of this
> newsgroup. As Walter said, it is the enthusiasm
> of everyone for the work he is doing that
> keeps him going. Maybe Walter didn't know
> his supporters were just childern, prone to
> bickering, fighting, and a lack of disipline.
>
> I don't think we deserve what Walter is doing,
> but he is doing it, and sharing it with us,
> and I think we should do our best to not
> destroy the good spirit that is behind what
> Walter is doing.
>
> Ilya Minkov wrote:
> > Frank D. Wills wrote:
> >
> >> Matthew Wilson wrote:
> >>> If it's in, then its use should make sense.
> >
> >> A lack of
> >> education beyond highschool is legal. Does that
> >> make a lack of further education sensible?
> >
> >
> > For some poeple yes. Some people just feel better when they do routine jobs, then when they have to think.
> >
> > You *are* naiive!

"Why can't we all just get along in peace and harmony?"

Well, we were, before you came and started telling people how insensitive they are.

I don't understand you.  What do you hope to gain by ranting this way?

Good luck getting rid of us all.  If you succeed, you may well destroy D in the process.  We are its users.  Be thankful.

Sean

"Frank D. Wills" <fdwills@sandarh.com> wrote in message news:bhjndo$g0v$1@digitaldaemon.com...
> I appreciate what you say, and it is good to be as understanding of others as possible. I certainly wish others well, but not all people do well or choose good.
>
> In the past I have tried to placate trouble makers, and
> befriend them. I wish I could say that it worked, but it
> only seemed to encourage them. As an example, I once knew
> a person who disrupted an entire computer science department
> for over one year, maybe two (it's been so long I don't
> remember.) I think eventually all of us were trying to
> encourage something good in this person. I the meantime
> he made a lot of things bad for a lot of people. Eventually
> this person, as was his way, got into a heated shouting
> match with the chairman of the computer science department.
> The argument spilled out of the chairman's office into the
> hallway, and became very physical. The trouble maker put the
> chairman into the hospital, having beaten him and caused
> many bone fractures. This person had no remorse for what
> he did. In fact, he was giddy with glee. The chairman
> left the department, worse for the wear. Eventually everyone
> stopped befriending this person, because nothing seemed
> to encourage him to enjoy anything but trouble. For myself,
> until things became like this I had liked this person
> fairly well.
>
> There seem to be people who enjoy and encourage trouble. It's not something I understand. In the end, I think each of us chooses how we respond to things, and the choices we make, and we get a glimpse of the good or the harm that will come with that choice. Some people, for some reason, just don't choose the thing that will make things better or good.
>
> What Walter is doing is very important to me, and I imagine, to some, perhaps many others. I have waited years for someone to do this, and it could end up being far more than we might hope at this point, but many things are possible, both good and bad, and what this becomes will be as small or as great, as good or as bad, as we choose to make it.
>
> >
> > Like Benji said, getting so bitter about goto isn't a good thing to do.
Like
> > Mike said, if there's to be an argument, go to (no pun intended) the
point.
> > And finally, programming isn't *that* important to get so expressive. Tomorrow starts world war 3 and in a week everything is destroyed. The
last
> > we'll be thinking is programming, so save your anger for better moments.
> >
>
> I am just very concerned that this newsgroup is going to decend into the common ground of so many other groups that end up fighting and bickering, and I'm saying that fighting and bickering, and personal attacks are very destructive, and that once people start flaming each other, the bad feelings grow, and it is hard to put an end to the bad things that grow, and the good things that are missed, and turn things back around into something good. In this case it would be a very bad thing for that to happen.
>
> For instance, what if all the Unix people had worked together,
> rather than fragmenting. What good could have come from that?
> There is no guarantee, _ever_ that things will become anything
> but what we make them. There is a lot of good and opportunity
> for us all here, and it will all be for the greater than
> imagined good _if_ we encourage each other, and bring out
> the best in each other, and make the best things happen.
>
> I especially think of that in the context of what Walter has given this group, and what he has dedicated himself to continue doing. And especially in the good, careful, and giving manner in which he is doing everything for this group and this project.
>
> Perhaps things that _any_ of us might do to _fail_ to be thankful and well-mannered in response to, with all of this good, which we are so incredibly fortunate, out of all the world, and in all of history, does bother me a bit. How many of us realize how lucky we are to be a part of this? Most of the billions of the people of people in the world, and in all of our history, could never even dream of being a part of something like this.
>
> And I will also add, that the creation of a language like D is a very significant thing, something along the lines of the creation of Unix and C. Right now, powerful corporations control the most used and most powerful languages. With that power comes control of our future as programmers and software developers. In that sence there is a fight, a struggle going on for this control. Those who control the operating systems, languages, and software of the future will control a fundamental, foundational aspect of out lives and our future. Who controls the future: which people, which corporations? It's all being determined now. How do we treat, and treasure, this opportunity?

It's not impossible.  Just allocate some memory, mark its page callable, and write some instructions there and call it!  You may have to copy your code (hope it's internally using relative addressing!)

You may find that you can modify the program code memory to be writable, allowing old-school SMC.

Personally I wish x86 would go the way of the dinosaur and make room for the new chip designs.  Trinary ops, anyone?  x86 code requires lots of superfluous mov's and register management.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:bhkqkp$1va8$1@digitaldaemon.com...
> I've always had a soft spot for self-modifying code. One example I thought was the cat's meow was when I figured out how the original ADVENT FORTRAN program initialized itself, and then rewrote its own executable.
>
> I then used a similar technique to avoid configuration files in my own programs. They'd just patch the executable. That came to a halt when virus checking programs became common, as self-modifying exe files were
supposedly
> a sure sign of virus activity. Then Microsoft killed it altogether by
making
> it impossible for an exe to write to itself while running. Oh well.
>
> I still enjoy writing x86 assembler.

WTF?

Dude?  Are you the same Frank D. Wills that was ranting just before?

That's a total 180.

Sean

"Frank D. Wills" <fdwills@sandarh.com> wrote in message news:bhjsak$kif$1@digitaldaemon.com...
> Walter wrote:
> > "Martin M. Pedersen" <martin@moeller-pedersen.dk> wrote in message news:bhgh13$flp$1@digitaldaemon.com...
> >
> >>"Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bhgdqv$cfh$1@digitaldaemon.com...
> >>
> >>>It would be more elegenat if you didnt use goto's :P.
> >>
> >>I know, but still, "goto" is part of the language.
> >
> >
> > Goto's are like pointers. You rarely need them, but when you do, they're real nice to have!
> >
> >
> Walter, if Matthew Wilson doesn't mind me
> quoting him, what you say sounds very naive.

"Walter" <walter@digitalmars.com> wrote in message news:bhk2kn$qfh$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhjuji$mri$1@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:bhjsnl$l61$1@digitaldaemon.com...
> > > A "goto" is invaluable if you're using D as a back-end for another
> > language,
> > > since all control structures can be represented by if's and goto's.
> > >
> > that's a big "IF". or should it be a why ? does it not make more sense
to
> > have an interface to the D compilers backend so you feed it an ast/dag instead (there are lots of tools for creating asts from langs, very few
> for
> > creating dag froms ast and less code from dag).
>
> It's no different than people using C as a back end to their language Z,
and
> many many people (including myself) have wanted to make C as the output of D. Supporting goto isn't hard, why close the door on such uses?
>
C is just used because there are no easily availiable tools for
ast->optimised code
why not open the door on the D back end ...
for example the Java language does not support the full range of operations
that the Java VM supports.
why not have an interface (in D) to allow the user to pass an ast to the
intermediate or back end which can create C,D,or OS linkable object files.
this way you can open up more than just goto, one feature of most CPUs that
emulator and VM writers use is jumping into a function that has the same
params (rather than calling it) [akin to tail recursion optimisations]

void op1( context * ctx ) { ctx.a ++; }
void op2( context * ctx ) { ctx.b ++; }
void func( context * ctx ) {
    switch( ctx.op ) {
    case 1: op1( ctx );
    case 2: op2( ctx );
    }
}

or even
void function(context * ctx )[] flut = { op1, op2 }
void func( context * ctx ) {
    if (ctx.op < flut.length ) { flut[ctx.op](ctx); }
}

when you want to write
naked void op1( context * ctx ) { ctx.a ++; }
naked void op2( context * ctx ) { ctx.b ++; }
void func( context * ctx ) {
    switch( ctx.op ) {
    case 1: jump op1;
    case 2: jump op2;
    }
}
or
void func( context * ctx ) {
    if (ctx.op < flut.length ) { jump flut[ctx.op]; }
}