Differences

This shows you the differences between two versions of the page.

--- computers:arduino:breeze [03-Jun-2019 10:32] – Steve Joynt
+++ computers:arduino:breeze [02-Feb-2025 16:14] (current) – external edit 127.0.0.1
@@ Line 146: / Line 146: @@
 display ( 5 + 7 )
 </code>
+This executes the command called "+" with "5" as the first parameter and "7" as the second. The same interface can be used to call native C functions that we use for square brackets. The called C function does not need to know if it has been triggered by [ ] or ( ).
 If we want to add three values together, we will unfortunately need to call the "+" function twice.
@@ Line 165: / Line 167: @@
 The word "goto" on line 100 is accepted by "if" as its second parameter, but otherwise ignored.
-The command "goto" on line 200 is always executed, even if the condition is false. Can you guess why?
+On line 200 there is a coding error, but not a syntax error. The command "goto" will always executed, even if the condition is false. Can you guess why?
+==== Named Sections of Code ====
-==== Named Labels For GoTo ====
 I think it would be a good compromise to allow the "goto" command to support named places within the code, rather than just use line numbers all of the time. This way, sections of the code can be divided up in the same way that "functions" are defined in other languages. This would make it easier for the programmer to remember where sections of the code are, rather than having to remember line numbers. This would require a little more C++ coding on the Arduino, but would make the scripting language much easier to use. Each line must still have a line number, as they are used when editing the script via the command line interface.
@@ Line 173: / Line 174: @@
 I propose to use the hash character "#" as the "command" to define a label. In many programming languages, the hash character indicates a comment, and so it is not executed by the interpreter. Labels also contain no executable code, so this feels intuitive to programmers, and is understood by many syntax highlighters.
-The first parameter will be the name of the label, and must be unique within the script. More parameters may be supplied, but will be ignored as comments, but beware of using [brackets] or (brackets) within the parameters as they will be executed as usual. It is recommended to enclose any comments in quotes.
+The first parameter will be the name of the label, and must be unique within the script. If there are no parameters, the command does nothing at all.
+More parameters may be supplied, but will be ignored as comments, but beware of using [brackets] or (brackets) within the parameters as they will be executed as usual. It is recommended to enclose any comments in quotes.
+If the first parameter is "#", it does not need to be unique and it is ignored. This form can be used to continue the comment from the previous line, to describe this subroutine in more detail.
 <code>
@@ Line 185: / Line 190: @@
 <code>
-# CountDown : This is the entry point to this sub-routine
+# CountDown "This is the entry point to this section of code"
+# # "It counts down from 10 to 1, then signals 'Blast Off'"
 set count 10
 # CountDownLoop
@@ Line 195: / Line 201: @@
 display "Blast Off!"
 </code>
+==== Calling Subroutines ====
+As one of the primary ideas of this script language is to make the interpreter as compact as possible without compromising too much on readability and usability, it would be good to have a way of re-using sections of script, rather than duplicating code.
+Most languages have the concept of a subroutine. Some call it a function or a method or procedure. I have called it a subroutine in this documentation because I plan to implement it like subroutines in the BASIC language.
+BASIC has the keywords "gosub" and "return". The "gosub" command works like the "goto" command, but remembers where it came from, so that when a "return" command is encountered, execution continues with the line after the "gosub" command.
+It is not possible to pass parameters to subroutines in BASIC using the "gosub" command, but you can define some variables before calling a subroutine, and that routine can return values by setting other variables. In this case it would be good to name the variables associated with the subroutine in a way that makes it obvious what they are related to, and also to prevent clashes with variables used by other subroutines.
+<code>
+set AskUser.question "Which country do you come from?"
+gosub AskUser
+set AskUser.question "Why have you come here from "[ get AskUser.answer ]"?"
+gosub AskUser
+set AskUser.question "Are you a spy?"
+gosub AskUser
+display "I don't believe you!"
+end
+# AskUser "Keep asking a question until we get an answer"
+display [ get AskUser.question ]
+input AskUser.answer
+if ( [ get AskUser.answer ] == "" ) goto AskUser
+return
+</code>
+==== Calling External Subroutines ====
+Many programming languages have a way of calling sections of code that are not part of the current program. This allows greater re-use of code and makes it easier for groups of people to work together on a project. It also makes it easier to test sections of code in isolation, then include them as part of a larger project.
+The BASIC language has a command called "chain". This allows the current program to be replaced by loading the named program into memory, but without losing any of the current variables. Normally the "load" and "run" commands in BASIC would clear all variables.
+So the variables don't "belong" to the current script, but they can be freely read and updated by it. They can be thought of like "environment variables" in MS-DOS, or Linux/Unix command shells, or "global variables" in most programming languages.
+Rather than adding a new command like "chain" to my script language, I plan to extend the syntax of the "goto" and "gosub" commands. It would be easy to allow a second parameter to these commands that would specify the name of another script to execute. The first parameter being the line number or label name to jump to within the destination script. The "return" command would need a little extra code as well to enable it to switch back to the original script.
+Switching between scripts in this way would be slow if the source code needed to be loaded into memory each time, but I will be using an [[AVL Tree]] to store the script (indexed by line number). Switching from one script to another simply requires the old file to be closed and the new one to be opened. There is no need to read large amounts of data into memory, as each line of the program is read only when it is needed.