Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!elroy.jpl.nasa.gov!aero!homeier From: homeier@aerospace.aero.org (Peter Homeier) Newsgroups: comp.sys.mac.programmer Subject: Re: Think Pascal Wishes...? Message-ID: <86815@aerospace.AERO.ORG> Date: 26 Sep 90 16:39:06 GMT References: <4251@husc6.harvard.edu> Organization: The Aerospace Corporation, El Segundo, CA Lines: 140 In article <4251@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger >feature requests? Annoyances? Any sort of commentary? > > Rich Siegel Software Engineer Symantec Languages Group > Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel I am so glad you asked! I absolutely *LOVE* THINK Pascal. It has, I think, the finest debugging environment I have ever used. Nevertheless, there *is* one feature that I would dearly love to see included, that does exists in many other "Mainframe" debuggers, but for some reason was overlooked in creating THINK Pascal's debugger. This feature is the "procedure traceback". The procedure traceback appears as a window that has two panes. The top pane is a list of the procedure call stack, as a scrollable text field with a line (in order) for each procedure (or function) called but not yet returned from. This line contains the name of the procedure or function. Clicking on the name of a function causes the list of formal parameter names and also local variables to appear in the lower pane, along with their current values (if printable). At the same time the code window resets itself to the code for that procedure or function, with the actual point of the call in progress highlighted. The values listed in the lower pane are editable, and any new value is assigned to the parameter or variable. (Actually, only *variable* parameters would be editable, not value, procedure, or function parameters.) All this should be made clearer with an example. Take the following code: 1. program test; 2. 3. var m, n: integer; 4. 5. procedure p(x: integer; var y,z: integer); 6. var a: integer; 7. begin a := z-1; 8. if x>0 then q(y,a) 9. end; 10. 11. procedure q(u: integer; var v: integer); 12. var d: integer; 13. begin d := u-1; 14. if u>0 then p(v,d,v) else STOP 15. end; 16. 17. begin 18. m := 2; 19. n := 3; 20. p(3,m,n) 21. end. If I have this figured out correctly, the above program should break at line 14 at the STOP. Then the code and traceback windows would reflect the current scope, as follows: +=============== TEST CODE ================+ +===== TRACEBACK =======+ | 11. procedure q(u: integer; var v: inte | |=>q(0,0) | | 12. var d: integer; | | p(1,0,1) | | 13. begin d := u-1; | | q(1,1) | | 14. if u>0 then p(v,d,v) else STOP | | p(2,1,2) | | 15. end; ^^^^ | | q(2,2) | | 16. | | p(3,2,3) | | 17. begin | | test() | | 18. m := 2; | +-----------------------+ | 19. n := 3; | | u: 0 | | 20. p(3,m,n) | | v: 0 | | 21. end. | | d: -1 | | | | | | | | | | | | | | | | | +------------------------------------------+ +-----------------------+ The "^^^^" is my attempt to show highlighting on the code screen. Then clicking, say, on the "p(2,1,2)" entry would result in the screen changing to +=============== TEST CODE ================+ +===== TRACEBACK =======+ | 5. procedure p(x: integer; var y,z: in | | q(0,0) | | 6. var a: integer; | | p(1,0,1) | | 7. begin a := z-1; | | q(1,1) | | 8. if x>0 then q(y,a) | |=>p(2,1,2) | | 9. end; ^^^^^^ | | q(2,2) | | 10. | | p(3,2,3) | | 11. procedure q(u: integer; var v: inte | | test() | | 12. var d: integer; | +-----------------------+ | 13. begin d := u-1; | | x: 2 | | 14. if u>0 then p(v,d,v) else STOP | | y: 1 | | 15. end; | | z: 2 | | 16. | | a: 1 | | 17. begin | | | | 18. m := 2; | | | | 19. n := 3; | | | +------------------------------------------+ +-----------------------+ Finally, if the user clicked on the name of the program, "test()", he would get the point in the main program where the first call was made, and see listed all global variables: +=============== TEST CODE ================+ +===== TRACEBACK =======+ | 17. begin | | q(0,0) | | 18. m := 2; | | p(1,0,1) | | 19. n := 3; | | q(1,1) | | 20. p(3,m,n) | | p(2,1,2) | | 21. end^^^^^^^^ | | q(2,2) | | | | p(3,2,3) | | | |=>test() | | | +-----------------------+ | | | m: 2 | | | | n: 3 | | | | | | | | | | | | | | | | | | | | | +------------------------------------------+ +-----------------------+ So much of this is already present in pieces in the THINK Pascal debugger! Already, when the program hits a breakpoint, the code window is updated to show the current location of the program counter. All that would need to be added here is the capability to pull the appropriate return address off the stack, and display the source code at THAT location. Already, the Observe window allows the interactive display of variables, updated at every break. To create the lower pane of the traceback window, all that would need to be added is the ability retrieve the variable names in the selected scope, evaluate them in THAT scope, and to edit their values. This traceback feature would immediately increase the programmer's vision into his program's state during debugging. So often the problem is not in the current scope where the error finally forced a break, but prior, in a higher scope than the current call. It is highly valuable to be able to go back to previous scopes and first, see the location where the call came from, and second, to examine the local parameters and variables there. I want to thank Rich Siegel at the Symantec Languages Group, and all the others at THINK, for their excellent implementation of Pascal. I hope the above suggestions were clear, and of value. It's not often you get the opportunity to comment like this; I hope Symantec finds it worthwhile. Peter V. Homeier homeier@aerospace.aero.org