Track Issue for HNM Grammar

[HoshinoTented]

Comment:

** single-line comment
(*
  multi-line comment
*)

Magic (or Function):

magic magic_name_with_an_optional_? [copy_arg: i32; ref_arg: ~i32] {
** `magic` can be replaced with `mag`
    ** Function Body
}: ReturnType

Box Sugar Statement (or Let Statement):

box i: i32 <- init_value.       ** '.' is IMPORTANT
**  ^~~^ Optional Explicit Type Declaration
box ref_i: ~i32 <- ~i.
** Get a reference of i by '~' operator
box j: i32 <- `ref_i.
** deref

Some Key Words:

Ja ** means True
Nein ** means False
logic ** means bool
i32 ** means... i32
lang ** means String
letter ** means char

Member Call:

box s: lang <- "qwq?n".
s->to_lower_case[]

Area Import (or Module Import):

area a->b->c

Crash (or Panic/Throw):

area natural.

magic center [] {
    natural->crash["This Magic Crashed QAQ."].
}

SenTakuShi (or If Statement/Expr):

do (Ja)? {
   when Condition is Ja
} or {
   when Condition is not Ja
}

Repeat SenTakuShi (or Loop):

area natural->world.

do (Ja) /* loop FOREVERRRRRRRRRR */ {
    world->emit["Hello, world!"].
}

^2:

box i <- 2.       ** which is i32
box j <- ! i.      ** `!` is a sugar that means `i * i`

null keyword:

box i: i32 <- null.       ** compile error: null: null is not allowed everywhere.

data structure definition

box point [] {  ** [] can be omitted
    x: i32,
    y: i32
}.

box ptr: point <- point { 2, y: 5 }.

anonymous data structure

box { inner: i32 } foo <- box { 123 }.

sequence (aka array)

magic new_sequence[seq: *i32] {
    seq
}: *i32.

magic center[] {
    ** argument list with separator ','  is treated as Variable Parameter
    box seq: *i32 <- new_sequence[1, 2, 3].

    natural->emit[sequence->length[~seq]].   ** output 3
}.

[chuigda]

What will we use for array subscription operation if we use brackets for function call?

[HoshinoTented]

It may be...:

area natural->arr.   ** I don't think the constructor name will be 'arr'

/* -- snip -- */

arr[1, 2, 3].        ** Like this?

[HoshinoTented]

Wait... What is "array subscription operation"? Get the nth element of an array?

I think we can make an array as a Magic (?, but I don't know how to impl it yet... It may be more complex...)

[chuigda]

Wait... What is "array subscription operation"? Get the nth element of an array?

just like in C

int array[] = {1926, 0817};
printf("%d", array[1]);

Java das not have a sugar like [], so we have to use methods like get(). In my opinion at least we should provide some kinds of syntactic sugar for such operations.

[chuigda]

I think we can make an array as a Magic

а на функщин, как на функщин. As far as I know, function or magic can act as some mutable data object except in JavaScript.

[HoshinoTented]

So I think... It may...:

area natural->arr.

box array <- arr[1, 2, 3].
box first <- array[0].

like this?

In this code, array is a magic. It has some overloaded magic... maybe...

[HoshinoTented]

But I didn't come out with what is the array type looks like yet... And this problem may be too hard for me.

[chuigda]

So I think... It may...:

area natural->arr;

box array <- arr[1, 2, 3];
box first <- array[0];

like this?

So the idea is to make a "builder" or "constructor" function return an array. So, is the array a value type or reference type?

[HoshinoTented]

So, is the array a value type or reference type?

It will be a value type, can be copied easily. Although this design is not common in the modern programming language

[chuigda]

But I didn't come out what is the array type looks like yet

Japanese “アレイ(arei)” is just the pronunciation of English “array”。I suggest using “Massiv” （русский:массив）。

[chuigda]

It will be a value type, can be copied easily.

Then it will be really hard to return an array from a function, just think about the array in C , std::array in C++，and [T; n] in Rust.

[HoshinoTented]

I may not create a new type of keyword for array...

[HoshinoTented]

Then it will be really hard to return an array from a function

Why?

[chuigda]

Then it will be really hard to return an array from a function

Why?

First of all, returning a value from a function involves copying the value from the stack frame of the callee to the stack frame of caller, which will be inefficient without RVO. What's more, values on stack are usually required to have fixed size, which will further limit the utility of array.

[HoshinoTented]

QAQ That's bad

[HoshinoTented]

Well, so array must be a reference type

[HoshinoTented]

but I think, the MaHouTsukai can:

magic return_array [] {
    ** do something
}: ~ <array type>   ** it returns a reference

[chuigda]

but I think, the MaHouTsukai can:

magic return_array [] {
    ** do something
}: ~ <array type>   ** it returns a reference

Then you will need to extend lifetime of the array being returned, by moving it to heap area. And the caller in fact gets a reference~ <array type> instead of a value <array type>.

[HoshinoTented]

array may be allocated at stack? IDK, what is the behavior of JVM about this?

[chuigda]

array may be allocated at stack? IDK, what is the behavior of JVM about this?

According to Oracle doc:

In the Java programming language, arrays are objects (§4.3.1), are dynamically created, and may be assigned to variables of type Object (§4.3.2). All methods of class Object may be invoked on an array.

Arrays are just Objects, which are created on heap.

[HoshinoTented]

Arrays are just Objects, which are created on heap.

My guess is right.

[HoshinoTented]

Designing a programming language is TOO DIFFICULT!

[HoshinoTented]

How about this kind of magic calling? :

foo[1, 2, 3; 4, 5, 6; 7].
** `1, 2, 3` is the first argument which is vararg, ';' separates two arguments, `4, 5, 6` is the second argument, `7` is the third argument

This makes vararg can be anywhere, not only at the last parameter.

[chuigda]

How about this kind of magic calling? :

foo[1, 2, 3; 4, 5, 6; 7].
** `1, 2, 3` is the first argument which is vararg, ';' separates two arguments, `4, 5, 6` is the second argument, `7` is the third argument

This makes vararg can be anywhere, not only at the last parameter.

Looks all fine but one thing: how does the callee's parameter list look like, and how will callee utilize these varargs?

[HoshinoTented]

"I found it!"

We can use <type>* to represent array type.

[HoshinoTented]

"I found it!"

We can use <type>* to represent array type.

Well... it will fall into left-recursion... How about *<type> ?

[HoshinoTented]

* means zero or many, not a pointer. BUT array is a pointer in C or C++!

[HoshinoTented]

Revert to <type>* version.

[HoshinoTented]

New Grammar:

box i <- 2.
box j <- i!.                  ** now j equals 4

! operator means x * x or x ^ 2

[chuigda]

New Grammar:

box i <- 2.
box j <- i!.                  ** now j equals 4

! operator means x * x or x ^ 2

Currently rule for identifier looks like this:

MagicChar = _{
    !(
        ":" | ";" | "<-" | "->" | "-" | "+" | "*" | "/" | "%" | "[" | "]" | "{" | "}" | "." | "~" | "`" | ASCII_DIGIT | WHITE_SPACE
    ) ~ ANY
}

Thus the ! mark can be part of identifier. How do we distinguish square operations from magic characters?

[HoshinoTented]

"!" cannot be the part of identity, this list isnt complete.

[chuigda]

And what's more, the mark ! has been used for factorial operations for a while in mathematics language.

And has been used for for boolean negation operation for a while in computer languages.

[HoshinoTented]

:sad: thats bad

[HoshinoTented]

Oh, my fault. According to THIS, ! should be a prefix operator of a number, like:

box i <- 2.        ** i is an i32
box j <- !i.        ** so `!i` is `i * i`

[HoshinoTented]

And I think, we should complete the grammar rule before writing the parser manually.

[HoshinoTented]

Does this sugar make the grammar more complex?

[chuigda]

Does this sugar make the grammar more complex?

I think not. As a funny language we must have grammar of much fun. Just take it as is.

[chuigda]

And I think, we should complete the grammar rule before writing the parser manually.

That does not matter. There are some common infrastructures between different parsers. I'll implement these firstly.

What's more, the parser of HNM will also be used for Pr47 (after being modified).

[chuigda]

Copying the box grammar to Pr47.

[HoshinoTented]

Initialization for box uses =:

box i = 1.

If you need to change the value which in the box, you have to use <-:

box  i = 1.
** i = 2.  Compiler Error
i <- 2.

[HoshinoTented]

What about this..? IDK 😢

[chuigda]

What about this..? IDK :cry:

I suggest always use <- for assignment like operation, and = only for equality testing.

[chuigda]

Of course I can implement either of them.

[HoshinoTented]

What about this..? IDK 😢

I suggest always use <- for assignment like operation, and = only for equality testing.

yes

[HoshinoTented]

i am back. maybe

[chuigda]

Spasibo khorosho. The parser of Pr47 is close to finish, and the develop of HNM may benefit from that. QwQ.

Also, it handles expressions correctly.

[HoshinoTented]

About math operators and bit operators:

These operators depend on Calculating Context:

• Math Context
• Bit Context

However, the number can be cast to bit implicitly, vice-versa. The context of a formula depends on the first operator, like:

• The context of 1 + 2 - 3 * 4 is Number Context
• The context of 1 >> 2 | 3 is Bit Context
• The context of 1 + 2 >> 3 ... Oh sorry! You will get a compile error!

Bit operators are not available in Number Context, vice-versa. But according to the implicitly cast rule, you can use parentheses to split the context, like:

box i <- (1 + 2) * (1 << 4).

The priority of operators:

• Number Context: * / ^ have the highest priority in Number Context, and + - have the secondary priority.
• Bit Context: ALL operators have the same priority.

About Bit Bit is similar to logic, they have two states, Ja and Nein for logic, Active and Tired for Bit.

[chuigda]

These operators are depend on Calculating Context:

• Math Context
• Bit Context ...

Bit operators are not available in Number Context, vice-versa.

Is this restriction intentional, or just because of implementation difficulty?

[HoshinoTented]

In order to avoid ambiguity

[HoshinoTented]

I think the context resolution is good, and I want to impl one by myself.