Arrangin simple way to follow lines and statements.

[E.K.Virtanen]

Hi all.

I would like to support multiple statements in line for end-users. Currently i have figured two ways to do this. In my previous project (osBasic) i tested both. First was very easy, but slow. Second was fast, but way harder to produce.

In first way, line was readed and stored fully in array$(x) and parsed from there. That caused looping through the line when finding next statement and made it slow. On the other hand, it was easy to loop through the string until seperator ( was found. I had quot() function with what i was able to track was : inside of quots or not.

Second way was that i stored each statement seperately in array. This way, it was very easy to move on next statement, just by increasing curStatement by 1. This caused problem to follow up in which line the statement was. Only way i could figure it out was to create seperate array to track lines, and in lineArray() i stored number of the statement which was first in that line.

In cases where there were multiple statements in line, rest of the statements had not pointer in which line the statement was. I needed to loop through the lineArray() until lineArray(x) was >= than curStatement and lineArray(x+1) was <= than curStatement.

Second way is better, though it is more complex.

To avoid this, i could store statements in 2-dimensional array, where statements(x, 1) is the statement and statements(x, 2) is the line number where statements locates.

For this, i need language which allows me to create user types and define the first cell as string and second cell as integer. That is not a problem though. I could also use regular string array, and use known basic function VAL() to track line number even if it is stored as string.

Since i am not pro. and i have done 99% of codings from my own imagination, i would appreciate offered ideas before i start to build the engine.

Thanks, E.K.Virtanen

[MystikShadows]

I would use a 3 field thing. 

Line Number
statement Number
Statement

so when you load the source file you would load it as such in your array.

100 1 PRINT "WHATEVER"
100 2 COLOR 15,0
100 3 SOMETHING ELSE

and so on, this way, you don't have to keep track as much, because the statement number (middle column) is already telling you that information. 

either a 2 dimentional array, statements(3, XX)  XX = number of lines.  or a TYPE

Code: [Select]

TYPE SourceCode
     LineNumber      AS INTEGER
     StatementNumber AS INTEGER
     Statement       AS STRING
END TYPE

I would use the TYPE instead, because after, when you condition in this, condition for numeric values is much faster than comparing string values.  might make your whole interpreter faster.

[Steve A.]

Languages that allow compound statements confuse me.
ie:
 Print "hello": age=100: name$=Dave:

I found them hard to parse, for the very reasons stated by E.K. above.
Early BASIC programs were full of this kind of stuff.
ie:
  GOSUB 200: GOSUB 300: GOSUB 400:
  IF yes THEN GOTO overthere ELSE GOTO somewhere

Make my eyes hurt.

Early on, when designing Bxbasic, I made the decision that compound statements would not be allowed.
Hence, one line, one statement.

[jcfuller]

I agree Steve. I rarely use them. The only exception is with MACRO's in PowerBASIC.
My preferences is carried a bit further with no single line IF statements.

James

[E.K.Virtanen]

Parsing the statements is not the problem. Problem is to track them down from statements() and keeping track also about the line number where statement exists, unless you use lot's of ram by using huge arrays.

Mystiks idea is neat, i have tested it, it works but im wondering way to make it with less ram usage.

Early on, when designing Bxbasic, I made the decision that compound statements would not be allowed.
Hence, one line, one statement.

Aye, i agree. However i cant decide how the rest of the world thinks so i ratherly allow multiple statements per line.

[Pjot]

Hi E.K,

I have replied here: http://www.allbasic.info/forum/index.php?topic=12.msg53#msg53

Also some code. Hope it helps!

Peter

[E.K.Virtanen]

Pjot: Noticed 

[Steve A.]

Parsing the statements is not the problem. Problem is to track them down from statements() and keeping track also about the line number where statement exists, unless you use lot's of ram by using huge arrays.

Yes, I agree and understand.
"If a compound statement has 3 statements in it, which one caused the error ?"

Ram usage, (IMHO),  should not be your major concern. Today, ram is cheap.
Whether 3 or 4 statements are formed on a single line, or, if they take 3 or 4 separate lines is of no consequence.
It still takes the same amount of ram to store the statements.

Mystiks idea is neat, i have tested it, it works but im wondering way to make it with less ram usage.

During parsing, each statement has to be tokenized and stored in an array, linked list or structure of some type.
If one element (integer) refers to which statement number and one element (integer) refers to what line number, that's all you need.
Not a huge waste of ram.

Aye, i agree. However i cant decide how the rest of the world thinks so i ratherly allow multiple statements per line.

I'm affraid you will never be able to please the rest of the world.
That's why there are so many different programming languages, let alone dialects.
Even languages developed at major universities have failed because they couldn't attract an audience.

It seems that unless a language has the word "Visual" in front of it, it doesn't get a lot of respect from serious programmers or institutions.
If you don't believe me, just Google: "programming jobs".

[codeguy]

as you will be able to see from my programs on qb64, i RARELY write compound statements in a line. my general rule of thumb is one statement per line and liberal use of structure statements (if/then/else, select case, etc) and i also VERY rarely use GOTO. for the sake of someone who may have to examine your code, you should really stick to the one command per line rule i generally enforce upon myself. and also, line numbers are not as descriptive as line labels. GOSUB DoSomeTask is far easier for me to decipher than GOSUB 2000. this is simply a matter of personal style. but line numbers are no longer the required norm and i very strictly choose line labels over line numbers. if you choose to follow the one statement per line rule as closely as possible, it will make life for ALL of us easier, including the compiler. one of the reasons basic got a bad rap is that same reason. it allowed spaghetti code that made following logic difficult at best. i have seen some HORRENDOUS code even from instructors, the same ones who presented the worst the programming world had to offer (bubblesort, for one), use of recursion when it is not necessary (recursive factorial -- ugh!). it has taken me a while to "unlearn" these bad habits. i learned how bad they were as i learned pascal, a language that strongly discourages but still allows some degree of pasta. i have experience in cobol and the arcane structure of jcl (DD SYSOUT=*). it was no fun learning the ins and outs of cobol, jcl and mainframes, just as it was no fun having the structure police of pascal. structure should remain a choice, but i think the better the structure, the better the program is overall. and i usually use variable suffixes, although as of late i have started using AS (integer, string,etc). i prefer suffixes because i can tell at a glance EXACTLY what kind of variable i am dealing with. i use longints because their range is good and they are not slow as doubles. i know many of the tricks of searching, sorting and things of that nature. i've even been known to practice a little "string fu," as another programmer put it. so unlike my writing, my programs are almost guaranteed to be structured and easily adapted.