Blog moved

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

See you there!

Yabasic 2.9.10 is out

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

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

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

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

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

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...