How will we implement looping in the Erasmo-language? I'll start by postulating two basic looping functions, the summation loop and the selection loop. Both loops perform their looping over the set of characters. The first takes the form CharacterSum(expression). In this case, expression is any group of terms and operators yielding a valid numeric result. Thus, a simple example might look like this: CharacterSum(Greed[Who] + Pride[Who]).
Here we run into an immediate problem with respect to the editor. What happens if the storybuilder attempts to put an arguement into the Greed or Pride values? Perhaps the solution here is to declare that, if the unspecified term is left, then the function will automatically use the index value, while if a specified term is entered, then the function will carry out the specified calculation. Yes, I like that.
The S-code string for the above example would look like this:
Unspecified
Pride
Unspecified
Greed
+
CharacterSum
Now, how are we going to tell the interpreter to treat this as a loop? It must have a warning token just before the first Unspecified to allow it to set up a loop. Ideally the warning token would be the CharacterSum token. But the editor requires that token at the end of the grouping. We have a problem here.
Perhaps we can kluge our way past this problem with a second arguement in CharacterSum. If it looked like this: CharacterSum(Greed[Who] + Pride[Who], LoopSignalToken), then the S-code string would look like this:
LoopSignalToken
Unspecified
Pride
Unspecified
Greed
+
CharacterSum
This approach has two flaws: first, LoopSignalToken does not indicate what kind of loop the interpreter will face. Second, what if the storybuilder edits the value of LoopSignalToken?
OK, here's another approach: there's just one function, called Loop, and it takes an arguement that specifies the character of the loop. Thus, we have the following structure:
Loop(Greed[Who] + Pride[Who], CharacterSum)
yielding the S-code string:
CharacterSum
Unspecified
Pride
Unspecified
Greed
+
Loop
Then all we do is create a new data type called LoopType, and all loop types are entered on this data type.
This is good, but it's harder for the storybuilder to read. Shouldn't we make Dave work a little harder with the first structure so that the storybuilder doesn't work as hard reading her own code? Here's another arguement in favor of the first system: using Loop at the outer level leaves us with untyped values, whereas identifying the looptype outside (rather than inside as an arguement) allows us to carry the datatype out to where the storybuilder can use it to advantage. That seals it.
So, what loop functions do we want?
CharacterSum: returns sum over all characters of arithmetic expression
CharacterSelect: returns index number of character matching boolean expression
CharacterSelectedSum: returns sum over all characters who match included boolean expression of included arithmetic expression
any other ideas?