Constants and literals

Most programming languages permit the expression of literal values, 3.14 or "Untitled", for example. Named values such as PI or MAXINT are also typically allowed.

It is bad form to mix literal or even named values in action language. In practice, model developers do it anyway, but with a few notable exceptions, there are safer and better alternatives.

You often end up with values that are special in the context of your application like, let’s say, 7, 270 degrees, 2500 psi, etc. Specifying these as literals or named values within the action language is bad form for many of the same reasons as in program language code. Here’s a quick review of these oft documented issues:

Problem 1: Hard to find values

A critical value like 350 degrees may need to be changed to 425 degrees someday. If it is in an attribute of some specification class it will be easy to find. Furthermore, the purpose of that limitation could be documented in its attribute description. But if instead the value just pops up in the action language somewhere, how will we find it? And why was that particular value selected?

Problem 2: Hard to ensure uniformity

You might change the literal 2500 psi in one place, but is it used elsewhere? What if it is used in three places, but you only change it in two? It’s only defined in one place? Great, how do you know? By instead putting the value in the class model, you can ensure that you have one fact in one place.

Problem 3: Unnecessary re-compilation

As with the class and state models, any edit to the action language necessitates re-compilation of the models. When you change the literal 350 degrees to 425 degrees in an activity, you must recompile, retest and reintegrate the portion of the model that you modified. But you shouldn’t have to. Instead, edit a value in the instance population data. Let’s say that you locate the Heating Specification initialization table, scroll down to some instance and then change the value in the Standard bake temperature column. The model is unaffected by this change, but you can reinitialize it with the new value. In fact, in a running system, you may be able to effect this change by issuing a runtime edit command without any need to recompile.

So what do we do in Scrall?

There are, of course, times when you want to perform a computation with a mathematical constant. A value like pi is typically outside the subject matter of your domain, so it doesn’t really belong in the class model. By the same reasoning, though, it really shouldn’t be defined in the action language either.

So we do need to find a way to define and use mathematical constants as well as special values like “” (empty string). And while a value like, pi doesn’t change, the desired approximation might. We also note that the boolean true and false literals are generally helpful.

And then there is also the question of values for enumerated data types. It wouldn’t be unreasonable to have logic in an activity that branches based on the current landing gear status like the following:

(/R1/Landing Gear.status == .retracted) ?
   do(x) : do(y)

And then there’s the issue of instance creation. How do you create a new instance without supplying values for each of its attributes?

Color = “Blue”
Doors = 4
Speed = 0.0

You could argue that the initial attribute values could be gathered from a related specification class such as Car Specification with attributes like Initial color, etc. But sometimes the specification class solution can be a bit of overkill, especially in smaller applications.

So while there are important exceptions, it is STILL bad form to bury a literal value like 15.2 deep in some activity. And if the action language allows it, bad or lazy modelers are going to keep doing this kind of thing.

Solution: No literals in Scrall (pretty much)

Since there are other ways to handle the exceptional cases, literal values are illegal in Scrall. In particular, a statement like this…

desired temp = 350.0  // Not legal!

is not legal. We’ll return to this example with a better solution, but first let’s take into account all the other cases and exceptions.

Instance attribute creation values

Boolean values

Special values

Enumerated values