Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
OI string error
I noticed that the following code compiles and produces this result:
code
result:
z is equal to the character a followed by 5 space characters. In general, it seems that [string][number] gets turned into [string] followed by [number] space characters.
Is this bug, or is this intentional behavior?
code
z = "a"5
result:
z = "a "
z is equal to the character a followed by 5 space characters. In general, it seems that [string][number] gets turned into [string] followed by [number] space characters.
Is this bug, or is this intentional behavior?
Comments
So far it's been surprisingly easy. The most difficult part was the angle bracket arrays, but that actually turned out to be quite simple .
For example, here is an excerpt from the list of all of the top level statement in the program:
You can drill down into each statement (all the way down to the level of variable, string, number, "@variables" and null) by clicking on a statement:
So you can see that the case statement has 18 cases:
Click on a case to see the condition of the case and the statements that are in it:
The condition of the first case statement is an equality expression (click on it to see the sub-expression) , and it has 1 statement, which is another case statement:
Below are the statements from one of the internal subroutines in the program:
As you can see, the last statement is a return statement. I could write an analyser that checked for this, and warned if not present.
Not sure if others would find this tool useful? I will post the code online when I have cleaned up the code and accounted for all statements.
For some reason the basic + compiler allows you to use keywords as variable names, which is a very bad idea and leads to the following:
if(a > 3) then a+=1 end
The basic + complier (that comes with OI) thinks it's a function call and fails to compile. However, if you put a space between the if and the left parentheses, then it interprets it as an if statement. I have made my parser behave in the same way, but I think it's absurd.
Also, not sure why basic + assigns so many different meanings to the angle brackets.
If Return then Return else Return
If Return then Return Return else Return Return
:P
As you can see, both branches return a variable called return
v = else*3
but the following is illegal
v = 3*else
clearly else cannot be used in an expression, and the fact that it works in the first case is a bug in their compiler.
a = [1,1,3,4,5,10,11,12]
is valid and creates an @fm delimited array. of the numbers in the square brackets....
i had no idea you could do that.
https://github.com/jgschis/BasicPlusParser
I still need to clean up the code quite a bit and think of a better way of storing identifiers, but it seems to work... I should also create a thing that exports the ast as json and then you can interact with the ast in a gui...
feel free to integrate this with your editor somehow if you want...getting warnings about unreachable code would be good
and detecting that b is not definitely assigned would be useful, which the analyser can detect.
if a then b = 3 end b += 3
There are a few things I haven't done yet though and one thing I won't do
I wont:
I won't implement the "white space operator". I.e.,
v = a b
, as there is no reason to use this, and if you do use it , you've probably made a mistake.. It's also very difficult to implement, as you need to look very far ahead.To do:
1. Need to properly implement "@" variables. At the moment, it allows any variable to start with @, but this is not correct. Only certain variables may start with @.
2. Need to change the list that stores statements to a linked list, as this will make goto/gosub simpler. At the moment, the location the code should jump to is stored in a tuple whose first element is a reference to the list of statements the label is in, and whose second element is a number that represents its position in the list. It would be better to just store the reference to the label statement, which I could do if it were stored in a linked list.
3. The unassigned variable analyser doesn't take into account the goto, or ongoto or ongosub statements yet. But adding them in should be quite simple.
I still need to implement "hover" popups, so when you hover over a function, it puts up a popup with info about it. Could also do that for equate variables. Also need to figure out how to integrate this with OI, as all it's doing at the moment is reading a text file.
Tom