{"id":413285,"date":"2024-06-29T23:01:58","date_gmt":"2024-06-29T23:01:58","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=413285"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=413285","title":{"rendered":"Lexical Analysis in 11l<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
This article discusses the lexical analyzer, which is an integral part of any compiler.<\/p>\n

The task of the lexical analyzer is to split the source code of the program into tokens.<\/p>\n

So for example the code <\/p>\n

print(1 + 2) <\/code><\/pre>\n
will be tokenized as
  print<\/code>, (<\/code>, 1<\/code>, +<\/code>, 2<\/code> and )<\/code>
  <\/a>  <\/p>\n
Significance of indentation<\/h3>\n
  Historically, compilers for most programming languages strip away<\/abbr> all whitespace characters such as space, tab, and newline.
  What does this mean? It means the compiler sees the source code like this:  <\/p>\n
if (foo)    if (bar)       m1(); else    m2(); <\/code><\/pre>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u2193
  if<\/code>, (<\/code>, foo<\/code>, )<\/code>, if<\/code>, (<\/code>, bar<\/code>, )<\/code>, m1<\/code>, (<\/code>, )<\/code>, ;<\/code>, else<\/code>, m2<\/code>, (<\/code>, )<\/code>, ;<\/code><\/p>\n
  This code is taken from the Nemerle programming language documentation<\/a>. It contains a so-called dangling else bug: when looking at this code, you might think that the \u201celse\u201d branch refers to the condition \u201cfoo\u201d, whereas in programming languages with C-like syntax (including C++, C#, Java and others) the \u201celse\u201d branch refers to the condition \u201cbar\u201d.
  As a solution to this problem, the developers of the Nemerle language introduced a rule that an \u201cif\u201d statement must always have an \u201celse\u201d branch, and if the \u201celse\u201d branch is not required, then the \u201cwhen\u201d statement should be used instead of \u201cif\u201d.
  In many new programming languages, such as Swift, Rust, and Go, the use of curly braces is mandatory even if the body of the \u201cif\u201d [<\/font>or other control statement<\/font>]<\/font> is only one line. When curly braces are used, the problem disappears:  <\/p>\n
if (foo) {    if (bar) {       m1();    } } else {    m2(); } <\/code><\/pre>\n
  Some coding standards, for example those from Oracle<\/a>, from Stanford University<\/a> or Carnegie Mellon University<\/a>, require the bodies of \u201cif\u201d and \u201celse\u201d statements to be enclosed in curly braces, to avoid the possibility of this bug:  <\/p>\n
int login;  if (invalid_login())     login = 0; else     printf(\"Login is valid\\n\");     login = 1; <\/code><\/pre>\n
Here the line login = 1;<\/code> will be executed in any case, no matter what value is returned by the invalid_login<\/code> function.<\/p>\n
  But in both of the above cases, the problem is not at all that \u201cif\u201d [<\/font>allowing an \u201celse\u201d branch to be either absent or present<\/font>]<\/font> expresses the wrong logic, or even that the curly braces were forgotten: it is\u2026 the discrepancy between the way this code is perceived by the human programmer and by the compiler. A human being perceives block boundaries visually, using indentation as a guide; but the compiler makes use of symbols [<\/font>which a human hardly notices<\/font>]<\/font>. What is more, the compiler [<\/font>for C\/C++, C#, Java, Nemerle, etc.<\/font>]<\/font> treats all whitespace characters in the same way, and, thus, completely ignores the indentation. This is where the root of the problem lies: the compiler and the human see code like this differently<\/b>.<\/p>\n
  And to solve this problem, the compiler must somehow take indentation into account [<\/font>so that the code examples given earlier either work as the programmer expects, or give an error at the compilation stage (or at least a warning<\/a>)<\/font>]<\/font>.<\/p>\n
  For this reason, it was decided to provide the new programming language 11l with a lexical analyzer that takes indentation into account.<\/p>\n
  Now let’s look at the implementation process. A brief description of the algorithm for parsing indentation is given in the Python programming language documentation<\/a>. In short, the algorithm works like this: at the beginning of each line, the indentation level is compared to the value on the top of a special stack. If it is larger, then it is pushed onto the stack and the lexer generates an INDENT token. If it is smaller, then all values exceeding the current line indentation level are removed from the stack and a DEDENT token is generated for each value removed. Further, at the end of the source file, a DEDENT is generated for each value remaining on the stack.<\/p>\n
  In addition to the fact that the lexical analyzer of the 11l language takes indentation into account, like the lexical analyzer of the Python language, the new language adds support for curly braces, which makes it possible to write code on one line or without indentation:  <\/p>\n
\n\n\n
With indentation:  <\/p>\n
fn sum(a, b)    return a + b <\/code><\/pre>\n
On one line:  <\/p>\n
fn sum(a, b) {return a + b} <\/code><\/pre>\n
Without indentation:  <\/p>\n
fn sum(a, b) { return a + b } <\/code><\/pre>\n<\/td>\n<\/tr>\n<\/table>\n<\/div>\n
In addition, code can be written using both indention and curly braces.  <\/p>\n
                         Here is how it works (in brief)<\/b>                         <\/p>\n
The indentation levels stack (indentation_levels<\/code>) in 11l, in contrast to the lexical analyzer of the Python language, stores not just the indentation level but also a flag that is set to true whenever a new block of code is formed by the symbol {<\/code>, rather than by increasing the indentation level. The indentation level is then set to -1<\/code>.
  The {<\/code> character is immediately followed by a new, arbitrary {i.e. lowering the indentation level is allowed} indentation level {its level is set instead of -1<\/code>}, which remains in effect up to the matching }<\/code> character.
  Here is a link<\/a> to the corresponding source code.  <\/div>\n<\/p><\/div>\n
This solution is the most versatile, and will suit both those who prefer using curly braces and those who prefer indentation.
  All popular indentation styles<\/a> are supported:  <\/p>\n
\n\n\n\n\n\n
Allman<\/th>\nK&R<\/th>\nGNU<\/th>\n<\/tr>\n
\n
if x == y {     something()     somethingelse() } <\/code><\/pre>\n<\/td>\n
\n
if x == y {     something()     somethingelse() } <\/code><\/pre>\n<\/td>\n
\n
if x == y   {     something ()     somethingelse ()   } <\/code><\/pre>\n<\/td>\n<\/tr>\n
Whitesmiths<\/th>\nRatliff<\/th>\n<\/tr>\n
\n
if x == y     {     something()     somethingelse()     } <\/code><\/pre>\n<\/td>\n
\n
if x == y {     something()     somethingelse()     } <\/code><\/pre>\n<\/td>\n<\/tr>\n<\/table>\n<\/div>\n
  <\/p>\n
Automatic line joining<\/h3>\n
  In addition to splitting the source code of a program into tokens, the lexical analyzer is also charged with determining statement boundaries. [<\/font>Although in some programming languages (like JavaScript or Kotlin<\/a>) assistance from the parser is required.<\/font>]<\/font><\/p>\n
  Traditionally, a semicolon is used in C-like programming languages (C++, C#, Java, D) as a statement terminator. However, most new programming languages (e.g. Swift, Go, Kotlin, CoffeeScript, Nim, Julia, Crystal, and others) allow the semicolon to be omitted, by using the newline character as the end of a statement. [<\/font>I am not the only one to have noticed this trend.<\/a><\/font>]<\/font><\/p>\n
  But the question then arises: when do two consecutive lines of source code represent parts of the single statement, and when are they two different statements? And different programming languages solve this problem in different ways.<\/p>\n
  Python uses<\/a> one simple rule for implicit line joining: if a line contains an unclosed parenthesis, square bracket, or curly brace, then it concatenates with following lines until all matching parentheses\/brackets\/braces are closed.<\/p>\n
  Go uses<\/a> the rule: if the newline comes after a token that could end a statement, then the statement is ended. However, this rule imposes significant restrictions on coding style.
  For example, in an \u201cif\u201d statement, the curly brace that opens a block must be on the same line \u2014 moving it down to the next line is not allowed. The \u201celse\u201d statement must<\/a> also appear on the same line as the closing curly brace.  <\/p>\n
\n\n\n\n\n
Right<\/th>\nWrong<\/th>\n<\/tr>\n
\n
if i < f() {     g() }  <\/code><\/pre>\n<\/td>\n
\n
if i < f() {     g() } <\/code><\/pre>\n<\/td>\n<\/tr>\n
\n
if x < 0 {     return -1 } else {     return 1 }  <\/code><\/pre>\n<\/td>\n
\n
if x < 0 {     return -1 } else {     return 1 } <\/code><\/pre>\n<\/td>\n<\/tr>\n<\/table>\n<\/div>\n
JavaScript uses a rather complex system of rules<\/a> to carry out automatic semicolon insertion.  <\/p>\n
a = 1 b = 2 <\/code><\/pre>\n
In this example, a semicolon will be automatically inserted at the end of the first line, since a = 1 b = 2<\/code> is not a valid statement<\/a>.
  However, in some cases a semicolon is not inserted, leading the code to function incorrectly.<\/p>\n
  For example, the following two lines of JavaScript code will be mistakenly joined into one.  <\/p>\n
a = b + c [d, e] = [e, d] <\/code><\/pre>\n
  And in this example, on the contrary, a semicolon will be erroneously inserted immediately after return<\/code>.  <\/p>\n
return   \"something\"; <\/code><\/pre>\n
That is, instead of returning a string \"something\"<\/code>, the value undefined<\/code> will be returned.<\/p>\n
  In most programming languages that allow semicolons to be omitted (for example, Python, Go, Kotlin, Ruby, Julia, and Nim), this code will not work:  <\/p>\n
r = 1   + 2 <\/code><\/pre>\n
Moreover, in Python, Go and Nim an error message will be displayed, while in Kotlin, Ruby and Julia the value of the variable r<\/code> will be set to 1<\/code>.<\/p>\n
  To solve this problem, 11l uses the following 3 simple rules that are easily understood by both the programmer and the lexical analyzer:  <\/p>\n
    \n
  1. If a line ends with a binary operator, then it is joined with the next line.<\/li>\n
  2. If a line begins with a binary operator, then it is joined with the previous line.
     \n
                             (It is necessary to check that it is not a unary operator!)<\/b>                         <\/p>\n
    \n
    a = b ++i \/\/ the plus character at the beginning of this line should not be mistaken for the binary operator `+` <\/code><\/pre>\n<\/div><\/div>\n<\/li>\n
  3. And also, just as in Python, a newline within expressions in parentheses or square brackets is ignored.<\/li>\n<\/ol>\n
      <\/p>\n
    \/\/ 1. if condition1 & \/\/ this line will be joined with the next one,    condition2   \\\\ since it ends with the binary operator `&`     some_func()  \/\/ 2. some_variable = 2               + 3 \/\/ this line will be joined with the previous one,                   \\\\ since it starts with the binary operator `+`  \/\/ 3. some_func(    \/\/ since this line includes an unclosed parenthesis, all    argument1, \\\\ subsequent lines will be joined until    argument2) \\\\ the parenthesis is closed <\/code><\/pre>\n
      <\/p>\n
    Semicolons<\/h3>\n
      While it is not necessary to use a semicolon to mark the end of statements in 11l, semicolons can be used to place multiple statements on one line:  <\/p>\n
    a = 1; b = 2; c = 3 <\/code><\/pre>\n
      But, for example, in Python it is not obvious what this line of code corresponds to:  <\/p>\n
    if b: print(1); print(2) <\/code><\/pre>\n
      <\/p>\n
    \n\n\n\n
    This code in Python:<\/td>\n\n
    if b:     print(1)     print(2) <\/code><\/pre>\n<\/td>\n<\/tr>\n
    Or this:<\/td>\n\n
    if b:     print(1) print(2) <\/code><\/pre>\n<\/td>\n<\/tr>\n<\/table>\n<\/div>\n
    \n\n\n\n
    This code in 11l:<\/td>\n\n
    if b {print(1); print(2)} <\/code><\/pre>\n<\/td>\n<\/tr>\n
    Or this:<\/td>\n\n
    if b {print(1)}; print(2) <\/code><\/pre>\n<\/td>\n<\/tr>\n<\/table>\n<\/div>\n
    Python’s behavior in this case is logical in principle, but not obvious.
      The behavior of 11l, by contrast, is both logical and obvious.<\/p>\n
      Furthermore, it is impossible to write a one-line function like this in Python:  <\/p>\n
    def f(x): if x: print(x) <\/code><\/pre>\n
    But in 11l, it is possible:  <\/p>\n
    fn f(x) {if x {print(x)}} <\/code><\/pre>\n
      <\/p>\n
    Always room for improvement<\/h3>\n
      In my anything but<\/sub> humble opinion, 11l implements the most advanced lexical analyzer of all currently existing programming languages. However, it can still be improved.<\/p>\n
      For example, the third automatic line joining rule could be dropped, to support code like this:  <\/p>\n
    set_timeout(             1.0,             fn ()                alert(\u2018!\u2019)             ,             0            ) <\/code><\/pre>\n
    In this case, the third rule must be replaced with the following two rules:  <\/p>\n