The code below is a good starting point for looking at the basics of APRON syntax. APRON is an interpreted functional script, where all commands are of the form y = f(x1, x2, x3). Each line of APRON code directly translates to a “virtual” hardware instruction. The simulator provided in APRON emulates an ideal processor array, that is capable of many functions.
// Tutorial 0 - The Basics // TUTORIALS ARE DESIGNED TO BE READ AND STEPPED THROUGH IN THE // APRON SIMULATOR. THEY WILL NOT DO INTERESTING THINGS IF RAN! // (c) David R W Barr 2011 // Welcome to APRON! This tutorial explains the basics of algorithm structure, // program flow and variables. Please read to the end of this source file, following // the instructions // <- These double slashes are a comment. APRON does not have block comments, although // Crimson Editor can "pretend" by selecting the text and hitting CTRL+M to comment, and // CTRL+SHIFT+M to uncomment. Try it! // Nearly all APRON programs need to specify they are going to use the APRON core // for compilation and simulation. This is defined in the headerfile 'apron.aps'. // Header files are placed directly in the code, line for line, when the pre-processor // command "!include" is used. Be careful not to include files twice, or in the wrong order. // The APRON compiler will catch recursive inclusions. // Include the main APRON system !include('apron.aps') // The above line is a pre-processor command. We know this because it begins with ! // pre-processor commands are executed at compile time and are used to help form // the algorithm through code-reuse, encapsulation and readability. // Character strings in APRON are surrounded by single quotes - 'like this' // APRON Script files have the extension "aps". There is no distinction between // source and header files, as headers are equally just source files. // Variables in APRON are all 32-bit floating point numbers (even the integers!) // They are implicitly defined when written to, but must have been defined when read. a = 3 // Create a variable "a" and set it 3. // APRON assumes variables implied this way are of type "VARIABLE" // Basic mathematical operators are included in the APRON core. // APRON is an interpreted assembly language. Therefore you cannot use long // expressions. b = a + 7 // is valid // but "b = a + 7 + 6" or "b = a + 2 * b" is not. // Why? This makes an assumption that one line of APRON code performs more than one hardware // level instruction. This will make more sense when you reach the advanced tutorials. For now, // treat expressions in APRON as if you were using a simple calculator from the 70's. // Frustratingly, "b = a + 7" is good, but "b = 7 + a" is not. APRON expressions should always be // variable = constant, // or variable = variable, // or variable = variable + constant, // or variable = variable + variable // Again reasons for this will be explained when you start designing models of procesisng hardware // As you step through the code in the simulator you will notice the variables are listed, and // their values change accordingly. The simulator allows you to change the value of a variable // by double-clicking on it. A single-click higlights the variable. This may be useful when your // algorithms become larger. counter = 0 // Create a variable called "counter" // Labels are code locations. For example #loop_one // It is conventional to indent after declaring a label counter = counter + 1 // Increment counter // Conditionally jump back to the label if true jumpif(counter, <, 5, #loop_one) // Removing the indent helps segment the above code form the rest of the program. More often // than not you will remove the indent after a jump, jumpif, or return statement jump(#loop_two) // unconditionally jump to labelled location // This is skipped - come back here in a bit... #sneaky_subroutine counter = 500 return #loop_two // We can use if..else..endif and if..endif blocks to optionally execute code if(counter, ==, 5) // The counter is at the correct value! counter = counter * counter else // The counter has been messed with! counter = 25 endif // A call jumps to the given location, and places the previous location // on a stack. When a return statement is encountered, the current // location is swapped with the previous location. callif(counter, ==, 25, #sneaky_subroutine) // Like jump, calls do not have to be conditional // Now counter should be 500 if(counter, >, 499) if(counter, <, 501) call(#all_good) else call(#all_bad) endif else call(#all_bad) endif // The "end" statement stops the simulation. Permenantly. end #all_good // Excellent! score = 100 // points return #all_bad // Booo! score = -100 // points return