APL Wiki Tutorial: Difference between revisions
No edit summary |
(expanded on error trapping) |
||
| (6 intermediate revisions by 4 users not shown) | |||
| Line 5: | Line 5: | ||
== Chapter 6: "Writing a Function" == | == Chapter 6: "Writing a Function" == | ||
=== "Saving a workspace" === | === "Saving a workspace" === | ||
Using Windows default | Using Windows default folder (NARS2000) versus current directory (other implementations). | ||
== Chapter 10: "Built-in Functions" == | == Chapter 10: "Built-in Functions" == | ||
=== "Comparative Functions" === | === "Comparative Functions" === | ||
"Find" is not available | "Find" is not available | ||
== Chapter 14: "Error Handling" == | == Chapter 14: "Error Handling" == | ||
=== Error | === Error Trapping, Debugging and Tracing === | ||
Currently NARS2000 | Currently NARS2000 offers both [[System Variable ELX|<apll>⎕ELX</apll> Error Latent Expression]] and [[System_Function_EA|<apll>⎕EA</apll> Execute Alternate]] for error trapping, two very helpful exception-handling / run-time-error-avoidance techniques or APL features, when used correctly.<br><br>To intentionally cause APL to halt just after the user-function line of code you wish to examine, place a line of APL code which looks something like 'a'÷1 right '''after''' the complex or not fully-understood line of code you wish to examine more closely. Since the APL interpreter cannot divide a string by a number, it will fail so you can examine the intermediary user-function results closely. Obviously, after you better understand how the user-function is working, you can then delete the 'a'÷1 intentionally inserted error, sometimes called code scaffolding since it is removed once the user function is corrected or complete - a process called debugging and or code testing. APL frequently makes use of complex idioms and debugging helps better understand the way the idiom(s) may be working. Important: Frequently comment your code with ⍝ so you remember what the code was supposed to be performing! | ||
<br><br>See also '''[[Examples/Files]]''' for a user-function example of ⎕ELX use. Default value for Quad ELX: ⎕ELX←"⎕DM" | |||
<br> | |||
Latest revision as of 00:40, 5 February 2015
The APL Wiki Tutorial contains several references to NARS2000 regarding extraordinary behaviour and/or missing features. See http://aplwiki.com/LearnApl/LearningApl
The following shall be a complete list of those issues. Used to make changes to the wiki when appropriate.
Chapter 6: "Writing a Function"
"Saving a workspace"
Using Windows default folder (NARS2000) versus current directory (other implementations).
Chapter 10: "Built-in Functions"
"Comparative Functions"
"Find" is not available
Chapter 14: "Error Handling"
Error Trapping, Debugging and Tracing
Currently NARS2000 offers both ⎕ELX Error Latent Expression and ⎕EA Execute Alternate for error trapping, two very helpful exception-handling / run-time-error-avoidance techniques or APL features, when used correctly.
To intentionally cause APL to halt just after the user-function line of code you wish to examine, place a line of APL code which looks something like 'a'÷1 right after the complex or not fully-understood line of code you wish to examine more closely. Since the APL interpreter cannot divide a string by a number, it will fail so you can examine the intermediary user-function results closely. Obviously, after you better understand how the user-function is working, you can then delete the 'a'÷1 intentionally inserted error, sometimes called code scaffolding since it is removed once the user function is corrected or complete - a process called debugging and or code testing. APL frequently makes use of complex idioms and debugging helps better understand the way the idiom(s) may be working. Important: Frequently comment your code with ⍝ so you remember what the code was supposed to be performing!
See also Examples/Files for a user-function example of ⎕ELX use. Default value for Quad ELX: ⎕ELX←"⎕DM"
