42 - The definitive answer to design, code and everything

--But you are not going to like it

Target audience

This tutorial is design for expert programmers, already knowledgeable in at least two or three of the languages Java, C#, C++ and Python. This tutorial lays out the basic knowledge for programming in 42 using AdamsTowel, but does not explore the foundational theory behind 42, or the mathematical rationale for the correctness of 42.
The language 42 and many 42 metaphors are inspired by The Hitchhiker's Guide to the Galaxy by Douglas Adams.

Downloading and running

Currently, you can download and run 42 as a Java program.

• For windows download here L42PortableWin.zip
• For Linux download here L42PortableLinux.zip
• For Mac download here L42PortableMac.zip
• Run «» to start the IDE.
• Run «» to run the 42 program inside of the folder «» from the command line.

Basics

(1/5)Simple hello world program

Let's look at a simple hello world program:

We do not need to always start from AdamsTowel; there are many interesting towels out there, and you may also become skilled in the advanced technique of towel embroidery. In this tutorial, all of our examples are expressed reusing «».

At the right of «» we write the expression that we wish to execute; in this case we just print out using the «» class. «» is not a method, and «» is not special name either. You can replace it with «» or any other valid upper-case name. In 42 there is no concept of main method as in Java or C. For now you can think of «» as a top level command. We will understand later how this fits with the general language design.

«» is a simple class whose most important method print a message on the terminal.

In 42, when a class has a most important method, it is conventional to use the empty name, so that can be used with the short syntax «» instead of a more verbose «».
In 42, Strings and numbers need to be created using their type, as in «» or «». Indeed «» is just a convenient syntax equivalent to «»; the syntax with quotes is needed to express negative or fractional number literals, as for example «» or «».

(2/5)Method declaration and call

Let's now define a method and call it.

Note that the method is called using the parameter name explicitly. We believe this increases readability.

You may also notice how there are two different usages for curly brackets: if there is at least one «» keyword then the expression is a block of statements, otherwise the expression is a library literal, which can contains methods and nested libraries. A nested library is denoted by an upper-case name, and can be created from a library literal or from an expression producing a library literal. A library literal can be a class (default case) or an interface (starts with the «» keyword). A nested library in 42 is similar to a static inner class in Java, or a nested class in C++. It is just a convenient way to separate the various components of our program and organize them into a tree shape.

The class «» from before offers a single class method, has no fields and you can not create instances of «», since no factory is present. In 42 we do not have constructors. Objects are created by factory methods, that are just normal methods that happen to return an instance of their class. We believe this is a much simpler and more consistent approach to object initialization than having special syntax that encourages programmers to make assumptions about the behaviour of the operations.

(3/5)Simple class with internal state

Now we show a class with state and a factory method:

Indeed, «» is a decorator. Decorators are classes/objects that offer an operator «», called the decorator operator, whose goal is to translate a library into a better library. In this case, «» is translating the class «» into a much longer class, with a factory method taking in input the fields and initializing them; but also containing boring but useful definitions for equality, inequality, conversion to string and many others.

Finally, we define a methods to add to each of the coordinates. For very short methods we can omit the curly brackets and «». Indeed, method bodies are just expressions, and the curly brackets turn a block of statements into one expression. In the method «» we show how to create a new «» instance and how to call getter methods. In the method «» we show an improved version, using the «» method, another gift of Data, which allows us to easily create a clone with one or more fields updated. We can define two methods, «» and «» with the same method name, if parameter names are different.

Note that we always use getters and we never access fields directly. In many other languages we can use write «» and «». Such syntax does not exists in 42. The same goes for object instantiation; in many languages there is a dedicated «» syntax, while in 42 it is just a method call.

Also, similarly to what happens in Python, we need to use «» to call methods when the receiver is «». While it makes some code more verbose, naming the receiver avoids ambiguities about scoping and nesting for method resolution.

Decorators

Decorators, such as «», are one of the main concepts used by 42 programmers. We will encounter many decorators in this tutorial. For now, just get used to the pattern of writing «» to go from a minimal chunk of code, with method declarations for the application specific bits, to a fully fledged usable class.

The backslash «»

In 42, we can use the «» character as a shortcut. There are two different ways to use the backslash: as a keyword or immediately followed by a lowercase identifier.

As a keyword, «» represents the expected type of the surrounding expression. The slash searches outwards on super expressions until it finds a place with an easily guessable type: the return type of the method, a method parameter or a local binding with an explicit type. For example:

Followed by a method name (and method parameters if any) a «» represents the receiver of the innermost method invocation. Thus, for example

In the rest of the tutorial, we will use «» when it saves space. This shortcut seems unusual at first, but with a little of experience becomes very clear. 42 is a pure OO language, where the method call is the central operation. This syntax allows for the expressions of the method parameters to depend on the method receiver. We will see that this enables many interesting micropatterns.

(4/5)Collection.list

Lists can be defined using «», as in the example below,

Consider now the following code:

(5/5)First summary

• At the start of your program, import a towel using «», as in «».
• To define a simple class exposing its state and some methods working with those, use «», as in «».
• You can define methods in classes with the «» keyword. Use «» for methods that can be called on the class object directly.
• To introduce the concept of list for a certain type, use «»
  as in the class declaration «»

Digressions / Expansions

Here, after the summaries, we will digress and expand on topics related to the chapter. Digressions/expansions may be more technical and challenging, and may refer to any content in any of the other chapters, including the forward ones. For example, we are now going to make some more precise remarks about:

Method selector

In 42 a method selector is the method name plus the list of all the parameter names, in order. Methods in a class must be uniquely identified by their method selectors. This provides a good part of the expressive power of overloading, while avoiding all the complexities of type driven overloading resolution.

Keep control: Modifiers, kinds of references and objects

(1/5)Kinds of objects

In object oriented languages, objects can form complex networks of dependencies by referring to each other using their fields. The Reachable Object Graph (ROG) of a given object is the set of all objects reachable from it, including itself.

An object is mutated if a field of an object in its ROG is updated . A mutable object is an object that can be mutated. The 42 type system is able to ensure that some objects can not be mutated. We call those immutable objects. All instances of «» are immutable. The ROG of a «» object contains the «» itself and the «» coordinates. Fields «» and «» can not be updated and the «» objects are immutable. Immutable objects are very easy to use but may be inadequate when representing entities whose state can change across time.

Let's now define a mutable «», whose location can be updated:

• The «» field is «». This is called a variable field: a field that can be updated by calling a setter. Non-variable fields can not be updated.
• «» is a «».
  We have seen a «» already, and we have seen methods such as «» and «» showing no modifier; they implicitly have the default modifier «». Similarly, whenever a type does not specify a modifier, it has the default modifier «».
  «» methods can mutate the «» object. If you have experience with C++ you can see the contrast with const methods. Immutable (default) methods works only on immutable «» objects. Later, we will see much more about modifiers.

As you see, we are using the «» method from before. Also notice that we are calling the setter «» without providing the parameter name. While this is usual in other languages, in 42 parameters are selected by name. Sometimes writing down all the parameter names can get tedious. If the first parameter is called «», we can omit it: Writing «» is equivalent to writing «». This works also for methods with multiple parameters, if the first one is called «». Writing «» is equivalent to writing «».

We can use «» by writing, for example:

(2/5)Interaction between mutable and immutable

We now explore some interaction between mutable and immutable objects.

The method «» first uses the «» setter method to update the «» field with the «» leftmost element of the field «». By the way, collections in «» are primarily designed to store and retrieve immutable objects; later we will show also how to manipulate mutable ones.
The method then uses the «» exposer method and the «» method to mutate the list of points. Both exposers and getters provide access to the value of a field; exposers are used to access the values of mutable fields. Exposers should be used with care: long term handling of references to (parts of) a mutable object could cause spooky action at a distance.
In general, methods starting with # should be used with care.

This code models an animal following a path. It can be used like this:

(3/5)Capsules: Keep aliasing graphs untangled

In 42 we can change «» to prevent this aliasing issue.

A capsule mutator is a class method whose first parameter is the capsule field as «». It is a way to mutate the value of a capsule field without exposing it. «» recognizes only the methods annotated with «» as capsule mutators. Those methods can then be safely accessed as instance methods with the same name.
The annotation is called «» because capsule mutators also clear all the object based caches. Automatic caching is one of the coolest features of 42 and we will explore it later in this tutorial.

Note that we cannot have «» exposers («») for capsule fields: other code could keep those references and then mutate the ROG of the field, breaking local reasoning about Animals. With «», we are forced to initialize two animals using different paths:

(4/5)Handle mutability

Immutable objects of any class

How can we get an immutable «»? When an «» is created using «» we create a «». In most cases you can promote such reference to immutable/capsule; just make the type of the local binding explicit. The type system will take care of the rest. If a reference can not be safely promoted to immutable/capsule, you may have to clone some data or to refactor your code.

immutable
dog1.move()
//dog2.move()  //ill-typed, requires a mut Animal
]]>

lent and read

We have seen immutable, mutable, capsule and class. The are still two modifiers: «» and «». They are hygienic references: they can be read but can not be stored in mutable/capsule/immutable fields. «» is an hygienic mutable reference, allowing mutation but not long term storage. «» is an hygienic read-only reference.

A method with a single mut parameter can still be called using a lent reference in place of it. «» is the common supertype of «»,«», «» and «». In general, we can use «» when we do not care about the mutability of an object. For example, we could add to «»

(5/5) Summary

Kinds of classes, summary

• immutable classes: have only immutable fields. It is useful to model mathematical concepts. It is easy to reason about code using immutable classes, but some properties of real objects can be better modelled with state mutation.
• shallow mutable classes: have only (variable) fields of immutable or capsule type (or class, as we will see later). Reasoning with shallow mutable classes is near as easy as reasoning with immutable ones, and often more natural.
• deep mutable classes: have mutable fields. Reasoning with deep mutable classes can be very hard.

Modifiers: summary

• immutable: the default. When you omit the modifier, you mean immutable. An immutable reference points to an object that is never changing. Its whole reachable object graph never changes and is immutable as well.
• mutable: A mutable reference behaves like a normal reference in Java, C#, C++ , Python and many other languages. Mutable references require mutable objects and allow mutating the referred object.
• capsule: capsule references are used only once and they guarantee that the whole reachable object graph is reachable only through that capsule reference. Capsule references provide a structured way to reason over deep mutable objects. Fields can be annotated capsule, the meaning is that they need to be initialized/updated with capsule variables. We will discuss more about capsule fields and how they differ from capsule references later.
• read: A readable reference can not be used to mutate the referred object; but other mutable references pointing to the same object can mutate it. Read references can point to both mutable and immutable objects. It is easy to be confused between read and immutable references. As a rule of thumb, if you are in doubt about whether to use an immutable or a readable reference, you probably want an immutable reference.
• lent: a hygienic mutable reference allowing mutation but not storage. Lent and read are useful to handle in controlled way the state of deep mutable classes; moreover using lent and read on method parameters allows to make explicit what are the method intentions and requirements.
• class: class references denote the class object, on methods the meaning is the same of static methods in many languages, but it can consistently be used on parameters/local variables/fields to encode behaviours similar to dependency injection.

Keep control, summary

• mutable: mutable objects can be freely aliased and mutated. They allow for a liberal programming style like we can find in Java/C++/C# or Python. They can be referred to by capsule, mutable, lent and read references.
• immutable: immutable objects can be obtained by promoting instances of mutable classes. They can be referred to only by immutable and read references.
• class: class objects can be accessed from anywhere by using the corresponding class name; It is also possible to store them into (class) local binding. Some programmers found the fact that class objects are instances of themselves deeply concerning or disturbing, while for others it is just a good story to tell to break the ice at parties.

Basic classes

(1/5) Num

«» is a general number type, implemented as an arbitrary precision rational. When in doubt of what numeric type to use, «» is a good first guess. Some examples of usage:

Other numeric types

AdamsTowel offers two other numeric types: «» (64 bits floating point) and «» (64 bits integers, rarely used).

Conversions

Conversions between various numeric classes must be performed explicitly. AdamsTowel offers a simple way to convert between numeric classes; all numeric classes implements «» so that they can be converted in to each other using the empty named method. For example we can convert indexes into doubles by writing «». This will avoid precision loss as much as possible.

(2/5) Units: An example library

We will now see how to load and use an interesting 42 Library:«». Consider the following code, where the class decorator «» allows us to load libraries and embed them in the current context, while the «» keyword imports the code from the web.

Num]
..
res = (6SI.Meter + 4SI.Meter) * 2Num //20Meter
//wrong = 6SI.Meter + 2SI.Second
]]>

As you can see, we can sum meters together, and we can use the support for multiplication, but we can not mix different units of measure. Mathematically you can obtain the support out of the unit by division; that is, 42 meters divided by 2 meters is 21. Units also provide method «», which is just extracting the value of the support from the unit. This can be convenient during programming but does not make a lot of sense mathematically and thus it should be used with care, similarly to other methods starting with «».

Some code which uses units in interesting ways:

0SI.Newton (Debug(S"I can fly"))
myAcc = myLift/stackWeight
reachedHeight = (myAcc*t*t)/2Num //after t (10 sec)
//works assuming the rocket fuel burnt in 10 sec is negligible
]]>

(3/5) Alphanumeric

In the same way «» allows easy creation of arithmetic classes, «» allows easy creation of alphanumeric classes: classes that can be instantiated from a string literal that follow certain properties.

(4/5) Enumerations

Enumerations can be obtained with «», as in the following code:

(5/5) Summary

• We had a look at the most basic features of AdamsTowel. There is rich support for defining your own specialized data structures instead of having to rely on the ones provided by default.
• Use «», «» and «» to give meaning to your constants. In this way, the type system will help you to use values with the semantics that you decided. Be sure to define all of the right base classes to establish a convenient vocabulary to talk about your problem domain.

Errors and Exceptions: Messages in AdamsTowel

(1/5)Errors, Messages, Asserts, Guards, .... So much terminology

In 42, when something takes an unexpected turn, you can throw an «». This is similar to Java unchecked exceptions. Every immutable object can be thrown as an error. While it is possible to thrown informative strings, they do no offer enough structure to fully take advantage of the error mechanism. AdamsTowel defines the interface «»: a structured way to provide a certain kind of message to the user. There are two main kinds of «»: «» and «». While assertions are useful to observe bugs, the application logic should not depend on them, since they may change in unpredictable ways during library evolutions, and can be enabled or disabled. Since program logic can depend on guards being thrown, guards need to be consistent across library evolution. Assertions are a convenient tool to prevent the code from proceeding out of our designed state space. The assertion class called «» looks like a road sign and represents a feeling of "NO/PROHIBITED/FORBIDDEN" or something similar. Assertions are also very convenient for checking pre/post conditions. The following code show usages of «» (for preconditions and, in general, blaming the client of a function) and «» (for postcondition checks in the middle and, in general, blaming the function implementation).

0Num; //simplest form
    answer<10000Num msg=S"here with personalized message answer= %answer";
    actual=answer, expected=42Num //do a better error reporting
    ] //in a bunch of assertions, they are all going to be checked/reported together.
  recomputedAnswer = 6Num*7Num
  X[//postconditions/checks in the middle
    actual=recomputedAnswer
    expected=42Num
    ]
  X[answer==recomputedAnswer]
  if answer>50Num (//how to just throw error X
    error X""
    )
]]>

«» is often used as last case in a sequence of if-return; for example, instead of defining «» inside of «», we could compute it externally as shown below:

(2/5) Create, throw and capture

Create and throw

You can create new kinds of messages using «» as a decorator:

Capturing errors and exceptions

In 42 there is no explicit «» statement, but any block of code delimited by round or curly brackets can contain «». In the code example below, lines 2 and 3 are conceptually inside the implicit «» statement. If nothing is thrown then lines 6, 7 and 8 are executed. Note that «» and «» can see «» and «»; this would not naturally happen in a language with explicit «» statements; «» and «» would become local bindings inside the «» statement.

Strong error safety

In 42, error handling guarantees a property called strong error safety (strong exception safety in the Java/C++ terminology). This means that the body of a catch must not be able to observe state mutated by the computation that threw the error. This is enforced by disallowing catching errors in some situations.
That is, the following code do not compile

Intuitively, a programmer who does a bunch of sequential operations on some mutable objects would expect them all to be executed. They expect the intermediate states of those objects not to be relevant to the surrounding program. Consider the following example:

Exceptions and errors violate this intuition, since they can be raised in the middle of the sequence and prevent the later operations. For example, if «» fails, then Bob will miss his party, possibly because he is too drunk. This violates the programmers' expectations outlined above.

Exceptions can be accounted for, since the type system knows about them; so the programmer can be expected to plan for them. On the other hand, errors can be raised anywhere and human programmers often account for them only as a last resort.

Thanks to strong error safety, this natural attitude of human programmers is somewhat mitigated: while it is true that Bob will miss his party, the program will never observe him in this sorry state. Bob is, indeed, ready to be garbage collected.
Without strong error safety, we could simply catch the error and keep observing Bob in his distress.

(3/5) Exceptions and errors

Exceptions are like checked exceptions in Java. As with errors, every immutable object can be thrown as an exception. You can just write «» instead of «» while throwing or catching. When catching, «» is the default, so you can write «» instead of «».
Exceptions represent expected, documented and reliable behaviour; they are just another way to express control flow. They are useful to characterize multiple outcomes of an operation, where it is important to prevent the programmer from forgetting about the many possible outcomes while focusing only on their preferred one. Exceptions are checked, so methods leaking exceptions have to mention it in their headers, as in the following.

Often, the programmer wants to just turn exceptions into errors. While this can be done manually, L42 offers a convenient syntax: «».

Assertions should not be thrown as exceptions, but only as errors.

(4/5) Return

As we have seen, we have used «» to exit from the closest surrounding pair of curly brackets. Also curly brackets can have «» or «», which must complete by throwing a «», «» or «».
Let's see some examples:

Return looks similar to error/exception

Return is actually another thing that can be thrown and captured. While only immutable values can be thrown as errors/exceptions, return can throw any kind of value, but returns can not leak outside of the scope of a method. Hold your head before it explodes, but curly brackets are just a syntactic sugar to capture returns; these two snippets of code are equivalent:

Depending on how your brain works, knowing the mechanics of «» can help you to use return better and understand why you can omit «» for simple method bodies, and why you can write multiple groups of curly brackets and have local returns. Or it may just be very confusing. If you are in the second group, just never ever write «» explicitly and continue on with your 42 experience.

(5/5) Errors, exceptions and return, summary

• Always detect misbehaviour in your code, and terminate it with an «».
• Whenever something outside your control happens, give it a name and throw it as an error, as in:
  It just takes 2 lines, and will make debugging your code so much easier.
• Use errors intensively, but use exceptions sparingly: they are needed only in a few cases, mostly when designing public libraries.
• To convert exception into errors, use the convenient short syntax «».
• Instead of manually writing long lists of leaked exceptions, you can use «». This is particularly convenient for small auxiliary methods.
• It is sometimes possible to write elegant and correct code that is not covered in layers upon layers of error/exception checking, but often is not possible or not convenient. Up to half of good 42 code will be composed of just error/exception handling, repackaging and lifting. Do not be scared of turning your code into it's own policemen.

Caching

(1/5) Normalization

One of the big advantages of deeply immutable objects is that two structurally identical objects are referentially transparent, that is, you can not distinguish whether they are represented in memory by one object or two. This means that it is possible to reuse the same objects to save memory. While in other languages the programmer would have to implement some specific support to reuse objects, in L42 this is supported directly in the language, by a process called normalization . An immutable object can be turned into its normalized version using «».

The logic needed for normalization is the same needed to check if two arbitrary objects are structurally equal, to print an object to a readable string and to clone objects. Thus data allows for all of those operations indirectly relying on normalization. Those are all operations requiring to scan the whole ROG of the object, so the cost of normalization is acceptable in context.

(2/5) Lazy Caching

Some methods may take a long time to compute, but they are deterministic, and thus we could cache the result and reuse it many times. A typical example is Fibonacci:

As you can see, the caching is is completely handled by the language and is not connected with the specific algorithm. This pattern is general enough to support any method from immutable data to an immutable result.

(3/5) Automatic parallelism

When decorated by «», «» caches the results of methods after they have been called the first time. However, why wait for the methods to be called? Once the receiver object is created, the method could be computed eagerly in a separate worker, so that when we call the method, we may get the result without waiting at all. That is, if we use «» we can get automatic parallelism: the language will handle a set of parallel workers to execute such method bodies.

An important consideration here is that both «» and «» are unobservable; that is, the observed result of the code is not impacted by lazy or eager cache. Consider the following code:

(4/5) Invariants and derived fields

We have seen that cached behaviour can be computed lazily or eagerly on immutable objects. But we can bring caching even earlier and compute some behaviour at the same time as object instantiation. This allows us to encode derived fields: fields whose values are completely determined by other values in the same object. Consider the following example:

We can build on this behaviour to encode class invariants: «» methods with «» return type designed to simply throw error if the state is incorrect. For example, consider this updated version of «»:

=0Double && y>=0Double) error X"""%
      | Invalid state:
      | x = %x
      | y = %y
      """
  }
]]>

(5/5) Summary

In 42 immutable objects, can be normalized in order to save memory. This works also on circular object graphs. In case you are interested in the details, it relies on a variation of DFA normalization. As a special case, objects without fields (immutable or not) are always represented in memory as a single object. Results of «» and «» are attached to the normalized version of an object, thus making it possible to recover them simply by building a structurally identical object.

There are three kinds of caching, depending on the time the caching behaviour activates:

• «» computes the cached value when the annotated method is first called. It works on «» and «» no-arg methods. An obvious workaround for the no-arg limitation is to define computation objects; this also works well with normalization: computation objects will retrieve the cached results of any structurally equivalent object.
• «» computes the cached value in a separate parallel worker, starting when the object is created. It only works on «» no-arg methods of classes whose objects are all deeply immutable. Those classes will automatically normalize their instances upon creation.
• «» computes the cached value during object construction. Since the object does not exist yet, the annotation can only be placed on a «» method whose parameters represent the needed object fields. This annotation does influence the observable behaviour. If there is no error computing the «» methods, then the fully initialized object is returned. But, if an error is raised computing the cache, instead of returning the broken object, the error is leaked during object construction.
  This, in turn, allows us to encode class invariants and to provide a static guarantee that users of a class can rely upon.

Caching on Mutable objects

(1/5) Cache invalidation

The main advantage of caching methods of immutable objects is that the cache stays valid. L42 can also cache methods of mutable objects, and discovers on its own when the cache needs to be invalidated. Consider this trivial variation of the «» example above where the fields can be updated:

(2/5) Deeply mutable objects

As discussed above, a deeply mutable object is a mutable object with some mutable fields. Also deeply mutable objects can support «», but such objects must have encapsulated state, as we have seen before for the class «».

maxD (
        maxI:=i
        maxD:=currentD
        )
      )
    if maxI!=I"-1" path.remove(maxI)
    )

  @Cache.Now class method
  Void invariant(read Points path, Point location) = 
    if path.contains(location) error X"..."
  }
]]>

Cache.Lazy and Cache.LazyRead

As we have seen before, we can annotate «» and «» methods with «» so that the result will be computed once, the first time that the method is called. We can also annotate «» methods in the same way. However, the cache is now stored in the actual objects and not in the normalized versions. This happens because a «» reference can refer to either mutable or immutable objects, and only immutable objects can have normalized versions. If anything in the ROG of the «» object is mutated, then the cache is invalidated, and the result will be recomputed the next time the method is called. Indeed this annotation enables lazy caching on mutable data-structures, where the cache is automatically invalidated and removed when a «» method terminates. Finally, since the type system can not track when the ROG from «» fields is mutated, a «» can only be applied to classes whose fields are all «», «» or «»; that is, their instance all have encapsulated state.

If a class has «» fields, but those are not actually used to compute the cached value, we can apply the «» annotation to an opportune «» method instead. Every method annotated as «» could instead be annotated as «». This annotation is a point in the middle between «» and «»; it produces the same behaviour as «» but works similarly to «»: it is applied to «» methods whose parameters represent fields, and «» generates a correspondent no-arg «» method. «», «» and «» methods all behave as if they where recomputing the result, but with a different performance.

Cache invalidation is considered one of the great challenges in writing correct programs; L42 can handle it correctly and automatically. However, there is a cost: you have to encode the algorithm so that the type system accepts your code and so that the caching annotations can be applied.

(3/5) Box patten

As we have seen, in order to write mutable objects with encapsulated state, we need to design them well, using «» to initialize the mutable data, using «» to mutate such state, and «» for the invariant. However, we can also program a naive deeply mutable object and box it up as a second step. This can require a little more code, but it is more intuitive, and works very well for arbitrarily complex cases. Consider the following code:

As we have seen, with the box pattern we can have the flexibility of temporarily open invariants without any of the drawbacks. Of course, programmers will need to keep in mind which values are protected by invariants and which values are unsupervised by invariants. In 42 this is under the control of the type system: a value of type «» has no special guarantees, while a value of type «» will ensure the invariant.

(4/5) Controlling the ROG shape

An attentive reader may have notice that we would allow for fields «» and «» to point to the same «» object. A Java programmer may be tempted to just add «» in the invariant, but this would just use the user defined «» operator, that on classes created using «» is likely to check for structural equality instead of pointer equality. AdamsTowel offers «» to check for reference equality, but this method only works for «» objects. The wheels are indeed «» objects, but the invariant method takes a «» receiver; thus we can only see the wheels as «». In this case, the inability to use pointer equality is actually a good thing, since it does not correspond to what we really wanted to express: what if the two wheels are different objects but they share the same «» object? What we want is to check that the mutable objects are not aliased in physically unreasonable ways. Generally, what we often want is to ensure the tree shape of the mutable part of the object graph. In 42, we can create classes where all of the instances are guaranteed to follow this property, by making all fields either «» types of classes that recursively respect this property or «»/«». However, according to what we have seen up to now, «» fields can only be mutated by defining «» methods, and those methods will be unable to mutate any other «» field. Consider the following code:

(5/5) Summary

Representation invariants and lazy caching can be applied to mutable objects as well as immutable ones. Proving properties on mutable objects requires us to know and apply various patterns. Historically, in software verification, representation invariants where small units of code, mostly focusing on the direct content of the fields and mostly relying on either pointer equality or the binary value of primitive datatypes, where the invariants could be deliberately broken while the program was still able to observe the broken object. None of this is possible in 42; in particular, 42 guarantees that no broken objects can be observed. The box pattern allows us to divide the value into two types: the one with an enforced invariant and the raw object state. This recovers the flexibility of temporarily open invariants without any of the drawbacks. Note that a sound language with normalization and caching/invariants can not offer pointer equality tests on immutable objects. Consider the example of a list whose invariant requires all of its elements to have a distinct pointer values. A list with such an invariant may contain two structurally equal but not pointer equal elements. Suppose such a list became immutable and was normalized. Now those two elements would be pointer equal, and the invariant would have been broken by normalization.

It can be hard to remember the differences between all of the «» annotations. Below, we show a table summarizing them.

Notes:

• imm* = applicable only on classes with all fields «»/«» and not «».
• read* = applicable only on classes with all fields «»/«».
• fields = method parameters are field names. Capsule fields are seen as «».
• fields+ = the first parameter is a «» field, seen as «». Additional parameters can be «»,«» or «».
• invalidation = the method is executed on the first call, or the first call after invalidation.
• invalidation+ = the method is executed during the factory, and immediately after any invalidation.
• instance- = caches in the instance are invalidated.
• read0 = a «» method with zero parameters.
• mut+ = a «» method with the additional parameters as for fields+.
• parallel = executed in a parallel worker starting after the factory.

Digressions / Expansions

As we have seen, parallel programming can be viewed as a form of caching. In some cases, we need parallel programming on mutable data. In our experience, this is not very common; the cost of copying data around is much smaller that most programmers assume. Let us repeat this very clearly: there are many other ways to optimize software, and they are much easier and much, much more rewarding than avoiding copying the few mutable parts of your data structure a couple of times. We think that only highly skilled and motivated programmers can discover and hunt down all of those other much more pressing algorithmic issues that often spoil performance. Only after approaching the performance limits of «» with good algorithms, it could make sense to adopt parallel programming on mutable data to avoid some extra clones. However, if you are in such a situation, you can use the annotation «» as shown below. Again, the 42 type system will ensure that parallelism is not observable.

Non-Mutable computation

In this pattern, none of the initialization expressions can use «» or «» parameters. In this way nothing can be mutated while the forkjoin is open, thus parallelism is safe. This is more expressive than «» since it allows us to run parallel code on «» references of mutable objects.

Single-Mutable computation

In this pattern, a single initialization expression can use any kind of parameter, while the other ones can not use «», «» or «» parameters. This pattern allows the initialization expression that can use «» to recursively explore a complex mutable data structure and to command updates to immutable elements arbitrarily nested inside of it. Consider for example this code computing in parallel new immutable string values for all of the entries in a mutable list:

This-Mutable computation

In this pattern, the 'this' variable is considered specially. The method must be declared «», and the initialization expressions can not use «», «» or «» parameters. However, the parameter «» can be used to directly call «» methods. As we have seen before, «» methods can mutate a «» field; thus different initialization expressions must use «» methods updating different «» fields. In this way, we can make parallel computation processing arbitrary complex mutable objects inside well encapsulated data structures . Consider the following example, where «»s could be arbitrarily complex; containing complex (possibly circular) graphs of mutable objects.

Interfaces, subtypes and matching

(1/5)Interfaces, Basis and Details

Interfaces Basis

Interfaces in 42 are quite similar to interfaces in other OO languages. There are however a couple of important differences.

While implementing an interface method, you can avoid the type signature. For example, in the following code, to implement «» inside of «», the types «» and «» are not repeated.

Interface diamonds are allowed; that is, the following code is correct:

You can refine the return type of an interface method, by repeating the full type signature with the desired return type. On the other hand, the parameter types cannot be refined.

(2/5) Interfaces and class methods

Interface methods in 42 are all abstract; that is, without bodies. A version of the body will be provided by all classes implementing the interface. This also includes class methods.
For example, consider the following code:

In 42 interfaces do not have implemented class methods. Sometimes we want to semantically associate some behaviour with an interface. For example we could check intersections between shapes using the draw method. What we would need, is a traditional (non dynamically dispatched) static method. In 42, static methods are just nested classes with a single class method with the empty name. In 42 adding new classes is very common, so do not be scared of adding a new class just to host a method.
For example

(3/5)Subtyping

Dynamic dispatch is the most important feature of object oriented languages. Subtyping is the main feature supporting dynamic dispatch; for example we can iterate over a list of «» and «» them without the need to explicitly handle in the code all the possible kinds of «» on a case by case basis. Note that modifiers («», «», «»,..)) offer subtyping but not dynamic dispatch.

Interfaces and classes represent two fundamentally alternative compromises between the providers and users of objects:

• Interfaces allows client code to be implicitly parametric on the behaviour of individual objects. The client code can make no assumption on the specific implementation of the interface.
• Classes allow client code to rely on their invariants. The user code is forced to pass only a specific kind of implementation.

In simpler terms, if we have a «» interface, and we call «», we will get the right kind of drawing behaviour for that shape. On the other hand, we can not statically predict what kind of shape and behaviour we will execute.
If instead we have a «» class, then we can statically predict what kind of behaviour «» will execute, and that the width and height of the drawn shape are going to be equal, as for the «» invariant. On the other hand, our «» using code can only be used with squares, not any of the other kinds of shape.

(4/5)Matching

It is possible to inspect the runtime type of an object by using matching. We will now provide various examples of matching and explain the behaviour.

The syntax «» can also be used in expressions when the type system needs help with figuring out the type, usually because some information will be generated by a decorator at a later stage. Sometimes we may have to write code like the following «»: the method «» is called on the result of «», that we expect to return a «». While «» will check the type at run time, the explicit (sub-)type annotation with «» is checked at compile time, as if we wrote «»

The code below:

(5/5)Interfaces, subtypes and matching, summary

Interfaces in 42 serve the same role that they serve in other languages, with a little bit of a twist in the details. The big news is that decorators («» in our examples) can provide the boilerplate implementations for free. This is much more powerful than traits, multiple inheritance or Java 8 default methods, since the implementation can be generated by examining the class.
In the right conditions, matching is a useful tool to reduce code size and complexity. However, dynamic dispatch is still the preferred option in the general case. On the other hand type matching works only on a finite number of hard-coded cases, making it fragile with respect to code evolution.

Collection: list, map, set, optional and their operations

(1/5)lists manipulation

As we have seen before, lists can be defined using «», as in the example below.

Immutable collections (and also mutable ones, as we will see later) can be accessed with the following methods:

Mutate sequences

Mutable sequences can be more efficient that immutable ones, and are more general, since they can store mutable objects.
Now we show some methods over a mutable list «»; consider each following line independently:

(2/5) Iterations on lists and views

We now show various pattens to iterate on lists. First some usual foreach:

ys.size()
  for x in NView(xs), y in NView(ys) ( .. )
    //will iterate for as long as both xs and ys have elements.
    //similar to a functional zip
  }
NViewM = Collection.View(Num.List).more()
MainMore = {
  xs= Num.List[..]
  ys= Num.List[..]
  for x in xs, y in NViewM(ys, more=30Num) ( .. )
    //will iterate as long as xs, even if ys is shorter.
    //y = 30Num when the iteration get over ys.size()
  for x in NViewM(xs, more=10Num), y in NViewM(ys, more=30Num) ( .. )
    //will iterate for as long as either of xs and ys have elements, and values
    //x = 10Num, y = 30Num are used when the collections exhausted their elements.
  for x in NView(xs), y in NViewM(ys, more=30Num) ( .. )
    //behaves as in the "x in xs" case: a 'cut' view will consume 'more' elements
    //if they are available
  }
]]>

The power of the \

There are various methods taking advantage of the «» syntactic sugar. They provide an expressive power similar to what list-comprehensions provide in python and streams in Java, but by just using simple control flow like for/if:

2Num \add(a) )
X[ bs1==Num.List[3\;4\] ]

//flatmapping
bs2 = Num.List()( for a in as for b in bs0 \add(a+b) )
X[ bs0==Num.List[11\;21\;31\;41\;12\;22\;32\;42\;13\;23\;33\;43\;14\;24\;34\;44\;] ]

//reduce to string
str0 = S"the content is: ".builder()( for a in as \add(a) )
X[ str0 == S"the content is: 1234" ]
str1 = S"[%as.left()".builder()( for n in as.vals(1I) \add(S", %n") )++S"]"
X[ str1 == S"[1, 2, 3, 4]" ]

//reduce/fold
acc  = ( var x = 0Num, for a in as ( x+=a ), x )
acc1  = 0Num.acc()( for a in as \add(a) ) //also \addIf, \times, \val ..
X[ acc==acc1; acc1 == 10Num ]

//checks a property; great in an if or an X[]
ok0 = Match.Some()( for a in as \add(a>3Num) )
X[ ok0 ]

X[ !Match.All()( for a in as \add(a>3Num) ) ]

X[ !Match.None()( for a in as \add(a>3Num) ) ]

X[ 0I.acc()( for a in as \addIf(a>3Num) )==2I ]

asContainsAllBs = Match.All()( for b in bs \add(b in as) )

asIntersectBs = Match.Some()( for b in bs \add(b in as) )

asDisjointBs = Match.None()( for b in bs \add(b in as) )
//Note: b in as == as.contains(b)
]]>

(3/5) Lists with mutable and immutable elements

Mutable sequences can contain mutable objects. While this can be useful in special circumstances, it can create aliasing issues similar to the ones of the animals example of before. To warn against such issues, methods «», «» and «» return «» references to mutable objects. In order to obtain a «» reference, the user needs to use the methods «», «» and «».

Up to now we focused on lists of «», but all instances of «» are immutable; we now discuss what happens where mutable lists contains a mixture of mutable and immutable elements. Consider the following code:

(4/5) Map, set, opt..

«» also support maps, sets, optional and enumerations. We will add more kinds of collections in the future.

Optional

In 42 there is no concept of null, and all the values are always intentionally initialized before they can be read. There are two main reasons programmers rely on nulls: optional values and circular/delayed initialization. Circular initialization can be solved with a «» types, an advanced typing feature that we do not discuss here. Optional values are a staple of functional programming and are logically equivalent to a collection of zero or one element, or, if you prefer, a box that may or may not contain an element of a certain type. Optionals values can be obtained with «» as shown below. Optionals are also optimized so that they do not require the creation of any new objects at run time.

  //we can just check if a box is not empty as if it was a boolean
  p01Box.#val().x(50\)//updates the x value of the point
  Debug(S"printing %p01")//printing Point(x=50, y=1)
  p00Box:= OPoint()//updates the local variables with empty boxes
  p01Box:= OPoint()
  if !p00Box ( Debug(S"printing %p00Box") )//printing <>
  X[
    !(p00 in p00Box);
    !p00Box;//using isPresent() or not is just a matter of style
    !p00Box.isPresent();
    ]  
  )
]]>

Optionals can be combined with the short circuting operators «» and «». Many interesting patterns emerge from this:

Map

Thanks to normalization 42 can have very fast and most reliable hash sets and hash maps. The values of sets and the keys of maps must be immutable, and are normalized just before being inserted in the collection. Then, the value of the normalized pointer is used to check for equality and hashcode. This has various positive effects:

• The user does not need to write equality and hashing behaviour
• There is no risk of mistake in the equality and hashing behaviour
• The intrinsic invariants of the hashmap/hashset are never violated/corrupted.
• The equality is a perfect structural equality, but is as fast as pointer equality; for maps with large keys this can make a massive performance difference.

%val") )
  //we can use (..) to extract the key/val fields from PointToString.Entry
  //this iteration is straightforward since all values are imm
  roads = Roads[
    key=S"Kelburn Parade", val=\(x=0\ y=0\); //immutable to immutable
    key=S"The Terrace", mutVal=\(x=0\ y=0\);//immutable to mutable
    key=S"Cuba Street", mutVal=\(x=0\ y=0\);//immutable to mutable
    ]
  for read (key, val) in roads ( Debug(S"%key->%val") )
  //we add 'read' in front to be able to read mixed imm/mut values
  //if all the values were mutable, we could just add 'mut' in front
  )
  mut Roads.OVal optPoint = roads.#val(key=S"Cuba Street"))
  optPoint.#val().x(50\)//update the field of the object inside the map
  ]]>

• To extract a value using the key: «», «» and «»; to extract an optional «», «» or a «» reference, respectively. As for lists, it is always safe to extract a «» reference. An empty optional will be produced when attempting to extract as «» a value that was inserted as «» instead, so to reliably ask if a key is contained in the map we should write «».
• Mutable maps can be modified by inserting immutable values with «» and mutable values with «». Finally, an association can be removed using «».
• «» creates a class remembering the insertion order. This is needed to make the iteration deterministic. The keys can be retrieved with their order using «» passing the desired «», from zero to «» The corresponding value can be retrieved by methods «», «» and «» to extract a «», «» or a «» (not optional) reference to the value, respectively.

Set

Sets behave a lot like maps where the values are irrelevant, and have differently named methods. In particular, in addition to conventional «» and «», sets offer methods «» and «» to add and remove an element, and elements can be extracted in the insertion order by using method «» We are considering adding operators «» to sets, as supported by lists. On the other side, boolean methods like «» «» and «» can already be easily emulated with «» as we shown for lists.

(5/5) Collection summary

• There are tons of methods and operators to know, but since most code works around collections, it is worth the effort to memorize them.
• Immutable collections are easy to play with, using operators and «» methods.
• Mutable collections can be more efficient and flexible, but they come with additional difficulties.
• Most methods have a general version that works with an index, and specialized «» and «» variants.
• «» can help remove a lot of boilerplate, but is a concept unique to 42, and require some effort to get used to.
• «» is very useful and flexible. It is common to find methods composed from just a large «» statement plus a little pre and post processing around it.

Digressions / Expansions

Collections support iteration with the «» syntax. Iteration in 42 is way more flexible than in most other languages, and it is delegated on method calls. Iteration in 42 is designed to support two main iteration strategy: explicit indexes and iterator objects. For example, the code

Iteration methods in detail

• «» and «»
  They return an object able to provide the elements of the list. The second variant returns a «» object, this is needed to provide the mutable version of those elements, and to update those elements in the list. The second variant is used if the local binding is explicitly declared either «», «»,«» or «». For complex bindings, like «», the second variant is used if any binding component would require it.
• «» and «»
  The initial iteration hint is produced by «» and moved forward by «».
• «», «» and «»
  The iterator checks if it has more elements to provide by calling «». Since iterations in 42 can work on multiple collections at the same time, «» results can be combined with «». This design offers a lot of flexibility; special kinds of collections may return special data types to coordinate termination in some way. The AdamsTowel collections opt for an efficient solution where there are four logical results for «»: «», «», «» and «». The iteration will stop if all the «» return «» or «», and an error is raised if some «» returns «» and some other returns «». With this design, the result of the single «» method coordinates the various iterators to check if more elements are possibly available, and to decide how strongly to insist for those elements to be visited.

Possible implementations of Iteration methods

The iterator methods allows for a range of possible options. The simplest one, and possibly the most efficient, is to delegate everything to the collection object: in this case, there is no need to create a new object to serve as an iterator, since the collection itself is able to simply access/update its elements by index, thus «» and «» may simply return «». «» returns the «» and «» returns «» if «» and «» otherwise. Finally, «» will throw error if «» would return «».

Another option would be the one of a linked list, where it would be inefficient to rely on the index to access the elements. In this case, the «» and «» may simply return a singleton object delegating the behaviour to the index object. «» can simply expose the first internal node, and «» can produce the next node. The singleton object may be able to see private methods of those internal nodes, thus even if we expose the internal nodes, they will be just unusable black boxes to the library user, and all the interactions can be mediated, and checked by the singleton iterator object.

Iterators in Java and other languages will throw an error if the collection is somehow modified during the iteration. This could be supported by providing a specialized sublist object that can remember its version; but it is unclear if this is a good idea in 42, where most collections would be iterated while they are immutable. The few cases of iteration on mutable collections may be the ones where there are good reasons to perform mutation during iteration. While adding elements at the start of a collection under iteration is most likely a bug, other operations have very reasonable use cases. For example, appending elements at the end of a list while computing a fixpoint, removing tasks from the end of a list if they are now unneeded, or replacing already visited elements with new ones.

Input Output with Object Capabilities

(1/5) Controlling non determinism

Traditionally, in imperative languages I/O and side effects can happen everywhere, while in pure functional languages like Haskell they are kept in check by monads. In 42 we have type modifiers to keep mutation and aliasing under control. With only the features shown up to now, 42 is a deterministic language, thus every expression that only takes immutable objects can be called multiple times with the same values and will produce the same result.
The whole caching system relies on this property to work.
Thus input output, random numbers and any other kind of observable non determinism must preserve this property.
Introducing object capabilities:
An object capability is a mutable object whose methods can do some non deterministic, or otherwise privileged operation. If a method is given a «» reference to an object capability, then it can be non deterministic, otherwise it will be deterministic. Creation of new object capabilities is only possible by either relying on an existent object capability or by using a capability method: a method whose name starts with «»; however those specially named methods can only be called from a main, from another capability method or from a «» method of a capability object.

(2/5) Example: File System

To read and write files we need to load a «» library as shown below:

(3/5) Object capabilities programming patterns

The advantage of the division of the file system in an interface and a «» implementation are not limited to testing. For example, the user could embed some security and some restrictions in an alternative implementation of a file system. Consider the following code:

(4/5) Connection with other languages

In general, all the non determinism in 42 is obtained by communicating with other languages. 42 allows us to connect with Java, and Java allows us to connect with C/assembly. The best way to connect with java is to use the library «» as shown below:

    |      "any string computed in Java using "+id+" and "+msg);
    |    }
    |  }
    """)
  S.Opt text = j.askEvent(key=S"BarAsk", id=S"anId",msg=S"aMsg")
  {}:Test"OptOk"(actual=text, expected=S"""
    |<"any string computed in Java using anId and aMsg">
    """.trim())
  )
]]>

{
    |      System.out.println("Ping Event received ping "+msg);
    |      event.submitEvent("BarOut","fromJavaToL42","pong");
    |      });
    |    event.registerEvent("Kill",(id,msg)->{
    |      System.out.println("Doing cleanup before slave JVM is killed");
    |      System.exit(0);
    |      });
    |    }
    |  }
    """)
  model=Model(count=0I, j=j)
  model.fromJavaToL42(msg=S"Initial message")
  keys=S.List[S"BarOut"]
  models=J.Handler.Map[key=S"BarOut" mutVal=model]
  for e in j(keys) ( e>>models )
  Debug(S"Completed")
  )
]]>

(5/5) Object capabilities summary

• While most languages run in a single process, 42 runs in a cluster of processes; this is needed so that the master process is protected from any slave process going into undefined behaviour. This is the final piece of the puzzle allowing the correctness properties of 42 to be ensured in any circumstance.
• To enable non deterministic behaviour we need to call those specially named «» methods. Since they can only be called in a few controlled places, we can control what parts of the code can perform non determinism by explicitly passing capability objects.
• Capability objects are a very convenient centralized point of control to inject security or other kinds of restrictions.

Digressions / Expansions

Non deterministic errors

When discussing errors, we did not mention how to handle errors happening in a non deterministic way; for example, how to recover when the execution run out of memory space. In 42 this is modelled by non deterministic errors. They can only be caught in a main, in another capability method or in a «» method of a capability object. AdamsTowel offers a single non deterministic error: «». When a non deterministic error happens, we can recover it by catching an «». The code below shows how to cause a stack overflow and to recover from it.

Aborting wasteful cache eagers

«» methods may return a cached result; such result is guaranteed to be the same that would be computed if we were to directly execute the method. How does this work if the method is non terminating or simply outrageously slow? Those eager cache methods will eagerly spend precious machine resources. If the results of those computations are ever needed by a main, the whole 42 process will get stuck waiting, as it would indeed happen if we were to directly execute the method. All good: in this case 42 correctly lifted the behavioural bug into caching. However, if the result is never needed by a main, it would be nice to be able to stop those runaway pointless computations. We can obtain this by calling «».
This works no matter if they are in loop, simply slow, or stuck waiting on another cache being slowly computed. In some cases, we can even have multiple computations stuck waiting on each other in a circular fashion.

Exercises

A very large class of practically useful programs can be obtained just by declaring basic classes, collections and simple Data classes. Let's see some exercises and solutions to better understand what 42 code looks like.

(1/5) Max method

Write a static method «» returning the max from a list of numbers

Basic Solution:

(2/5) Merging and filtering

Write a static method «» producing a string from two lists of strings of the same length. For example «» should produce «z, b->y, c->z]"]]>»

Solution:

%v"))
    if res.isEmpty() return S"[]"
    text = res.reduce()(for s in \vals \add(\acc++S", %s"))
    return S"[%text]"
    }
  }
]]>

Precondition: «» is not negative

Solution:

= 0I]
    S.List()(for s in that if s.size()<= size \add(s))
    )
  }
]]>

(3/5) Read/Write files

Write a static method «» returning the content of the file where the current source code is located.

(4/5) Random mole (and how to divide you code in multiple files)

Here we show a larger 42 example. When writing large programs it is convenient to divide the source in multiple files. In 42 this can be obtained with the «» symbol. That is, if in a given file we write

More precisely, a 42 project must be a folder containing a file called «». Folders can contain other files «» or folders containing other «» and other files.
The meaning of «» depend on both the location in the code and of the position of the current file in the file system. To evaluate a «» 42 locates the nearest enclosing nested library declaration, and we record its name («» in the example). This identifies either a file or a folder. If both or neither of these exist, there is an error.
Note that the found «» file can contain more «», which will be resolved relative to the file before importing it into the current scope.

We can now design a longer example, represent a piece of land as a 80*80 bi-dimensional map, where every cell can be full of dirt (90%) or rock (10%). Then a mole start from the left top corner and attempts to digs through dirt randomly. After 3000 steps the mole stops. Define the opportune classes and write a «» method.

To start, we define some auxiliary classes:

=0I; x<80I;
  y>=0I; y<80I;
  ]

method This go(Direction that) = {
  return that.go(this)
  catch error X.Guarded _ return this
  }
  
method I index() = 
  (this.y()*80I)+this.x()
]]>

(5/5) Examples summary

• Always think about what can go wrong upfront
• Many methods can be completed by first checking for errors/issues and then using a «», possibly inside a «» or a «».
• Before heading into a problem, spend some time to define your problem domain. We dodged a lot of headaches by defining points with invariants.
• Well organized code, properly divided in files and folders is much easier to navigate and maintain.

Finally, Metaprogramming

Metaprogramming is the most important feature of 42. All the decorators that you have seen up to now are implemented with metaprogramming, which shows that 42 offers a good balance of freedom and safety.

The main idea of 42 metaprogramming is that only library literals can be manipulated. Metaprogramming is evaluated top down, most-nested first. Once a library literal has a name, it can not be independently metaprogrammed; but only influenced by metaprogramming over the library that contains it.

«» is a decorator allowing to store code in a reusable format. «» is a decorator that extracts the code from a trait. For example

Simply composing traits allows us to emulate a large chunk of the expressive power of conventional inheritance. For example, in Java we may have an abstract class offering some implemented and some abstract methods. Then multiple heir classes can extend such abstract class implementing those abstract methods. The same scenario can be replicated with traits: a trait can offer some implemented and some abstract methods. Then multiple classes can be obtained composing that trait with some other code implementing those abstract methods.

(2/5)Trait composition: methods

Trait composition merges members with the same name. As shown above, this allows method composition. Also nested classes can be merged in the same way: nested classes with the same name are recursively composed, as shown below:

Fields?

But what about fields? how are fields and constructors composed by traits? The answer to this question is quite interesting: In 42 there are no true fields or constructors; they are just abstract methods serving a specific role. That is, the following code declares a usable «» class:

• All candidate factories provide a value for all candidate getters, and all the types of those values agree with the return type of the corresponding getters. The parameter type of all candidate setters agrees with the return type of the corresponding getters.
• Additionally, any non-class method can be abstract if none of the candidate factories return a value whose modifier allows to call such a method.

Earlier in this tutorial we have shown code like

(3/5)Nested Trait composition: a great expressive power.

Composing traits with nested classes allows us to merge arbitrarily complex units of code. In other languages this kind of flexibility requires complex patterns like dependency injection, as shown below:

 %weight")
    }
  Wall = /*..*/
  Map = {
    var S info
    class method mut This (S info)
    class method mut This empty() = \(S"")
    mut method Void set(Item i) = this.info(\info++i.info()++S.nl())
    }
  }
TestAlice = (
  files=FS.#$()
  {}:Test"justARock"(
    actual=MockAlice.load(files=files, fileName=S"justARock.txt")
    expected=S"""
      |Rock: Point(5,6) -> 35
      """)
  {}:Test"rockAndWall"(
    actual=MockAlice.load(files=files, fileName=S"rockAndWall.txt")
        expected=S"""
      |Rock: Point(x=5, y=6) -> 35
      |Wall: Point(x=1, y=2) -> 10
      """)
  ..//more tests here
  )
]]>

(4/5)Typing considerations

Object oriented programs often contain entangled and circular type definitions. For example, strings «» have methods «» and «», while both «» and «» offer a «» method. That is, while circular values are a double edged sword (useful but dangerous), circular/recursive types are unavoidable even in simple programs. So, how do recursive types interact with metaprogramming? Path names can only be used in execution when the corresponding nested class is fully typed, thus the following example code would not work:

This also allows us to avoid defining many redundant abstract methods. Consider the following working code:

(5/5)Metaprogramming summary

Here we have introduced the way that 42 handles metaprogramming and code reuse. We focused on «» and «». Composing code with «» or «» we can partition our code-base in any way we need, enabling simple and natural testing and code reuse patterns.
When reusing code, we have to be mindful of missing types and missing methods. Structuring the code-base to avoid those issues will require some experience, and is indeed one of the hardest parts about writing complex 42 programs.

Traits and rename

(1/5)An introduction to Programmatic Refactoring

Traits allow us to programmatically rename methods and nested classes to other names. Consider the following example code, defining trait «», containing many nested classes: the interface «», the class «» implementing «», the class «», that is similar to «» but does not implements «» and finally the class «» that uses both «» and «»:

'A.k()]
Concrete2 = {//equivalent to just writing the following directly:
  A = {interface,  method S k()}
  B = {[A],        method S k()=S"Hi"                    class method This()}
  C = {            method   m()=S" world"                class method This()}
  D = {            method S callBoth()=B().k()++C().m()  class method This()}
  }
Main2 = Debug(Concrete2.D().callBoth()) //still prints "Hi World"
]]>

'A.k();
  'B.#apply() =>'B.of();
  'C=>'D;
  'D=>'C;
  ]
Concrete3 = {//equivalent to just writing the following directly:
  A = {interface,  method S k()}
  B = {[A],        method S k()=S"Hi"                       class method This of()}
  C = {            method S callBoth()=B.of().k()++D().m()  class method This()}
  D = {            method   m()=S" world"                   class method This()}
  }
Main3 = Debug(Concrete3.C().callBoth()) //still prints "Hi World"
]]>

(2/5) Programmatic Refactoring: all kinds of operations

Single

Programmatic refactoring of nested classes is transitive by default. All the nested classes are going to be renamed together with the renamed root. The code below shows how to specify a single rename instead:

'K; 'A=>'D.H ]
MultiConcrete = {//equivalent to just writing the following directly:
  D = {
    H = {
      class method S hi() = S"hi"
      B = {class method S world() = S"world"}
      }
    }
  C = {
    D = { class method S space() = S" " }
    }
  K = {
    class method Void print() = Debug(D.H.hi()++C.D.space()++D.H.B.world())
    }
  }
Main4 = MultiConcrete.K.print() //still prints "hi world"
]]>

We can also rename «». For example, with the code below we can make the original top level into a nested class, and the nested class «» into the top level:

'OriginalTop;single='NewTop=>'This]
]]>

On the other side, self rename, for example «'C]]>» is usually an error, and thus it will raise an exception. However, we can silence such errors and turn self rename into a no-op by using «'C]]]>» or «'C]]]>».

Hide

The code below shows how to hide a method or a class:

Clear

Hidden code is still part of the result, but it is no more accessible. Symmetrically, cleared code is not part of the result, but its entry point is still accessible, but abstract; clearing code allows us to override already defined behaviour, as shown below:

Soft rename

Clearing code allows us to override code by removing code. This is different with respect to what happens with overriding in most languages, where the former code still exists and can be invoked, for example with «». In 42 we can easily emulate super by using «]]>» instead of «»; the code below shows how «]]>» can be used on both methods and nested classes:

'SuperA; 'C.D.space()->'C.D.superSpace() ]:{
  SuperA = { class method S hi() B={class method S world()}}
  A = {
    class method S hi() = S"[%SuperA.hi()]"
    B = {class method S world() = S"[%SuperA.B.world()]"}
    }
  C={
    D={
      class method S superSpace()
      class method S space()=S"[%this.superSpace()]"
      }
    }
  }
Main7 = MultiConcrete4.C.print() //now prints "[hi][ ][world]"
]]>

Redirect

Finally, programmatic refactoring allows us to rename a nested class into an externally declared class. We call this kind of rename redirect. This also provides a simple encoding for generics. Consider the following code:

Num]
Main = (
  myBox = NumBox(3Num)
  Debug(myBox)
  Num n = myBox.that()
  Debug(n)
  )
]]>

We can redirect multiple nested classes at the same time, and we can put arbitrary constraints on the structural type of the destination types simply by specifying abstract methods and implemented interfaces. Consider the following example:

e2.myIndex().eval(e1)
    if res return e1
    return e2
    }
  }
Adventurer = Data:{S name, Num attack, Level level}
Level = Data:{
  Num exp
  S profession
  method Num eval(Adventurer that) = {..}
  }

DuelOperation = Class:Operation
  ['Elem.myIndex()=>'Elem.level()]
  ['Elem=>Adventurer;'Index=>Level]

Main= /*..*/ DuelOperation.best(e1=luke e2=gandalf) /*..*/
]]>

(3/5) Different ways to supply missing dependencies

As we have seen, in 42 it is convenient to write self contained code, where the dependencies can be specified as nested classes with abstract methods. In 42 there are three different ways to satisfy those dependencies:

• Sum: We can compose two traits with the operators «» or «» to provide some of the missing method implementations.

• Redirect: We can rename a class to an external one

Foo]
]]>

• Rename: We can rename a member to another member in the same unit of code:

'A]
]]>

(4/5) Introspection and Info

It is also possible to programmatically query the code structure and make decisions about it. For example

t2.info().methods().size() return t1
  return t2
  }}
MyClass = Class:Larger(t1=ATrait, t2=AnotherTrait)
]]>

(5/5)Programmatic refactoring summary

• Many kinds of operations can be performed on code
• Rename, as for «'B]]>» or «'A.bar()]]>», is used to rename all the occurrences of a member into another name or form, for the sake of the final user.
• Soft Rename, as for «'B]]>» or «'A.bar()]]>», only moves the declaration. It leaves in place all the usages and an abstract version of the original signature.
• Clear, as for «» or «», removes the implementation and all the private details of a member. It leaves in places all the usages and an abstract version of the original signature.
• Hide, as for «» or «», renames all the occurrences of a member into an uniquely named one. This new name is now completely invisible from outside the code unit.
• Redirect, as for «Num]]>», redirects all the usages of a nested class into an externally declared one. The internal declaration is simply trashed.

More decorators

Using the expressive power of programmatic refactoring many different decorators can be designed. Here we list and explain some of the most useful.

(1/5)Public

The «» decorator allows us to select certain members as «», and to hide all the others: for any nested class containing at least one «» annotation, «» hides all the non «» annotated members.
Consider the following example:

=18I]
    }
  }
]]>

Alternativelly, when we only wish to hide a few specific methods, we could just specify the private members. To this aim, we need to specify in «» the path to use to indicate privateness. We could for example use «», that loosely speaking represents a form of denial:

=18I]
    }
  }
]]>

Finally, «» is closing all the nested classes; this means that the fields and constructors are not any more abstract methods but implemented methods delegating to hidden ones. A sealed class encapsulates its state, but can be reused in less flexible ways: the code of two sealed classes can not be merged with trait operators «» and «».

(2/5)Organize

With metaprogramming, often we have to create code in a certain order, and this order may be in contrast with the final structure we want to create. For example, we may want to have an interface whose nested classes implements such interface. However, the following code:

'This]
]]>

In metaprogramming systems, code generation needs to proceed in a specific order. This sometimes creates difficoult situations. For example, the following naive implementation of a «» with a map of friends to locations would not work:

(3/5)Data.**

The «» decorator contains many useful nested classes, that can be used as independent decorators.

Data.AddList, Data.AddOpt, Data.AddSet

Decorators «», allows us to add a nested class «» working as a list of «». «» and «» work similarly, but for «» and «». That is, to define a «» supporting both lists of points and sets of points we can simply write:

Data.AddConstructors

«» applies a heuristic to decide what are the field of a class and add two constructors: The first is called «» and the second has the empty name; also known as «». «» simply takes all fields as immutable and produces an immutable result. «» takes the most general type for the fields and produces a «» result if class instances are mutable, and «» otherwise. The most general type for fields may be «» or «». We have not seen «» types yet in this guide; they are useful for circular initialization. For example

Data.Seal

«» also takes two parameters: «» and «». «» chooses the nested class to influence, and it is «» by default. «» is false by default, and if it is true attempts to use an already existent «» method to only expose normalized values out. It only works if class instances are immutable and fails if any constructor parameter is forward. «» is the part of «» processing and activating of all the «» annotations.

«» implements all of the abstract state operations by delegating to an equivalent private method. The class is then sealed. «» is a convenient class method that applies «» on all the nested classes in a library literal. «» uses «» internally. As discussed for «», code composition of sealed classes is less flexible since the state is now set in stone.

Data.Wither

«» takes an open class and adds «» methods; one for each field. Those methods create a new object calling «», where all the fields are the same, except for the one provided as a parameter. For example, in the usual iconic «» example, we could write «» to get «» Note that this generates only the withers to update a single parameter at a time.

Data.Defaults

In 42, methods are distinguished by their full selector, not their name; this is particularly convenient to encode default arguments, so that calling a method without mentioning a parameter will be equivalent to passing a default value to it. This can be done by hand; as shown in the example below:

This generate method will not have any of the parameter with a recognized «»; it will call those «» methods to produce the needed values and delegates to the original method.

Data.Relax

«» works exactly like «», but does not call «» on the result.

Data traits

Finally, the following methods return traits with one operation each, as obvious from their name: «», «», «», «», «», «», «».

Data as a combination of decorators

In the end, «» just composes all of those decorators and traits together as follows:

(4/5)Decorator

The «» decorator simplifies creating new decorators. for example, for a variant of «» that always normalize, we could do as follows, where we simply specify a method from «» into «» that can throw any kind of «».

We can produce very liberal variations of «» by simply re-implementing the method that composes all the individual decorators and traits. For example, if we wanted a variation of data that does not generate the withers, we could just write:

«» is a much more challenging decorator to define, but we have finally explored all the needed features. As a reminder, «» generates one enumeration element for any nested class. Thus, for example

'Vals.prev()]  //res.Vals.next is renamed into .prev
      step = TraitEnumStep['E=>nameFromRoot]  //set the current TraitEnumStep name
      res := (step+base)[hide='Vals.prev()]  //the new candidate result composes step and base
      //res.Vals.prev is hidden, so that the next iteration we can rename next onto prev
      )
    res := (res+TraitCacheVals)[hide='Vals.next()]  //res.Vals.next connects the
    //inductive step with the result, and can then be hidden
    (res+trait)[hide='sealed()]  //finally, we compose what we created with
    //any extra code that the user provided, and we seal the top level interface
    )
  }
]]>

As you can see, with a little experience it is possible to define decorators that behave like language extensions. Developement on a large 42 program should start defining some appropriate decorators to make the rest of the code more fluent and compact.

(5/5)Metaprogramming summary

• Metaprogramming is hard; 42 tries to make it simpler, but it is still not trivial.
• Making your own decorators it is easy when your decorators are just a simple composition of other decorators.
• Error handling is important while writing decorators. A large part of decorators code should be dedicated to handling errors and lifting them into a more understandable form, for the sake of the final user.
• We are just scratching the surface of what we can do with metaprogramming. If you are interested in becoming a Magrathean, then join our effort to design the painful metaprogramming guide.
• In the current state of the art we do not have an answer for what is the best 42 (meta-)programming style. Indeed, we still do not understand the question.

Example of a 42 program

In this chapter, we will see how to develop a GUI connected with a DataBase. For simplicity, consider that we have a database with a single table «» that contains a few fields. We want to make a GUI that displays the data and allows us to edit it.

(1/5) Query boxes

First we load the libraries we need: Unit, JavaServer, GuiBuilder and Query.

We then ask «» to generate a class to support SQL queries using a Java slave and a connection string. As an example, we are using a derby DB. For now, we consider the DB to be already populated. In the end we discuss how to initialize the DB itself.

Right now the class «» supports both «» and «». We expect to add more query languages in the future. «» is a query language to query the user by asking them to complete a form. Using «» in 42 is very similar to using «». In particular, the result of both SQL and IQL queries is a lists of objects instantiated using a unique #immK(..) method. While this is a consistent and flexible way to process tabular data, it means that for queries returning a single column we must have a type with such a single field. In 42, declaring those types and their corresponding list type takes just a single line. Note how for Person we can use our specialized units «», «» and «».

We can now make the set of all user queries with another «»:

(2/5) Model

To write a GUI we need a Model and a View. The model is an object whose methods are triggered by events of the view. Comparing this with the conventional MVC, here the model serves both the roles of the model and the controller. In this example, the model will have the two boxes and the java slave to control the Gui.

The other methods have a similar structure.

In this setting we represent persons in two different classes: «» and «». This allows for those two different classes to actually be quite different: «» have an «» field and fields «» and «» are of type «». On the other side «» have no «» field and fields «» and «» are of type «» and «». Those two classes serve different roles, and if we wish to change the kind of data the user must provid we can change «» and make it even more distant with respect to the information stored in the database. On the other side, if we wanted to apply a transformation on the data readed from the DB, we could use another custom person class, instead of «», and define and appropriate «» method to adapt the data from the database into any shape we need.

It is also interesting to consider what happens if the database schema changes. If the person table is removed, or the person fields are renamed, then we will get an error while typing the model.
In some sense we are turning events that would have caused a runtime exception into understandable compile time errors.

(3/5) View

The library «» allows to write a GUI using Java Swing. For safety reasons, Java code is compiled and executed on a separated JVM. We can easily generate a GUI for our example in the following way:

SwingUtilities.invokeLater(()->tModel.addRow(msg.split(","))));}
    |{event.registerEvent("Example.Display","tableClear",
    |  (k,id,msg)->SwingUtilities.invokeLater(()->tModel.setRowCount(0)));}
    """
  )
]]>

new l42Gui.L42Frame(event,"Example",800,600){
        JPanel screen1=new JPanel();
        {add(screen1);}
        JPanel buttons=new JPanel();
        {addNorth(screen1,buttons);}
        JButton addPerson = new JButton("add");{
          addPerson.addActionListener(e->event
            .submitEvent("Example","addPerson","PressedAdd"));
        }
        {addFlow(buttons,addPerson);}
        JButton removeById = new JButton("remove by id");{
          removeById.addActionListener(e->event
            .submitEvent("Example","removeById","PressedRemove"));
        }
        {addFlow(buttons,removeById);}
        JButton removeByName = new JButton("remove by name");{
          removeByName.addActionListener(e->event
            .submitEvent("Example","removeByName","PressedRemove"));
        }
        {addFlow(buttons,removeByName);}
        JButton printAll = new JButton("printAll");{
          printAll.addActionListener(e->event
            .submitEvent("Example","printAll","PressedPrint"));
        }
        {addFlow(buttons,printAll);}
        Object[] tLabels={"id","name","age","height","weight"};
        DefaultTableModel tModel=new DefaultTableModel(new Object[][]{},tLabels);
        JTable table = new JTable(tModel);
        {addCenter(screen1,new JScrollPane(table));}
        {event.registerEvent("Example.Display","tableAdd",
          (k,id,msg)->SwingUtilities.invokeLater(
            ()->tModel.addRow(msg.split(","))));
        }
        {event.registerEvent("Example.Display","tableClear",
          (k,id,msg)->SwingUtilities.invokeLater(
            ()->tModel.setRowCount(0)));
        }
      }
    );
  }
}
]]>

(4/5) Putting all together

Finally, a «» puts this all together

>model )//event loop
  )
]]>

If we wanted to add functionalities to initialize and to clear the database, we could do as follow:

(5/5) Summary

42 metaprogramming allows for complex applications to be written in compact and secure ways: in this application we used «», «», «» and «». Those are all normal 42 libraries that 42 programmers could write themselves, and indeed studying the implementation of those libraries is currently the best way to become a Magrathean.

In particular, «» allows us to take queries written in another language (for now, just SQL and IQL, but the concept is expandable) and converts them into a simple 42 well typed API that can be used to build programs in an compact and elegant way. Concepts like the «» can be used to control what part of an application is allowed to do important operations, adding a great deal of security.

Deploy 42

In the context of 42 and AdamsTowel, there are three things that can be deployed: Executable programs, Towels and Modules.

(1/5)Deploy Towels

A towel is about the most massively useful thing a programmer can have. A towel has immense psychological value, and you should always know where your towel is. All the classes that we have used up to now without defining them, are defined in AdamsTowel. They are all normal classes/libraries.
You can code without a towel, but this means starting from first principles, which could be quite unpleasant; especially since the only primitive things that 42 offers are Library literals (code as first class entities), the constant «», and the types «», «» and «».

Towels are libraries providing standard functionalities and types, such as number, boolean, string and various kinds of decorators and system errors.

However, we do not expect all 42 programs to reuse the same exact towel. For hygienic reasons, in real life everyone tends to use their own towel. For similar reasons, any sizeable 42 program will use its own towel.

We expect different programs to use massively different libraries for what in other languages is the standard library. That is, there is no such thing as 'the 42 standard library'.

Using multiple Towels

Towels shines when multiple towels are used at the same time.

Staining Towels

If you are writing a sizeable program, or many similar programs, it make sense to enrich a towel with some pre loaded libraries and basic classes.

A Stained Towel is a towel that looks like another but it is enriched by adding more things, either at the bottom. In our example, «» is just a stained variation of «».

(2/5)Module deployment

If you start writing in 42, you will soon feel the need to factorize your project into libraries that can be independently tested, deployed and loaded. We call those library Modules. Very successful modules are used by multiple independent projects and developers; they are what is often called a third party library. However, most modules exists just as development tools in order to keep the complexity of big projects under control.

In 42 it is easy to code with multiple modules, and modules can be much smaller than usual third party libraries and frameworks in other languages.

In 42 it is possible to employ a programming model where every developer (or every pair of developers in a pair programming style) is the only one responsible of one (or more) modules and their maintenance process, while the group leader gives specifications and tests to be met by the various module developers and will glue all the code together.

Modules can be deployed in a way similar to towel deployment; «» is used to load libraries, but it also contains all the knowledge to deploy them.
The following example code deploys a Module using «»:

The deployed library can be imported as usual. For example the main «» allows us to see the content of «».

All the deployed code is closed code. Towels are closed because they contain all the code to implement strings, numbers and so on. Modules are also closed. They have abstract classes/methods for each of the original towel concepts (before staining), and they can be rebound to a multitude of towels. In particular all stained versions of the same towel are compatible. Every needed nested library that was not present in the original towel, will be made private. On the other side, all the classes in the original towel will be made abstract by «» and will be rebound to the current towel by «».

Thus, in our example, «», «», «» and «» would become a private implementation detail of the exposed library.

(3/5)Deploy programs

We can run our applications inside 42, but we can also deploy them as Jars, so that they can be run as a Java application.
In 42 libraries can be directly manipulated, and one possible manipulation is to convert them in another format, like an executable jar or a native program and then save the result somewhere, such as on the website where the users can download it.
For example, we could rework the code of the former chapter as follows:

>model )
    )
  }
//..
Tast = DeployGit.jar(ToJar()
  on=Url"github.com/Bob/Modules42/MyApplication.jar"
  writer=GW.#$of(token=Secret.#$of(),message=S".."))
]]>

When 42 is used to deploy an application as a Jar, you can see the whole 42 execution as a comprehensive compilation framework, encompassing all the tools and phases that could possibly be needed into a single cohesive abstraction. Such jar can be run with the following command «»

In this example we reuse AdamsTowel both outside «» and inside of it. The two towels do not need to be the same. The outermost just has to support the deployment process «», while the inner one is needed to make «» a closed library: only libraries that do not refer to external classes can be deployed.

A 42 project testing and deploying

A common way to use 42 is to have a folder with the name of your project, containing a folder «» with all the actual code, and then various files providing testing and deploying functionalities, as in the following example:

(4/5)Towel embroidery: Define and deploy our own towel

Towel embroidery it is like adding your initials to your towel.

While we can simply add to the end by staining, embroidery is much more powerful.

The most common embroidery tool is «». Together with late casts, we can add methods to any existing class as shown below:

Num]:{@AbstractTowel{
    "en.wikipedia.org/wiki/International_System_of_Units"}}
  Load$={
    class method Introspection.Nested.List _baseDeps()
    class method Introspection.Nested.List baseDeps() = this._baseDeps().withAlso(\[
      Info(Unit);
      Info(SI);
      ])      
    }
  }
Secret = {...}
GW = Load:{reuse [L42.is/GitWriter]}
LoadDeploy = Load:{reuse [L42.is/Deploy]}
DeployGit = LoadDeploy.with(writer=GW)
DeployRicherTowel = DeployGit.towel(
  Organize:RawCode
    ['Load.baseDeps()->'Load._baseDeps()]
    [hide='Load._baseDeps()]
  on=Url"github.com/Bob/Modules42/SITowel.L42"
  writer=GW.#$of(token=Secret.#$of(),message=S".."))
]]>

By using semantic URIs as ontological nodes, we can create a basis for other libraries when trying to infer the meaning of our added types. In the example above we used wikipedia links to relevant concepts. This may not be the best solution, devising a good solution for this problem would require very intense research in the area of Ontological mapping.

«» can be used now to deploy and load libraries wrote in «», and libraries deployed and loaded in this way will share a unique definition for certain units of measure. Note that libraries originally developed for «» can still be loaded normally since «» is structurally a superset of «».

(5/5)Deployment: programs, libraries and towels; summary

• 42 is a metaprogramming tool. It is natural to use 42 either as a language (to run a program) or as a compiler (to deploy programs, libraries and towels).
• Indeed we expect all sizeable 42 projects to use 42 as a compiler, to produce some reusable artefacts.
• The distinction between towels (that do not need «») and modules is introduced not by 42, but by «»; radically different towels may provide different meaning for the concepts of deploying and loading libraries/towels.
• Application developers can freely stain and embroider towels; in this way they can adapt «» to serve them better. However, library developers need to carefully consider the effect of embroidery.

• Contact Us |
• Mailing list |