Skip to the main content of this page.
The sable mammal, Martes zibellina
SABLE Programming Language

IDEs and FileIns

IDEs

When coding in SABLE, programmers will invariably use a graphical Integrated Development Environment. It displays information in terms of Assemblies, Namespaces, Classes, Groupings, and Methods. The main browser view consists of a hierarchical list and a text editor control; selecting an item from the list will display the corresponding unit of code, or an appropriate template, in the text editor.

Here is how our HelloWorld example might appear in an IDE. Click on an item in the list box to display its corresponding code. (JavaScript must be enabled for this example to work.)

This shows a compact way to express method groupings. For region, the grouping indication starts with *- for static methods, +- for constructors, and =- for instance methods. The easy mnemonic is:

*-      star for statics
+-constructors add an instance to the system
=-only instances can be compared as equal

Accessibility appears after the grouping name with an abbreviation of the accessibility name; this is omitted for #Public groupings.

When adding or modifying code, you'll save an Assembly, Class, or Method definition, and the IDE compiler will give immediate feedback if there are errors. One powerful feature of the environment is the ability to "try out" some code; just select the text and execute it. This will always take place within the context of an assembly; its references and "use" directives will apply, determining what classes can be referenced and by what names.

Debugging in SABLE

The IDE will have an integrated debugger, allowing you to step through the code, inspect variables, set breakpoints on messages (not on lines), etc.

The SABLE debugger will employ a combination of compiled and interpreted code to make it feel like a dynamic language during development time. You'll be able to step into a method where a defect appears, modify and save it, and continue debugging from the start of that method, without recompiling and restarting the program.

This ZIP file for Windows indicates what it's like to step through SABLE code in a debugger. It's the program for the BeerSong example, coming up later. Unzip the contents, preferably into a directory C:\Temp\beersong. Open the Microsoft CLR Debugger provided with the .NET platform (DbgCLR.exe) and drag/drop the file beersong.dln onto it. If you used a different directory, select menu item Debug -> Program To Debug, and change the Program and Working Directory paths. A breakpoint is already set on the first program line. Step through all of the methods, and note how the selection nests into inner structures and back out.

This will give you an idea of debugging in SABLE, but the model is imperfect. For one thing, the CLR Debugger is oriented to lines; it doesn't understand nested structures. So if you try to set a breakpoint on a certain expressions, it will move to an outer, enclosing structure.

FileIns

Files are essential for storage and interchange of code and for batch compilation. For these purposes, SABLE uses the file-in format derived from Smalltalk. However, there is no need to cover it here. SABLE programmers spend little or no time reading or writing code in this format. Instead, we use an IDE.

I will mention, though, that the files contain Unicode characters in UTF-8 format. SABLE strings can contain any Unicode character, and its identifiers can use letters in practically any natural language.