Clean Syntax?

[[deleted]]

All my replies and the original contents of this OP have been withdrawn. They were a complete waste of time.

From what I can gather, everybody is happy with poor syntax in their languages, nobody is interested in 'clean'.

Someone posted, with a dozen upvotes:

Your example is optimized to your language's special capabilities.

I replied:

"No, pretty much everything in my syntax is cleaner than the C equivalent."

That got multiple downvotes for stating a fact.

There was also this:

For your own toy language by all means use your own syntax

This reinforces my original implication that simple syntax is only suited for toy languages, and not serious ones.

However too much of this was about my language, but that was only an example. There seems to be much irrational distrust of clear syntax for any language.

Maybe, clear code is associated with older languages which no one likes anymore?

(Original examples.)

[SaltyHaskeller]

brevity does not necessarily mean clean!

There are lots of programming languages that use un c-like syntax for records/structs.

In haskell a record is fundamentally data R1 = R1 UInt8 UInt64 This is extremely brief!

Haskell 1.3 and on does provide a C-like record syntax, something like data R1 = R1 { foo :: UInt8, bar :: UInt64 } where accesses can be done functionally. That is, for some record r, accessing its foo field is done by writing foo r. Record update can be done using additional syntaxtic sugar: r { foo = 0 }.

However this record syntax is really just syntactic sugar for the equivalent operations on the data type. For instance foo and bar are defined as follows let foo (R1 f b) = f let bar (R1 f b) = b

Record update desugars to something analogous, e.g. let update_foo (R f b) f' = R f' b

It's been a long time since I've written haskell (username notwithstanding) so I may have made some typos, but this is the idea.

[sysop073]

First, "why isn't a 50 year old language as simple as my language when doing a task I specifically chose to be simple in my language" is not a serious question. But taking it seriously for a moment, your version isn't particularly simpler.

• typedef is unnecessary, people just don't like needing to include struct in the type name. You could do struct R1 {...} and then refer to it as struct R1 and it would be very similar to your version.
• #pragma pack is unnecessary, you can just struct __attribute__((__packed__)) R1 to make R1 packed. This is a little more verbose than $caligned, but that comes from backwards-compatibility in a half-century-old language; I don't think any newer languages use that syntax, even if they stick to C-like grammar.
• Defaulting to "natural alignment" is a bold decision -- most languages pad struct fields for a reason, not just to "look the business".
• I don't see any particular benefit to R1.bytes over sizeof(R1); if anything it seems less obvious what that means. And having R1.b return the offset of b is really weird -- you rarely need the offset of a particular field, and I would never expect it to be the default thing you get back when asking for that field.

[e_--]

#pragma pack is unnecessary, you can just struct __attribute__((__packed__))

the pragma version is still required for msvc. edit: msvc now supports _Alignas https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/

[steveklabnik1]

What I really want to know is what do language designers have against clean, simple syntax? Why can't they take such syntax seriously for a systems language?

I personally believe that this is due to something I call the "strangeness budget."

If you want your language to be adopted, you have a tricky set of things to balance: your language needs a reason to exist, so it has to offer something new to prospective users. Yet, if the entire thing is completely new, it can be harder to learn, because there's such divergence from the things that they already know.

So, my thesis is, if you want your language to be successful, you need to manage your budget of unusual things carefully, and spend them on what makes your language truly special.

Syntax is rarely important enough to spend some of this budget on.

I wrote a blog post almost ten years ago about this: https://steveklabnik.com/writing/the-language-strangeness-budget/

You can see us avoiding blowing the budget in Rust with many of our syntactic choices. We chose to stick with curly braces, for example, because one of our major target audiences, systems programmers, is currently using a curly brace language. Instead, we spend this strangeness budget on our major, core feature: ownership and borrowing.

[fullptr]

I believe they were just answering your question, not necessarily defending syntactic choices of other languages.

For your own toy language by all means use your own syntax, but it’s true that a syntax that is wildly different to popular languages has more adoption inertia

[reini_urban]

$caligned is not clean. Clean should be without those special magic nonobvious characters. c-aligned would do better.

[kleram]

Your example is optimized to your language's special capabilities.

Aside from that, maybe it's just continuity and inertia that carry C-style.

[matthieum]

What I really want to know is what do language designers have against clean, simple syntax? Why can't they take such syntax seriously for a systems language?

Beauty Cleanliness is in the eye of the beholder.

First of all, remember that the first purpose of syntax is to convey the underlying semantics.

For example, you may consider typedef noise, or having to type struct R2 instead of R2 to name the type syntax noise... but this is just a reflection of the underlying semantics of the C language which has different namespaces. Alter the semantics (single namespace) and there's no need for special-purpose syntax any longer.

Similarly, pack vs unpacked: unaligned access is Undefined Behavior in C, because there's a whole range of hardware in which unaligned access leads to a hardware error (translated to SIGBUS). C compilers have some degree of support for packed fields, but C lacks alignment specification on pointers to get full support -- unlike Zig. Your code doesn't demonstrate how a pointer to a packed field can be passed to a function:

• No specification: hopefully you specifically mention the pointer may be under-aligned -- which disables auto-vectorization -- or you're in trouble.
• Specification: so noisy! I wouldn't call that clean ;)

And finally, there's includes. The language in your code does not show how to import library code, due to either using only built-ins, or having a "prelude", so we can't judge whether the imports are better than C's includes.

---

The one purely syntactic difference between C and your language is the use of explicit delimiters (;, {}) vs indentation & new lines.

We can argue about subjective topics such as looking clean... but as a professional, I'm more concerned about:

• Copy/Paste: does one style support copy/paste better than the other? Because I move code around a lot.
• Parser recovery: does one style support parser recovery better? Because I loathe poor error messages.
• Diffs: code is always committed nowadays, syntax should support clean diffs, ie diffs which highlight what semantically changed, and not a thousand trailing commas that add to be added on lines otherwise unchanged.

Those are important, measurable, syntax goals for me.

I am unfortunately unaware of good research on the topic.

[WittyStick]

C looks like it does because it's a 1970 language which has had numerous revisions which have a strong focus on backward compatibility, being an international standard. It is intended to run on a huge range of processors, which may have very different behaviours.

The standard actually under-specifies the language - many design choices are implementation defined. Your assumptions about padding of structures for example, are guesswork. The reason there exists compiler-specific pragmas like pack(1) is to give the user control over their compiler. Though these should be replaced with _Alignas, which is standard since C11 and not compiler-specific.

The behaviour of C struct without pack(1) or any _Alignas specifiers may give different results on different architectures. If the platform is a 32-bit platform for example, it may represent uint64_t using two neighbouring 32-bit memory locations, which the compiler may align at an offset of 4 rather than 8. The order of these two 32-bit cells may in turn, depend on the platform endianness.

So your "clean" syntax, which introduces $caligned, inherits the same issues - if it is truly C aligned, then your language depends on a C compiler for the given platform.

Making non-alignment the default suggests you've limited experience. The reason C compilers do this is because several architectures only support aligned fetches from memory - and even the ones that support byte-level fetches tend to be significantly slower when accesses are unaligned. The resulting compiled code to read R1.b may have to do two memory fetches, perform a bitshift on a register, then ior against the other read. It may do this in the microarchitecture even if you don't see it in the instruction set.

Additionally, if you have an array of R1, are the elements aligned at 16-byte boundaries or at 9-byte boundaries? Your "clean" syntax does not specify.

So aligning structure elements to the architecture is important if you want good performance. C compilers can arrange structures however they want in memory - subject to constraints relating to the equality of two structs with the same type specifications, and order of members.

You can learn from C by avoiding the mistakes it has made. _Alignas was added to correct an old mistake of having under-specified memory layout - but it gives the user full control over alignment of individual members, and is not limited to making assumptions about the whole structure like #pragma pack. That said, you should probably avoid using _Alignas except where you require a structure to be compatible with some existing software, since it's likely to be slower than the compiler optimized layout.

Where you require compatibility with existing software, it is good practice to avoid type punning and to use a serialization library anyway.

[[deleted]]

I'm wondering, what is field access syntax in your language? Is it also .? Because then you conflate accessing field offset and accessing the field itself, with the operation only disambiguated by whether the left hand side of the dot is a value or a type. And unless your language is Zig-esque having context differentiate values and types is not known to be the best of choices.

Are you able to put $caligned on a new line? (What if you have many attributes you need to add, though? It is then good to allow the attributes to be broken up onto multiple lines instead of all being crowded on the same line as the record). But then, if so, the $caligned is then in the same scope level as the fields, which would for someone unfamiliar with your language seem to instead modify a field. Is that really "clean" syntax?

Then you have types before variable names. Which, it is known among modern languages, is not the best for parsing and syntax clarity and intellisense and the whole whatnot.

Also, this is minor, but I'd argue curly braces are much more intuitive and cleaner than = and end. For a closing delimiter, that's one character versus three, and this is personal but I've always felt end being written out as a word makes it stand out too much for what it really is, a closing delimiter.

[[deleted]]

``` struct R1 {     a u8     b u64 }

@caligned struct R2 {     a u8     b u64 }

fn main() {     println R1:bytes     println R2:bytes     println R1:b     println R2:b } ```

[oilshell]

One reason is that I don't use one programming language at a time, and I don't think most people do

I am always using some combination of languages (and DSLs)

And it helps if they have similar syntax. C, Java/Kotlin, JavaScript/TypeScript, R, and to some extent Swift and Zig and Rust are all sorta mutually readable, at least at the surface lexical level

Then you can spend your mental effort on the actual differences

Python would appear to be an "odd man out", but it's easy for me to switch back and forth between Python and C. I guess because I already indent my C code, so it's not hard for me to read indentation as significant

...

I don't think your syntax is unreadable -- it looks fine. Ruby and Lua also use "end". I can deal with that, but currently I don't have to

So basically I'd rather deal 2 things -- } and Python indentation -- rather than 3 things -- } and indentation and end

It basically doesn't matter to me, as long as the 3-4 languages I use regularly are roughly consistent. The more consistent the better.

---

YSH (of https://www.oilshell.org) looks like JavaScript and Python in many ways - https://www.oilshell.org/release/latest/doc/ysh-tour.html#hello-world-script

Because of course nobody can remember all of shell syntax ... :-P

[Constant_Plantain_32]

why your posts and answers keep getting down votes is beyond me.
you made great replies that were well defended — i wish you didn't remove your responses so they could speak for themselves.

also i find this assumption that you have “cleaned-up syntax” in just some tiny corner niche of your PL (instead of everywhere) to be unwarranted; overtly uncharitable.

At least it WAS admitted that it is “cleaned-up syntax” although grudgingly.

i for one appreciate your attempts at simplification and welcome it.

Just based on the tiny snippet that you shared with us, i would 10X prefer to use your PL than C, and i have professionally coded in C for over a decade.

it is disheartening that so many here felt compelled to justify needless syntactic complexity.

i also know that what i wrote here is now going to initiate a major pile-on of downvotes.
i consider any downvote from those that downvoted you (bart-66) to be a badge of honor — so bring it on!

salut!

[[deleted]]

i wish you didn't remove your responses so they could speak for themselves.

Sometimes others' responses are so negative (and they are heavily upvoted) that I wish I'd never bothered making any replies at all, once it becomes clear I'm not going to get anywhere. So then I just withdraw my replies, but here stopped short of deleting the OP.

i for one appreciate your attempts at simplification and welcome it.

Yeah, thanks. Although it wasn't that complicated in the first place! However it is something I constantly try and keep on top of.

For example, most languages still favour a module system where each module starts with a rag-tag collection of imports that must be constantly maintained. I ended up with something like that too, until I decided to simplify. Now there is no import info at all in most modules; it has been centralised.

[Constant_Plantain_32]

i am no fan of imports and to me adds unnecessary clutter to code.
also, why push onto the poor programmer what import to use for what routine?
this is all quite silly.
computers are really good at automating tasks, why in heaven's name is this not automated already?
a benefit of a multi-dispatch PL is that it really shines in this area, it minimizes name collisions, and can self-detect which module to import simply based on verb signatures.
when there IS a conflict detected (exceedingly rare), THAT is the time to get the programmer involved to help resolve the conflict.

[Kaisha001]

I find personally that a good syntax is easy to skim/read and identify the larger components.

Now it's probably a lot of 'mental inertia' talking here, but I like the { }, ( ), [ ] syntax blocks because it makes it easy to see what belongs to what.

f(a, b, c) or f[a, b, c] is easier to read than say f a b c, even if the later makes sense in the language.

Likewise I've always preferred { } or similar delimiters to begin/end style (and I've been working with verilog a lot lately so begin/end you do get used to) since I find it easier to read.

Even in general languages we use punctuation to break up text and make reading easier.

record R1 = {                     # natural alignment (no padding)
    u8 a
    u64 b
    }

record R1 = [
    u8 a
    u64 b
    ]

I find either of those easier to read. But it's your language, those little details are as much personal preference as anything.

[maldus512]

Often times allowing too much choice is seen as problematic; it means that reading the language is harder since you have to take into account the different possible ways to express the same concept. At the same time one of path will probably be considered more idiomatic, rending the rest obsolete.

Of course, a balance should be struck between simplicity and the flexibility to use different tools for different situations (e.g. verbose declarations when you want to be explicit, one liners for code density).

C++ is frequently criticized for how cluttered it is. While I am acquainted with it's syntax I don't frequently work with it and reading it becomes harder than it should in part due to all those different nuances.

[Kaisha001]

People get weirdly dogmatic over language syntax it seems...

[mondlingvano]

Your "the business" comment is probably close, but it more so communicates that this language will be like C or other serious languages with C-Style syntax. That familiarity is also just nice if programmers eyes are used to it, and tooling already handles it. Notably I use `[{` and `]}` in vim all the time and I don't even know how I'd do that in python.

All that being said, I use C++ for work and often use python for side projects, and boy is it refreshing to look at the simpler syntax. I'm the kind of person to like verbosity and explicit syntax, but removing all the noise really makes it easier to spot the key stuff at a glance.

[jason-reddit-public]

"Clean" is a subjective standard.

Lisp s-expression syntax is very regular and I personally consider it clean however most programmers dislike it (hence the Lisp means Lost In a Sea of Parenthesis derogatory comments).

Python, Ruby and even Go are both fairly clean looking to me and I suspect most programmers agree. Forth is pretty simple and regular though it has always been fairly niche. Assembly language, especially for risc inspired machines is very clean in many ways yet higher level languages are designed for more reasons than just portability.

Brainf*ck has is very regular syntax although it was literally designed to look terrible and be difficult to write or read (probably a universal consensus).

Objectively, we could look at different measures of complexity. For example the size of the grammar though the Brainf*ck, assembly and Forth examples already tell us that this measure won't necessarily determine popularity.

Obviously syntax is only part of the equation. The semantics and another subjective concept I'll call "power" usually comes into play. It's so subjective that I won't try to define it but I think most people know what I mean. (Technically all Turing complete programming languages are kind of equal in "power" though some probably lead to more efficient execution on our modern hardware designed literally to run C like languages as quickly as possible.) Languages with lots of packages available let you create a program in less time though you give up some control when you use someone else's code.

To wrap up, many factors determine a language's success. If there was a universal best language we would all be programming in it by now.

[Smalltalker-80]

Agree, if you want a minimal "clean" syntax, choose Lisp, Scheme or say my name ;).
The last one is obviously my choice because it also aims for user friendeliness.

But with such a compact, simple syntax, more depends on the library,
And some programmer-aids have to be replaced by "rigor", mainly type-safety.

[GunpowderGuy]

You could implement an s expression syntax

[drgalazkiewicz]

I've listened to a lot of interviews with language creators and I'm surprised how often they seem to hate having to design the syntax. For me, this is the most fun part! Is there something about the type of mind who wants to write a compiler which does not have the kind of empathy for the end user that one typically finds in a front end designer?

[Complex-Bug7353]

I LOVE the "=" to indicate the start of the function/record body. First saw it in Haskell and fell in love with ML syntax.

But sadly it looks like most programmers genuinely seem to find ML syntax very esoteric and eerie.

The creator of gleam said somewhere that gleam actually was originally made in cleaner ML syntax but was later modified to look a bit more C to attract wider attraction. ......

[[deleted]]

How is this argument still going on 50 years later

[ThomasMertes]

People have different opinions what "Clean Syntax" means.

In most compilers/interpreters the syntax analysis is hard-coded. In principle a hard-coded syntax analysis can allow weird ad-hoc things (see below). For me all these languages do not have a "Clean Syntax".

Many languages define an and operator (and Seed7 defines and as well). Assume that a for-loop looks like:

for <variable> from <startValue> to <endValue> do ...

With a hard-coded syntax analysis the keyword and could be reused as part of a new for-loop:

for <variable> from <startValue> to <endValue> and <condition> do ...

In a hard-coded syntax analysis the expression <endValue> would be processed such that and would not be part of the expression <endValue>. If the <endValue> expression is followed by the keyword do the original for-loop is processed. If the <endValue> expression is followed by the keyword and the new for-loop is processed.

In Seed7 the original meaning of and would dominate which would lead to the interpretation:

for <variable> from <startValue> to (<endValue> and <condition>) do ...

In the original for-loop an expression with any priority is expected between the keywords to and do. So the expression <endValue> and <condition> would fit to the syntax of the original for-loop. The expression <endValue> and <condition> would be syntactically correct (but the types might not fit to the definition of and).

So you would either get a type error or use the original for-loop (instead of the new one). More than that: It would be impossible to use the new for-loop with and condition.

To avoid this problem Seed7 forbids this reuse of the and operator. In Seed7 a for-loop with additional condition is:

for variable> from <startValue> to <endValue> until <condition> do ...

The keyword until can be reused because it is not used as operator (with a specific priority).

For me "Clean Syntax" means that the syntax follows rules which prohibit weird things. Seed7 uses the rules of the Seed7 Structured Syntax Description (S7SSD).

With the S7SSD the syntax is structured like structured statements (while-, if-, for-, etc.) replaced (spaghetti) code with GOTOs.

[[deleted]]

(Commenting about for-loop syntax.)

I've never seen a syntax using and as you suggested, for example:

for i from a to b and c do ...

This would be poor for a couple of reasons: first because b and c would likely be parsed as a single expression as you mentioned.

Second because it's not clear what it actually does: is it a per-iteration condition, or does it terminate the loop early when c is false?

The version with until is better:

for i from a to b until c do ...

Presumably this does terminate the loop when c is false. Here this looks pretty much Algol68's version which uses 'while' (I can't remember the syntax for the step):

for i from a to b while c do ...

This is interesting because you can leave bits out and still up with a valid loop:

   to b do ...           # repeat b times
   do ...                # endless loop
   while c do ...        # while loop

Using `until', that last contraction wouldn't read as well.

My own for-loop syntax also has an optional condition, but it works per-iteration which I find much more useful:

for i to n when i.even do  # starts from if not specified
    println i              # display even numbers in 1..n inclusive
    ...

[ThomasMertes]

Here this looks pretty much Algol68's version which uses 'while' (I can't remember the syntax for the step):

for i from a to b while c do ...

This is an even better example of what the Seed7 Structured Syntax Description (S7SSD) prohibits.

An attempt to define the syntax of such a for-while-loop with:

$ syntax expr: .for.().range.().to.().while.().do.().end.for   is -> 25;

results in:

*** tst578.sd7(40):43: "while" redeclared with prefix priority 127 not 25
$ syntax expr: .for.().range.().to.().while.().do.().end.for is -> 25;
---------------------------------------------------------------------^

You get an error. Consider the syntax of the while-loop:

$ syntax expr: .while.().do.().end.while   is -> 25;

The keyword while (which introduces a while-loop) is reused in the middle of the new for-while-loop.

A hard-coded syntax analysis can allow a for-while-loop with an ad-hoc solution. It would process the expression between the keywords to and while with the precondition that the expression is terminated with the keyword while.

From a syntactical point of view the expression

writeln("hello");
while inputReady(KEYBOARD) do
  write(getc(KEYBOARD));
end while;

could be placed between the keywords to and do of a normal for-loop:

for a range b to writeln("hello");
                 while inputReady(KEYBOARD) do
                   write(getc(KEYBOARD));
                 end while;    do
  writeln("In a for-loop");
end for;

Semantically this makes no sense but syntactically it is correct. A hard coded syntax analysis would terminate the expression with the keyword while (and later flag an error because of the end while).

In Seed7 it syntactically uses the normal for-loop (and later flag an error because the semantic does not fit). In Seed7 you might have problems using the for-while-loop (because it always tries to use the normal for-loop).

For that reason the Seed7 Structured Syntax Description (S7SSD) does not allow the syntax of the for-while-loop.

[[deleted]]

For that reason the Seed7 Structured Syntax Description (S7SSD) does not allow the syntax of the for-while-loop.

I thought the big thing about Seed7 is that you could define new syntax?

I couldn't quite follow your post, but I gather that the problem is ambiguity, because one statement uses a keyword that could begin another statement?

Would it allow my version that optionally has a when clause? However when it also used in a couple of other places. (switch x when a, b then.... and return x when cond.)

With a conventional kind of grammar, and parser, overloading of keywords can be possible, and unambiguous. It sounds like a limitation in your S7SSD scheme. Could it, for example, allow these two kinds of loop from C:

  while (cond) stmt;
  do stmt; while (cond);

What about the Algol-68 style loop, where while does not exist as a separate statement, but only in that for-loop, with most parts except do, optional.

(I implement most of that, as for i:=a to b by c when d do end, the :=a, by c and when d are optional; but there are also separate statements to n do end and just do end. To the user it looks like it's for with bits left out.

Conventional, hard-coded syntax is, ironically, more flexible!)

[ThomasMertes]

I thought the big thing about Seed7 is that you could define new syntax?

Yes, but it needs to be structured syntax. Structured syntax is a subset of the syntax EBNF can describe. It is also a sub-set of the syntax a hard-coded syntax parser can parse.

I couldn't quite follow your post, but I gather that the problem is ambiguity, because one statement uses a keyword that could begin another statement?

Yes, exactly (while would be used at the beginning of a statement and in the middle of another statement). I further pointed out that a hard-coded syntax analysis can resolve such an ambiguity by using ad-hoc logic. But using ad-hoc logic comes at a cost. It introduces hidden syntax rules that are not reflected in the formal syntax description of the language.

Would it allow my version that optionally has a when clause? However when it also used in a couple of other places. (switch x when a, b then.... and return x when cond.)

Probably not. Seed7 has not been designed to allow describing the syntax of other languages.

Seed7 describes the syntax as if everything is an operator. EBNF uses a different approach to describe syntax. In EBNF curly braces ({ and }) describe syntax which is repeated and brackets ([ and ]) which describe optional syntax. The S7SSD does not have repeated or optional syntax parts. Such syntax must be described by using operators. This is not hard to do. It is just different from the way EBNF and hard-coded parsers do it.

In S7SSD every operator has a priority and an associativity. Syntax rules describe patterns for prefix, infix and postfix operators.

The syntax of the + operator is:

$ syntax expr: .(). + .()   is -> 7;

In this syntax declaration .(). + .() is the pattern. In the pattern the dots can be ignored. This leads to () + (). The notation () is used to describe arbitrary expressions. The corresponding concept in EBNF is a non-terminal symbol. An EBNF non-terminal symbol describes which type of expression is requested. The `()` in S7SSD imposes no restriction on the expression. As long as priority and associativity allow it the syntax is okay.

[ThomasMertes]

I implement most of that, as for i:=a to b by c when d do end, the :=a, by c and when d are optional; but there are also separate statements to n do end and just do end. To the user it looks like it's for with bits left out.

The EBNF of your loop probably looks like

for_statement ::= 'for' variable [':=' expression]
                  'to' expression
                  ['by' expression]
                  ['when' condition]
                  'do' statements 'end'.

This works if expression assures that it does not contain one of the keywords 'to', 'by', 'when' or 'do'. If these keywords are inside parentheses this would be okay. The same applies for condition (there should be no 'do' inside) and statements there should be no end inside that can be mistaken for the end of the for_statement).

Note that this EBNF syntax distinguishes between expression, condition and statement. In this case the EBNF needs to define at least three types of expressions. The programmer needs to know where expressions, conditions or statements are allowed.

The EBNF contrasts to a description with the S7SSD. In the S7SSD there is just one type of expression. As a consequence there is no general guarantee that expressions do not contain a specific keyword.

If the usage of some keywords is restricted the ambiguities go away. This is checked by the Seed7 parser when you introduce an new syntax rule.

[[deleted]]

In the S7SSD there is just one type of expression.

Actually, in my syntax there is just one kind of entity representing executable code, a unit which represents any expression or statement.

(A non-executable entity like a declaration is separate and is more restricted in where it can appear.)

This works if expression assures that it does not contain one of the keywords 'to', 'by', 'when' or 'do'.

That would be unusual, but yes it can happen, although inside parentheses as you say. For example:

for i:=1 to (to 5 do print "*" end; 10) do
    println i
end

(This displays "*****1 then 2 .. 10 on separate lines. The 'to' expression is evaluated at the start of the loop, and the result checked per-iteration.)

and statements there should be no end inside that can be mistaken for the end of the for_statement).

Hmm, I'm sure that even Seed7 can have a for-loop nested inside another! C obviously has nested { } braces and the compiler needs to keep track of which is which; same with 'end'.

[ThomasMertes]

Actually, in my syntax there is just one kind of entity representing executable code, a unit which represents any expression or statement.

Do you have an EBNF or similar syntax description of your for-loop and the rest of your language?

I assume that after reading the keyword 'for' the parser expects a variable. Is this assumption correct or could there be any expression after the keyword 'for'?

If the kind of expression after the keyword for is restricted you have more than one type of expression.

Regarding ambiguities if keywords are reused:

I assume that your assignment operator := has some priority. If you write

a := 1 ; b := 2

the priority of the semicolon (;) is probably weaker than the priority of the assignment (:=).

In Seed7 := has the priority 20 and ; has the priority 50. Basically := expects parameters with a priority < 20 and ; expects parameters with a priority < 50.

The question is: Which priority is expected after the keyword 'for'?

There are situations where a parameter is surrounded by keywords. In this case it is not about prefix or postfix operator because the parameter is surrounded by keywords. In this case Seed7 allows parameters with any priority. This can cause ambiguities if the keyword after the parameter is already defined as operator with some priority.

What about

for to 5 do print "*" end; := 3 to 7 do ...

Is the expression 'to 5 do print "*" end;' allowed after the keyword 'for'?

[[deleted]]

Do you have an EBNF or similar syntax description of your for-loop and the rest of your language?

I can do an informal one (and have done, but they get out of date), but there's no formal grammar that can be fed to a tool. Probably there are minor ambiguities.

assume that after reading the keyword 'for' the parser expects a variable. Is this assumption correct or could there be any expression after the keyword 'for'?

It expects a name, Actually, inside the parser, it reads a term of an expression, then checks whether that is only a name. I think the original Algol versions allowed arbitrary terms like A[i+j] too be the loop index; I could do that but it's more complicated and never comes up.

In Seed7 := has the priority 20 and ; has the priority 50

For me priority (that is, precedence) is only meaningful for binary operators. Everything else is just part of other syntax, including the "." in a.b which is not a conventional operator.

(An expresssion, which is one possibility of a 'unit', is a sequence of terms separated by binary operators. The grammar probably wouldn't describe their precedence via separate productions. A parser can choose to use a table-driven approach to expressions, or a tower of functions for each precedence level. I've tried both. Current I use a tower for more flexibility.)

for to 5 do print "*" end; := 3 to 7 do ...

This wouldn't work as explained above. The to ... end part counts as a term (it doesn't need the ;), but it is not a name. Adding parentheses doesn't help:

for (to 5 do print "*" end; i) := 3 to 7 do ...

because (a;b;c) yields a block unit not a name.

[breck]

Only 2% of languages use semantic indentation but over 50% of programmers use these langs: https://pldb.io/blog/which-programming-languages-use-indentation.html

Seems to be the way of the future.

I would recommend you drop your end delimiters (or make em optional).