Yabasic

Blog moved

2010-03-30T17:49:00.000-07:00

The Yabasic blog now uses Wordpress. It is located at yabasic.basicprogramming.org.

See you there!

Yabasic 2.9.10 is out

2010-02-12T20:27:00.001-08:00

I should prefix this by apologising for my lack of activity on Yabasic over the last couple of weeks. I have been extremely busy, and this is likely to continue. I do intend to daily spend some time working on Yabasic.

Yabasic 2.9.10 is available for download. It is primarily a bug-fix release, and the only real addition is that you can specify a "symbol prefix" when importing a file or library. For example:

use "curses" as c

c.init ()

Essentially, if "as <prefix>" appears after the name of a file passed to import or use, all the symbols in that file will be prefixed with "<prefix>.". If you have time, could you please check this out and report any bugs that you find?

This version, like the last, doesn't include any modules by default. That is not to say that Pedro's SDL module, for example, is not any good—quite the contrary! I'm still playing around with different implementations of the module system (focusing in particular on module installation), and I need to do a bit more work in order to ensure that it is solid, stable, and "fool-proof". I'm in the process of creating a Curses module, which is helping me to test the module system.

Thanks, by the way, for expressing your views on the forums about features that you think should be re-added to Yabasic. I'll spend some time reading the various discussions, and I'll probably follow up with a post on this blog.

Releasing Yabasic 2.9.9, featuring modules and structures combined

2010-01-26T20:03:00.000-08:00

Yabasic 2.9.9 is now available for download. It isn't polished (just look at todo.txt!), but nevertheless I invite you to test it, experiment with it, and report any bugs that you find.

What's new in 2.9.9?

In theory, modules are now fully integrated into Yabasic.
There are two new command-line options, --library-path and --module-path, which allow you to specify the directories that libraries and modules are loaded from respectively.
Now, the default module and library paths are relative (on Unix-like systems, modules/ and libraries/; on Windows systems, modules\ and libraries\). (Could someone please ensure that this works on Windows?)
There is a new special function (or array variable) called __arg$ () (synonym __args$ ()). It takes a single numerical parameter, the number of an argument passed to Yabasic at startup. If the specified parameter is within range, the argument is returned as a string, otherwise an empty string ("") is returned.
Several bugs have been fixed.

I have tried to integrate Pedro's module code into Yabasic, but I may have left bits out accidentally (although I used vimdiff to check everything). Please let me know if you find any mistakes or omissions.

I managed to eliminate all compilation warnings. I did make three significant changes related to modules:

I've used the term "module" throughout, as opposed to "plugin". I don't really have a major preference, but it is important that we use the same term consistently in order to avoid confusing users. It would be very easy to change to using "plugin" if that's what people prefer, but we would need to use it consistently. (By the way, the file extension for modules is now .ybm rather than .ybp.)
I've "expanded" some of the abbreviated symbol prefixes used by Pedro. For example, I changed ybpi_ to yabmod_interface_, and ybpf_ to yabmod_function_. (The main reason for this change is simple: to make modules more usable and understandable to inexperienced users.) Consequently, some of the existing module code (the SDL module, for example) will need to be changed in order to reflect the new symbol prefixes.
I've eliminated the anonymous variadic macro CHECK_FUNCTION_CALL, which was used to check module function calls; such macros are not permitted in standard ISO C. It would, I think, be possible to write a function to perform the same task (using va_arg and family) in an ISO C-compatible way, or alternatively to write several macros each taking a particular number of arguments.

You will need to compile modules manually for the time being; the .ybm file should end up in the modules directory.

An argument for free software

2010-01-22T15:32:00.000-08:00

You may have noticed that I often call Yabasic "free software". In this context, I always mean "software that is free in the sense of freedom". (Of course, Yabasic is also available free of charge.) I am careful to avoid confusing the terms "open source software" and "free software": the former is a development methodology (a way of creating software), and the latter is a philosophy. Software can be "open source", yet not be "free" in the sense of freedom. Yabasic qualifies both as free and as open source software.

A program qualifies as "free software" if its copyright holders have made it available under terms that allow recipients to freely use, copy, study, modify, and distribute it (either modified or unmodified). I could procrastinate at length about the moral high ground of the free software movement, but I'm not going to do that. Instead, I want to develop an argument for free software which is often neglected, an argument that is quite relevant to many BASIC programmers today: the argument from preserving our software heritage. Allow me to elaborate.

We all know that computers change and that the computing world evolves. Not so long ago, computers were found only within the domains of universities and highly-funded institutes; now, it's not uncommon (in the Western world, at least) for individual households to have more than one personal computer. Software changes rapidly as new algorithms and better techniques for data storage become known, and also as companies try to outdo each other. Suffice it to say, a lot of software that we currently use will look quite different in ten years' time.

Data formats and programming languages change as well. I am confident that BASIC will not die out within the space of a decade, and its potential as a fun language, often agreeable to beginners, may even cause certain variants to gain in popularity. (I live in hope.) We would be fooling ourselves, though, to think that pre-compiled software that runs quite well on our 32- or 64-bit computers will run just as well on modern systems ten years later. Unless programs are changed as the computing world changes, it is unlikely even that most of today's body of source code—whether written in C, C++, Java, or some other language—would compile or run properly on a modern system in a decade's time.

What I'm getting at, then, is that software will quickly be rendered obsolete and unusable unless it is updated regularly as computers change, libraries are improved, and the computing world in general rolls on. Now to tie that into my main argument.

A program counts as "proprietary software" if its copyright holders do not allow users to use, copy, study, modify, or distribute it freely. Indeed, much proprietary software is licensed in such a way that users are forbidden from doing anything with the software except using it, and, usually to a very limited extent, copying it locally. The copyright holders of proprietary software most often refuse to make source code publicly available, and this has a number of profound negative consequences.

For many reasons, programmers cannot be expected to support archaic programs indefinitely. Sadly, many historically-important programs fall out of common use and are lost in the mists of time—often, really lost, because the copyright holders selfishly refuse to release the source code into the public domain. (In some cases, it's impossible to contact the copyright holders.) If such programs will not run on today's systems, how much less will they function on the systems to be found in a decade's time? When historians try to research the history of the computing world, they will run up against walls of all kinds: technical walls, legal walls, and, perhaps worst of all, "language" walls.

Open up an compiled executable file in a text editor, and observe the wonderful Language of the Computer. You almost certainly cannot understand it, and there are few who can (and even they cannot fully deduce the source code of a program from its compiled executable). And it's not a static Language; changes are made to it as new ways of doing things are discovered. Programmers will keep up with the Language of the day, and, in ten years' time, very few people will understand the arcane symbols you see in front of you now. In fifty? Well, I'll stop there, because you can guess the situation. If the program is free in the sense of freedom, you can rest in peace: the source code will probably still be accessible from some public archive even fifty years into the future.

How does this relate to us? Well, I think all of us have an interest in the history of BASIC, and a respect for our computing heritage. We now have to come to terms with the fact that so many BASIC interpreters and compilers, and so many BASIC programs, are no longer usable on modern systems (I know there are various emulators available, but often they are not fully functional). We will lose more and more BASIC-related programs in the future. Why? Because so many dialects of BASIC, and so much software created using BASIC, is proprietary, and the Language of the Computer slowly but surely changes.

Free software is the only kind of software that reliably preserves our software heritage. Already, we are losing old proprietary BASIC interpreters and compilers—pieces of software that would, ideally, help us to research, remember, and enjoy our history. Let's not support proprietary software. We need to address the problem now, so that humanity won't have to suffer ten, twenty, thirty, a hundred years from now because of our "short-mindedness".

Distributing modules

2010-01-17T20:12:00.001-08:00

How should we distribute Yabasic modules?

We could explicitly separate modules from the Yabasic core, distributing them individually so that users could download just the modules they wanted from a central location such as yabasic.basicprogramming.org. For example, a user could download yabasic.3.*.*.tar.gz, yabmod-sdl.*.tar.gz, and yabmod-curses.*.tar.gz and then install each of these components separately; and if our user later required (say) a FLTK module, it would be a simple matter to download and install yabmod-fltk.*.tar.gz. I'll need to take a closer look at the technicalities behind all of this to see exactly how such a system would function, but I doubt it would be too difficult to implement.

The alternative is to actually distribute modules with the Yabasic core. This approach has its benefits: users would only need to download one file (yabasic.3.*.*.tar.gz) to get a "full" Yabasic. But there are also downsides; this "centralised" approach could quickly become cluttered and confusing, there would need to be a more stringent process for "officially" adopting modules, and users would find it more difficult to develop their own modules and share them. In my opinion, there's also a certain inelegance about it all: packing a bunch of source files together, each one written by a different author in a different style... maybe I'm just not pragmatic enough.

Which approach should we choose? I'll pass the microphone—or, rather, the comment button—to you.

Documentation for Yabasic 3

2010-01-17T20:11:00.001-08:00

Clearly, it is important to ensure that changes made to Yabasic are reflected accurately in the language's documentation. With Yabasic 3 introducing several major new features and many alterations on a more minor scale, it seems logical to write a completely new manual. Elmar Vogt has volunteered to take on this daunting task, and plans to start working on the manual this spring (read "autumn" if you live in the Southern Hemisphere).

Elmar intends to use LaTeX for document formatting, and, as a result, Yabasic's manual will be distributed in at least two widely-accepted formats: as a nicely-laid-out PDF document, and as an XHTML document for easy browsing and searching.

Releasing 2.9.8, featuring structures

2010-01-08T17:34:00.000-08:00

It is my pleasure to announce that Yabasic version 2.9.8 is now available for download. It's notable mainly because it features an implementation of structures that is actually usable. This is an unstable release and may contain quite a few bugs, and I would be very appreciative if you could help to test it. There is still a small amount of work that remains to be completed before I can finally stamp Done on structures, in particular providing an easy way to declare structures local or static.

To avoid confusion: this release does not incorporate any of Pedro's module code; it will probably be integrated into the next release (2.9.9). This is because I haven't had the opportunity to download and work on this code until now. You will notice that I've departed a little from my tentative schedule by working in this way, but I'm not terribly worried about that, as a stable Yabasic 3.0.0 release in early February still looks very feasible.

For your interest, here is a (fairly self-explanatory) example of structure usage.

// Enable the "explicit" option.
enable explicit

// Define terrain, creature, and item types.
terrain_None = 0
terrain_Water = 1
creature_None = 0
item_None = 0
item_Jewels = 1

// Define the map's width and height.
map_width = 100
map_height = 100

// Map structure for a basic roguelike game.
struct map (map_width, map_height)
   terrain
   creature
   items (20)
end struct

// Fill the map.
for x = 1 to map_width
   for y = 1 to map_height
      map (x, y).terrain = terrain_Water
      map (x, y).terrain = creature_None
      for set_items = 1 to 20
         map (x, y).items (set_items) = item_None
      next
   next
next

// Put jewels at a random location.
map (int (ran (map_width)) + 1, int (ran (map_height)) + 1).items (1) = item_Jewels

// And so on...

Tentative timetable for Yabasic 3 (stable)

2009-12-27T00:47:00.000-08:00

I can make no guarantees about the actual release date for Yabasic 3 (stable). But this is my tentative timetable for development (which, knowing myself, I probably won't stick to).

December 31: Begin documentation.
January 1–2: Work on modules/plugins, ensuring that they are integrated fully.
January 3–7: Implement structures/types. Release version 2.9.8, a test version.
January 8–15: Write a comprehensive user manual for Yabasic. Release version 2.9.9, a test version.
January 16–18: Develop a Curses module.
January 19–February 1: Develop a SDL module.
February 2: Release version 3.0.0, a stable version.

Blog moved

2009-12-26T18:52:00.000-08:00

You will notice that the Yabasic blog has been moved from yabasicblog.blogspot.com to yabasic.basicprogramming.org/blog. If you navigate to the former location, you will be redirected to the latter.

The Blogger software is still being used, though—only the hosting location has changed. I've also changed the style of the blog: I hope you enjoy it.

Yabasic and modules

2009-12-25T12:30:00.000-08:00

I have not posted here for a little while—as I noted in my last post, I have been on holiday in New Zealand. I am sorry to say that this post will be rather short, as well. But before I start, I'd like to welcome Pedro Sá to the Yabasic blog: he is currently working on implementing modules (or "plugins", if you prefer that terminology) for Yabasic; and he now has posting access here, so I'm looking forward to hearing directly from him about his work so far.

Currently, the modules system works as follows: (1) C functions are imported into Yabasic, using the new csub statement, by a Yabasic library which provides a Yabasic interface to a module; (2) the user imports the library (using use or import); and (3) the user is able to run the C functions in the module through the library interface.

Let's have a look at how that might work in practice.

An extract from the (yet-to-be-created) library sdl.yab might look something like the following:

csub openwindow (x, y, name$) from "sdl"
csub usewindow (window_id) from "sdl"
csub updatewindow () from "sdl"
csub closewindow () from "sdl"
csub color (red, green, blue) from "sdl"
csub circle (x, y, radius) from "sdl"
csub readkey$ () from "sdl"

Then a user might write a program, circle.yab, which looked something like the following:

use "sdl" as "gui"

gui.usewindow (gui.openwindow (100, 100, "Circle"))
gui.color (0, 0, 0)
gui.circle (50, 50, 20)
gui.updatewindow ()
gui.readkey$ ()
gui.closewindow ()

That's a very tentative example, because a lot of development work is currently taking place, so don't start writing your module-using programs just yet!

There have been a few minor hiccups so far, but Pedro has done a good job addressing these issues. Many others have helped out in this process, and I would like to personally express my appreciation to them.

And we would love to hear your suggestions and feedback on modules, because nothing is yet written in stone...

Thanks—and a new version

2009-12-06T20:07:00.000-08:00

I want to thank everyone who has provided feedback on the 2.9.5 release of Yabasic. In most cases, the feedback I have received has been positive, and I'm very grateful for your encouragement and patience despite the imperfections and rough edges that still remain to be ironed out of the interpreter. I have also taken suggestions for improvement into consideration, and I'm currently working on addressing a few issues.

I'm releasing Yabasic 2.9.6 today (you can acquire it from yabasic.basicprogramming.org), which implements a few minor changes:

a bug where the first internal command was not properly initialised has been fixed;
the inc and dec commands have been added (at least for scalar variables);
a bug related to use-statement parsing has been fixed;
the special variables __time$ and __date$ have been added (time$ and date$ were removed unnecessarily, so please accept my apologies);
the statement select is now a valid alternative (synonym) to switch;
output is now flushed properly;
the short-if form has been re-added.

I plan to re-add the goto, gosub, and label statements. Line number support, however, will probably not be implemented; it is simply impractical if line numbers cannot be updated properly.

I should note that from December 14 to December 30 I'll be away in New Zealand, and I'm not sure how much Internet access, if any, I will have during this time. Thanks again! I'm pleased and humbled that the Yabasic community is alive and well, and honoured to be working on Yabasic. It has been well worth the effort so far, and will continue to be so long into the future.

Yabasic 3 beta release (2.9.5)

2009-11-26T19:56:00.000-08:00

I can announce, at long last, that a beta release of Yabasic 3 (known as version 2.9.5) is available for download. I want to emphasise very strongly that this release is just that, a beta release. Yabasic is still undergoing intensive development leading up to a stable and full-bodied version 3, and the "to-do" list for Yabasic remains quite long; it can be found in the file "doc/TODO" in the release tar-ball. I encourage you to experiment with Yabasic and test it rigorously, but there are a number of things you should be aware of before you begin to do so.

Firstly, you should be aware of the following changes and additions. (You can find a more complete list of new features in the file "doc/NEWS" in the release tar-ball: please read this file before experimenting with the beta version.)

Basic structures. (Not quite completed, but the framework exists and is usable.)
Block comments between /* and */ markers.
Options, including "explicit" (which causes an error to be reported whenever a variable is used uninitialised).
Special variables beginning with the __ prefix.
Changes to the way in which files (and libraries) are imported. Note, in particular, the difference between the "import" command and the new "use" command.
Minor changes and additions to expression operators (for example, "mod" is now an operator).
Some syntactical restrictions have been removed.
Some bugs have been fixed.
Interface improvements have been made.

The following things have been removed.

The commands "goto", "gosub", and "label" and line numbers (perhaps temporarily). See my blog post on the subject; I need to hear more feedback before making a decision.
Some functions and commands, particularly those pertaining to terminal and window management.
Variables such as time$, date$, and so on.
The functions peek (), peek$ (), and poke (). Note that file access peeks and pokes will probably be re-added, since they are fast, useful, and quite conventional.

Most of the system-dependent parts of Yabasic have been removed and will be migrated to modules in the near future. However, I am not confident that Yabasic will compile without errors on Windows systems, and I do not use Windows and therefore cannot test it. Because of this, I am relying on your bug reports and feedback to make Yabasic usable on Windows systems. Please record any changes needed to make Yabasic to run on Windows systems, and send them to me so that I can incorporate them into the next release. I remain committed to ensuring that Yabasic compiles on both Unix and Windows systems without errors or warnings.

On Unix systems, simply unpacking the release tar-ball, moving into the unpacked directory, and typing make at a shell prompt should suffice to build Yabasic. You can, of course, use make install to install Yabasic. On Windows systems, a different approach will be needed, and I would like to hear any suggestions you might have.

Over the next few months, I intend to work with Pedro Sá to implement modules and a universal standard for modular components. Currently, we have SDL and Curses modules planned, but suggestions are very welcome, and contributions highly appreciated.

I would love to receive feedback, bug reports, and feature requests, and you are welcome to e-mail me any time. Keep an eye on yabasic.basicprogramming.org for news, announcements, and releases.

Enjoy!

Limiting and reducing language complexity

2009-11-10T20:11:00.000-08:00

Programming languages have an unfortunate tendency to become increasingly complex as the communities associated with them grow. A language may initially be "simple", but as its user-base grows and users experiment with other tools and acquire new ideas pressure is placed on the language's developers to implement new features. Therefore, a language may begin to suffer from featuritis—the disease of having too many features, or being overly complex.

As Bruce MacLennan writes in his book Principles of Programming Languages (3rd. ed., published by Oxford University Press), "Featuritis arises from the fact that it is inherently easier to defend adding a feature to a language than to oppose it. This is because the benefits of adding a feature often outweigh the consequent increase in complexity, and because the benefits are specific and clear, whereas the costs are often general and hidden."

I believe MacLennan has a point. Often, adding just a small feature to a programming language will improve it in some small way, perhaps even make it more useful. However, one new feature leads to another, and after hundreds of small features—all useful in themselves—have been implemented, a language begins to suffer from bloat and inconsistency, both of which lead to new users of the language quickly becoming confused.

Every language has a distinctive character, and this is something to be proud of, not to shy away from. Designers and authors need to appreciate the "personality" of various programming languages, encourage diversity, and remember that there will be some features outside the scope of any given programming language which should be left for other languages to implement.

How is it possible to decide which features are within the scope of a programming language and which are not? I believe that the answer lies in having an individual leading the development of a language. I do not like the term "benevolent dictator", but that probably best describes the kind of role that I refer to. If the development of a language is led by an individual person, as opposed to a committee, it logically follows that the language will reflect some aspects of that person's personality. If that individual identifies with the philosophy of the language, there is an increased chance that they will know whether or not adding a feature is "good" for that language. If they feel uncomfortable with making a change, it probably is in the project's best interests not to implement it. And, as "Syzygy" recently commented, "If one can feel the author's 'signature' in the interpreter, the programmer can follow along the lines of the author's thought, and will more readily understand what is feasible, and how an end can be achieved."

An individual will have their own sense of what is "right" or "wrong" for a language, and, provided that they do not continually have to justify their feelings about particular issues, they can guide a language's development, maintaining simplicity while increasing usefulness. Committees find this far more difficult to
accomplish, since each person on the committee is obliged to explain their opinions to other members, and often it is very difficult to pinpoint exactly why one feels uncomfortable with a particular feature or change. I do not believe it is crucial that only one individual develops a language; this would be impractical in many ways. But I do believe that an individual, ultimately, should have the final say on what goes into and what stays out of a programming language.

Of course, the community can always fork a language and create a new project, particularly if they are greatly displeased with the attitude of, or some of the decisions made by, the development leader. Ideally, this will never happen: it is emotionally taxing and costly in terms of resources. But the option is always there for those who need it, and the right to fork is fundamental to the concept of free software.

Programming languages like Yabasic with small yet active communities usually do not suffer from featuritis. At any rate, I do not think that Yabasic is negatively impacted by feature creep, although I am undoubtedly biased. But as our community grows and the language is developed further, it is important that we move quickly to counteract any symptoms of featuritis if and when they do appear. I will be releasing a beta version of Yabasic 3 soon, within a week or two from now at most; and I look forward to hearing your feedback, bug reports, and—of course—feature requests. I would love to hear your thoughts on keeping Yabasic both simple and useful.

Goto, gosub, and line numbers: considered harmful, BASIC, or both?

2009-11-01T20:06:00.001-08:00

I want to discuss an issue that, in many ways, straddles the divide between old, "traditional" BASIC dialects and newer, more "modern" versions: are goto, gosub, and line numbers harmful, fundamental to BASIC, or both harmful and fundamental? Do they have a place in any modern BASIC dialect? Where is Yabasic on the scale that ranges from "traditional" to "modern"? In experimenting with Yabasic 3, I have removed these three features, and the decision before me is whether or not to re-add them. I hope to acquire some valuable feedback by provocatively arguing that they are not, actually, fundamental to a BASIC dialect, and additionally that they are harmful and unnecessary. All that said, I am quite willing to hear opposing arguments, and at this point I could fairly easily be convinced to re-add them.

The goto statement jumps to a particular line number (or to a defined label, which is more common nowadays) within a program, and program execution continues from that point. There is no way to return from this jump to the location jumped from, other than by using another goto statement to jump to a label or line number before that location. The gosub statement, however, jumps to a particular line number or label with a view to return later—by using, for example, the return statement.

Line numbers date back to the original BASIC, where every single line was represented a numbered statement (hence line numbers). By combining line numbers with the goto statement, it was possible to write loops and simplify conditionals. For example:

10 PRINT "HELLO, WORLD!"
20 COUNT = COUNT + 1
30 IF COUNT < 10 GOTO 10
40 END

This example displays the string "HELLO, WORLD!" ten times before exiting.

It is technically possible to write any program without using the goto or gosub statements, line numbers, or labels. Using goto can occasionally be useful for breaking out of nested loops prematurely:


while condition_1
   while condition_2
      if time_to_go then
         goto get_out
      endif
   wend
wend

label get_out

...

However, it is possible to use variables to accomplish precisely the same task:

get_out = false
while condition_1
   while condition_2
      if time_to_go then
         get_out = true
         break
      endif
   wend
   if get_out then
      break
   endif
wend

...

The goto statement, in particular, leads to what computer programmers term spaghetti code, which essentially means that a program, while executing, does not follow a logical consecutive order but instead jumps wildly from one location to another. This is not only considered poor design, it makes a program less understandable to users. However, goto is often very tempting to a beginning programmer: I recall that when I first learnt Yabasic (and it was the first programming language I really learnt), I used goto very often to control program flow, because it was easy and seemed simple—until I had to read and re-write my programs.

Similarly to goto, gosub tends to have adverse effects on program readability and maintainability. There are at least two other pitfalls: there is no guarantee that the location jumped from will be returned to eventually, and there is no way of passing information along with the gosub statement, or of returning information from a routine, other than using global variables:

name$ = "Thomas Larsen"   // bad practice!
location$ = "Australia"   // bad practice!
gosub display_person   // can't pass any arguments
end   // must have this to avoid continuing into label

label display_person

print name$ + " lives in " + location$ + "."

return   // can't return any value

Conversely, subroutines, defined using the sub statement, and subroutine calls suffer from neither of these flaws:

display_person ("Thomas Larsen", "Australia")

sub display_person (name$, location$)
   print name$ + " lives in " + location$ + "."
   return true
end sub

Line numbers inherently have many problems. For example, if a new statement is added to a program then all existing lines in the program must be re-numbered and all references to them updated. Some old BASIC dialects which included an editor performed this automatically or upon receiving a particular command (for example, GW-BASIC), but newer BASIC versions which execute programs stored in files which are created by other editors should not modify those files (for instance, Yabasic).

None of these features, particularly if they are used regularly in a program, are conducive to major re-writes or fundamental changes being made. One has to ask whether such features are actually in keeping with the philosophy of BASIC, which is arguably to make programming relatively easy, understandable, and enjoyable for beginning programmers (and veterans, too). If goto, gosub, and line numbers cause confusion, lead to flawed program design, and encourage undesirable programming habits, are they really fundamental to BASIC dialects? No, I would argue.

But, after all, this is just my two cents.

The Most Stupid Bug of the Year

2009-10-23T21:18:00.001-07:00

In the header file yabasic.h, distributed with the Yabasic source, there's a carefully-organised, enumerated list of Yabasic functions. I tidied it up and sorted everything alphabetically into groups of functions with one argument and zero, two, and three arguments:

/* Yabasic functions (sorted carefully by number of arguments). */
enum functions {
   fZEROARGS, fRAN2,

   fONEARGS, fABS, fACOS, fASC, fASIN, fATAN, fATAN2, fCHR, fCOS,
   fEXP, fFRAC, fINT, fLEN, fLOG, fLOWER, fLTRIM, fMAX, fMIN,
   fRAN, fRTRIM, fSIG, fSIN, fSQR, fSQRT, fSTR, fSYSTEM, fTAN, fTELL,
   fTRIM, fUPPER, fVAL,

   fTWOARGS, fAND, fEOR, fINSTR, fLEFT, fLOG2, fMID2, fOR, fRIGHT,
   fRINSTR,

   fTHREEARGS, fINSTR2, fMID, fRINSTR2
};

See if you can notice the bug before you continue reading. Trust me, it's not difficult to find if you know Yabasic.

It turns out that in the process of sorting the functions into their respective groups, I incorrectly placed fMAX and fMIN (corresponding to the functions max () and min (), respectively) in the group of functions taking only one argument. If you are familiar with Yabasic, you will know that both of these functions actually take two parameters. I was surprised when I ran a program that used one of these functions and was rewarded with a segmentation fault. It only took me a minute or two to figure out where the problem was and fix it, but I reckon it wins the prestigious title of Most Stupid Bug of the Year. And the year isn't even over yet...

Anyway, fMAX and fMIN are now in their proper places, in the group of functions accepting two parameters:

/* Yabasic functions (sorted carefully by number of arguments). */
enum functions {
   fZEROARGS, fRAN2,

   fONEARGS, fABS, fACOS, fASC, fASIN, fATAN, fATAN2, fCHR, fCOS,
   fEXP, fFRAC, fINT, fLEN, fLOG, fLOWER, fLTRIM, fRAN, fRTRIM, fSIG,
   fSIN, fSQR, fSQRT, fSTR, fSYSTEM, fTAN, fTELL, fTRIM, fUPPER, fVAL,

   fTWOARGS, fAND, fEOR, fINSTR, fLEFT, fLOG2, fMAX, fMID2, fMIN, fOR,
   fRIGHT, fRINSTR,

   fTHREEARGS, fINSTR2, fMID, fRINSTR2
};

So all is now well.

What defines a BASIC?

2009-10-23T21:06:00.001-07:00

You are probably aware that the name "Yabasic" stands for Yet Another BASIC. If you know your programming history, you will also be aware that BASIC is an acronym for Beginners' All-purpose Symbolic Instruction Code. Today, we have a huge body of "BASIC" dialects which bear little or no resemblance whatsoever to the original BASIC invented over forty years ago. The question is, are they actually BASIC languages at all? If the answer is yes, then this might lead us to ask another question: what defines a BASIC?

I want to focus briefly on the term "beginners". It would seem to imply that BASIC languages have a target audience of beginners, but I would argue that now this is not the case. Certainly, BASIC was originally a beginners' language, but it has evolved so much that there are now very complex, powerful dialects which are not particularly suited to those with no prior exposure to programming.

It is interesting to note that BASIC, in its early days, was used primarly within the confines of universities and colleges. This meant that "beginners" actually had at least some experience in operating computers, and, presumably, some familiarity with basic computer theory. Nowadays, we tend to apply the same term to those who have little or no experience in either programming or computer theory.

Then we have the term "all-purpose". Obviously, the original BASIC was not "all-purpose" as we know the term today: it was used mainly to find the answers to various mathematical problems. Nowadays, we have games, editors, and scripts written in a variety of "BASIC" dialects. Most modern "BASIC" dialects do not even attempt to be "all-purpose": it is widely accepted that different versions are better for accomplishing different objectives. However, the widespread use of BASIC variants in many different, diverse fields seems to have proved that the "BASIC" concept is, indeed, "all-purpose" to a large extent.

So, what defines a BASIC? Is it syntactical conventions or the longstanding print statement? Or a philosophy shared with the original BASIC? Or an ever-diluted (or ever-enriched) heritage? Or is there no definition, and the label "BASIC" is only widely used because it is an effective, respected "brand name"?

What might the future look like? How might "BASIC" dialects look in a decade, in two decades from now? Will they still deserve the label "BASIC"? What changes might have taken place? What changes should have taken place?

There is one more very interesting question that I would like to open up for discussion: should there ever be a limit on how far a language can evolve? If a new and potentially very useful feature could be added to a language, but only by significantly or drastically altering it, should it be implemented—or left for another, completely separate programming language to implement?

(I should apologise, by the way, for the shortness of this post; I was extremely busy during the past week. I would love to hear your ideas for future posts: please e-mail me at larsen.thomas.h @ gmail.com, or else use the comments system.)

Structures in Yabasic 3

2009-10-16T21:10:00.000-07:00

Often, it is desirable to have variables that can contain data of mixed types (real numbers and strings). For example, take a student database (a typical example, I know, but sufficient). The name, gender, and date of birth of each student must be stored, as well as course information for each individual. To accomplish this in Yabasic as it stands, about six array variables are required. (Technically, fewer are necessary if clarity is unimportant.)

In Yabasic 3, structures will be able to contain any type of data: real numbers, strings, and even other structures. This will allow for better organisation of variables and a more consistent approach to various aspects of Yabasic programming.

Take the aforementioned example, for instance. In Yabasic as it currently stands, an implementation of the student database might be as follows:

number_of_students = 30
number_of_courses = 5

dim name$ (number_of_students)
dim gender (number_of_students)
dim dob_year (number_of_students)
dim dob_month (number_of_students)
dim dob_day (number_of_students)
dim course_name$ (number_of_students, number_of_courses)
dim course_teacher$ (number_of_students, number_of_courses)

name$ (1) = "Amy"
gender (1) = female
dob_year (1) = 1989
dob_month (1) = 5
dob_day (1) = 14
course_name$ (1, 1) = "Mathematics"
course_teacher$ (1, 1) = "Pythagoras"
course_name$ (1, 2) = "Physics"
course_teacher$ (1, 2) = "Einstein"
...

Clearly, this has the potential to become extremely confusing, particularly when used in complicated Yabasic programs. In Yabasic 3, on the other hand, the same database program might conceptually be implemented as follows:

number_of_students = 30
number_of_courses = 5

struct students (number_of_students)
   name$
   gender
   struct dob
      year
      month
      day
   end struct
   struct courses (number_of_courses)
      name$
      teacher$
   end struct
end struct

students (1).name$ = "Amy"
students (1).gender = female
students (1).dob.year = 1989
students (1).dob.month = 5
students (1).dob.day = 14
students (1).courses (1).name$ = "Mathematics"
students (1).courses (1).teacher$ = "Pythagoras"
students (1).courses (2).name$ = "Physics"
students (1).courses (2).teacher$ = "Einstein"
...

Compare this with the previous example. It is more readable and logical, and easier to understand. If you are not convinced, imagine a complex database program making use of many data fields. Without structures, the risk of errors would be unacceptably high.

Structures are not overly difficult to implement, although there may initially be a few hiccups. Instead of making complicated changes to the existing variable-handling code in Yabasic, a special "rearranging" trick could be used. Array indices could be brought to the right-hand side of the full structure name for the purpose of internal representation, allowing structures to make use of existing array and scalar handling routines in Yabasic: for example, students (1).name$ could become students.name$ (1). The struct statement would, therefore, handle all necessary "dimensioning" of arrays, and, if appropriate, make variables local or static. Later, it will probably become possible for users to define types, structure templates. Tentatively, their implementation might be as follows (but I am very open to suggestions):

type person
   name$
   gender
   struct dob
      year
      month
      day
   end struct
end type

number_of_people = 30

struct people (number_of_people) as person

people (1).name$ = "John"
people (1).gender = male
people (1).dob.year = 1987
people (1).dob.month = 11
people (1).dob.day = 5
...

I expect to implement structures in time for the Yabasic 3 beta release, but types may come a little later, since I need more feedback on the basic design before I extend it significantly.

Introduction to Yabasic 3

2009-10-08T23:08:00.000-07:00

I indicated in my last post that I would provide some background to Yabasic 3, which I am currently developing, and discuss some of the decisions I have made so far in relation to Yabasic development. I will not delve too far into the history of Yabasic, although that topic may be the subject of a later post.

Marc-Oliver Ihm authored Yabasic and maintained it up to version 2.763. Sadly, in 2007 he came to the conclusion that he would not be able to continue developing Yabasic: "I am really not comfortable with this conclusion, but I have to admit that probably I will not develop Yabasic any further within the foreseeable future." However, Yabasic had a functional, clean code-base and a strong community associated with it.

As an avid Yabasic programmer, I wanted to keep Yabasic "alive" and operational. I wondered whether or not to take on the role of developing Yabasic, but I was reluctant to commit myself at a time when my knowledge of the C programming language (in which Yabasic is written) was fairly minimal. Eventually, after some experimentation, I finally decided to take on the responsibility of developing Yabasic with Pedro Sá. As you can see, I was optimistic about how long it might take to produce Yabasic 3: "...I am working on the syntax parser, and I have not yet started on the various actions for the commands and functions, so the initial release date will be some time from now (hopefully no longer than a few months)." And that was in May 2008.

Originally, I intended to write Yabasic 3 entirely from scratch. I estimate that I attempted a complete re-write about six times; at minimum, each implementation supported basic commands ("print", at the very least). But I considered them all unsatisfactory, for one or more reasons.

Finally, I decided to use the existing code-base of Yabasic. I was determined to pare it down to the bare essentials, correcting existing bugs, implementing clean memory management (which I do not expect will be completed in time for the beta release, but it is certainly one of my goals for the future of Yabasic), improving consistency, and in general improving the language's aesthetics in order to prepare it for the changes I intended to make for Yabasic 3. Much of this process has already been completed, and my major focus has now shifted to implementing new features.

So, what are these "new features"? Well, I've already implemented block comments, which are incredibly convenient when a programmer wishes to comment out a whole block of code. Now you can write the following:

/* This is a block
   comment that
   extends over
   multiple lines. */
   print "Hello, world!"

But the real meat of Yabasic 3, I hope, will be modules, libraries, and "user-defined types". At the risk of being too verbose, I would like to discuss each of these features in turn, explaining their benefits and implementation. Because "user-defined types" merit a topic of their own, I will cover them in my next post.

Modules

Previous versions of Yabasic implemented rudimentary graphics and some terminal manipulation. Users could, for example, open a window and draw lines, circles, and triangles or print text at a particular location and with a particular colour to the terminal. However, this functionality was built into the core of Yabasic itself, and a number of issues arose as a result of this design.

There was the issue of compatibility of features across different computer systems. For example, while Marc-Oliver Ihm admirably made graphics handling very similar on both the GNU/Linux and Windows operating systems, there were still a few inconsistencies and incompatibilities that were noticeable in some "graphical" Yabasic programs. Once, I developed a graphical text editor in Yabasic (YATE, or Yet Another Text Editor), and had to spend a significant amount of time addressing compatibility concerns. Clearly, this is not a desirable burden to impose on any casual user.

One way of addressing the issue is to separate Yabasic into a number of modules, with a "core" at the "centre". The Yabasic core is responsible for performing general, system-independent tasks (such as parsing, execution, variable handling, and expression evaluation), while modules are either system-dependent (for instance, graphics or terminal handling) or responsible for performing a specialised task (complex number handling, for example). In general, Yabasic programs written on any one platform should function on all platforms without requiring changes to be made in order to operate correctly or consistently. This implies that modules for performing a particular task should interface consistently with the Yabasic core and Yabasic programs.

For aesthetic reasons there should be a clear division between system-dependent or specialised modules and the, ideally, system-independent Yabasic core. This does not mean, however, that neatness and clarity are more important in the Yabasic core than in Yabasic modules: indeed, this is not the case. Clarity and aesthetic design are important in any program. But a modular design, which divides a program into components with specific purposes, is easier to debug and usually more fail-safe.

Modules should not get in the way of a programmer: they are, supposedly, tools for getting jobs done in a consistent, clear way, not obstructions. So I intend to make them blend pleasantly into Yabasic. It is important to note that modules will be compiled into Yabasic and will, therefore, be part of the compiled Yabasic executable. It is, however, important to distinguish modules from the Yabasic core. A standard for modules may need to be written, but I will look for more community input before resolving to pursue this course of action.

How might modules look? Well, take the following old code which opens a window and displays a red circle in the middle of it:

open window 100, 100
color 255, 0, 0
circle 50, 50, 20

This might (tentatively, very tentatively) be accomplished like this in Yabasic 3:

graphics.set_window (graphics.new_window (100, 100))
graphics.color (255, 0, 0)
graphics.circle (50, 50, 20)

I will not be writing many modules before the Yabasic 3 beta release. I might write a basic terminal-handling module for GNU/Linux, but developing a full, consistent set of modules will take more than a month or two and will require some community effort.

Libraries

In Yabasic, libraries usually are Yabasic programs that contain sets of functions. Users can import these libraries and call the functions defined in them. Thus, libraries can be shared between programs, and much difficult and duplicated effort can be avoided.

Libraries have already existed in older versions of Yabasic. Yabasic 3, however, simplifies the implementation of libraries significantly while embracing and extending the general concept, and to this end library handling has been completely re-written.

As I propose to implement libraries, the "export" statement would disappear, and users would reference imported functions by their name prefixed with the name of the library. For example:

import "number"      // imports library

for number = 1 to 1000
   if number.prime (number) then    // "number.prime ()"
      print number
   endif
next

The library file number.yab would contain:

sub prime (number)
   local check
   for check = 2 to sqrt (number)
      if number mod check = 0 then
         return false
      endif
   next
   return true
end sub

This is, of course, a conceptual example, and I would like to hear your feedback.

Yabasic blog

2009-10-04T23:25:00.000-07:00

Welcome to the Yabasic blog!

My name is Thomas Larsen, and currently I am busy developing the next version of the Yabasic interpreter, Yabasic version 3 (see yabasic.basicprogramming.org for more information). It is my intention to post regularly, at least once or twice a week, for two reasons.

Firstly, I want to keep you informed about progress on Yabasic development. Yabasic 3 development has taken longer than I ever expected it would, but I'm fairly confident that I will be able to release a beta version in November, or December at the latest.

Secondly, I want to discuss certain features of Yabasic and gain valuable feedback. How should Yabasic evolve in the future? What could, or should, be done to make Yabasic more aesthetic, practical, and usable? With Yabasic 3 implementing new features such as user-defined types and modules, I look forward to hearing your answers to these questions.

When Yabasic 3 is out of beta, I intend to open this blog up to other interested Yabasic developers and programmers so that they, too, can share their experiences and ideas. I hope that future "generations" of Yabasic users will find the Yabasic blog interesting, useful, and inspirational.

In my next post, I'll provide some background to Yabasic 3 and discuss some of the decisions I have made so far in relation to Yabasic development.

Enjoy!