Initial compiler features

[JOT85]

Currently prioritised features

• pattern (rule, match, precedence and reserve syntax #3)
• rule (rule, match, precedence and reserve syntax #3)
• rulegroup (no issue yet - name not final)
• reserve (rule, match, precedence and reserve syntax #3)
• precedence (rule, match, precedence and reserve syntax #3)
• yield (yield and eval behaviour #5)
• eval (yield and eval behaviour #5)
• add, sub, mul, div (no issue yet)
• const (no issue yet)
• label, jump, if, call, return (Branching (label, jump, jumpz, if) #9)
• list-length, list-iter, list-indx (no issue yet)
• >>, >, | (see discussion)
• # (one line comment)

Features that are required but not priority

• floats
• syscalls
• function calling/returning
• compiler errors
• imports and includes
• compile time if
• compile time printing
• compile time user input
• optimisers and formatters

[sharnoff]

Initial syntax elements:

• Pattern - defines repeatable syntax elements that exist solely as strings
• Rule - defines syntax elements that can be converted into assembly (or our equivalent). Rules are entirely distinct from patterns.

Getting a value from a pattern Pat will be done by s~Pat, where s is now assigned the string value that matched on Pat. For rules, we'd say v@Rule to indicate something completely different: Storing the return register of the assembly produced by Rule into v.

We're also adding character ranges and negative look-ahead assertions, which are illustrated by example:

pattern Numeral: <|0-9|>

rule DecValue: n~Numeral {
    const n -> x
    yield x
}

reserve Value(1)

rule Value: x@Value y@DecValue $ !Numeral {
    mul x 10 -> x
    add x y -> x
    yield x
}

[JOT85]

I've updated the list in the initial comment and created #3

[JOT85]

Ideas:
>> ... parse the line as program code, using patterns.
> x <- ... parse ... as program code and let x be a compiler variable referencing the result.
Note that the syntax above isn't required. There are other ways of doing the same thing, eg:

rule get_x: "get_x" x@<expression type> {
    code using x
}
>> get_x...
rmrule get_x

However the above is messy, not obvious, and you define a rule to only use it once - which seems unnecessary when the syntax above above could be used instead.

Multiple lines for the first syntax can be handled simple as:

>> line1
>> line2
>> line3

For the second syntax, it could be:

> x <- line1
> line2
> line3

However this could be ambiguous in the case where line2 for example starts with "y <-".
Perhaps curly braces could be used?

> x <- {
> ...
> ...
}

This makes the end unambiguous.

[sharnoff]

Looks good - thoughts on this instead?

> x <- ...
| ...
| ...

or:

> x <-
| ...
| ...

[JOT85]

We also need to be able to group rules. We'll create a rulegroup directive for this.

[JOT85]

Looks good - thoughts on this instead?

> x <- ...
| ...
| ...

or:

> x <-
| ...
| ...

I think we implement the first as the second is a subset of that.
How about curly braces? They look nicer.

> x <- { ...
| ...
| ...
> }

It makes it nice and clear when it ends. I'm not too attached though.

[sharnoff]

How about curly braces?

I like them - they draw the eye more easily. An open curly should immediately require a newline, however. E.g.

> x <- {
| ...
| ...
> }

Invalid:

> x <- { ...
| ...
> }

[JOT85]

I've updated the first message with some new features as discussed offline.

[sharnoff]

@JOT85 The current one-line syntax makes it difficult to parse, as the line of code could contain an open curly brace. Thoughts?

---

Example

> x <- { foo = bar() }

and

> x <- {
| ...
> }

are both valid, assuming { foo = bar() } is a valid line of code in whatever language it is.

[JOT85]

@JOT85 The current one-line syntax makes it difficult to parse, as the line of code could contain an open curly brace. Thoughts?

Example

> x <- { foo = bar() }

and

> x <- {
| ...
> }

are both valid, assuming { foo = bar() } is a valid line of code in whatever language it is.

It is difficult to parse, but not ambiguous, since it is not followed by a | or closed by a > } - so you know it cannot go over multiple lines.
Since nothing else is allowed after the curly brace when you have multiple lines:

> x <- {
| ...
> }

It is not difficult to parse > x <- { foo = bar() } as that has characters after the {.
The main difficulty in parsing with this is that if you line of code was just { (and that somehow evaluates to something), you would have to look ahead as above to see if there was a vertical bar below. When it has more than just a {, you can see that there's more on that line so know that it's a single line expression. This does make it more complex to parse, so I think we stick with what you said and just allow:

> x <- {
| ...
> }

for now, and add a single line syntax in later if we think it's required.
The other thing with > x <- { foo = bar() }, is that if you're not familiar with the language, you might assume that the curly braces aren't code but are instead just for wrapping it, potentially giving the code a different meaning, which is bad.

[JOT85]

Also, how is the following line parsed:
>> code
It it parsed with the space at the start, so as " code", or is the space ignored and is it just parsed as "code". If the space is ignored, then the space should be compulsory - making >>code invalid.
The same rules should apply to | code.
I'm not sure what the best option is.
If you were parsing Python for example (or most other languages that use the off-side rule), you wouldn't be able to have that extra space, so you'd have to write >>code, which is ugly. But the alternative is to ignore a space, which seems like an imperfect solution.

[JOT85]

Also, how is the following line parsed:
>> code
It it parsed with the space at the start, so as " code", or is the space ignored and is it just parsed as "code". If the space is ignored, then the space should be compulsory - making >>code invalid.
The same rules should apply to | code.
I'm not sure what the best option is.
If you were parsing Python for example (or most other languages that use the off-side rule), you wouldn't be able to have that extra space, so you'd have to write >>code, which is ugly. But the alternative is to ignore a space, which seems like an imperfect solution.

Following discussion, it has been decided that everything past the >> is parsed as code, including the space - it is NOT ignored or discarded.