SmallBasic Open Edition

[KristianVirtanen]

Hi,

This project (SmallBasic Open Edition) is part of a larger whole, where the goal is to recreate Microsoft SmallBasic, at least in its main features.

The first phase of the project, which is exactly this, is to create the same classes as in SmallBasic: Text, Math, GraphicsWindow, and so on. The project is mostly complete, although types for variables, some small tests, and so on are still required.

Note: The classes Array, Flickr, and Dictionary have not been created.

Array is missing because I have not yet decided on the final way the future compiler will handle arrays. I have a couple of different solutions for this, but I haven’t had time to decide yet. 

Flickr is missing because I am simply not very familiar with this service, and their API is completely unknown to me. 

Dictionary is a class I’m not sure if I want to spend time on, at least not personally.

Unlike the original SmallBasic, Open Edition converts SmallBasic code into the C# programming language and compiles it afterward. This brings significant advantages in terms of memory management, speed, and extensibility.

Variables will function mostly the same way as in the original SmallBasic. This is made possible by C#’s dynamic. However, the idea is that variables will require a suffix of "$" at the end of their names. Not only does this make the programs easier to compile, but I also believe it helps distinguish variables and makes coding a bit easier.

The program that tokenizes and converts SmallBasic code into C# is also mostly done. However, at the moment, it's more like a pile of sticks rather than a well-designed and structured program, so its release will be more appropriate at a later time.

Example SmallBasic program:

Code:

' Example Smallbasic program
x$ = 1
y$ = 2
c$ = "Foo"
TextWindow.WriteLine(x$ + y$ + c$)
SayHello()
Goto MyLabel:
TextWindow.WriteLine("I'm never printed.")
MyLabel:
Program.End()
Sub SayHello
    TextWindow.WriteLine("Hello")
EndSub

Converted to C#:

Code:

// Converted as C#
namespace SmallBasicOpenEditionDll
{
    public static class SB_Program
    {
        // Declare dynamic variables (similar to Smallbasic's dynamic typing)
        public static dynamic x = 1;
        public static dynamic y = 2;
        public static dynamic c = "Foo";
        // Entry point of the program
        public static void Main()
        {
            // Equivalent of TextWindow.WriteLine(x$ + y$ + c$)
            TextWindow.WriteLine(x + y + c);
            // Call the method SayHello()
            SayHello();
            // This line will not be executed
            Goto MyLabel:
            TextWindow.WriteLine("I'm never printed.");
            MyLabel:
            Program.End();
        }
        // The equivalent of SmallBasic's subroutine 'SayHello'
        public static void SayHello()
        {
            TextWindow.WriteLine("Hello");
        }
    }
}

Note: I work with this while I am working with two job's and such, so this will not move forward in fast speed. Help is appreciated here. Let me know

[KristianVirtanen]

Dang, sorry. I guess this would have belong here instead.

[litdev]

Thread moved here as suggested.

Nice work Kristian,

This is my understanding of what you are doing.

So far what you have on GitHub looks like a reworking in C# of most of the standard objects (effectiively SmallBasicLibrary.dll written without reference to Primitive types).  You also suggest you are mid way through writing a syntax converter between a Small Basic (like) syntax and C#.

I would suggest that it would be a good idea to make the language converter 100% compatible with standard Small Basic if possible - there is just such a large backlog of Small Basic programs and it would be fantastic to progress users to C# using this resource.  For example I feel this is one unfortunate issue that sVB has - it is similar but not compatible with original Small Basic syntax - it would have been great to extend the language (not change it); this also applies to the various other online SB variants.  

One big hurdle I see with migration to C# from SB is the daunting complexity of Visual Studio (and to a slightly lesser extent SharpDevelop) - some way to ease this pain would be good.  What kind of interface to envisage for your program - it could even be a plugin for VS, VS Code, SB-Prime.

If you don't want to make a direct clone of SB, but extend its capabilities, then I would still consider making it 100% backwards compatible with extra features.  If you do fancy writing a direct clone of SB, then perhaps you could make it run on linux and Mac - this is certainly a missing feature now - quite a lot of work, but doable with .Net core.  Not being able to use existing extensions has always detered me from this!

I assume you know that any compiled exe of Small Basic program can be converted to C# using .Net reflection tools fairly easily.  Therefore, it would be good to consider how your work would complement this capability - I assume using C# without the Primitive types.  Perhaps showing the C# equivalent to SB code alongside the SB code in an interface.

I may be wrong and it would be good to get other input about the biggest challenge programmers find migrating from SB to C#.

In summary, I would try to get a clear plan of what you would like the final version to do, then identify the challenges (stuff you are not sure how to do) and work on these.  This would influence the code you write - for example static dynamic types, arrays, lists, maps etc.

Anyway, great work so far and I hope that we can help Small Basic users migrate to C# once they have a good grasp of Small Basic.

[z-s]

i think this is good idea.
why you are using $ for variables i think you should see the variable regex of sb prime.

[KristianVirtanen]

Hi,

First of all, I want to clarify that the goal here is not to create SmallBasic exactly as it was. My idea is somewhat similar to what FreeBasic did back when QBasic was becoming "outdated." FreeBasic could compile 99% of QBasic code, but at the same time, it offered much more than that old workhorse from the DOS era was capable of.

SmallBasic is still quite pleasant and usable, but unfortunately, its time is running out. If I understand correctly, it hasn’t been updated in years, and its source code is not available.

SmallBasic Open Edition is not an updated version of SmallBasic, but rather an interpreter that strives to translate the original SmallBasic code into C# as accurately as possible, and then leverages the existing C# compiler to create a runnable program.

In my opinion, the most important single aspect here is replicating the original SmallBasic library (smallbasic.dll). Most of the code written in SmallBasic relies on using the classes and methods in that library. By creating a copy of this library, I save a significant amount of coding when it comes to the interpreter itself, as the classes and methods already present in the library don’t need to be handled further. Adding, modifying, or removing classes and methods is relatively easy for anyone with proficient knowledge of C#.

The project does not depend on the "Primitive" type variables found in the original SmallBasic. The same outcome is achieved in C# using the "dynamic" type, which allows the type of content in a variable to change on the fly. My project allows this, but it does not force the user to take full advantage of C#'s type system.

I still need to do a bit more polishing on the library I’ve released now, but I don’t think it will take too much longer. Then I can focus on the interpreter that translates SmallBasic code to C#. Initially, I made the mistake of trying to work on both at once, and that’s why the interpreter is still in a very rough state and not ready for release even as early beta.

Once I get the whole package together, expanding it will be much easier. If something is possible in C#, then adding it to my project will also be possible.

As for variable naming, I knew I’d be stirring up a hornet’s nest—some might even call it “witchcraft.”

This hasn’t been set in stone yet. Whether the interpreter requires a "$" suffix for variable names or not is ultimately a minor adjustment. However, in my opinion, distinguishing variables with a "$" suffix makes the code more readable and less prone to guesswork. But as I said, this isn’t set in stone yet.

[z-s]

SmallBasic is still quite pleasant and usable, but unfortunately, its time is running out. If I understand correctly, it hasn’t been updated in years, and its source code is not available.

The source code of small basic could be found here
And the smallbasiclibrary.dll is here
Good project we could make csharp to a basic level.

[KristianVirtanen]

Oh cool. I was not aware of that the source is available...though i have not looked much
Would have made things easier for start, but it does not matter anymore at this point.

[Scout]

Hi Kristian,
your idea would also enable another great application.
It could also convert a SmallBasic program into a C# program that can be further processed in a C# IDE.
Small Basic can therefore export to VB.NET and Open Small Basic to C#.

My comment on your devil's work$:
If all variables in Open Small Basic require a postfix $, all of the previous Small Basic source code would not run.
Conversely, the Open Small Basic source code does not run in Small Basic and Small Basic Prime because variable names with $ are not allowed there. So far I only know the postfix $ in Basic as an identifier for string variables (Liberty Basic,...). It would be a nice extension of Open Small Basic to use the postfix $ to set a variable to string so that no complicated constructions are necessary when assembling strings.

Have fun and perseverance in realizing your idea
Scout

[litdev]

@Scout,

The SB-Prime option (Advanced->Decompile) does the same as Graduate, except that it converts to C#.  It takes as input a pre-compiled SB exe.

[Scout]

@litdev,
thanks for the tip. I tried it straight away with the Chessengine program that operates the console and the graphics and of course it failed.
It's like exporting to VB.NET. Source code and a project file are created, but how do they fit into the development environment (in this case VS 2017). Small Basic seems to be somehow more error-tolerant than the VS languages.
That's why I think that the C# source code that is created directly from the SB source code should be cleaner and easier to port to the new development environment. Especially if it has already been converted to an SB exe as C#.
I'll show my failed attempt in another thread so as not to stray from the topic of Open Small Basic: https://litdev.uk/mybb/showthread.php?tid=148