dave@tygra.UUCP (David Conrad) (01/27/91)
In article <2427@bnlux0.bnl.gov> kushmer@bnlux0.bnl.gov (christopher kushmerick) writes: > >Except for the fact that an exit is just a fancy way of spelling goto, with the >effective label being a automatic label right before the ultimate end. (I do >not know if this is how it is actualy implemented, it may be a return, but >from a logical viewpoint, this is what it is.) > >I like to use gotos within programming blocks, but not between programming >blocks, by programming block, I mean a begin-end pair. > >I also do like the exit construct mentioned above, but I understand that it is >a goto. > >Now: goto work :-) >-- >Chris Kushmerick kciremhsuK sirhC >kushmer@bnlux0.bnl.gov <===Try this one first >kushmerick@pofvax.sunysb.edu Yeah, right, and a repeat until is just a fancy way of spelling goto also, with the effective label at the repeat, and a if not(until_expr) then goto <the label> at the end, where until_expr is the conditional which follows the until. For that matter, while expr do.... I hope you see what I'm getting at. All structured programming constructs can be emulated with goto's, and can be thought of etc. But they have the advantage that the compiler does the work for you so you can't screw it up by adding/subtracting lines. That's the difference between structured and spaghetti code. If this isn't obvious, consider the following examples. If it is, press n. procedure foo; label done; begin if errorTest then goto done; done: end; ---------- procedure foo; label done; begin if errorTest then goto done; done: bar; (* This call was adding, breaking the logic *) end; ---------- procedure foo; (* One without goto's *) begin if errorTest then exit; end; ---------- procedure foo; begin if errorTest then exit; bar; (* This time the addition of the call to bar breaks nothing *) end; I'd like you all to know I had to shell out and spend some time with the online help to figure out the syntax of label's and goto's. Never used one outside of BASIC and FORTRAN, and never will. -- David Conrad | label hell; dave@ddmi.com | goto hell; -- = CAT-TALK Conferencing Network, Computer Conferencing and File Archive = - 1-313-343-0800, 300/1200/2400/9600 baud, 8/N/1. New users use 'new' - = as a login id. AVAILABLE VIA PC-PURSUIT!!! (City code "MIDET") = E-MAIL Address: dave@DDMI.COM
ts@uwasa.fi (Timo Salmi) (01/28/91)
In article <1991Jan27.074528.23487@tygra.UUCP> dave@tygra.UUCP (David Conrad) writes: : >I hope you see what I'm getting at. All structured programming constructs >can be emulated with goto's, and can be thought of etc. But they have the >advantage that the compiler does the work for you so you can't screw it up >by adding/subtracting lines. That's the difference between structured and >spaghetti code. : I may be misinterpreting your implication, but as the guilty party of commencing the debate, let me again point out repeat using gotos != spaghetti code not using gotos != writing well structured programming careless usage of gotos = spaghetti code until false The heat produced in the discussions obviously emanate from the fact that these relations are not transitive. ................................................................... Prof. Timo Salmi Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.12.37 School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
dave@tygra.UUCP (David Conrad) (01/28/91)
In article <1991Jan27.185044.19856@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes: >In article <1991Jan27.074528.23487@tygra.UUCP> I write: >: >>I hope you see what I'm getting at. All structured programming constructs >>can be emulated with goto's, and can be thought of etc. But they have the >>advantage that the compiler does the work for you so you can't screw it up >>by adding/subtracting lines. That's the difference between structured and >>spaghetti code. >: > >I may be misinterpreting your implication, but as the guilty party >of commencing the debate, let me again point out > >repeat > using gotos != spaghetti code > not using gotos != writing well structured programming > careless usage of gotos = spaghetti code >until false > Well, yes, you did misinterpret, but it's probably my fault for not being clear enough. I don't think that goto's mean automatic spaghetti code, I just think they are unnecessary and *usually* lead to spaghetti code. The spaghetti code I meant was when the adding/subtracting lines starts to screw up the original intent. Then your talkin' serious pasta. One can write bad code in any language, and one can also do structured programming in any language. A (possibly) amusing example: I was working on an accounting application in COBOL (Ak! Gasp!), and another programmer on the project was a mainframe COBOL programmer from way back who didn't know pascal. Well, halfway through the project I started teaching him Turbo Pascal in our spare time because he wanted to know what this great thing was that I'd been using to write little utilities for the project. (Like an editor that called up the COBOL compiler...Turbo Editor Toolbox!) After he had learned some pascal he looked at the COBOL programs I'd been writing and he said (and I don't remember his exact words), "You know, you write COBOL just like pascal," or, "You make your COBOL programs look like pascal," or something. -- David Conrad dave@ddmi.com -- = CAT-TALK Conferencing Network, Computer Conferencing and File Archive = - 1-313-343-0800, 300/1200/2400/9600 baud, 8/N/1. New users use 'new' - = as a login id. AVAILABLE VIA PC-PURSUIT!!! (City code "MIDET") = E-MAIL Address: dave@DDMI.COM
ian@syacus.acus.oz.au (Ian Joyner) (02/04/91)
There is yet another consideration in the goto debate. This is concurrency. The use of gotos make it difficult for a compiler to generate concurrent code. While this may not be a problem at the moment, I guess machines coming out in the next ten years will be inherently concurrent. This is also the argument against global variables. You will have to synchronise updates to globals, and if many processes are trying to update the same set of variables, this will result in a bottleneck, or worse still be error prone. Avoiding globals is easy. If you find you have the urge to put in some globals, chances are that you have found another class. If not they should all be placed in an "application" class. Of course it is impossible to avoid globals where the language isn't a suitable tool. I don't find languages that don't have gotos or globals restrictive. It will probably be common in the future, and noone will argue, because such languages make the new generation of parallel and concurrent systems possible. -- Ian Joyner ACSNet: ian@syacus.oz ACUS (Australian Centre for Unisys Software) DNS: ian@syacus.oz.au Tel 61-2-390 1328 Fax 61-2-390 1391 UUCP: ...uunet!munnari!syacus.oz
derek@sun4dts.dts.ine.philips.nl (derek) (02/05/91)
ian@syacus.acus.oz.au (Ian Joyner) writes: about concurrency, with which I agree, then says: >Avoiding globals is easy. If you find you have the urge to put in some >globals, chances are that you have found another class. If not they should >all be placed in an "application" class. Of course it is impossible to >avoid globals where the language isn't a suitable tool. I don't find >languages that don't have gotos or globals restrictive. It will probably >be common in the future, and noone will argue, because such languages >make the new generation of parallel and concurrent systems possible. This is all very true and good. However, I wonder what the memory ramifications are? In a program I'm writing at the moment (in good old 5.0 - waiting for an update to 6.0), I'm using globals to reduce the stack overhead in a recursive procedure - sounds dangerous, but I'm being careful - these are mainly work records for pushing things onto the heap, which is cleared before each recursion. With the possibilities of very many recursions and large lists of things on the heap, surely this is a place to use globals, as long as concurrency is not a problem. Of course, since I've not yet got into OOP, perhaps there is another way? Suggestions? I'm also experimenting with the Desqview API library. Here concurrency is certainly an issue, but globals can help in passing information between tasks in the same process. And that is what the critical region switches are for. Best Regards, Derek Carr DEREK@DTS.INE.PHILIPS.NL Philips I&E TQV-5 Eindhoven, The Netherlands Standard Disclaimers apply.
John G. Spragge <SPRAGGEJ@QUCDN.QueensU.CA> (02/06/91)
In article <654@sun4dts.dts.ine.philips.nl>, derek@sun4dts.dts.ine.philips.nl (derek) says: >In a program I'm writing at the moment (in good old 5.0 - waiting for an >update to 6.0), I'm using globals to reduce the stack overhead in a >recursive procedure- sounds dangerous, but I'm being careful - these are >mainly work records for pushing things onto the heap, which is cleared >before each recursion. In a similar situation, I used a typed local constant: this could be used as a buffer, persisted, did not cause additional stack memory to be allocated, and could only be accessed in the single procedure it was attached to. It was a bit kludgey, I admit, but given the stack linitations in Turbo, I think it qualified as a necessary bit of hacking. disclaimer: Queen's University merely supplies me with computer services, and they are responsible for neither my opinions or my ignorance. John G. Spragge