[PATCH olang v1 0/2] docs: variables specification

[PATCH olang v1 0/2] docs: variables specification

[Carlos Maniero]

This patchset specifies variables and constants. I would love to add
more information about how the labels could be generated for global
variables, but it depends on an agreement on the "[RFC] Namespaces in
OLANG".

Carlos Maniero (2):
  docs: spec: rename program to translation-unit
  docs: spec: add variables and constants specification

 docs/pages/language-specification.md | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

-- 
2.34.1

[PATCH olang v1 1/2] docs: spec: rename program to translation-unit

[Carlos Maniero]

We started to rename the program node in AST to translation-unit. This
commit also makes a few refactors on spec such as:

- Makes EOF a end-of-statement
- create global-statements section to accommodate upcoming global
  definitions.

Signed-off-by: Carlos Maniero <carlos@maniero.me>
---
 docs/pages/language-specification.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/docs/pages/language-specification.md b/docs/pages/language-specification.md
index 5769d95..4541ba8 100644
--- a/docs/pages/language-specification.md
+++ b/docs/pages/language-specification.md
@@ -22,7 +22,9 @@ language.
 
 ```
 (* Entry Point *)
-<program>             ::= <ows> <function-definition> <ows> <end-of-file>
+<translation-unit>    ::= <ows> (<global-statements> <end-of-statement>)*
+
+<global-statements>   ::= <function-definition>
 
 (* Functions *)
 <function-definition> ::= 'fn' <ws> <function-name> <ows>
@@ -35,7 +37,7 @@ language.
 (* Statements *)
 <block>               ::= '{' <ows> <statement> <ows> (<end-of-statement>
 <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
-<end-of-statement>    ::= ';' | <line-break>
+<end-of-statement>    ::= ';' | <line-break> | <end-of-file>
 <statement>           ::= <return-statement>
 <return-statement>    ::= 'return' <ws> <expression>
 
-- 
2.34.1

Re: [PATCH olang v1 1/2] docs: spec: rename program to translation-unit

[Johnny Richard]

On Wed, Mar 27, 2024 at 12:21:27AM -0300, Carlos Maniero wrote:
> We started to rename the program node in AST to translation-unit. This

Nitpick:  Perhaps we can highlight the problem and solution better?

    Today, the AST node "program" serves as the main entry point for the
    grammar, potentially leading to confusion as the program ultimately
    becomes the final ELF binary after linking all .o files. Therefore, we
    have collectively decided to replace it with "translation-unit," which
    more accurately conveys the concept of a singular unit being translated
    into a single binary. This adjustment enables us to assert that a
    translation-unit corresponds directly to the .ol source file on a
    one-to-one basis.

> commit also makes a few refactors on spec such as:
> 
> - Makes EOF a end-of-statement

This patch does the opposite.  Make a end-of-statement a EOF as well,
which I not agree.  See following comments...

> - create global-statements section to accommodate upcoming global
>   definitions.
> 
> Signed-off-by: Carlos Maniero <carlos@maniero.me>
> ---
>  docs/pages/language-specification.md | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/pages/language-specification.md b/docs/pages/language-specification.md
> index 5769d95..4541ba8 100644
> --- a/docs/pages/language-specification.md
> +++ b/docs/pages/language-specification.md
> @@ -22,7 +22,9 @@ language.
>  
>  ```
>  (* Entry Point *)
> -<program>             ::= <ows> <function-definition> <ows> <end-of-file>
> +<translation-unit>    ::= <ows> (<global-statements> <end-of-statement>)*

This change expect that every followed new statement has no optional
white space. According to your change the following expression is invalid:

    |fn add(): u32 {
    |  return 0;
    |}
    |
     ^~~ this is a line-break (syntax error according to your grammar)
    | fn main(): u32 {
     ^~~ this is a linear-space (syntax error according to your grammar)
    |  return 0;
    |}


suggestion: This change fixes the problem.

    <translation-unit>    ::= (<ows> <global-statements> <ows> (<end-of-statement> | <end-of-file>))*

> +
> +<global-statements>   ::= <function-definition>

This doesn't need to be plural if it has a single "statement".

>  
>  (* Functions *)
>  <function-definition> ::= 'fn' <ws> <function-name> <ows>
> @@ -35,7 +37,7 @@ language.
>  (* Statements *)
>  <block>               ::= '{' <ows> <statement> <ows> (<end-of-statement>
>  <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
> -<end-of-statement>    ::= ';' | <line-break>
> +<end-of-statement>    ::= ';' | <line-break> | <end-of-file>

Hmmm... this is not true, this means the every end-of-statement can be a
end-of-file.

Re: [PATCH olang v1 1/2] docs: spec: rename program to translation-unit

[Carlos Maniero]

> > commit also makes a few refactors on spec such as:
> > 
> > - Makes EOF a end-of-statement
>
> This patch does the opposite.  Make a end-of-statement a EOF as well,
> which I not agree.  See following comments...
>
...
>
> Hmmm... this is not true, this means the every end-of-statement can be a
> end-of-file.

I'll try a different approach and send a new patch, the challenge here
is that you should not be able to do that:

  fn a(): u32 {} fn b(): u32 {}
  fn a(): u32 {} var a: u32 fn b(): u32 {}

That's was the issue I was trying to address when I make EOF a EOS. To
allow multiple definitions that requires an new line in between.

[PATCH olang v1 2/2] docs: spec: add variables and constants specification

[Carlos Maniero]

This commit introduces the specification for variables and constants. A
valid program under this specification is as follows:

  var x: u32 = 1
  const y: u32 = 2
  x = 2

  fn main(): u32 {
    var x: u32 = 1; const y: u32 = 2
    return x
  }

Variables and Linkage:
----------------------

Variables can be defined globally or within a function. Variables
defined globally are added to the *.data* section. On the other hand,
variables defined within a function utilize the stack. Currently, the
specification does not provide a keyword for external linkage yet, hence
variables cannot be accessed outside their translation unit.

Constants and Linkage:
----------------------

Constants behave similarly to variables. Constants defined at the file
level are added to the *.rodata* section. Constants within functions are
subject to semantic checks. Attempting to bypass these checks to
reassign a global constant will result in a segmentation fault
(SEGFAULT) and will be accepted at the function level.

Example of bypassing semantic checks in C:

  int a = 1;
  const int b = 2;
  int *c = &a + 1;
  *c = 3;
  assert(b == 3); // its true

Static variables in function level
----------------------------------

In C, static variables can be defined within the scope of a function.
These variables are added to the `*.data*` segment and are only
accessible within the function where they are defined. This is a unique
behavior of C that some might find unusual.

However, olang does not support this feature. In olang, if you need a
variable that retains its value across function calls (like a static
variable in C), you must define it at the file level.

Signed-off-by: Carlos Maniero <carlos@maniero.me>
---
 docs/pages/language-specification.md | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/docs/pages/language-specification.md b/docs/pages/language-specification.md
index 4541ba8..708b679 100644
--- a/docs/pages/language-specification.md
+++ b/docs/pages/language-specification.md
@@ -24,7 +24,15 @@ language.
 (* Entry Point *)
 <translation-unit>    ::= <ows> (<global-statements> <end-of-statement>)*
 
-<global-statements>   ::= <function-definition>
+<global-statements>   ::= <function-definition> | <variable-definition> | <variable-reassign> | <const-definition>
+
+(* Variables *)
+<variable-definition> ::= 'var' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>?
+<const-definition>    ::= 'const' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>
+
+<variable-name>       ::= <identifier>
+<variable-assign>     ::= '=' <ows> <expression>
+<variable-reassign>   ::= <variable-name> <ows> <variable-assign> <end-of-statement>
 
 (* Functions *)
 <function-definition> ::= 'fn' <ws> <function-name> <ows>
@@ -38,11 +46,11 @@ language.
 <block>               ::= '{' <ows> <statement> <ows> (<end-of-statement>
 <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
 <end-of-statement>    ::= ';' | <line-break> | <end-of-file>
-<statement>           ::= <return-statement>
+<statement>           ::= <return-statement> | <variable-definition> | <variable-reassign> | <const-definition>
 <return-statement>    ::= 'return' <ws> <expression>
 
 (* Expressions *)
-<expression>          ::= <integer>
+<expression>          ::= <integer> | <identifier>
 
 (* Identifiers *)
 <type>                ::= 'u32'
-- 
2.34.1

[olang/patches/.build.yml] build failed

[builds.sr.ht]

olang/patches/.build.yml: FAILED in 35s

[docs: variables specification][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50474
[1]: mailto:carlos@maniero.me

✗ #1179573 FAILED olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1179573

Re: [PATCH olang v1 2/2] docs: spec: add variables and constants specification

[Johnny Richard]

On Wed, Mar 27, 2024 at 12:21:28AM -0300, Carlos Maniero wrote:
> This commit introduces the specification for variables and constants. A
> valid program under this specification is as follows:
> 
>   var x: u32 = 1

Since this patch adds support to assignments, lets also add support to
all assignment operators like "-=" "+=" "<<=" and so on.

>   const y: u32 = 2

This patch lacks support to the following valid assignment expression
(which I think adds flexibility to the language):

    var x: u32 = a = b = c = 1
    var y: u32
    y = a = b = c = 1

>   x = 2
> 
>   fn main(): u32 {
>     var x: u32 = 1; const y: u32 = 2
>     return x
>   }
> 
> Variables and Linkage:
> ----------------------
> 
> Variables can be defined globally or within a function. Variables
> defined globally are added to the *.data* section. On the other hand,
> variables defined within a function utilize the stack. Currently, the
> specification does not provide a keyword for external linkage yet, hence
> variables cannot be accessed outside their translation unit.
> 
> Constants and Linkage:
> ----------------------
> 
> Constants behave similarly to variables. Constants defined at the file
> level are added to the *.rodata* section. Constants within functions are
> subject to semantic checks. Attempting to bypass these checks to
> reassign a global constant will result in a segmentation fault
> (SEGFAULT) and will be accepted at the function level.
> 
> Example of bypassing semantic checks in C:
> 
>   int a = 1;
>   const int b = 2;
>   int *c = &a + 1;
>   *c = 3;
>   assert(b == 3); // its true
> 
> Static variables in function level
> ----------------------------------
> 
> In C, static variables can be defined within the scope of a function.
> These variables are added to the `*.data*` segment and are only
> accessible within the function where they are defined. This is a unique
> behavior of C that some might find unusual.
> 
> However, olang does not support this feature. In olang, if you need a
> variable that retains its value across function calls (like a static
> variable in C), you must define it at the file level.
> 
> Signed-off-by: Carlos Maniero <carlos@maniero.me>
> ---
>  docs/pages/language-specification.md | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/pages/language-specification.md b/docs/pages/language-specification.md
> index 4541ba8..708b679 100644
> --- a/docs/pages/language-specification.md
> +++ b/docs/pages/language-specification.md
> @@ -24,7 +24,15 @@ language.
>  (* Entry Point *)
>  <translation-unit>    ::= <ows> (<global-statements> <end-of-statement>)*
>  
> -<global-statements>   ::= <function-definition>
> +<global-statements>   ::= <function-definition> | <variable-definition> | <variable-reassign> | <const-definition>

nitpick: maybe _external-declaration_ sounds better since definitions are
not statements?

> +
> +(* Variables *)
> +<variable-definition> ::= 'var' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>?
> +<const-definition>    ::= 'const' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>

We don't need to define twice the variable-definition for "var" and
"const", let's combine both in a single rule.

> +<variable-name>       ::= <identifier>
> +<variable-assign>     ::= '=' <ows> <expression>
> +<variable-reassign>   ::= <variable-name> <ows> <variable-assign> <end-of-statement>
>  
>  (* Functions *)
>  <function-definition> ::= 'fn' <ws> <function-name> <ows>
> @@ -38,11 +46,11 @@ language.
>  <block>               ::= '{' <ows> <statement> <ows> (<end-of-statement>
>  <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
>  <end-of-statement>    ::= ';' | <line-break> | <end-of-file>
> -<statement>           ::= <return-statement>
> +<statement>           ::= <return-statement> | <variable-definition> | <variable-reassign> | <const-definition>
>  <return-statement>    ::= 'return' <ws> <expression>
>  
>  (* Expressions *)
> -<expression>          ::= <integer>
> +<expression>          ::= <integer> | <identifier>
>  
>  (* Identifiers *)
>  <type>                ::= 'u32'
> -- 
> 2.34.1
> 

I have done few adjustments according to my feedback (I also fix the
unnecessary line breaks on function and block).  Let me know what you
think about it.

---->8----
Subject: [PATCH olang] fixup! docs: spec: add variables and constants specification


diff --git a/docs/pages/language-specification.md b/docs/pages/language-specification.md
index 708b679..2650dd9 100644
--- a/docs/pages/language-specification.md
+++ b/docs/pages/language-specification.md
@@ -22,35 +22,45 @@ language.
 
 ```
 (* Entry Point *)
-<translation-unit>    ::= <ows> (<global-statements> <end-of-statement>)*
+<translation-unit>     ::= (<ows> <external-declaration> <ows> (<end-of-statement> | <end-of-file>))*
 
-<global-statements>   ::= <function-definition> | <variable-definition> | <variable-reassign> | <const-definition>
+<external-declaration> ::= <function-definition> 
+                         | <variable-definition>
+                         | <assign-expression>
 
 (* Variables *)
-<variable-definition> ::= 'var' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>?
-<const-definition>    ::= 'const' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>
-
-<variable-name>       ::= <identifier>
-<variable-assign>     ::= '=' <ows> <expression>
-<variable-reassign>   ::= <variable-name> <ows> <variable-assign> <end-of-statement>
+<variable-definition>  ::= <variable-qualifier> <ws> <variable-name> <ows> ':' <ows> <type> (<ows> <assign-operator> <ows> <expression>)?
+<variable-qualifier>   ::= 'var'
+                         | 'const'
+<variable-name>        ::= <identifier>
 
 (* Functions *)
-<function-definition> ::= 'fn' <ws> <function-name> <ows>
-<function-parameters> <ows> ':' <ows> <return-type> <ows> <function-body>
+<function-definition> ::= 'fn' <ws> <function-name> <ows> <function-parameters> <ows> ':' <ows> <return-type> <ows> <function-body>
 <function-name>       ::= <identifier>
 <function-parameters> ::= '(' <ows> ')'
 <return-type>         ::= <type>
 <function-body>       ::= <block>
 
 (* Statements *)
-<block>               ::= '{' <ows> <statement> <ows> (<end-of-statement>
-<ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
-<end-of-statement>    ::= ';' | <line-break> | <end-of-file>
-<statement>           ::= <return-statement> | <variable-definition> | <variable-reassign> | <const-definition>
+<block>               ::= '{' <ows> <statement> <ows> (<end-of-statement> <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
+<end-of-statement>    ::= ';' | <line-break>
+<statement>           ::= <return-statement> | <variable-definition> | <assign-expression>
 <return-statement>    ::= 'return' <ws> <expression>
 
 (* Expressions *)
-<expression>          ::= <integer> | <identifier>
+<expression>          ::= <integer> | <identifier> | <assign-expression>
+<assign-expression>   ::= <variable-name> <ows> <assign-operator> <ows> <expression>
+<assign-operator>     ::= '='
+                        | '*='
+                        | '/='
+                        | '%='
+                        | '+='
+                        | '-='
+                        | '<<='
+                        | '>>='
+                        | '&='
+                        | '^='
+                        | '|='
 
 (* Identifiers *)
 <type>                ::= 'u32'

Re: [PATCH olang v1 2/2] docs: spec: add variables and constants specification

[Carlos Maniero]

On Wed Mar 27, 2024 at 6:37 PM -03, Johnny Richard wrote:
> On Wed, Mar 27, 2024 at 12:21:28AM -0300, Carlos Maniero wrote:
> > This commit introduces the specification for variables and constants. A
> > valid program under this specification is as follows:
> > 
> >   var x: u32 = 1
>
> Since this patch adds support to assignments, lets also add support to
> all assignment operators like "-=" "+=" "<<=" and so on.
>
> >   const y: u32 = 2
>
> This patch lacks support to the following valid assignment expression
> (which I think adds flexibility to the language):
>
>     var x: u32 = a = b = c = 1
>     var y: u32
>     y = a = b = c = 1
>
> > -<global-statements>   ::= <function-definition>
> > +<global-statements>   ::= <function-definition> | <variable-definition> | <variable-reassign> | <const-definition>
>
> nitpick: maybe _external-declaration_ sounds better since definitions are
> not statements?

What do you think about *file-declarations* a file declaration? Does not
mean that it is external. At least while we try to define a file.

>
> > +
> > +(* Variables *)
> > +<variable-definition> ::= 'var' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>?
> > +<const-definition>    ::= 'const' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>
>
> We don't need to define twice the variable-definition for "var" and
> "const", let's combine both in a single rule.

I don't know if you noticed, but variables has an optional assignment
while const has required assignment.
>
> > +<variable-name>       ::= <identifier>
> > +<variable-assign>     ::= '=' <ows> <expression>
> > +<variable-reassign>   ::= <variable-name> <ows> <variable-assign> <end-of-statement>
> >  
> >  (* Functions *)
> >  <function-definition> ::= 'fn' <ws> <function-name> <ows>
> > @@ -38,11 +46,11 @@ language.
> >  <block>               ::= '{' <ows> <statement> <ows> (<end-of-statement>
> >  <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
> >  <end-of-statement>    ::= ';' | <line-break> | <end-of-file>
> > -<statement>           ::= <return-statement>
> > +<statement>           ::= <return-statement> | <variable-definition> | <variable-reassign> | <const-definition>
> >  <return-statement>    ::= 'return' <ws> <expression>
> >  
> >  (* Expressions *)
> > -<expression>          ::= <integer>
> > +<expression>          ::= <integer> | <identifier>
> >  
> >  (* Identifiers *)
> >  <type>                ::= 'u32'
> > -- 
> > 2.34.1
> > 
>
> I have done few adjustments according to my feedback (I also fix the
> unnecessary line breaks on function and block).  Let me know what you
> think about it.
>
> ---->8----
> Subject: [PATCH olang] fixup! docs: spec: add variables and constants specification
>
>
> diff --git a/docs/pages/language-specification.md b/docs/pages/language-specification.md
> index 708b679..2650dd9 100644
> --- a/docs/pages/language-specification.md
> +++ b/docs/pages/language-specification.md
> @@ -22,35 +22,45 @@ language.
>  
>  ```
>  (* Entry Point *)
> -<translation-unit>    ::= <ows> (<global-statements> <end-of-statement>)*
> +<translation-unit>     ::= (<ows> <external-declaration> <ows> (<end-of-statement> | <end-of-file>))*
Way more elegant! Thanks.
>  
> -<global-statements>   ::= <function-definition> | <variable-definition> | <variable-reassign> | <const-definition>
> +<external-declaration> ::= <function-definition> 
> +                         | <variable-definition>
> +                         | <assign-expression>
>  
>  (* Variables *)
> -<variable-definition> ::= 'var' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>?
> -<const-definition>    ::= 'const' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>
> -
> -<variable-name>       ::= <identifier>
> -<variable-assign>     ::= '=' <ows> <expression>
> -<variable-reassign>   ::= <variable-name> <ows> <variable-assign> <end-of-statement>
> +<variable-definition>  ::= <variable-qualifier> <ws> <variable-name> <ows> ':' <ows> <type> (<ows> <assign-operator> <ows> <expression>)?
This is invalid for const unless we want to allow unassigned constants.
It also can be interpreted as a semantic error, in that case I believe
the spec should not check for semantics.
> +<variable-qualifier>   ::= 'var'
> +                         | 'const'
> +<variable-name>        ::= <identifier>
>  
>  (* Functions *)
> -<function-definition> ::= 'fn' <ws> <function-name> <ows>
> -<function-parameters> <ows> ':' <ows> <return-type> <ows> <function-body>
> +<function-definition> ::= 'fn' <ws> <function-name> <ows> <function-parameters> <ows> ':' <ows> <return-type> <ows> <function-body>
>  <function-name>       ::= <identifier>
>  <function-parameters> ::= '(' <ows> ')'
>  <return-type>         ::= <type>
>  <function-body>       ::= <block>
>  
>  (* Statements *)
> -<block>               ::= '{' <ows> <statement> <ows> (<end-of-statement>
> -<ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
> -<end-of-statement>    ::= ';' | <line-break> | <end-of-file>
> -<statement>           ::= <return-statement> | <variable-definition> | <variable-reassign> | <const-definition>
> +<block>               ::= '{' <ows> <statement> <ows> (<end-of-statement> <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
> +<end-of-statement>    ::= ';' | <line-break>
> +<statement>           ::= <return-statement> | <variable-definition> | <assign-expression>
>  <return-statement>    ::= 'return' <ws> <expression>
>  
>  (* Expressions *)
> -<expression>          ::= <integer> | <identifier>
> +<expression>          ::= <integer> | <identifier> | <assign-expression>
> +<assign-expression>   ::= <variable-name> <ows> <assign-operator> <ows> <expression>
> +<assign-operator>     ::= '='
> +                        | '*='
> +                        | '/='
> +                        | '%='
> +                        | '+='
> +                        | '-='
> +                        | '<<='
> +                        | '>>='
> +                        | '&='
> +                        | '^='
> +                        | '|='
>  
>  (* Identifiers *)
>  <type>                ::= 'u32'

Re: [PATCH olang v1 2/2] docs: spec: add variables and constants specification

[Johnny Richard]

On Thu, Mar 28, 2024 at 11:11:38AM -0300, Carlos Maniero wrote:
> On Wed Mar 27, 2024 at 6:37 PM -03, Johnny Richard wrote:
> > On Wed, Mar 27, 2024 at 12:21:28AM -0300, Carlos Maniero wrote:
> > > This commit introduces the specification for variables and constants. A
> > > valid program under this specification is as follows:
> > > 
> > >   var x: u32 = 1
> >
> > Since this patch adds support to assignments, lets also add support to
> > all assignment operators like "-=" "+=" "<<=" and so on.
> >
> > >   const y: u32 = 2
> >
> > This patch lacks support to the following valid assignment expression
> > (which I think adds flexibility to the language):
> >
> >     var x: u32 = a = b = c = 1
> >     var y: u32
> >     y = a = b = c = 1
> >
> > > -<global-statements>   ::= <function-definition>
> > > +<global-statements>   ::= <function-definition> | <variable-definition> | <variable-reassign> | <const-definition>
> >
> > nitpick: maybe _external-declaration_ sounds better since definitions are
> > not statements?
> 
> What do you think about *file-declarations* a file declaration? Does not
> mean that it is external. At least while we try to define a file.

hmm.. It sounds weird mention file. Feels like you are going to declare
files... But I don't want to spend a lot of time on it.  It was a
nitpick... If you think *external-declaration* is not good enough we can
keep *global-statement* (no blocking here).

> > > +
> > > +(* Variables *)
> > > +<variable-definition> ::= 'var' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>?
> > > +<const-definition>    ::= 'const' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-assign>
> >
> > We don't need to define twice the variable-definition for "var" and
> > "const", let's combine both in a single rule.
> 
> I don't know if you noticed, but variables has an optional assignment
> while const has required assignment.

Sure, I noticed.  I took a look to how C solve this problem and seems
like it allows defining a const without assignment  (I don't know why...).

I would do the same to keep the gramma simple. And if we really want to
advice the developer about weird declaration, we could warning message
during semantics checking phase.

> > +<variable-definition>  ::= <variable-qualifier> <ws> <variable-name> <ows> ':' <ows> <type> (<ows> <assign-operator> <ows> <expression>)?
>
> This is invalid for const unless we want to allow unassigned constants.
> It also can be interpreted as a semantic error, in that case I believe
> the spec should not check for semantics.

Let's handle it during semantics analysis.

Re: [PATCH olang v1 2/2] docs: spec: add variables and constants specification

[Carlos Maniero]

> +<assign-operator>     ::= '='
> +                        | '*='
> +                        | '/='
> +                        | '%='
> +                        | '+='
> +                        | '-='
> +                        | '<<='
> +                        | '>>='
> +                        | '&='
> +                        | '^='
> +                        | '|='
I believe we may need two non-terminals, one for assignment which is
just the '=' and other for reassignments.

The statements *const x: u32 += 1* is valid in the language but it is
not valid, but I'm not sure if it also isn't a semantic issue that most
ignored for the simplicity of the spec. 

Anyway, since you already addressed most of the issues in the spec I
propose, few free to send a v2 or let me know what you think about the
points I raised so then I can proceed with a new version.

Re: [PATCH olang v1 2/2] docs: spec: add variables and constants specification

[Johnny Richard]

On Fri, Mar 29, 2024 at 10:14:56PM -0300, Carlos Maniero wrote:
> > +<assign-operator>     ::= '='
> > +                        | '*='
> > +                        | '/='
> > +                        | '%='
> > +                        | '+='
> > +                        | '-='
> > +                        | '<<='
> > +                        | '>>='
> > +                        | '&='
> > +                        | '^='
> > +                        | '|='
> I believe we may need two non-terminals, one for assignment which is
> just the '=' and other for reassignments.
> 
> The statements *const x: u32 += 1* is valid in the language but it is
> not valid, but I'm not sure if it also isn't a semantic issue that most
> ignored for the simplicity of the spec. 

Yeah, you are right. But I would love to catch this erro during syntax
analyses. This error looks like a grammatic problem.  What do you think?

> Anyway, since you already addressed most of the issues in the spec I
> propose, few free to send a v2 or let me know what you think about the
> points I raised so then I can proceed with a new version.

I can wait for other revision from you, no problem at all.  Only if you
really want me to do it.

[PATCH] fixup! docs: spec: add variables and constants specification

[ricardo_kagawa]

From: Ricardo Kagawa <ricardo_kagawa@disroot.org>

> subject to semantic checks. Attempting to bypass these checks to
> reassign a global constant will result in a segmentation fault
> (SEGFAULT) and will be accepted at the function level.

I would be careful with the wording here. Are you absolutely sure you
can enforce this rule in case of a bypass attempt? If not, use something
like "should" or "may" instead of "will".

In the current version of the specification, it would be impossible to
bypass the `const` check, and it would be possible to enforce it at
compile-time. But depending on what you are planning to add to the
language, it might become impossible to do so later.

> Since this patch adds support to assignments, lets also add support to
> all assignment operators like "-=" "+=" "<<=" and so on.

I disagree. Support for those assignment operators should only be added
when both assignments and operators are defined, and none of these
operators are defined yet.

> This patch lacks support to the following valid assignment expression
> (which I think adds flexibility to the language):
> 
>     var x: u32 = a = b = c = 1

Personally, I don't like this idiom, but I wouldn't stop you from adding
it. Johnny's patch actually already enables this, and also the
following (for clarity, of course the `if` statement does not exist yet,
but it is included here as an example of what might come in the future):

```
var x
if (x = next()) {
  return x
}
```

Which is something I don't like either, just as much.

> > > We don't need to define twice the variable-definition for "var" and
> > > "const", let's combine both in a single rule.
> > 
> > I don't know if you noticed, but variables has an optional assignment
> > while const has required assignment.
> 
> Sure, I noticed.  I took a look to how C solve this problem and seems
> like it allows defining a const without assignment  (I don't know why...).
> 
> I would do the same to keep the gramma simple. And if we really want to
> advice the developer about weird declaration, we could warning message
> during semantics checking phase.

I agree with Carlos, unless you have plans to allow constants to be
initialized later (or not even initialized), which I don't like.

I don't know what your plans for the future are, but in the case of the
C language, I guess they didn't have a choice but allow for
uninitialized constants. The compiler can validate the immutability of
the constant, _as long as it is strictly accessed through its binding_.

But the C language allows for pointer arithmetics and inline assembly,
which allows the program to access memory positions in other ways
besides references to the variable name. So the immutability of `const`
variables is not a hard guarantee, but more like an advice, in this
case.

The compiler simply cannot make that many assumptions on what pointers
point to, or where your assembly code writes things to. This is so bad
that in legacy operating systems, it was possible to override kernel
instructions, as long as you knew where they were in the physical
memory.

In modern operating systems, processes never have access to physical
memory addresses, but they still have full access to their own memory.
In other words, a pointer can still mutate constant variables, and even
literal values in instructions (or the instructions themselves, which
means macros are not immune to mutation either).

Other languages can make stronger assumptions about constant variables,
as they do not allow for direct memory manipulation.

So, in my opinion, the decision should hinge on the compiler's ability
to properly validate the constant's immutability, and whether or not
late initialization should be allowed (complicating semantic checks).

> I believe we may need two non-terminals, one for assignment which is
> just the '=' and other for reassignments.

I sort of agree here. But I guess the non-terminal names are bit
confusing. The `=` sign in `const` and `var` declarations is _not_ an
assignment operation, but declares an initializer. The semantics are
subtly different, but still different, so assignment operators should
not be allowed in variable/constant declarations.

---
Discussions:

- Are you planning to hoist declarations, or are declarations required
  to be placed before their use?
- Are you planning to include type inference for variable declarations?
  If so, the variable type in variable and constant declarations could
  be made optional.

-- >8 --

- Moved statements common to the translation unit and function bodies to
  their own non-terminal.
- Restored Carlos' definition of variable and constant definitions, as
  they are not quite the same, structurally and semantically.
  Personally, I'd rather constants to be initialized immediately, but
  you may have a different opinion on this.
- Moved some non-terminals from the "Statements" section to the
  "Functions" section, as there will be some statements that are
  function-body specific, some that are translation-unit specific, and
  some that are common to both.
- Renamed "assign" to "assignment", for better wording.
- Renamed <variable-assign> from Carlos' patch to
  <variable-initializer> (must not be used in <assignment-expression>).

Signed-off-by: Ricardo Kagawa <ricardo_kagawa@disroot.org>
---
 docs/pages/language-specification.md | 36 ++++++++++------------------
 1 file changed, 13 insertions(+), 23 deletions(-)

diff --git a/docs/pages/language-specification.md b/docs/pages/language-specification.md
index 2650dd9..b218462 100644
--- a/docs/pages/language-specification.md
+++ b/docs/pages/language-specification.md
@@ -24,15 +24,14 @@ language.
 (* Entry Point *)
 <translation-unit>     ::= (<ows> <external-declaration> <ows> (<end-of-statement> | <end-of-file>))*
 
-<external-declaration> ::= <function-definition> 
-                         | <variable-definition>
-                         | <assign-expression>
+(* Translation Unit *)
+<external-declaration>  ::= <common-statement> | <function-definition>
 
 (* Variables *)
-<variable-definition>  ::= <variable-qualifier> <ws> <variable-name> <ows> ':' <ows> <type> (<ows> <assign-operator> <ows> <expression>)?
-<variable-qualifier>   ::= 'var'
-                         | 'const'
-<variable-name>        ::= <identifier>
+<variable-definition>   ::= 'var' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-initializer>?
+<const-definition>      ::= 'const' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-initializer>
+<variable-name>         ::= <identifier>
+<variable-initializer>  ::= '=' <ows> <expression>
 
 (* Functions *)
 <function-definition> ::= 'fn' <ws> <function-name> <ows> <function-parameters> <ows> ':' <ows> <return-type> <ows> <function-body>
@@ -40,27 +39,18 @@ language.
 <function-parameters> ::= '(' <ows> ')'
 <return-type>         ::= <type>
 <function-body>       ::= <block>
+<block>               ::= '{' <ows> <statement> <ows> (<end-of-statement> <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
+<statement>           ::= <common-statement> | <return-statement>
+<return-statement>    ::= 'return' <ws> <expression>
 
 (* Statements *)
-<block>               ::= '{' <ows> <statement> <ows> (<end-of-statement> <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
 <end-of-statement>    ::= ';' | <line-break>
-<statement>           ::= <return-statement> | <variable-definition> | <assign-expression>
-<return-statement>    ::= 'return' <ws> <expression>
+<common-statement>    ::= <variable-definition> | <const-definition> | <assignment-expression>
 
 (* Expressions *)
-<expression>          ::= <integer> | <identifier> | <assign-expression>
-<assign-expression>   ::= <variable-name> <ows> <assign-operator> <ows> <expression>
-<assign-operator>     ::= '='
-                        | '*='
-                        | '/='
-                        | '%='
-                        | '+='
-                        | '-='
-                        | '<<='
-                        | '>>='
-                        | '&='
-                        | '^='
-                        | '|='
+<expression>            ::= <integer> | <variable-name> | <assignment-expression>
+<assignment-expression> ::= <variable-name> <ows> <assignment-operator> <ows> <expression>
+<assignment-operator>   ::= '='
 
 (* Identifiers *)
 <type>                ::= 'u32'
-- 
2.44.0

Re: [PATCH] fixup! docs: spec: add variables and constants specification

[Johnny Richard]

Thanks a lot for your contribution, I very impressed you managed to send
a really nice PATCH.

Sorry for that, but there is another Patchset version which was applied
to the main branch.  I think Carlos forgot to mention this Patchset was
SUPERSEDED[v2] by version 2.

v2: http://lists.johnnyrichard.com/olang/5fzsolce5h42aa6udppiwezgbzeqerkde3xvyilidnkcjaho2j@ygxd7ugzck4m/T/#m0f5cc6f2d49835ec83d4fd5c24d97d2597cb5363

However, I will leave my thoughts here but (we should try to address the
current implementation problems in a new patches).

On Thu, Apr 11, 2024 at 07:39:58PM -0300, ricardo_kagawa@disroot.org wrote:
> From: Ricardo Kagawa <ricardo_kagawa@disroot.org>
> > Since this patch adds support to assignments, lets also add support to
> > all assignment operators like "-=" "+=" "<<=" and so on.
> 
> I disagree. Support for those assignment operators should only be added
> when both assignments and operators are defined, and none of these
> operators are defined yet.

Sure... Unfortunately we don't have the specification for operators but
they are already implemented into the language parser (I was planning to
submit the assignment operators spec after this patch get applied).

As soon as I send the Patch we can discuss on top of it anything related
to assignment operators.

> > This patch lacks support to the following valid assignment expression
> > (which I think adds flexibility to the language):
> > 
> >     var x: u32 = a = b = c = 1
> 
> Personally, I don't like this idiom, but I wouldn't stop you from adding
> it. Johnny's patch actually already enables this, and also the
> following (for clarity, of course the `if` statement does not exist yet,
> but it is included here as an example of what might come in the future):
> 
> ```
> var x
> if (x = next()) {
>   return x
> }
> ```
> 
> Which is something I don't like either, just as much.

Carlos and I discussed it and we also agreed on removing this assignment.
The patch v2 has removed it.

> So, in my opinion, the decision should hinge on the compiler's ability
> to properly validate the constant's immutability, and whether or not
> late initialization should be allowed (complicating semantic checks).

I prefer to not do a late initialization as well (it will make things
simpler).  I prefer to make the assignment mandatory for constants.

> ---
> Discussions:
> 
> - Are you planning to hoist declarations, or are declarations required
>   to be placed before their use?

We are planning to have declarations being placed before their use.

> - Are you planning to include type inference for variable declarations?

No.  Everything should be verbose and explicit.

> -- >8 --
> 
> - Moved statements common to the translation unit and function bodies to
>   their own non-terminal.

Good.

> - Restored Carlos' definition of variable and constant definitions, as
>   they are not quite the same, structurally and semantically.
>   Personally, I'd rather constants to be initialized immediately, but
>   you may have a different opinion on this.

We also prefer to have the constants being initialized immediately.

> - Moved some non-terminals from the "Statements" section to the
>   "Functions" section, as there will be some statements that are
>   function-body specific, some that are translation-unit specific, and
>   some that are common to both.

I liked it.

> - Renamed "assign" to "assignment", for better wording.

Nice.

> - Renamed <variable-assign> from Carlos' patch to
>   <variable-initializer> (must not be used in <assignment-expression>).

Nice.

> 
> Signed-off-by: Ricardo Kagawa <ricardo_kagawa@disroot.org>
> ---
>  docs/pages/language-specification.md | 36 ++++++++++------------------
>  1 file changed, 13 insertions(+), 23 deletions(-)
> 
> diff --git a/docs/pages/language-specification.md b/docs/pages/language-specification.md
> index 2650dd9..b218462 100644
> --- a/docs/pages/language-specification.md
> +++ b/docs/pages/language-specification.md
> @@ -24,15 +24,14 @@ language.
>  (* Entry Point *)
>  <translation-unit>     ::= (<ows> <external-declaration> <ows> (<end-of-statement> | <end-of-file>))*
>  
> -<external-declaration> ::= <function-definition> 
> -                         | <variable-definition>
> -                         | <assign-expression>
> +(* Translation Unit *)
> +<external-declaration>  ::= <common-statement> | <function-definition>
>  
>  (* Variables *)
> -<variable-definition>  ::= <variable-qualifier> <ws> <variable-name> <ows> ':' <ows> <type> (<ows> <assign-operator> <ows> <expression>)?
> -<variable-qualifier>   ::= 'var'
> -                         | 'const'
> -<variable-name>        ::= <identifier>
> +<variable-definition>   ::= 'var' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-initializer>?
> +<const-definition>      ::= 'const' <ws> <variable-name> <ows> ':' <ows> <type> <ows> <variable-initializer>

After discussing with Carlos I regretted my suggestion about combining
_var_ and _const_.  Today we have both combined.  But separate them
makes a lot easier to implement.

Could you please prepare a new patch over the _main_ branch with this
change (if Carlos agree of course)?

> +<variable-name>         ::= <identifier>
> +<variable-initializer>  ::= '=' <ows> <expression>
>  (* Functions *)
>  <function-definition> ::= 'fn' <ws> <function-name> <ows> <function-parameters> <ows> ':' <ows> <return-type> <ows> <function-body>
> @@ -40,27 +39,18 @@ language.
>  <function-parameters> ::= '(' <ows> ')'
>  <return-type>         ::= <type>
>  <function-body>       ::= <block>
> +<block>               ::= '{' <ows> <statement> <ows> (<end-of-statement> <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
> +<statement>           ::= <common-statement> | <return-statement>
> +<return-statement>    ::= 'return' <ws> <expression>
>  
>  (* Statements *)
> -<block>               ::= '{' <ows> <statement> <ows> (<end-of-statement> <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'
>  <end-of-statement>    ::= ';' | <line-break>
> -<statement>           ::= <return-statement> | <variable-definition> | <assign-expression>
> -<return-statement>    ::= 'return' <ws> <expression>
> +<common-statement>    ::= <variable-definition> | <const-definition> | <assignment-expression>
>  
>  (* Expressions *)
> -<expression>          ::= <integer> | <identifier> | <assign-expression>
> -<assign-expression>   ::= <variable-name> <ows> <assign-operator> <ows> <expression>
> -<assign-operator>     ::= '='
> -                        | '*='
> -                        | '/='
> -                        | '%='
> -                        | '+='
> -                        | '-='
> -                        | '<<='
> -                        | '>>='
> -                        | '&='
> -                        | '^='
> -                        | '|='

As I said before, these _assignment operators_ are already implemented.
I have implemented it before we start the language spec.  I will prepare
a patch to fix the spec.

> +<expression>            ::= <integer> | <variable-name> | <assignment-expression>
> +<assignment-expression> ::= <variable-name> <ows> <assignment-operator> <ows> <expression>
> +<assignment-operator>   ::= '='
>  
>  (* Identifiers *)
>  <type>                ::= 'u32'
> -- 
> 2.44.0
> 

Re: [PATCH] fixup! docs: spec: add variables and constants specification

[Carlos Maniero]

> Thanks a lot for your contribution, I very impressed you managed to send
> a really nice PATCH.
>
> Sorry for that, but there is another Patchset version which was applied
> to the main branch.  I think Carlos forgot to mention this Patchset was
> SUPERSEDED[v2] by version 2.
>
> v2: http://lists.johnnyrichard.com/olang/5fzsolce5h42aa6udppiwezgbzeqerkde3xvyilidnkcjaho2j@ygxd7ugzck4m/T/#m0f5cc6f2d49835ec83d4fd5c24d97d2597cb5363

Sorry Ricardo. My bad! I forgot to update the mailing list saying that
this patch was superseded.

> > ---
> > Discussions:
> > 
> > - Are you planning to hoist declarations, or are declarations required
> >   to be placed before their use?
>
> We are planning to have declarations being placed before their use.

Just an observation here, this is only valid for external declarations
and just inside a function scope.

valid:
  
  1| fn main(): u8 {
  2|   return exit_success
  3| }
  4| 
  4| const exit_success: u8 = 0

invalid:

  1| const a = b + 1
  2| const b = 0

also invalid:
  
  1| fn main(): u8 {
  2|   exit_success = 0
  3|
  4|   var exit_success
  4|   return exit_success
  5| }

> Could you please prepare a new patch over the _main_ branch with this
> change (if Carlos agree of course)?

LGTM! And thank you so much for your contributions Ricardo!

Re: [PATCH] fixup! docs: spec: add variables and constants specification

[Johnny Richard]

On Sat, Apr 13, 2024 at 12:36:55AM +0200, Johnny Richard wrote:
> > > This patch lacks support to the following valid assignment expression
> > > (which I think adds flexibility to the language):
> > > 
> > >     var x: u32 = a = b = c = 1
> > 
> > Personally, I don't like this idiom, but I wouldn't stop you from adding
> > it. Johnny's patch actually already enables this, and also the
> > following (for clarity, of course the `if` statement does not exist yet,
> > but it is included here as an example of what might come in the future):
> > 
> > ```
> > var x
> > if (x = next()) {
> >   return x
> > }
> > ```
> > 
> > Which is something I don't like either, just as much.
> 
> Carlos and I discussed it and we also agreed on removing this assignment.
> The patch v2 has removed it.

Made a mistake here.  The current spec still have assignment
expressions.  For context, we agreed on keep it because the only place
we would miss this feature would be on *if* and *while* statements.

But we also don't have strong option on keep it. Since it will be little
bit annoying of optimizing the binary.

In conclusion, I believe everyone is Okay on removing it.

PS. Carlos prefers being called Maniero haha :^)