Search for a label than a trailing right brace

[AUMathTutor]

Well, I've been claiming all along that structured programming simplifies program semantics and therefore increases readability and maintainability. This is not meant to be an absolute, but a generalization from experience (which I assume is shared by most people who are involved in research into what makes a programming language "good" or "bad").

Like I said, everything I've seen here could be handled just as easily without GOTOs as with. I suspect that the only difference between these small examples are large, complicated examples is that... well... in 1,000,000 lines of code, there will be 1,000 times as much benefit to be gained by using one construct over another in 1,000 lines of similar code. That is, the benefits are proportional to the code size anyway...

Then again, if you have a single function with more than 1,000 lines, you should probably rewrite the function. But that's another story...

All I'm trying to say - and I'm sure you guys agree - is that when you need to effect some control flow, the first place you should look is if-then-else and loops, and the GOTO should be used with caution.

And what do you guys think of alternative control flow structures and/or marking blocks of code as GOTO or other. I believe C# does something similar with pointers.

 

[AUMathTutor]

"I use it because it's the right tool for the job."
Well, you think it's the right tool for the job. The same thing can always be done without goto, and whether or not to use it is a matter of taste.

The real issue is that if your design leads to an overabundance of gotos, your design needs some attention. If you see yourself being put into situations where you need to use gotos, you may want to make your code cleaner. I've never had to use a goto for anything I've ever done... for whatever that's worth. I have used breaks, continues, and returns before, but it's not something I'm particularly proud of.

"Why? What benefit would there be to restricting goto in such a way?"
Because doing that makes spaghetti code. I cannot imagine any code with gotos going forward and backward that I would want to read. Because to make it not act as a loop, you will need another goto which jumps that goto. And then say you want to go back again. You start getting crossing gotos and nobody likes that.

What about just a rule that gotos are not allowed to cross? Like this isn't allowed:

void foo()
{
   //...
   if (cond1) goto label1;
   // some code...
label3:
   // some more code...
   if (cond2) goto label2;
   // some more code...
label1:
   // some more code...
   if(cond 3) goto label3;
   // some more code...
label2:
   // some other code...
}

Whether or not this is allowed in the language or not, this is what the anti-goto people are avoiding. If you guys think that would be acceptable under any circumstances, then our differences of opinion are so fundamentally different that my continuing to try to sway you to my side would be in vain. To me, the above sort of thing is *indefensible*.

Now, some of the things you guys have shown are a different story. I don't have to like them, and I don't advocate doing it that way, but I can at least see the arguments to be made for clear and appropriate uses of the goto:

void bar()
{
   if(cond1) goto label1;
   // code...

   if(cond2) goto label2;
   // code...

   if(cond3) goto label3;
   // code...

   goto label4;

   label3:
   // code...
      goto label4;

   label2:
   // code...
      goto label4;

   label1:
   // code...
      goto label4;

label4:
// code...
}

Again, I don't have to like it, but if you really think it it's better than the alternative, whatever. It's playing with fire IMHO, but if you know what you're doing, you can probably get away with it.

 

[AUMathTutor]

Of course, I would prefer:

void bar()
{
   if(cond1)
   {
      // code...
      if(cond2)
      {
         // code...
         if(cond3)
         {
            // code ...
            if(cond4)
            {
               // code...
            }
            else
            {
               // code...
            }
         }
         else
         {
            // code...
         }
      }
      else
      {
         // code...
      } 
   }
   else
   {
      // code...
   }
}

 

[rcgldr]

The point of this thread was the specific abhorence to gotos even in the few cases where they are appropriate In a switch case sequence, the breaks are essentially goto's, but few if any complains about break statements. Ditto for break and continues in loops. Some complain about multiple returns in a function.\

Since I did a lot of assembly programming in the early part of my career, perhaps my biases are different than most. One concept I have is that a big part of the current state of a machine is it's current execution address. An old example of this is a traffic signal controller, all code, 1 register, the program counter (execution address), and multiple inputs from sensors in the pavement. The outputs drive the signals. It's just a collection of loops for each "state" of the traffic controller {all_lights_red, ns_red_ew_green, ns_red_e/w_yellow, ...}.

This is probably why I'm biased to using pointers to functions in C (or overriding class member functions in C++), as opposed to a bunch of state variables and switch case statements. For debugging purposes, I will use conditional compile time code to store states in one or more global variables to help trace what happens in the case of a failure in debug builds if not offered in the compiler. Dating back to Watcom's mainframe Fortran compiler back in the 1970's, some languages include a debug build option that includes storing the current state (line number) in a one or more global variables to show where in the source code any failure occured.

 

[AUMathTutor]

Of course, if you have any appreciable amount of code being executed where I have // code..., then you could make the separate parts into inline functions or something and do the following:

void bar()
{
   bool cond1 = cond2 = cond3 = cond4 = false;

   cond1 = f1();
   if (cond1) cond2 = f2();
   if (cond2) cond3 = f3();
   if (cond3) cond4 = f4();
}

 

[AUMathTutor]

Yes Jeff, I think most of it has to do with what you're used to. I'm used to one way of doing things, and it's only natural that somebody with more experience using the GOTO would prefer it.

I wonder if the anti-goto people (I guess I'll throw my lot in with them, though at the end of the day, I'd use a GOTO or the like if it made my life a lot easier) sound as finicky and ante-diluvian to the pro-goto people as the pro-functional paradigm (usually = anti-OO paradigm) people sound to the pro-OO people.

Just out of curiosity, how do you guys feel with regard to that?

And what of studies done regarding the goto? I'll remind everyone that, strictly speaking, these forums aren't about our opinions, however well-reasoned they are. We should really be focusing on facts here... so what are the facts?

 

[D H]

"I use it because it's the right tool for the job."

Back to your old ways, I see. Please use the quote button. Or the multi-quote button. Don't just quote text using quotes.

The same thing can always be done without goto, and whether or not to use it is a matter of taste.

No, it cannot. See the article cited in post #7, repeated here.

Kozen, Dexter and Tseng, Wei-Lung Dustin, "The Böhm–Jacopini Theorem Is False, Propositionally", Lecture Notes in Computer Science, 5133 177-192, Springer-Verlag, 2008
http://ecommons.cornell.edu/handle/1813/9478

"Why? What benefit would there be to restricting goto in such a way?"
Because doing that makes spaghetti code. I cannot imagine any code with gotos going forward and backward that I would want to read. Because to make it not act as a loop, you will need another goto which jumps that goto. And then say you want to go back again. You start getting crossing gotos and nobody likes that.

You are being overly dramatic. Nobody here is advocating a return to 1960's style spaghetti code. The end goal is (or should be) code that is usable, reusable, maintainable, verifiable, ... Spaghetti code has none of those features. Unfortunately, code written according to overly draconian coding rules that make structured programming an end in and of itself often has none of these features, either. See post #21 for a good example.

 

[AUMathTutor]

"Back to your old ways, I see. Please use the quote button. Or the multi-quote button. Don't just quote text using quotes."
Get over yourself. What are you, obsessive compulsive?

"No, it cannot. See the article cited in post #7, repeated here."
Fair enough... I was only just able to actually read the thing, and it looks to be in order. Still, I don't think that this means using the GOTO anywhere is alright. When the GOTO is being used in the place of other constructs which could do the job just as well, I don't think it's a great idea. And honestly, how often have you ever *had* to use a GOTO? Rarely, I imagine.

"You are being overly dramatic. Nobody here is advocating a return to 1960's style spaghetti code. The end goal is (or should be) code that is usable, reusable, maintainable, verifiable, ... Spaghetti code has none of those features. Unfortunately, code written according to overly draconian coding rules that make structured programming an end in and of itself often has none of these features, either. See post #21 for a good example."
It's a matter of degrees, not absolutes. The less structured your code is (read: the more gotos you have), the more likely it is to be (or turn into) incomprehensible spaghetti code.

And I agree that structured programming is not an end, but a means to an end. What seems to be giving me trouble in understanding your POV is that you seem to use the fact that it's a means to an end to throw it out the window whenever it isn't convenient for some or some other reason.

The GOTO has never been accused of not being clear to the person who used it. Then again, the point of employing any of these design ideas into your program is to help other people, not yourself, deal with your code. For me, the GOTO is the code equivalent of spewing acronyms and technical jargon at the customer. You know exactly what you're talking about, and other people familiar enough with what you're talking about can probably follow, but otherwise it's a mess.

I feel like if you're going to have rules, that you stick by them - for consistency's sake, if nothing else. Deviation from these rules should be subjected to scrutiny - which is really all I'm advocating. Clearly the context determines how much deviation is allowed. Under certain conditions, the GOTO - as well as any other bad programming idea you can think of - can be acceptable. Naturally, here, we're talking about generalizations, and in general, the GOTO should be avoided where it is feasible to do so.

That's my position, and I've: (a) heard it, (b) read it, (c) experienced it, (d) understood it, and (e) agreed with it for too long to just throw it out the window on a whim. Can you find any studies in software engineering that discuss the relative merits of the GOTO?

 

[AUMathTutor]

"http://books.google.com/books?id=c42oYf4zBzMC&pg=PA118&lpg=PA118&dq=bohm+jacopini+false&source=bl&ots=fpxxYAp852&sig=92c8tTVUpm5SAhRNE4eAgfikjgs&hl=en&ei=D1bvSaf7Od6Jtgf_lfHBDw&sa=X&oi=book_result&ct=result&resnum=7"
That might be an interesting read. It seems to confirm what I had been thinking all along - that while a program using GOTOs may not be possible to convert using Bohm and Jacopini's method, the results of it can certainly be achieved using Bohm-Jacopini.

I think it's much more reasonable that a program may not be able to be represented using WHILE and IF-THEN-ELSE, but I have a hard time believing that whatever the program does couldn't be done in such a way that the WHILE and IF-THEN-ELSE were sufficient. If this is true, then we just get right back to the real issue: should we write our programs in terms of GOTO, or in terms of structured programming?

You know, D H, if you can turn that 3-state automaton into a program that computes some value which cannot be computed without a GOTO, I will have to concede at least the point that the GOTO is required in any Turing-complete programming language. Like I said, I don't think it's possible to come up with any computational procedure which, given a set of inputs, produces an output which cannot be replicated by some other procedure using only WHILE and IF-THEN-ELSE. We'll see...

 

[rcgldr]

Of course, if you have any appreciable amount of code being executed where I have // code..., then you could make the separate parts into inline functions or something and do the following:

void bar()
{
   bool cond1 = cond2 = cond3 = cond4 = false;

   cond1 = f1();
   if (cond1) cond2 = f2();
   if (cond2) cond3 = f3();
   if (cond3) cond4 = f4();
}

Here you're using a condition that implies some dependency. The issue to me is the level of dependency between a condition and a code fragment.

In my previous example, an application may require the allocation of multiple resources before it can run, but the invidual allocations of resources are independent of each other, memory allocation is independent of opening a file, or createing a mutex, so I don't write code that implies some inter-dependecy. If someone else has to add or remove allocation statements, there aren't any confusing implied dependency conditionals to deal with.

Otherwise I rarely use goto's. Breaking out several levels of nested code is one case where I'd use a goto. Failure status of an otherwise independent step is another case where I'll use a goto for error and exit handling code, so that the main stream code deals with the non-exceptional sequences of steps in a process.

An anology would be a pilot procedure for an aircraft. How readable would the procedure be if every step was individually preceded with list of conditionals for all the things that could fail? "if (engine_not failed){ if(fuel_not_low){ if cockpit_not_on_fire){ ... { { { ... ask_for_clearance_to_taxi_to_runway)(); ... } } } ... } } }.

discuss the relative merits of the goto?

As I just pointed out in this post, goto's can eliminate the implication of non-existant dependencies (beyond simple non-failure) between independent sequences in a program. Goto's also allow the main line code to not be cluttered with exception handling.

 

[AUMathTutor]

Well, I mean refereed, journal quality papers discussing studies into the GOTO, not personal opinions. I think we all know about where we stand at this point.

 

[Hurkyl]

Still, I don't think that this means using the GOTO anywhere is alright.

Nobody is advocating using goto anywhere. They're advocating using goto when it's the right tool for the job.

When the GOTO is being used in the place of other constructs which could do the job just as well, I don't think it's a great idea. And honestly, how often have you ever *had* to use a GOTO? Rarely, I imagine.

Nobody is advocating using goto when other constructs do the job just as well. They're advocating it when other constructs don't do the job as well -- such as breaking out of a double loop. The question of whether the goto *had* to be used is completely irrelevant.

It's a matter of degrees, not absolutes. The less structured your code is (read: the more gotos you have), the more likely it is to be (or turn into) incomprehensible spaghetti code.

So? Spaghetti code is bad because it's spaghetti, whether or not it uses a goto is irrelevant. Containing a goto is simply not grounds for condemnation.

the GOTO should be avoided where it is feasible to do so.

"Feasible" isn't good enough. The goto should be avoided only when other methods are better.

 

[AUMathTutor]

""Feasible" isn't good enough. The goto should be avoided only when other methods are better."

And you know what my response would be, so let's look for some refereed papers on the subject rather than continuing this tired debate.

 

[rcgldr]

What is the signifcant difference between "goto", "break", or "continue"?

 

[Hurkyl]

""Feasible" isn't good enough. The goto should be avoided only when other methods are better."

And you know what my response would be, so let's look for some refereed papers on the subject rather than continuing this tired debate.

There is no point in looking if we cannot agree upon what we're looking for. I want to write the best code I can, and I don't care whether or not it involves goto. You, on the other hand, seem to consider "avoiding goto" a goal, and you're willing to sacrifice the quality of your code to achieve it.

 

[AUMathTutor]

"willing to sacrifice the quality of your code to achieve it."

Again, you know how I'm going to respond to this. But just so we're on the same page, my response would be something like:
"And you're willing to sacrifice the quality of your code by ignoring software best practices and using the goto in an ad-hoc fashion to get quick and dirty results."

As far as refereed papers are concerned, I'll do my best to find some which are freely available and deal with the GOTO, when and why it's used, and whether it's good or bad software engineering practice to use them freely, use them sparingly, or avoid using them as long as possible. Dijkstra's paper on this is one example, but I think there are others. Perhaps there are even a few papers defending the goto. Who knows?

 

[D H]

You've been given one paper already, and by none other than Knuth.

None of us are advocating a return to the days of spaghetti code. As Hurkyl and I have both said many times, the ultimate goal is to write the highest quality code; code that is usable, maintainable, understandable, verifiable; all those -ilities.

There are, in fact, several good places where all but the most rabid of structured programming workplaces still gotos:

• To break out of a nested loop in a language that does not provide a multi-level breakout.
  
  
• Error handling, particularly in
  • Languages that do not support or projects that do not allow exceptions. For example, even though C++ provides a powerful exception-handling capability, use of it is often verboten in real-time systems (as is use of new).
  • Projects with the (IMHO) incredibly onerous "single point of entry / single point of return" rule. (BTW, very few languages support multiple points of entry. Fortran is the only one that I can think of that does.)
  
  
• To directly implement finite state machines. The use of gotos here is in a sense the natural implementation of an FSM. The more typical implementation as a loop around a switch statement is a somewhat artificial, but not too onerous, construct invented solely to avoid use of gotos.

 

[rcgldr]

The days of spaghetti code.

Maybe spaghetti code was more prevalent during the 1960's, but I started programming as high school student back in 1968, and good coding practices were being taught back then, even for assembly language programming.

One 1960's standard that has carried through current times is the ideal of modularizing code; keeping the main program and any subroutines (functions) reasonably small, with each subroutine performing one main function. There are always exceptions, but this was a general rule.

Another concept was top down design, bottom up implementation, to simply unit level testing of subroutines without having to create stubs and generation of data. The bottom up implementation wasn't a strict rule, but a general guide. In some cases, key or potentially problematic subroutines would be implemented (or partially implemented) first to see if there was a flaw or problem with the design.

One thing that has mostly gone away is the manual drawing of flow charts. Some of us always preferred writing psuedo-code since it could be easily maintained, and eventually the flow chart tools ended up using pseudo-code like languages as input to create their flowcharts. Then programmers started becoming aware of the fact that it was easier to read the pseudo-code input files than to view the created flowcharts for any but the simplest of algorithms. I still have my plastic flow chart drawing guide, as well as an old K&E slide rule, but thes are just collectors items now, along with my Microsoft OS/2 coffee cup.

Speed is less of an issue now. I can remember some projects where microseconds mattered, and I would do things like changing interrupt vector address pointers to handle a sequence of interrupt driven steps to minimize latency. Perhaps this explains why I'm still fond of using pointer to functions for handling interrupt or message driven code.

 

[Hurkyl]

Again, you know how I'm going to respond to this. But just so we're on the same page, my response would be something like:
"And you're willing to sacrifice the quality of your code by ignoring software best practices and using the goto in an ad-hoc fashion to get quick and dirty results."

How would I know that? My stated goal is to write the best code I can, and I cannot write the best code I can if I sacrifice the quality of my code. Your response makes absolutely no sense.

 

[AUMathTutor]

Hurkyl, your feigned indignity is very entertaining, and I'm assuming that was the intent. Clearly this is the case; either that or you have never fully understood the phrase "beating a dead horse".

"How would I know that?"
Because we've been doing this little tete-a-tete for the last 15 or so posts, it seems. We can both come up with new ways of saying the same thing all day and night, but that's not going anywhere fast.

"My stated goal is to write the best code I can"
As is mine... the difference is in how we seek to achieve this goal, viz. whether or not using the goto is a good idea, ergo this discussion thread.

"and I cannot write the best code I can if I sacrifice the quality of my code."
Finally we agree. I generally accept the truth of tautological statements, but it never hurts to check.

"Your response makes absolutely no sense."
In the best case, that's the pot calling the kettle black. In the worst case, it's the pot making wild accusations that apples are in fact black, if that's how he sees it.

 

[AUMathTutor]

D H:

That you did, and I appreciate the effort to find relevant material. I don't recall how old the paper you provided was, however, and I really wanted to see if there's any current research in the area, or if it is generally considered to be dead and buried. In fact, I have a few minutes, let me do a quick Google search and see what we turn up:

Here's the Dijkstra paper I've mentioned:
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

Ironically, that's even older than the one by Knuth.

Here's another pretty basic one that's turned up:
http://portal.acm.org/citation.cfm?id=800283.811114

There are others out there, but I'm running low on time, so I think I'll let you guys take a look at some of these if you're interested. The last one, in particular, was very enjoyable.

Here's a deliciously mathematical look at how it may come to pass that such questions as whether the GOTO is an appropriate statement to use or not may some day no longer be a matter of opinion:
http://www98.griffith.edu.au/dspace/bitstream/10072/12328/1/5314.pdf

 

[Hurkyl]

"My stated goal is to write the best code I can"
As is mine... the difference is in how we seek to achieve this goal, viz. whether or not using the goto is a good idea, ergo this discussion thread.

Then you need to explain something. You made a comment earlier:

in general, the GOTO should be avoided where it is feasible to do so.

which seemingly directly contradicts the claim you just made, that you seek to write the best code you can. Here, you assert that (generally speaking) goto should be avoided when feasible. You didn't say that goto should be avoided when when there are better options, you said it should be avoided when feasible.


You have made similar comments in the past:

I, personally, avoid the GOTO when it is not too inconvenient to do so.

Where again, you suggest that code quality is not your primary concern: instead, you avoid goto whenever sufficiently convenient.

 

[AUMathTutor]

Yes, because my philosophy is to avoid mistakes which can be caused by using the GOTO by avoiding the GOTO; yours is to avoid those mistakes by simply not making them, which is a great philosophy if you can pull it off, but which is generally speaking not a satisfying solution to the problem, since if it were, there would be no problem in the first place.

This sort of reminds me of The Feynman Problem-Solving Algorithm:
(1) write down the problem;
(2) think very hard;
(3) write down the answer.

That's a great general-purpose way to go about things, too, if you can pull it off.

"You didn't say that goto should be avoided when when there are better options, you said it should be avoided when feasible."
In my way of looking at it, if other options are feasible, they are by default better options.

And was it you who said earlier that thinking about new control flow structures was not a productive activity since you can't go use them in C++? New languages happen... and when new control flow constructs or constraints are added to the language, people need to have thought about them and discussed the need for them in future languages.

And what about declaring blocks of code as GOTO if they use GOTOs, loops as BREAK or CONTINUE if they use BREAK or CONTINUE, and MULTIPLE ENTRY / EXIT if they contain multiple points of ENTRY / EXIT? This seems like a good idea to me. I think that in C# you can do the same thing to use pointers, which I think is a great idea.

 

[rcgldr]

Yes, because my philosophy is to avoid mistakes which can be caused by using the goto by avoiding the goto; yours is to avoid those mistakes by simply not making them

What are "mistakes" that can be caused by using goto? I've never seen a list of these anywhere. How difficult would be it be to avoid these mistakes? In my examples where I did use goto, would you find it difficult to understand or maintain the code where I used goto's?

Why is goto the only statement to be avoided? Couldn't the same argment be made for any statement type of a language? What mistakes can goto cause that couldn't also be caused with poor usage of break, continue, if+else, ... ? Should we also ban the usage of pointers because of the risk of mistake? Should be ban recusion because it can be coded around?

 

[AUMathTutor]

Mistake may not have been the best word for it. I'll think about exactly how I want to say this bit before I get back to you.

As far as the other part of your post, I agree that other constructs are just as bad as the GOTO. The GOTO is sort of a scapegoat. However, I do believe that some constructs are inherently "better" than others.

I feel that the more limited in scope and more rigid in behavior a construct, the better. Why? Because if people are familar with what a construct is capable of accomplishing, it is easier to understand code which uses this construct. Naturally, this necessitates a larger set of constructs than may otherwise be required. The GOTO is sufficient to simulate the IF-THEN-ELSE, the SWITCH, the WHILE, the FOR... you name it, the GOTO can do it. So why have any constructs at all?

We know how to reason about if-then-else constructs, while loops, and for loops from mathematics. These constructs correspond to very familiar ideas in mathematics... they are, in a sense, referentially transparent in that their semantics do not depend on their context. This makes it a lot easier to reason formally about what a program is actually doing.

 

[rcgldr]

Maybe it would help to mention my restrictions for the usage of goto. I didn't make it clear that I limit the usage of goto's to two situations, only providing examples instead of stating restrictions on usage.

1. I use goto's for exception or failure cases, so the main code flow deals with the normal case, and without "undeeded" indentation.

2. I use goto's for multiple exit paths out of nested code, but these situations are relatively rare. In languages where this could cause problems, compilers will usually issue errors or at least warnings. I'll prefix such sections of code with a comment regarding any breakout gotos, a warning similar to the try clause of a try throw catch sequence.

One annoying (to me) situation is when reacing the end of a nested section represents failure. Due to my rule #1, no significant exception handling in the main line of code, I end up using another goto just after the nested sequence to deal with the exception, followed by a "success" label to continue the main line code.

In other cases, the early or final exits are simply alternate conditions. For example when building and using a dictionary, it's expected to not find a match, so the two main paths are create new entry and/or use existing entry.

 

[Hurkyl]

Yes, because my philosophy is to avoid mistakes which can be caused by using the GOTO by avoiding the GOTO;

So it's more like buying insurance then. You (may) pay a price on every piece of code you write -- your will write poorer code than you could have in any situation where using goto, break, multiple returns, et cetera would be an improvement -- to help protect against a particular kind of problem.

Is this a fair characterization? If so, it really is misleading to discuss alternatives to goto as if they are better pieces of code...

And was it you who said earlier that thinking about new control flow structures was not a productive activity since you can't go use them in C++?

I am the one you're thinking about, but you have the intent wrong -- the point was that it's not fair to criticize a particular implementation on the grounds that it really should the "condexpr" construct when it doesn't actually exist.

 

[AUMathTutor]

"your will write poorer code than you could have in any situation where using goto, break, multiple returns, et cetera would be an improvement"

By my definition of quality, surely you realize that - almost by definition - the fewer unconditional jumps, the better. Exceptions to the rule can certainly be allowed, but only when the alternatives aren't feasible - that is, to do it another way won't work for some reason. I won't agree that my philosophy is to write poor-quality code just to dogmatically avoid a language construct, because that's not my intent.

 

[rcgldr]

unconditional jumps

Unconditional jumps aren't the issue, or at least not mine. All the exampes of the goto's and discussion here have been about using goto's for conditional branching.

Unconditional goto's might be used to implement the equivalent of a while(1){...} in a language that didn't suport it, where the exit point is in the middle of a loop instead of at either end, but this wasn't brought up until now.

 

[Hurkyl]

I won't agree that my philosophy is to write poor-quality code just to dogmatically avoid a language construct, because that's not my intent.

You (practically) define goto to be bad. How is that not dogmatic?

Anyways, your definition of "quality" is irrelevant to me -- I'm interested in things like correctness, readability, portability, efficiency, reusability, rather than in syntactic games -- so I'll stop discussing it.