Al: Opinion on Syntax of a procedure

[waldo1001]

The current syntax for a simple function is this

local procedure TestMessage2();
begin
    message('Published event Event is working!')                
end;

Why is there a semicolon after the procedure. this feels really bad while coding.
also, I'd rather have no "begin" and "end". lots of statements work with { }. something like this is makes more sense to me:

local procedure TestMessage2()
{
    message('Published event Event is working!')                
}

... just my opinion

[TheDenSter]

I agree, the semicolon is confusing there, and {} makes more sense than begin-end, especially with lower case vs upper case

[Gallimathias]

This is my opinion too, and I had already made it as a issue and got a short answer from StanislawStempin Issue 48. If, however, more of the opinion are, MS should also think more about it

[ghost]

I also agree the semicolon is confusing. However, my opinion is the current syntax is a bit inconsistent between begin/end and {/}.

Why not replacing begin/end for usual AL blocks?
if condition then { doSomething() }

... just my opinion :)

[luxferresum]

Another way could be to replace the ; with an : which would make more sense:

local procedure TestMessage2():
begin
    message('Published event Event is working!')                
end;

Also I want to mention that the ; is not consistent with classic C/AL where ; is a statement seperator.

[Gallimathias]

So we're getting begin and end must go. I'm just doing a workaround to find the way to fix this without MS.

And the damn semicolon I will surely somehow get away.

local procedure TestMessage2()
{
  message('Published event Event is working!');                
}

What annoy me synonymous still are the semicolons as a separator for parameters. You can not just take commas like the rest of the world. No, we need semicolons for unfathomable reasons. Please use the semicolon as other languages. Under Stay tuned it out with the .NET guys.

[ajkauffmann]

From several trainings about AL and VS Code I got the same response from people:

• Remove the semicolon after the function
• Use curly brackets instead of begin...end (at least for procedure)
• Use comma as separator for parameters, field properties, etc.

Feels far more natural, I have made so many times mistakes here, typing a comma where the language want a semicolon.

[waldo1001]

I have the same feedback from people in my trainings..

[StanislawStempin]

In July Update the semicolon after method/trigger has been made optional.

[Gallimathias]

This is a damn good news. I will ensure that in our rules the semicolon is banned on the spot. I love the decision now :D. Let's tackle the next issue.

[Gallimathias]

@StanislawStempin
Ok sorry again for the double issue #645.
I'm trying to explain my point of view on the subject of brackets without the I love C# argument :D.

Point one is the consequence in AL itself. Currently, four symbols are used to declare blocks: BEGIN END {}. However, in my opinion, the rule does not clearly define when which symbol is valid.
We see that layouts, classes, areas, groups, fields, actions using parentheses have a break in the syntax if the methods use begin end at once. This is especially confusing for beginners. Because what's the rule:"Anything but methods uses {}?" Why do you use two different symbols? Why wasn't one of the two variants chosen?

The second point is a psychological one. Symbols always work better than text because our human brain is designed for it. A word consists of several symbols. at begin of four b, e, g, i, n. All four symbols have to be processed individually by the brain and then recognized as a context. If the result is in a foreign language, we translate it unintentionally. Certainly all processes in the subconscious mind, but that's why people always find symbols more pleasant than texts.

Then there is the fact that a single symbol is not only recognized faster, but we also automatically associate a meaning with it. In the case of parentheses, we know that they are bracketed. This works even better when people are through school and massively tormented by mathematics ;). In addition, the parentheses have a deeper effect on the recognition of parentheses, and I am now saying that most of the popular and widely used languages use parentheses as block syntax.

In addition, the begin and end are highlighted with the same color as other expressions. Since the words are wider than a parenthesis, for example, this seems to us to be more massiv. With a lot of code there are no breaks and interruptions for the eye, which makes the code look messy and messy because we have the feeling of a massive text block. It's strenuous reading.

The third point is a completely practical forklift. A bracket is much easier to identify and search for. Since special characters, especially parentheses, are not allowed in identifiers, their meaning is always unique. A begin end, on the other hand, could also be the part of a word. OnBeginReading, OnValidatingEnds etc.....
And it should be easier for you in the transcompiler to recognize the parentheses instead of an begin and end.

I would also like to mention that we will do a lot with web in the future. This means that JSON and JavaScript become an important part of the NAV every day or are already an important part of it. However, brackets are also used there. A more frequent change is easier for me if certain things like blocks are identical to each other and I don't have to remember any exceptions in expressions.

````csharp
trigger OnAction();
var
test : Text;
begin
if test.Contains('Hello world') then
begin
if true then begin
end;
end else begin
end;
end;

trigger OnAction();
var
test : Text;
{
if test.Contains('Hello world') then
{
if true then {
};
else if true {
};
};
};
````

Ok, next big point are the variable declarations. I don't think that due to the use of parentheses it is possible to declare variables like in C#.

Personally, I'm a little conflicted. As a developer I say "I want to declare and initialize where I think it is right" but from the point of view of clean code I think it is very good if you say variable must be declared at the beginning of a class or method.

But what I've always wondered. If AL is not designed to handle the full power of development, but also consultants should be able to customize the application, I wonder why there are data types at all. It would be much more sensible to use a quasi DuckTyping under the aspect of simplicity. So the Transcompiler recognizes which data type to use based on the assignment. Why should a consultant have to deal with the paradigm of typing? Well, I know that would be hard work remodeling.

I personally don't mind this fact at the moment.But I wanted to say it once.

The last point is the commas in parameter declarations. Ok, on the one hand, yes, I'm used to other people talking about using a normal comma. And I understand the separation by semicolon in such a way that it is said that they are actually declarations of local variables. But if you consider that a semicolon starts a new statement, it is wrong because the parameters belong to the signature of the method.

Furthermore, it seems to me to be logical with the parameters identical with the call.

Finally, perhaps why I have these wishes. Of course I love C#, but I also have to switch back and forth between many languages and it's just nicer if certain things are simply consistent. And yes, AL will be new, so it has to be measured against existing languages, and I still have a long working life (at least 50 years or more) ahead of me, which means that I may have to work very long with today's syntax decisions.

With everything I bring in I would like to say that I find really cool what you do. :)

[lvanvugt]

I know there has been a discussion when conceiving AL regarding the use of begin end in the code parts. If I recall right it was decided not to change that to { } (curly brackets), to not make the differences with C/AL to big. The curly brackets would solely be used for bordering the various other section (objects, fields, actions, etc.).
I must admit I was in favor of that. Now working with VSCode for some time, I find it somewhat confusing to have both in the same object. And with me various attendees to my workshops. Especially those (and that's what, among others, the modern development experience is aiming at) who do come from environments like Visual Studio. Not in the least the youngster our world is needing.

So my request is also to get rid of the begin .. end construct, in favor of the curly brackets {}

[kine]

My point of view on the {} vs Begin/end:
I understand that C/AL was based on Pascal syntax. Thus the var declaration, ; at the end of command etc. Now it is time to decide - stick on this or create AL as a own, consistent, language? I think the decision was done by using { } in the TXT format of objects in C/Side already. The TXT format is not Pascal syntax and now, AL is trying to stick on the TXT format of the objects (slightly changing it, but I think the AL is more TXT format of C/AL object than C/AL itself). Thus we already left the Pascal syntax.

For me it is same like why = is used to assign value to property, but := to assign value to variable. Why this duplicity? It means, we have TWO assignments operators, and one operator have two meanings based on context (= as compare and as assignment).

Focusing on keeping the change of syntax at minimum is short time decision. It is just because conversion from old system to new one. This is one-time job. Replacing begin/end with { } is simple job. Using it for next X years is much more important. And thus the consistency in the language syntax for me is much more important than consistency with "legacy" system.

[kine]

Just want to add one example of the "result" of being inconsistent:

           SubPageLink=CmdGuid=FIELD("Command ID");

???
If you who this to someone, he will think about it long time, what does it mean.

Try this:

           SubPageLink := CmdGuid=FIELD("Command ID");

I think it is more clear... and consistent...

[Gallimathias]

To the bracket thing:

Is there a discussion status, what is the situation / opinion? @atoader @StanislawStempin Or in moment you can't say anything and you wait for more opinions from the Community ?

[rdebath]

This issue is completely the wrong way round. I agree that the current situation is a mess; Professor Wirth will be disgusted by what's been done to his language (Though he's seen it before, with some other, now dead, "languages").

The C/AL language should have been extended to into the MS/AL language using the ALGOL / Pascal / Modula2 / Oberon-2 style not the C / C++ / Java / C# style. The programmer who did the extension obviously didn't get the idea that the Navision text files are property list files (like XML) with embedded (pascal-ish) code, not a single language. Microsoft has previously shown this themselves with the XML based object exports that they created in NAV version 6.

As for going forward: Personally, I am quite happy using languages of either C or Pascal form but the mixed up mess is confusing and cannot survive in the long term. Creating a new C like language seems pointless not least because it completely discards the history of the C/AL language and the "easy to learn" advantages of the Pascal heritage.

So really, IMO, the only way forward is to cherry-pick the Modula-2 and Oberon-2 syntax, replacing the C like syntax, for what's needed to bring C/AL up to date. Though, the syntax of the Oberon-2 language is so simple you may end up pulling it all in.

NB: The semicolon stays, it's separating the procedures and it's automatically inserted (by tprocedure) anyway.

[Gallimathias]

@rdebath I completely disagree.

First of all we at least agree that you either drive one style or the other style. (By the way, C/AL was developed by Michael Nielsen who was only oriented to Pascal, the first interpreter was written in c++, I think, but can also be mistaken).

Question. Why should the language AL be based on ALGOL / Pascal / Modula2 or Oberon-2? Just because C/AL walked this way? Already in the past we have become closer and closer to the C family in C/AL. We are not talking about the C/AL text files, they are dead.

The fact is that young developers are needed to serve the ERP market in the future as well. Pascal / ALGOL / Modula2 or Oberon-2 are not considered the most popular languages in the world ^^. I personally find the style of these languages terrible and terrible to look at. But that's personal taste.

Another fact is, by the way, C/Al and AL are converted to C#. This makes it much easier or more obvious to lean to the C syntax instead of turning away.

And it gets complicated at last. We want a simple language but at the same time technical expectations and challenges are increasing. Both will never be completely reconciled.

Honestly, if we wanted to have it easy to learn then one way would be Type or Javascript. (Why should anyone care about data types too) If we want performance and force we have to use C# and Co.

The semicolon after the signature, and it is only about this, is completely unnecessary because firstly it describes the separation between two statements (but the body of the method belongs to the signature, in my eyes) and secondly the body is seperatet with bracket (Begin / End or { }) is separated from the signature.

Conclusion: At least we agree that you should go one way or the other, but not mix different styles.

[rdebath]

TLDR: Nope, stick with pascal (with an outside bet on Python), though embedding C# would be nice.

@Gallimathias

I don't know about the "first interpreter" but yes, the "development environment" as it's now called is written in C++. Though, several C# bits have been bolted on, you can recognise them easily, they're the slow bits. (Except, probably, the font change. I've no idea what they broke when they changed the font)

The strength of NAV's programming has never been that the core language includes "powerful" concepts. In fact it's the exact opposite, the language is easy enough to read by someone who has only had minimal contact with professional programming. This is music to SMEs as it sounds like they can do changes to the code in-house and, sometimes, yes they can. (Though the Prince of Darkness will growl at them if they don't follow the versioning rules)

The fact that the C/AL language has been successful in Nav since 1990 is most definitely a strong reason to keep close to the language style.

OTOH, the C derived chain of languages have a set of strange "patterns" that you know very well, the use of curly brackets to denote block structure seems to be the first one that throws people. If you go on to look at languages like Haskell you have even more ways of making the language more expressive and powerful. (That _you_ may not know of).

BTW: C/AL text files were never "alive" IMO, they have always been a tool for bulk changes to the code. Renumbering objects, merging different development streams and so forth. Pushing them into a VCS was never reliable even if it is incredibly useful.

WRT the translation, you should look at the C# code that's generated by Nav. The problem isn't converting the language from pascal-like to C-like, for a modern source to source translator that is almost trivial (Unless you're after bug for bug compatibility of course). The major problem is an environment feature; the fact that you can change the C/AL code that the system is running _while it's running_. This is in complete opposition to the assumptions built into the normal DotNET environment and requires some ugly code that, apparently, cannot be encapsulated (hidden) in C#. Anyway, many, many languages are converted into C this doesn't say anything about any of those languages, it's more about C being a "machine code like" language or a preferred target language.

The reconciliation between the simplicity and complexity of language was settled many years ago in Navision in the same way it's always settled. Navision gained the ability to call "Automation objects" and so could link with the best language for any given esoteric problem. Either directly or through C the "universal machine code". DotNET Interop isn't quite as good, but it's good enough and like automation or direct linking it is almost zero cost.

No, javascript isn't the "easy to learn" language, Python is the current language in that slot. Used by school children and scientists everywhere. You will notice that the syntax and grammar of Python is kinda like pascal without begin-end; at least it's closer to that than any C-ish language. Javascript is in use only because it's the ONLY language available in web browsers. This does mean that many people have to learn it, but it doesn't make it "easy". There have been several attempts to "get rid of it", but as it is really a "nice enough" language they've all been basically failures; though the recent "web asm" stuff looks promising as it's a method of allowing _any_ language.

As for types, "primitive types" are not a difficult concept, but in general it's unnecessary to formalise them because the lay concept of "numbers" vs "text" is usually sufficient until full types are needed.

I do not agree that C/AL has been moved away from the pascal family of languages. If you're thinking of (sort of) object oriented features; well that's the variations in and around Oberon and Oberon-2. This recent MS/AL mess might count, though, it still looks more like dumping the C/AL text file syntax features in to me.

Actually, these answers to your points have raised another thought with me. For Microsoft specifically, if they want to move to a C like language it would be stupid to use anything but C#. The major problem is they have blocked that completely from running on BC (in the cloud) because they can't trust the sandboxing. This is in addition to the problem of changing the currently running code "on the fly" I mentioned earlier which would appear to block complete conversion to C# everywhere.

But for "On-prem" there is an even nicer solution (than Interop) to the simple vs complex issue, which has been used for many other languages. These languages leverage the fact that they're compiled into another language and allow the programmer to include fragments or functions written in that language directly in the source (in this case embedding C# functions in C/AL). It actually goes all the way back to embedding assembler in C code! It's almost possible already, as you can compile and run C# code with System.CodeDom.Compiler and System.Reflection. But it's usually a bit much to compile the code every time you want to run it.

This would have the nice advantage that any code transition could occur gradually, without requiring the entire "ecosystem" to flick over in an instant. Especially if I'm wrong about the encapsulation of the boilerplate for on the fly object replacement of Nav objects written directly in C#. I don't think such a transition would be a good idea, of course, because it will look like it's trying to exclude SME "in-house" programmers from adding their code (irrespective of the sandbox issue).

And finally. That isn't what the semicolon is for. The semicolon is required in the language so that it's possible for the compiler to generate good error messages. The idea is to give the language sufficient redundancy that not only are typos detectable but that you can get a 90% probable resolution for most of the simple errors. Obviously, if your IDE generates big chunks of boilerplate code (eg: You create functions by populating IDE list forms) this becomes less important.

PS: Using whitespace as grammar ... I bet that throws people too.

[Gallimathias]

Well, the development environment currently has more C# than native code. If I know it right now, only the FinLink is natively the ROTAccess the ndbcs and on the server still the navlic nativ. No guarantee for completeness ^^. Actually the finsql is only used to display the Visual Studio text editor.

I often hear that with the simplicity aspect and that may well be true. but on the one hand I see (subjectively) fewer and fewer customers do it themselves or they have hired real developers. I also see that the technical requirements and topics are constantly increasing. As said, in my eyes it can be easier or / but also more powerful. Both directions are possible.

What does it mean that C/AL in Nav has been successful since 1990? The language has never had competition since 1990 or am I misinformed ^^?

Haskell and Pascal are for me more languages of academic nature. Haskell is powerful for mathematical problems. To my knowledge, the languages are mainly to be found there in their pure form.

Personally, I don't find the "strange" patterns strange. I find the use of symbols and signs much more pleasant and understandable than text. I once wrote a text about it in an issue. I often find syntax that rely on terms overloaded and it looks like a lot. In addition to the psychological and practical advantages of symbols, it is ultimately taste. (Just like JSON vs. XML)

Nice that we agree again on the C/AL files.

The functionality that "C/AL" code can be changed at runtime has little to do with the generated code. The text file on the server is a newer one so it will be re-downloaded and compiled with other required files to a new assembly. The code that is generated is ugly because of the encapsulation, debugging functionality and conversions. If one exhausts its possibilities one can by the way very well optimize at this place. (Should you need performance).

Well, Com is dead. Working via the com service costs more time than if you integrate a dll directly. When comparing the speed with the dotnet "data type", please add whether client or server side. (Server side causes network communication). C is not "universal machine code" by the way but is translated into machine code when compiling, but you know that as C developer ^^.

I don't think the simplest language can be said across the board. I like python but it doesn't occupy a slot alone. Both languages JS and python have advantages and disadvantages for beginners. I don't like JS itself, but it's easy.

Well Phyton was also strongly influenced by C languages. I mean more than Pascal was talking about. At this point I don't want to start analytically comparing the syntaxes what pascal and what c is. (Ok phyton was developed as a replacement for ABC. Because van Rossum wanted to do better.)

Since I work a lot with students and other beginners to teach them development / programming I have to disagree with you. In my experience, the subject of types is unfortunately difficult for most people to understand. The easiest way is as you say. Numbers and texts.

I don't know, but I also don't believe that Microsoft orientates itself to Oberon-2 during development.

For me, the simple fact is that code units and consorts behave like objects. This is no wonder because a code unit is a class inherited from NavCodeunit. When I instantiate and discard a nav object an object of a class is created and discarded. This is the case with everything in C/AL. Why, because at the end of the day C# code is generated.

compromise. Make AL as a simple language and allow the right developers to work with the right target language.

What you're talking about is the topic of inlining. A great feature (which I miss in C#. how cool would it be to inline IL). You don't have to compile all the time. There are solutions. Besides, in the current process, inlining don't make the cabbage fat any more.

Sorry, but no a semicolon actually separates instructions. May be the "newer" languages do it differently (own language, own rules). But the fact is that the semicolon was originally used in assembler to separate instructions. This is also the reason why many new languages do without the semicolon because such a separation is no longer necessary. That's what I learned and that's how it can be read everywhere ^^ (I did some research before this answer to be really sure) At university you learn that a semicolon is actually the beginning of a statement and not the end :D.

[rdebath]

This is much too long...

That is not the visual studio text editor; it's significantly worse and more buggy, also the "useoldeditor" option reselects an editor that is almost identical to the normal C/AL text editor. But finsql.exe's main purpose at the moment appears to be to handle the FOB file and database object table BLOB format (which is very similar) and convert it into something the C# generator can reliably generate code from.

The internal complexity level of accounting and business management is not changing. Many of the external interfaces are gaining pointless complexity, but for a few the complexity is real. Within Nav Microsoft are doing a reasonable job of controlling the complexity, they have scattered some code out with the data, but it appears to have mostly been justified. Nevertheless, in some of the very new code you do run into over abstraction (creating complexity where none really exists; email reports anyone!).

The current event-requests are a good example of this control, rather than guessing and so adding events where nobody will ever need them they are actually only adding events (complexity) that will be used.

I would guess one of the reasons we're seeing a reduction in Customer C/AL is tools like Jet reports which move this "code" outside of Nav and Page web services which demo as an easy route to interface to Nav. After that the "you could/should write code inside Nav" is a hard sell.

Of course there are competitors, the major thorn has always been Axapta. (Oh look it's a C-ish -- perhaps Objective-C)

For Haskell you're probably right, in fact most functional languages seem to be academic, (The seem to be seen as more difficult) but it's a very influential language feeding features into many of the the big names. OTOH, IME Pascal is almost never used in it's "pure" form, so it didn't benefit much from the network effect of Github and it's predecessors. Though it too is influential, they have, for example, both fed into C#.

You seem to feel that words aren't "symbols" in some respect. Both words and "funny" symbols are actually symbols. In programming languages there is a range from COBOL at one end where (in the original) everything is like English prose to APL at the other where _nothing_ is. Neither of these is a good option in the real world, but commercial programming has always tended to the more wordy end IME. I'd guess because symbol characters are just punctuation in English and generally don't add meaning.

Sigh, yes C is a "universal machine code". It abstracts a few things that are easy to mechanically convert into individual machine code instructions (ie: expressions, stack allocation) but the rest is directly matched with machine instructions. Historically, it's the final result of the increasing complexity of the macro assemblers of the '60s colliding with the very simple BCPL language. Probably one of the major "tells" for this is the "string" type; why doesn't C have a primitive string? Because machine code doesn't (and every possible implementation is wrong ...sometimes).

You're thinking of javascript in web browsers. The javascript always downloaded as source unless the browser can prove it doesn't need to. Likewise with "compiling" the javascript (JIT), it actually uses data types only known at runtime. This is a lot more complex than traditional compilation and a lot more costly.

Compiling of C/AL as a language is basically simple. DotNET has debugging baked into the compilers and libraries, the types are basically identical, perhaps you'd need something special to deal with int overflows (probably not), but everything in C/AL has a direct analogue in C#. Except for the dynamic loading.

The DotNET csc compiler compiles _and links_ the code to an EXE or DLL, the blocks of code and jump tables you get (after the msil to native conversion) are designed to be linked once, as the program starts, into a anonymous block of machine code. Some implementations of DLLs even go back and patch the original jump/call instructions so that calling DLL code has zero cost increase over direct linking. Remember the program we're talking about here is the service tier, it should never stop (well, every month is probably forced).

With C/AL it is expected that you can load an updated object (or extension) into the database and the currently running service tier will use it, right now. That is not a DLL that's loaded once and forever.

Re: COM, Agreed DotNET's interface to COM is very slow, but that's not relevant for V7+ because the overhead of the RPC to the client. Note, it client side DLLs and controls that have the network overhead, your C/AL code runs on the service tier. The RTC Nav client works _a lot_ like a home-brew web browser.

Of course Python isn't the only easy language, but I think the only thing javascript has is the hiding of types. Oh, and I don't think we disagree about types, in that once you go past "number" vs. "string" you're getting into the rabbit hole of (for example) why "real number" and "floating point" and "integer" are different and why 0.1 + 0.2 is not always 0.3.

I strongly believe the person or people who designed MS/AL had never heard of Oberon-2 :grin:

The (minor) object orientation features of C/AL predate Microsoft if you grab a copy of Navision V3.60 codeunits are still a reference type and tables are still not a reference type. You get the same instance of a codeunit if you pass a codeunit around without the REF but for tables you need a "REF". NB: There's also a bug in the reference counting (all classic versions) where if you clear the last reference to a codeunit from inside the codeunit the client will crash.

The word "inlining" has been used for a lot of (vaguely related) things. The implementation I'm thinking of here would probably be the ability to include private functions written an C# in the same class that the holds the translation of the C/AL code. As Microsoft have realised, with control-addins, storing the C# DLLs in the database has advantages and this would have the same ones. Though it may be that all that's actually needed is the ability to install server side DLLs (as DLLs, C# or other DotNETs) in the control-addin table. The ability to include full Nav objects written in other languages would obviously be very nice though. (This is all "onprem" of course, because Microsoft don't trust C# can be sandboxed)

And finally. There are two grammatical ways that the semicolon is used. Either as a statement separator or as a terminator. In the C-ish languages it's usually a terminator, in Pascal it's a separator. But in the (very old) C based language awk it's a separator, eg: you don't need a ; (or a newline) before a } in fact most of the time you don't need semicolons at all, because it uses newlines as a conditional separator. But, because Pascal uses := as the assignment _statement_ it almost doesn't need semicolons either; without them normal code isn't LALR, but it is still unambiguous. Adding the semicolon gives redundancy that makes good error messages easier (and makes it LALR).

New languages, like awk do without the semicolon because they use newlines and/or keywords.
Putting the comma at the start of the line just means you hate that format, try yaml :grin:

PS: Json vs XML, they both have their advantages! One is simple, easy and concise. The other has a 500 page specification you can hit people with.

[JavierFuentes]

Hi everybody, after read all the above suggestions, I think all this about AL format to Improve code readability:
(I make a numbered list so that people can individually comment on each of the suggestions)

1. Automatic formatter should place { and begin in the same line where block starts, not in a new line (or at least it should be configured)... the example below, would have 10 more spacing lines, near 40% more lines, with those unnecessary line breaks.
2. { } should be used only for structural file blocks like layout{ } or area(...) { }, not for language blocks like IF-THEN-ELSE or REPEAT-UNTIL... Our actual code in codeunits and procedures should be kept reusable with a simple _Copy&Paste_ action.
3. Variable declaration zones are structural zones too, so, following the previous suggestion, we could have this type of syntax solving some AL folding issues in VSCode...

actions {
  area(processing) {
    action(ActionName) {

      trigger OnAction() {
        var {
          // Local variables declarations
        }
        code {
          // Our OnValidate code
          if ( condition1 ) then begin
            // ...
          end else if ( condition2 ) then begin
            // ...
          end else begin
            // ...
          end;
        } //#code
      } //#trigger_OnAction

    } //#action_ActionName
  } //#area_processing
} //#actions
...

var {
  // Global variables declarations
}

... note the use of var { } and code { } blocks... of course, all these syntax should be supported by automatic formatter.

1. Automatic format should apply the same Case format like Intellisense in all commands.
   In Variables it should apply the same Case format like in its declarations.
2. We should use comma , as separator for parameters, field properties, etc.
3. We should use := to assign value to properties, variables, etc and use = to compare values

SubPageLink := CmdGuid=Field("Command ID");

Finally, I would like to say that I love CAL and the new AL language and I hope that Microsoft do the best for keeping simplicity and consistency and make it more powerful taking ideas from modern languages like Typescript and Kotlin.