Home Demos Forum Research Guide
Viewing topic in forum 'announcements'
back to topic list

Dana v159
Dana v159 is out now and includes a major reworking of the compiler. This impacts on some of the ways in which syntax works and we discuss each change in detail here.

Semicolons

The Dana syntax has evolved significantly since it was first designed, generally becoming simpler than earlier versions. As a result of this we no longer require line-end markers as part of syntax. In addition to this, the Dana compiler has itself evolved significantly over the past couple of years, being extended and redesigned several times, making it increasingly difficult to maintain.

Together these two factors led us to undertake a larger redesign of the compiler for v159, cleaning up many legacy elements that had become confusing, and reworking some of the fundamental parts of the syntax parsing subsystem. This has led to a far cleaner design of the compiler's core subsystems but has also meant some changes at the Dana source level.

The most obvious one of these is that semicolons aren't required any more. Code that contains semicolons is still valid, but the compiler simply removes them before proceeding with further stages of syntax processing. In the rest of this article we detail some of the more subtle changes at the Dana source level.

Loops with empty loop bodies

In previous versions of Dana, a loop could be declared as:


for (int i = 0; i < 10; i++);
 


Note the semicolon at the end of the loop header. Now that semicolons are removed prior to syntax parsing, the above statement is ambiguous (i.e. it's not possible to determine whether or not to take the statement following the loop header as the loop's body).

An empty loop must now therefore be declared as:


for (int i = 0; i < 10; i++){}
 


The v159 compiler will provide an appropriate warning when detecting cases of this.

Syntactic strictness

Previous versions of the Dana compiler actually had two separate syntax parsers - one for "global" information like component headers and data type definitions, and one for "local" logic like function bodies. In v159 we've simplified this to have a single unified syntax parser. What this means, however, is that keywords used at "global" scope are no longer usable for "local" scopes. This is because the unified syntax parser will assume that, for example, the use of the keyword data anywhere in your code will be followed by a type definition.

This is probably the most annoying of the changes arising from our new syntax model, requiring most code modification. In future we advise that you do not use any keywords as variable or function names (even if it's currently OK to do so).

Array constants

Another factor of unifying our syntax parsing system is that array constants are declared and initialised just like regular arrays, using the "new" notation. This provides a more consistent feel to Dana source code and, in future, will permit more complex expressions in global scopes such as constant declarations.

The v159 compiler will provide errors and warnings covering all of the above changes when compiling v158-based code, but we wanted to explain the rationale behind these changes in more detail to give you an insight into our design process and future plans.

It's likely that there will be some growing pains as we get more used to the new compiler and its corresponding syntax model, and we realise that some of this will be frustrating as old code needs to be migrated, but we hope you see the improvements that we do.

Happy coding :-)
by barry on 2015-12-18 09:56:58 (0 replies)

© Francis Research Ltd. 2018