SparForte 1.3 Preview

SparForte is my programming language designed to ease the burden of two common programming problems: (1) code aging...making it easier to reuse work as a program grows and changes over time, including migrating scripts to other environments, and (2) to improve the speed and quality of a programmer's work by providing features for bug elimination and removal, software design and code maintenance. The details can be found in the SparForte documentation.

I've been working on SparForte for over a decade. It's open source and the latest development snapshot is available from GitHub.

The work in version 1 prioritizes implementing and expanding core features. Version 1.3 will be add new features for "scaling up" your applications. Here are a few of the new features you can expect.

Separate Files

To build a project of any large size, a programmer must break up the source code into separate files. I've been been avoiding these "include files" for a long time. I wanted to implement a version of Ada's powerful user-defined package system. However, this was a complex enhancement that would take a long time to implement and also tied into my planned changes to how variables are represented.

As an interim measure until a package system can be created, I've backported the include file system from the Business Shell 2.0 prototype. That doesn't mean I skimped on the error-checking features are the core of the language.

To use an include file (technically called a "separate declaration file"), use the statement "with separate". For example,

with separate "globals.sp";

Unlike most languages, it will not load any arbitrary file. SparForte will only include a file that has been designated an include file. This protects the developer from including a file that was never intended to be included.

Along with separate declaration files, SparForte 1.3 also implements its version of Ada separate subprogram files. This type of file contains a single function or procedure that has been separated out from its parent file but is intended for use only with the parent. Most languages don't care whether or not an include file is intended for sharing, but SparForte differentiates between these two cases.

More Memcache

Version 1.2 introduced memcached imports and exports. Version 1.3 expands memcached support with two distributed memcache packages. One is optimized for high numbers of reads, while the other for balanced reads and writes. These packages are the same ones used for imports and exports, using the same hashing algorithm, and you can combine these features.

A memcache cluster would have two or more servers. The key would automatically be stored on two servers in the cluster. If one server fails, a program can still retrieve the data. This is the way the memcache package for balanced reads works.

The highread package defines and uses two memcache clusters, using them as if they were a single cluster. Data is stored on four times instead of two. Programs using memcache.highread get double the redundancy, but reads are also distributed across the four servers. This makesthe packaget a good choice for high reliability tasks, or when are more reads than writes.

Here's a simple example from the command line and only two copies of memcache running on localhost:

=> c := memcache.highread.new_cluster
=> (Assuming c is a new memcache.memcache_dual_cluster variable)
=> memcache.highread.register_alpha_server( c, "localhost", 11211 )
=> memcache.highread.register_beta_server( c, "localhost", 11212 )
=> key : string := "candy"
=> memcache.highread.set( c, key, "cane" )
=> ? memcache.highread.get( c, key )
cane
=>

Normally the alpha and beta clusters would have at least two servers each, but they will function with only one server in each cluster. In this case, the key "candy" is stored on both clusters. If there were four or more servers, it would be stored four times. When the key is read, the reads would be spread out across the four servers with the key. If a server fails, SparForte would automatically switch to one of the remaining servers with the key.

This is explained in greater detail in the SparForte documentation.

JSON

JavaScript Object Notation is a method of importing and exporting more complex data types than mere strings, as well as a way of sharing data with other languages. Using JSON, you can encode strings, numbers, enumerated types, arrays and records as strings and share them with JavaScript, PHP or other languages.

SparForte 1.3 provides JSON functions in the existing built-in packages. There are also two new import and export pragmas for sharing variables outside of SparForte.

type message_record is record
     message_type : integer;
     message_body : string;
end record;

message : message_record;
pragma import_json( cgi, message );

And that's it. SparForte takes care of the work of finding the message in the submitted HTML form, decoding the JSON data and storing it in the variable named "message".

Or even write a JSON response to somewhere else like to memcache running on localhost:

response : message_record;
pragma export_json( local_memcache, response );

You can build more complicated JSON strings using the built-in packages. These use a new string type, json_string, to logically differentiate JSON-formatted strings from other string types. This improves error checking and can be used to create more complex JSON structures.

js : json_string;
records.to_json( js, message );

More Architecture Directives

One of SparForte's goals is to help manage software design. Although there are many features already that help with that on a microscopic level, version 1.3 is starting to look towards the bigger design management issues. An important part of that is the ability to shape features to fit requirements.

New restriction directives control access to major features. Does you IT shop use MySQL as its standard? No problem: disable PostgreSQL. Do you require all scripts to be documented? That can be enforced. Prevent files containing TODO's from being promoted to your UAT environment? That can be done as well.

The architect on your team can use these pragmas in a configuration file to guide the design of a project, to ensure software adheres to business requirements, to shape how one project interfaces with another. As far as I know, my language is the first to begin tackling these kind of issues.

Other pragmas for dealing with high-level concepts like portability or reliability are also planned. It is my hope that these will make deliverables better and faster.

There will be more architectural features in the future.

License Management

Tracking software licenses is a big problem for many government agencies.

Using the new license directive, scripts can declare which license they support, including the most popular open source licenses including BSD, Apache and, of course, GPL. For example:

pragma license( public_domain );

License names are checked with the list of licenses known to SparForte.

SparForte has a new command line switch to pull the license data out of the scripts. There's no need to search the text of scripts to guess at the license or risk problems with typos or copying errors.

More Documentation Updates

SparForte 1.3 completes the documentation cleanup and reformat. The package documentation will have the same look-and-feel as the rest of the documentation. It will be easier to read and navigate, with new hyperlinks and cross-references with other programming languages for easier searching.

Other Features in the Works

These features are being worked on but probably will not make it into SparForte 1.3 due to time constraints.

• OpenGL - support for the MESA library under SDL. I've created a brand new low-level OpenGL binding in Ada and want to begin integrating it.
• Database Connection Pools - good database libraries are hard to find. GNADE, the most popular library for Ada, uses Embedded SQL which cannot be used with SparForte. I'm looking at porting some of the other open source database libraries. The existing work is done using Warren Gay's APQ library version 2 (version 3 was released by another developer but I haven't had a chance to update it yet). Regardless, SparForte was designed to use only one database connection at a time, which is fine for small companies but not for larger ones. A database connection pool, managing multiple connections and reusing connections for speed, is a big feature I've been working on for a while. I don't know if it will be available in the version 1.3 release.
• More Business Shell 2.0 Feature Backports - including libspar, a version of the SparForte interpreter that you can run from programs written in other languages, including Ada and C.

The list of changes in version 1.3 are stored in the ChangeLog on the GitHub page. There's a link to it on the SparForte download page.

December 28, 2011