gBasic

[Steve A.]

Okay,...
It took me a little longer than I anticipated to work out the kinks (being new to SB).

Here is a link for gBasic v.01 translator:
http://sites.google.com/site/bluntaxebasic/Home/updates/gbasic.zip

Its primative and it's language support is extremely limited, but, many of the translator functions that will be needed down the road are already in place.

In the zip, there is a readme.txt that explains, in some detail, how to use gbasic.bas.

[JRS]

Nice Job Steve!

This is a huge boost for the project and hope this will get others to join in.

BTW:

CALL is only needed if you reference a SUB before it's declared in your script. I'll do a quick test to validate this comment.

If you put C:\scriptbasic\bin in your environment PATH, you can use scriba from anywhere.

The $ is optional in SB for strings and string functions. It doesn't matter to me if you use them or not.

Thanks for the great effort to get gBasic rolling.

[Steve A.]

CALL is only needed if you reference a SUB before it's declared in your script.
If you put C:\scriptbasic\bin in your environment PATH, you can use scriba from anywhere.
The $ is optional in SB for strings and string functions. It doesn't matter to me if you use them or not.

Hey John,
Personal preferences:
re: CALL::  I just want to be consistant with other dialects that require CALL,
re: PATH:: Yes, I just don't like adding crap to my environment if I can avoid it.
re: $::       I prefer to specify data types, especially character string data.
     

[JRS]

Life is good and your standards are fine with me.

[JRS]

Here is the first gBasic script translated to C.

Code: Text

1. '  this is a test
2.  
3. '
4.  
5.  
6.     PRINT "Hello World!"
7.  
8.     PRINT "My name is Steve"
9.  
10.     END
11.  
12.  

Code: C

1. //      ************* gBasic Compiler *************
2.  
3. //      Copyright: s.arbayo (c) 2011
4.  
5.  
6.  
7. /*--------------------- DECLARE HEADERS ---------------------*/
8.  
9. #include <stdio.h>
10.  
11. #include <stdlib.h>
12.  
13.  
14.  
15. /*------------------- Function Prototypes -------------------*/
16.  
17.  
18.  
19.  
20.  
21. /*---------------------- BEGIN PROGRAM ----------------------*/
22.  
23.  
24.  
25. int main(int argc, char *argv[])
26.  
27. {
28.  
29.     printf("Hello World!\n");
30.  
31.     printf("My name is Steve\n");
32.  
33.  
34.  
35.     return 0;
36.  
37. }
38.  
39. /*--------- end main ---------*/
40.  

jrs@Laptop:~/gBasic/gBasic_01$ gcc test.c -o Hello_Steve
jrs@Laptop:~/gBasic/gBasic_01$ ./Hello_Steve
Hello World!
My name is Steve
jrs@Laptop:~/gBasic/gBasic_01$


7,090 Byte executable.

[JRS]

I installed MinGWTDM under Wine and compiled Steve's gBasic program.

C:\gBasic>gcc test.c -o Hello_Steve.exe

C:\gBasic>Hello_Steve
Hello World!
My name is Steve

C:\gBasic>

27,527 Byte executable.

[JRS]

Steve,

I notice this line of code in the translator and wasn't sure if you are trying to concatenate the string.

     xstring$ = xstring + ch$

xstring$ and xstring are two distinct variables.

a = 1
b = "2"

c = a + b

This would return 3 as the + indicates to SB that a math operation is being done

c = a & b

This would return "12" as the & tells SB that the two variables are to be concatenated.

SB also supports the following.

xstring$ &= ch$

[Steve A.]

Ahh!,
habits are hard to break.
I can't tell you how many times that came up, where the code (related to strings) wasn't working, only to find that I had substituted a "+" for a "&".
And, leaving off the "$" in that case was simply a typo.
Thanks for pointing that out.

I spent last evening fixing some other bugs, too.

[Steve A.]

I've uploaded a new zip with some fixes:
http://sites.google.com/site/bluntaxebasic/Home/updates/gbasic.zip

Repaired some typos that got by me.

[JRS]

Thanks Steve!

The translator is taking shape and I'm glad your getting comfortable with SB. Looking forward to the next release.

I split the topic at the first release as the thread was getting a bit long.

I encourage those that are interested in the gBasic project to get a copy of SB and MinGWTDM and follow along. If your able to contribute, all the better.

[JRS]

Code: [Select]

' ----------------------------------------------
' ========== Declare Global Constants ==========
' ----------------------------------------------
    Const BUFSIZE = 256
    Const TOKENLEN = 21
    Const VARNAME = 33
    Const LLEN = 33
    Const IOARRAY = 99
    Const PATH = 129
    Const RECLEN = 128
    Const bTRUE = 1
    Const bFALSE = 0

I noticed your comment of Global Constants and thought I would clarify what GLOBAL means in ScriptBasic.

By default, all variables are global to the module. MAIN:: is the primary module in SB. Unless you declare a variable LOCAL in a SUB or FUNCTION, it is a global variable.

GLOBAL CONST  allows you to assign a constant that can be accessed in any module. A typical example of GLOBAL CONST might be to assign a newline escaped sequence to a constant.

GLOBAL CONST NL = "\n"

PRINT "this is a test",NL

BTW: PRINTNL is a shortcut to just print a newline and nothing else.

[Steve A.]

I noticed your comment of Global Constants and thought I would clarify what GLOBAL means in ScriptBasic.
By default, all variables are global to the module. MAIN:: is the primary module in SB.

Okay, I'm glad you did.
I was unclear about scope. Generally speaking, in Basic, variables and constants are global, but, after reading the docs I was unclear. The docs are a bit shy on illustrations and examples. I wanted to expedite the process and not take chances of a constant not being recognized.

Unless you declare a variable LOCAL in a SUB or FUNCTION, it is a global variable.

Ummm..., does that mean that vars declared within a SUB are global in scope, if not declared as LOCAL ?
My assumption (and hope) would be that they would be LOCAL only to that SUB and be destroyed on exiting the SUB, regardless of being declared as LOCAL.
i.e.:
SUB MySub
   myint = 100
   mystr$ = "hello"
'   do stuff
END SUB

...MySub.myint no longer exists.
...MySub.mystr$ no longer exists.

would this be true or not ?

The matter of scope has been a topic of much discussion from the eariest programming languages and seldom agreed upon from one language to the next.

[JRS]

I'll explain by example.

Code: [Select]

FUNCTION test(arg1, arg2)
LOCAL a,b,c
  a = "one"
  b = "two"
  c = "three"
  PRINT my_global_var,"\n"
  test = arg1 + arg2
END FUNCTION

a = 1
b = 2
my_global_var = "John"
PRINT test(a,b)

END

This script would display the following.

John
3

I had mentioned that SB supports name spaces. (modules)

Code: [Select]

MODULE Steve

SUB SA()
  PRINT a,"\n"
END SUB

END MODULE

a = 1
CALL Steve::SA()

This would print undef as a is assigned in the MAIN:: name space and not in the Steve name space.

Even though its legal to access variables from other name spaces, it defeats the purpose of coding with modules. (there is always an exception to the rule and breaking it should be a programmers choice)

a = Steve::a

OR

a = MAIN::a

GLOBAL can be used to make a variable or CONST global among all modules.

You can INCLUDE code at any point in your script.

INCLUDE "\scriptbasic\gBasic\myfunctions.bas"

If your using the basic|scriba.conf configuration file, the module (DLLs) and include(module .BAS) directories are defined there. This is normally used for extension modules that contain DECLARE SUB ext_func_name ALIAS "dll_func_name" LIB "lib_name" and any Basic code that supports that module.

IMPORT mysql.bas

The difference between INCLUDE and IMPORT is that IMPORT will only include the file|ext module once.

[JRS]

I would also like to mention that duplicate label names are allowed if used within context.

Code: [Select]

' Test labels

SUB Test1
  GOTO IT
  PRINT "FYI, I'm in Test1\n"
IT:
END SUB

SUB Test2
  GOTO IT
  PRINT "FYI, I'm in Test2\n"
IT:
END SUB

TEST1
TEST2

GOTO IT
PRINT "FYI: I'm in MAIN\n"
IT:

END

jrs@Laptop:~/SB/test$ scriba testlabel.sb
FYI, I'm in Test1
FYI, I'm in Test2
jrs@Laptop:~/SB/test$ scriba testlabel.sb
jrs@Laptop:~/SB/test$

I remarked the GOTO lines in both subs to show that the SUBS are being called in the first test run and then unremarked the lines for the second run.

[JRS]

Ummm..., does that mean that vars declared within a SUB are global in scope, if not declared as LOCAL ?
My assumption (and hope) would be that they would be LOCAL only to that SUB and be destroyed on exiting the SUB, regardless of being declared as LOCAL.

I have to disagree on the LOCAL as default being the rule. I find it a pain in the ass to have to pass needed working variables as arguments. To me SUBs & FUNCTIONs are just routines and if I want isolation, a one line LOCAL statement declaring variables used for that purpose is painless. If one desires a more modular approach, use name spaces.