Melang: An event-driven script language

by vorgio • 4 years ago

7 4 4 years ago

pmontra2• 4 years ago

I skimmed very quickly through the sections because I have little time today. One comment:

  if (conditions) {
    ...//some statements
  } fi

and the other equivalent statements without fi or without }

That last line contains so much redundancy that there should be a better way to design the statement / code block combination. Actually, any other language got it: either { } or if-fi. Even if "} fi" is syntactically correct, hide it. Do not document it, nobody will use it, nobody will be surprised or complain about it and spend time criticizing this tiny feature of the language instead of exploring the useful features.

nivertech2• 4 years ago

The first form called the "open if statement" and the second the "closed if statement".

The "open" variant is problematic once you have the "else" clause in the nested if statements, i.e. it becomes unclear to which "if" each "else" belongs, so the languages had to introduce some complex rules. With the "closed" form everything is straightforward and you don't have this problem.

The workaround in C-style languages (C/C++/Java/JS/TS/etc.) is to always put the else clause into the curly brackets, even if it's a single statement. Just to be sure put always both "then" and "else" branches into a curly brackets.

It can get even more complicated if you allow "if"-s as ternary operator inside the conditional expressions...

Another solution is merging "else if" into an "elif" keyword.

So just use "if-then-else-fi" / "if-then-else-end" with an optional "elif".

pmontra2• 4 years ago

Ruby's solution:

  if cond
    if cond
      something
  else
    something_else
  end
  end

That else belongs to the second (closest) if even if I misindent the code like that. Of course Ruby doesn't care about indentation.

Melang: An event-driven script language

Related Stories