Recent changes to LES

LES modified by David Piepgrass

David Piepgrass — Thu, 14 Aug 2014 20:38:28 -0000

--- v14
+++ v15
@@ -1,4 +1,4 @@
-I originally introduced LES, LLLPG and Loyc trees with a [CodeProject article](http://www.codeproject.com/Articles/606610/LLLPG-2cplusLoycplustrees-2cplusandplusLES-2cpluso). No one seemed interested at the time, but I still have big hopes.
+**THE PROJECT HAS MOVED TO [GitHub](github.com/qwertie/Loyc) with web sites at [loyc.net](http://loyc.net) and [core.loyc.net](http://core.loyc.net).** The SF Wiki will no longer be updated.

 LES is simply a textual representation of [Loyc trees], nothing more. In other words, it's an AST interchange format (AST = Abstract Syntax Tree), and a way of representing syntax independently of semantics. In comparison with the syntax trees inside most compilers, Loyc trees are designed to have an almost LISP-like simplicity. Meanwhile, the LES language is designed to resemble popular modern languages like C, Rust, and Python, while remaining fairly simple (in terms of parser size) and concise.

LES modified by David Piepgrass

David Piepgrass — Tue, 17 Jun 2014 22:46:36 -0000

--- v13
+++ v14
@@ -606,7 +606,7 @@

 If backslash and forward slash are not recognized as part of an escape sequence, they are left alone (e.g. `'''\Q/'''` is the same string as `"\\Q/"`).

-Triple-quoted strings do not support unicode escape sequences. Please use the character itself, and note that the recommended encoding for LES files is UTF-8 with or without a "BOM".
+Triple-quoted strings do not support unicode escape sequences. Please use the character itself, and note that the recommended encoding for LES files is UTF-8 with or without a "[BOM](http://en.wikipedia.org/wiki/Byte_order_mark)".

 ## Generics ##

LES modified by David Piepgrass

David Piepgrass — Tue, 17 Jun 2014 22:37:12 -0000

--- v12
+++ v13
@@ -606,6 +606,8 @@

 If backslash and forward slash are not recognized as part of an escape sequence, they are left alone (e.g. `'''\Q/'''` is the same string as `"\\Q/"`).

+Triple-quoted strings do not support unicode escape sequences. Please use the character itself, and note that the recommended encoding for LES files is UTF-8 with or without a "BOM".
+
 ## Generics ##

 LES supports a special `!` operator for expressing things that have "generic" or "template" arguments. The LES expressions

LES modified by David Piepgrass

David Piepgrass — Tue, 17 Jun 2014 22:34:17 -0000

--- v11
+++ v12
@@ -629,7 +629,7 @@
     x
     x

-LES cannot support the  notation because it is highly ambiguous; trust me, it would be impossible to tell the difference between angle brackets and the greater/less than operators in LES. The "exclamation mark" notation is taken from [D](http://dlang.org).
+LES cannot support the `` notation because it is highly ambiguous; trust me, it would be impossible to tell the difference between angle brackets and the greater/less than operators in LES. The "exclamation mark" notation is taken from [D](http://dlang.org).

 ## Using LES in .NET ##

LES modified by David Piepgrass

David Piepgrass — Tue, 17 Jun 2014 22:33:08 -0000

--- v10
+++ v11
@@ -594,7 +594,7 @@
     .  };
     };

-I decided that I wanted all the string types to support any string whatsoever. In particular, I wanted it to be possible to store `"**\r\"\"\""` as a triple-quoted string. Therefore, I decided to support escape sequences inside triple-quoted strings, but the sequences have a different format (with an additional forward slash). The following escape sequences are supported:
+I decided that I wanted all the string types to support any string whatsoever. In particular, I wanted it to be possible to store `"'''\r\"\"\""` as a triple-quoted string. Therefore, I decided to support escape sequences inside triple-quoted strings, but the sequences have a different format (with an additional forward slash). The following escape sequences are supported:

 * `\n/` for a newline (character 10)
 * `\r/` for a newline (character 13)
@@ -604,7 +604,7 @@
 * `\0/` for a null character (character 0)
 * `\t/` for a tab character (character 9)

-If backslash and forward slash are not recognized as part of an escape sequence, they are left alone (e.g. `**\Q/**` is the same string as `"**\\Q/**"`).
+If backslash and forward slash are not recognized as part of an escape sequence, they are left alone (e.g. `'''\Q/'''` is the same string as `"\\Q/"`).

 ## Generics ##

LES modified by David Piepgrass

David Piepgrass — Tue, 17 Jun 2014 22:30:17 -0000

--- v9
+++ v10
@@ -542,7 +542,7 @@
 * Booleans: @true and @false
 * Void: @void
 * Characters, e.g. 'a' or '\n'. Characters are Unicode, but under .NET, characters are limited to 16 bits. Hopefully proper 21-bit Unicode characters can be supported somehow, someday.
-* Strings, e.g. "é" or "ĉheap". LES does not support C# `@"verbatim"` strings; instead, it supports triple-quoted strings using either `**three single quotes**` or `"""three double quotes"""`.
+* Strings, e.g. "é" or "ĉheap". LES does not support C# `@"verbatim"` strings; instead, it supports triple-quoted strings using either `'''three single quotes'''` or `"""three double quotes"""`.
 * Symbols, e.g. @@foo or @@`BAM!` (see below)
 * null, denoted `@null`, which (in the context of .NET) has no data type.

LES modified by David Piepgrass

David Piepgrass — Tue, 17 Jun 2014 22:28:44 -0000

--- v8
+++ v9
@@ -76,7 +76,7 @@

 The prefix "@" introduces an identifier that contains special characters, and then the backquotes are added for identifiers with ''very'' special characters. So in ``@`#{}` ``, the actual identifier name is `#{}`, which is the built-in "function" that represents a braced block. Similarly `@#>` and `@#`. represent the identifiers "#>" and "#.". Please note that '#' is not considered a special character, nor is it an operator; in LES, # is just an identifier character, just as an underscore _ is an identifier character in the C family. However, # is special by convention, because it is used to mark identifiers that represent keywords and operators in a programming language.

-The @ sign is not part of the identifier. After the @ sign, the tokenizer expects a sequence of letters, numbers, operator characters, underscores, and # signs. For example, `@you+me=win!` is a single token representing the identifier `you+me=win!`. Note that when I talk about "operator characters", it does not include the characters ``, ; { } ( ) [ ] ` " #`` (but `#` counts as an identifier character; it's allowed after @, it's just not treated as punctuation). If you need extra-special characters such as these, enclose the identifier in backquotes after the @ sign. Escape sequences are allowed within the backquotes, including ``\` `` for the backquote itself. For example, ``@`{\n}` `` represents `{\n}` where `\n` represents a linefeed character.
+The @ sign is not part of the identifier. After the @ sign, the tokenizer expects a sequence of letters, numbers, operator characters, underscores, and # signs. For example, `@you+me=win!` is a single token representing the identifier `you+me=win!`. Note that when I talk about "operator characters", it does not include the characters ``, ; { } ( ) [ ] ` " #`` (but `#` counts as an identifier character; it's allowed after @, it's just not treated as punctuation). If you need extra-special characters such as these, enclose the identifier in backquotes after the @ sign. Escape sequences are allowed within the backquotes, including ``\` `` for the backquote itself. For example, ``@`{\n}` `` represents `{\n}` where `\n` represents a newline character.

 Identifiers can contain apostrophes _without_ using @, e.g. `That'sJustGreat` (there are several languages that use apostrophes in identifiers). However, an apostrophe cannot be the first character or it will be interpreted as a character literal (e.g. `'A'` is the character 'A').

LES modified by David Piepgrass

David Piepgrass — Tue, 17 Jun 2014 22:27:59 -0000

--- v7
+++ v8
@@ -76,9 +76,9 @@

 The prefix "@" introduces an identifier that contains special characters, and then the backquotes are added for identifiers with ''very'' special characters. So in ``@`#{}` ``, the actual identifier name is `#{}`, which is the built-in "function" that represents a braced block. Similarly `@#>` and `@#`. represent the identifiers "#>" and "#.". Please note that '#' is not considered a special character, nor is it an operator; in LES, # is just an identifier character, just as an underscore _ is an identifier character in the C family. However, # is special by convention, because it is used to mark identifiers that represent keywords and operators in a programming language.

-The @ sign is not part of the identifier. After the @ sign, the tokenizer expects a sequence of letters, numbers, operator characters, underscores, and # signs. For example, `@you+me=win!` is a single token representing the identifier `you+me=win!`. Note that when I talk about "operator characters", it does not include the characters `, ; { } ( ) [ ] ` " #` (but `#` counts as an identifier character; it's allowed after @, it's just not treated as punctuation). If you need extra-special characters such as these, enclose the identifier in backquotes after the @ sign. Escape sequences are allowed within the backquotes, including `\`` for the backquote itself. For example, `@`{\n}`` represents `{\n}` where `\n` represents a linefeed character.
-
-Identifiers can contain apostrophes ''without'' using @, e.g. `That'sJustGreat` (there are several languages that use apostrophes in identifiers). However, an apostrophe cannot be the first character or it will be interpreted as a character literal (e.g. `'A'` is the character 'A').
+The @ sign is not part of the identifier. After the @ sign, the tokenizer expects a sequence of letters, numbers, operator characters, underscores, and # signs. For example, `@you+me=win!` is a single token representing the identifier `you+me=win!`. Note that when I talk about "operator characters", it does not include the characters ``, ; { } ( ) [ ] ` " #`` (but `#` counts as an identifier character; it's allowed after @, it's just not treated as punctuation). If you need extra-special characters such as these, enclose the identifier in backquotes after the @ sign. Escape sequences are allowed within the backquotes, including ``\` `` for the backquote itself. For example, ``@`{\n}` `` represents `{\n}` where `\n` represents a linefeed character.
+
+Identifiers can contain apostrophes _without_ using @, e.g. `That'sJustGreat` (there are several languages that use apostrophes in identifiers). However, an apostrophe cannot be the first character or it will be interpreted as a character literal (e.g. `'A'` is the character 'A').

 ## Comments & stuff ##

@@ -258,7 +258,7 @@
     }
     whistle(c);

-And therefore the parser will produce the same structure, even though the programmer probably intended the boundaries between the statements to be ''in different places'' in these two blocks of code.
+And therefore the parser will produce the same structure, even though the programmer probably intended the boundaries between the statements to be _in different places_ in these two blocks of code.

 I think it's pretty dangerous that you could forget a semicolon and accidentally change the meaning of the program. If the parser ignores newlines, you could potentially forget a semicolon in some [LEL] code and the program would still compile without any warnings or errors, causing the program to do something unexpected when it runs. For example (assuming the parser is not in "Python mode") if you write

@@ -267,11 +267,11 @@

 If the parser ignores newlines, the interpretation would be `a = Foo(b, c = d)` according to the "superexpression" rules explained above. Oops!

-Note that this danger would be ''caused'' by the parser's ignorance of whitespace, combined with the fact that you can combine two expressions ''simply by putting them next to each other''.
+Note that this danger would be _caused_ by the parser's ignorance of whitespace, combined with the fact that you can combine two expressions _simply by putting them next to each other_.

 So I've decided to fix the problem by making the parser even more space-aware (note, the following plan is **not yet implemented**; newlines are currently ignored).

-Specifically, the parser will produce a warning if you continue a statement without giving some indication that you ''intended'' to continue the statement. Specifically, when a new expression starts on a new line, and it's not the first expression in the statement, it must either 
+Specifically, the parser will produce a warning if you continue a statement without giving some indication that you _intended_ to continue the statement. Specifically, when a new expression starts on a new line, and it's not the first expression in the statement, it must either 

 1. Be indented compared to the first expression, or
 2. Be prefixed with a colon (:)
@@ -311,7 +311,7 @@
       y = 0;
     }

-There's no warning on "else" because it is not located at the beginning of the line, or in other words, because "}" is not the beginning of an expression. Similarly, in the second case "y" is not the beginning of an expression, so there is no warning about it and no need to use ":". In fact, you are not ''allowed'' to use a colon either; for the purpose of statement continuation, a colon can only appear at the end of an expression and the beginning of a line.
+There's no warning on "else" because it is not located at the beginning of the line, or in other words, because "}" is not the beginning of an expression. Similarly, in the second case "y" is not the beginning of an expression, so there is no warning about it and no need to use ":". In fact, you are not _allowed_ to use a colon either; for the purpose of statement continuation, a colon can only appear at the end of an expression and the beginning of a line.

 ## Precedence rules ##

@@ -425,7 +425,7 @@
     else:
       return

-Since "else" is not a keyword, there's no way for the parser to know that "else" is supposed to be part of the "if" statement. So this ''must'' be interpreted as two ''separate'' statements. To solve this problem, a colon can be used at the beginning of a line to indicate that the same statement continues:
+Since "else" is not a keyword, there's no way for the parser to know that "else" is supposed to be part of the "if" statement. So this _must_ be interpreted as two _separate_ statements. To solve this problem, a colon can be used at the beginning of a line to indicate that the same statement continues:

     if c:
       Proceed()
@@ -490,7 +490,7 @@
     def subfunction(y):
     ...

-I don't think we can expect those ignorant programmers to stop mutilating our code, but I have a solution in mind for this problem: dots and spaces. I envision a code editor that supports not just spaces and tabs for indentation, but also ''dots with spaces''.
+I don't think we can expect those ignorant programmers to stop mutilating our code, but I have a solution in mind for this problem: dots and spaces. I envision a code editor that supports not just spaces and tabs for indentation, but also _dots with spaces_.

 If a line of LES code begins with a period followed by a space or a tab, the LES lexer recognizes that as equivalent to a tab. Multiple tabs and/or spaces after the dot are treated the same as a single space. So the above code can now be written as follows:

@@ -507,8 +507,8 @@

 For this feature to work,

-* the line ''must'' begin with a dot. If the line begins with a space or a tab, all dots on the line will be treated literally (as the dot operator).
-* if a dot is ''not'' followed by a space or a tab, it is also treated literally.
+* the line _must_ begin with a dot. If the line begins with a space or a tab, all dots on the line will be treated literally (as the dot operator).
+* if a dot is _not_ followed by a space or a tab, it is also treated literally.
 * after the first non-space character on a line, all dots are treated as dots even if they are followed by spaces.

 For example, the interpretation of the following lines:
@@ -548,7 +548,7 @@

 There is no literal notation for arrays or tuples (note that a tuple such as (1, "two") is not a "literal"; it is a Loyc tree that some programming languages may or may not interpret as a tuple.) More literal types will probably be added in the future (such as unlimited-size integers, 8-bit and 16-bit ints, byte array literals).

-A few languages, including Ruby and LISP, have a symbol data type; symbols are singleton strings, and they are implemented by the Symbol class in Loyc.Essentials. Symbols have a performance advantage over strings in many cases. The advantage of symbols is that you never have to compare the ''contents'' of two Symbols. Since each Symbol is unique, two Symbol references are equal if and only if they point to the same heap object. [Loyc.Essentials] allows derived classes of `Symbol` and "private" symbol pools, but LES supports only global symbols. Symbols are a [useful alternative to enums](http://www.codeproject.com/Articles/34753/Symbols-as-extensible-enums).
+A few languages, including Ruby and LISP, have a symbol data type; symbols are singleton strings, and they are implemented by the `Symbol` class in Loyc.Essentials. Symbols have a performance advantage over strings in many cases. The advantage of symbols is that you never have to compare the _contents_ of two Symbols. Since each `Symbol` is unique, two `Symbol` references are equal if and only if they point to the same heap object. [Loyc.Essentials] allows derived classes of `Symbol` and "private" symbol pools, but LES supports only global symbols. Symbols are a [useful alternative to enums](http://www.codeproject.com/Articles/34753/Symbols-as-extensible-enums).

 All three of the syntaxes for strings produce the same data type (System.String), and the two kinds of triple-quoted strings are otherwise identical. Double-quoted strings like `"this one"` must be entirely written on a single line, while triple-quoted strings can span an unlimited number of lines.

@@ -598,7 +598,7 @@

 * `\n/` for a newline (character 10)
 * `\r/` for a newline (character 13)
-* `\\/` for a ''single'' backslash (character 92)
+* `\\/` for a _single_ backslash (character 92)
 * `\"/` for a double quote (character 34)
 * `\'/` for a single quote (character 39)
 * `\0/` for a null character (character 0)

LES modified by David Piepgrass

David Piepgrass — Tue, 20 May 2014 15:48:44 -0000

--- v6
+++ v7
@@ -1,6 +1,6 @@
 I originally introduced LES, LLLPG and Loyc trees with a [CodeProject article](http://www.codeproject.com/Articles/606610/LLLPG-2cplusLoycplustrees-2cplusandplusLES-2cpluso). No one seemed interested at the time, but I still have big hopes.

-LES is simply a textual representation of [Loyc trees], nothing more. In other words, it's an AST interchange format (AST = Abstract Syntax Tree). In comparison with the syntax trees inside most compilers, Loyc trees are designed to have an almost LISP-like simplicity. Meanwhile, the LES language is designed to resemble popular modern languages like C, Rust, and Python, while remaining fairly simple (in terms of parser size) and concise.
+LES is simply a textual representation of [Loyc trees], nothing more. In other words, it's an AST interchange format (AST = Abstract Syntax Tree), and a way of representing syntax independently of semantics. In comparison with the syntax trees inside most compilers, Loyc trees are designed to have an almost LISP-like simplicity. Meanwhile, the LES language is designed to resemble popular modern languages like C, Rust, and Python, while remaining fairly simple (in terms of parser size) and concise.

 [TOC]

LES modified by David Piepgrass

David Piepgrass — Tue, 06 May 2014 17:52:39 -0000

--- v5
+++ v6
@@ -1,6 +1,8 @@
 I originally introduced LES, LLLPG and Loyc trees with a [CodeProject article](http://www.codeproject.com/Articles/606610/LLLPG-2cplusLoycplustrees-2cplusandplusLES-2cpluso). No one seemed interested at the time, but I still have big hopes.

 LES is simply a textual representation of [Loyc trees], nothing more. In other words, it's an AST interchange format (AST = Abstract Syntax Tree). In comparison with the syntax trees inside most compilers, Loyc trees are designed to have an almost LISP-like simplicity. Meanwhile, the LES language is designed to resemble popular modern languages like C, Rust, and Python, while remaining fairly simple (in terms of parser size) and concise.
+
+[TOC]

 ## Design goals ##