A new compiler for Small Basic: suggestions welcome! RRS feed

  • General discussion

  • Hello SB Forum!

    I have been working on a new compiler for Small Basic and hope to include it as the default compiler in the next version of SB IDE++. The compiler takes a raw Small Basic program and emits PEVerifiable IL code in an EXE. I intend to make the compiler fully open-source once it is finished.

    I understand that one of the main goals of the SB project is to keep the language as simple as possible. However, I know that some people are running into the limits of the compiler but are still not ready to make the leap to VB or C#. In my compiler, I would like to add some features to make the language a little more advanced but still user-friendly. Here are some ideas I have:

    *Subroutine arguments (and maybe scoped variables)

    *Simple exception handling

    *True arrays

    *Additional operators (such as +=, -=, /=, *=, %, bitiwise, etc.)

    *Support for compilation to DLLs

    *Support for compilation of multiple files so source files don't become so large

    These are just some ideas: please feel free to add your own or comment! 

    Please mark any answers and "vote as helpful" any posts that help you!

    Friday, January 24, 2014 2:13 AM

All replies

  • Hey gungan

    Here's some ideas & observations?

    One thing I've seen asked a few times on the forum is: can I get my sb program to open another sb program? Or perhaps open any other program for that matter.

    Then when the other program opens have the option of closing the first. Perhaps even then resuming another programs execution.

    Also would it be possible to add a custom pic in the top left corner of the program/window title?

    • Edited by Jibba j Friday, January 24, 2014 4:11 PM
    Friday, January 24, 2014 4:10 PM
  • @jibba Jabb

    Other programs (including another compiled SB exe) can be started with LDProcess.Start and an icon can be set in GW if this is what you mean using LDUtilities.Icon.


    My guess is that function arguments and integer indexed arrays are the main requests.  Your other ideas also sound fun.

    Friday, January 24, 2014 6:37 PM
  • Litdev, wow that's good. That's exactly what I meant.

    I don't know if this is a good idea or not, but I've installed some of the extensions, had a bit of a look, but have put off doing anything with them because there's still a few more things I want to learn that I thought native sb might be good for.

    What do you think?

    • Edited by Jibba j Friday, January 24, 2014 7:13 PM typo
    Friday, January 24, 2014 7:11 PM
  • Whatever suits you - extensions don't really help learning much - they just allow you to do more and introduce some new functionality, programming ideas or methods in a familiar SB environment.  For some,  this opens new opportunities to program the sort of thing that interests them from SB (e.g. 3D, databases, more GUI controls, physics simulation, USB control etc.).  Also they can be fun to write - main reason I write one, and I guess why gungan wrote SB IDE++ and is working on an extended compiler.

    Learning the way you are is the most valuable, but you don't have to know everything before trying new things.

    Perhaps also try out C# or java as well.  You are getting pretty good at SB.

    • Edited by litdev Friday, January 24, 2014 8:06 PM
    Friday, January 24, 2014 7:33 PM
  • Litdev, thanks for sharing that, and the fb.

    For me it's just starting to become a tug of war between stubborn shores and new horizons.

    Put sb on the shelf for a month or 2 and concentrate on c#, then come back, learn more, finish some wish list projects and use some extended classes AND OR reassess my learning needs and wants.

    SB community and MSDN has been a great help in updating my own approach. I've also started asking questions on other forums - a broader resource. I like the codeProject as well.

    Sorry gungan, I just cloudjacked your discussion a bit.

    Friday, January 24, 2014 8:37 PM
  • @Jibba Jabba  thanks for your suggestions! As Litdev already said, those things can be implemented with extensions. I would like to add to the standard library (or rewrite it) but I think it may be best to leave things as they are and allow users to download extensions if they would like.

    @Litdev thanks for your input! I will definitely implement args and returns in my compiler. My idea is that subs could return a value (if wanted) but not take params and funcs would take params and could return a value (again, if wanted.)

    Integer indexed arrays are also high on my list. How do you suggest that they be implemented? With an actual declaration like "foo[] = new foo[500]" or something like that?

    Please mark any answers and "vote as helpful" any posts that help you!

    Saturday, February 1, 2014 4:38 AM
  • As you know integer arrays would have to be declared before use to dimension them - which would make things harder for users, but it is the price to pay.  It would be nice if the syntax was as close to current SB, obviously allowing only indices in range to be used (some compilation checking where possible and run time 'out of range' error message.)


    foo = newArray[500][2] if multidimensional allowed, or just foo = newArray[500] with newArray being the additional keyword.  Or perhaps foo = dimArray[500] or just foo = Dim[500] or foo = Dimension[500].

    Maybe you could keep the current SB dictionary arrays using [] syntax, but add a new array method for integers, maybe with {}.  It would be nice if the new compiler could also handle standard SB format - be a superset with added capabilities rather than an alternative.

    foo = Dimension{100}
    for i = 1 To 100
      foo{i} = i

    Just some ideas, probably keep indexing starting at 1, not 0.  Also make it an array of Primitives so the arrays could hold any SB type unless this defeats the performance increase.

    Another performance issue in SmallBasicLibrary is the use of dictionaries to hold shapes, their positions and many other objects/properties - some thought as to how this could be changed (not sure how since objects (e.g. shapes) are just a name like "Ellipse1", but it is the limiting factor in many programs). 

    So if we store shapes in a new array, foo{i} = Shapes.AddEllipse(20,20), when we use the shape (e.g. Shapes.Move(foo{1},100,100) a dictionary of shapes, and another with their positions have to be negotiated by SmallBasicLibrary).

    If this was changed it would also kill most extensions - much food for thought!


    I guess I am thinking that the main reason to do indexed arrays is for performance, but many bottlenecks are in SmallBasicLibrary so need to decide if a rewrite of SmallBasicLibrary is also needed and for both compiler and SBLibrary need to decide if compatibility with existing code is a requirement or handled in some way.

    • Edited by litdev Saturday, February 1, 2014 2:03 PM
    Saturday, February 1, 2014 9:27 AM
  • Thanks for your ideas, Litdev! Backwards compatibility is probably my number 1 concern--- after all, why would anyone want to use my compiler if it couldn't compile their existing programs?

    I like your curly brace syntax and think I will use it. I agree that 1-based indices are a good idea to keep things consistent with the SB library.

    The poor performance of Dictionaries is a good point. Unfortunately, I am also guilty of using them heavily in the I/O Extension. Once the compiler is written, I will look into a complete rewrite of the SB library (with backwards compatibility, of course.) 

    If I rewrite the library, I am also considering implementing method overloading. That way, beginning users could use simpler arguments but advanced users could also be satisfied with a larger amount of control.

    One last thing I am considering is rewriting the SB IDE++ debugger to take advantage of CLR debugging APIs (the current solution uses TCP communication and reflection to send data back to the IDE and back to the program.) This, coupled with the compiler, could even make it possible to do things like edit and continue!

    Please mark any answers and "vote as helpful" any posts that help you!

    Sunday, February 2, 2014 10:47 PM
  • At the moment I can't think of a good solution to not using dictionaries for shape objects, it may just be a limitation to live with for SmallBasic.

    But array indexing for purely math type codes (without hundreds of shapes) and functions/subroutine arguments would be a good target - I think you are right to make compatibility a pre-requisite.

    Monday, February 3, 2014 10:48 AM