Basic features for a basic language? DSL suggestions?

Question

I've finally begun to understand the complexity behind creating an interpreter and a compiler. I've built several versions of TinyBasic, 1964 (Dartmouth) Basic, and my own expansions on those languages before getting to this point. The most recent project is one I call Open Source Basic... because I could think of no other features of the language that would interest people. To be able to open up the source of the language and understand how some complex things are done (how scanning, parsing, interpreting, and compiling are done)

Open Source Basic is first interpreted into a stack based language. That stack based language is then interpreted and executed immediately or turned into a CLR executable.

My questions all boil down to this:

• What are the basic features/constructs of a Basic-based language? I have these basic constructs already: Assignments, Expressions, Variables, some functions (Random, ToUpper, ToLower), Looping (for and do-while/until), If (block and single-line) Else decisions, console based input (Input) and output (Print), and sub-routines (with no parameters, yet).
• When I'm 'done' adding the basic constructs onto my language - how should I branch out? Into what domain(s)? In other words, what direction(s) should my open source basic language take once I've got all the generic constructs working?

Thank you for your time,

Dominick

Answer 1

My experience with early BASIC on the Commodore [Vic-20,C-64] gave me the impression that line numbers were a core "feature" of BASIC. It seems like they are no longer used in modern implementations, which to me is something of a detriment since my primary view of BASIC is as a learning language from which to springboard onto something else.

Answer 2

Definitely a noble endeavor, but I think that you've got your priorities reversed.

Your first concern should be the "domain" problems that your language is targeted to address. That's why it is called a "Domain Specific Language" in the first place. A DSL is tolerable only when it is small, simple and very narrowly focused to solve particular set of problems like a knife through butter.

After you've identified the domain and how your language will work in the domain, you can lay down specific constructs or features.

Finally, it might be helpful to consider whether you want an internal or external DSL.

Answer 3

I have been developing a scripting language for a CAE/FEA application and some features that I found useful for end users are: Local and global variables Matrices with dynamic allocation and expansion Functions with arguments and by reference passing Structures (user defined types) Along with the features you mentioned yourself should make a quite powerful language to begin with. Then you will develop according to user request.

Answer 4

There are several features that can be added or extended if already exists, but...

...Basic-like programming languages, are very similar to script languages, and a feature that many missed or included later, was namespace or modules.

C, C++, PHP, Visual Basic, started without modules / namespaces, and where added later.

The next could be subroutines (procedures or functions that doesn't return a value), and functions (subroutines that return an special value).

Answer 5

understand how some complex things are done (how scanning, parsing, interpreting, and compiling are done)

There is a nice question over on the Stack Overflow site on resources for understanding compilers. You can also have a look at my Compilers class page.

When I'm 'done' adding the basic constructs onto my language - how should I branch out?

Given the features you've already built, I suggest adding three data types: int, string, boolean. You'll need to do three things, each a little harder than the prior:

1. Modify the grammar so that you can parse those key words. Test.
2. Create (or add to your existing) symbol table so that you can include the data type along with the variable name and other properties. Then make a debug switch so you can test this and see the symbol table.
3. Check for compatible types before code generation to MsIL or during interpretation. Test both error and non-error cases in each execution mode for all types.

If that goes well, then I suggest working on scope (local in sub-routines vs. global). Let me know if you'd like some advice on that.

Good luck. And enjoy!