It does make the code a little verbose, but in my experience with this (in modern Fortran), it can be rather nice.

Explicitly tagging the construct you are closing makes it easier to understand long swaths of code (where the start of a loop or function may have disappeared off the top of the page by the time you scroll to the end of the loop/function). It can also make compiler error messages more helpful.

I don't see it in the ParaSail code samples, but where this really shines in Fortran is letting you name loops. This makes the control structure much easier to understand (again, especially in longer loops). So you can have code like

    loop_timesteps: do
        ...
        loop_converge: do
            ...
            loop_actors: do
                ...
            end do loop_actors
            ...
        end do loop_converge
        ...
    end do loop_timesteps

Now to break out of a loop, you can be explicit about which one you want to break out of. Not only does that help with code clarity, it also allows you to jump out of a deeper nesting than just the immediate one, which means you don't have to set flags, or repeat tests, in order to get to where you want to go.

I realize that most programmers on HN will be thinking "if I had a loop or function that long, I would break it up into smaller functions, and express my nesting that way."

That's generally good advice, but it's not always useful in numerical code (which ParaSail seems to target).

In numerical code, you tend to run through those loops a lot of times, and you tend to have a lot of local variables (for example, in a physics calculation you might take primary variables like pressure, temperature, and mass fractions, and use them to find a lot of related values like humidity ratio and molar concentration and gradient estimates &etc). So the overhead of making large numbers of function calls with long parameter lists can become too much.

There is no doubt that ParaSail syntax is verbose, mainly because it was designed more with readability than writeability in mind. But knowing how strong are the feelings about syntax, we actually designed four different parsers (all of which are included in the downloadable release). The one we use normally is the one we wrote about, and is the most oriented toward readability. The other three have somewhat winsome names and presumably obvious connections to Python, Java, and SPARK: Parython, Javallel, and Sparkel. In fact, the ParaSail parser permits the use of Python-like syntax, with ":" instead of keywords like "then" or "loop" and no "end blah" (so long as the indentation is all copacetic), and "def" instead of "func" -- hence:

  def Sum_Of_Squares(N : Int) -> Int:

    return (for I in 1 .. N => <0> + I ** 2)

is legal ParaSail syntax. Parython uses a syntax similar to this, but with the "for loop" syntax re-arranged a bit to better match existing Python syntax.

So the hope is for folks to look a bit beyond the surface syntax, and consider the underlying semantic model, which is hopefully where the more interesting issues reside in any case.

-Tuck

Yep, and also if then, case of, end if... Hopefully an editor can color out the less relevant keywords and maybe autotype them.

It's strange that the home page of a parallel language doesn't give an example of parallel code. Check https://elixir-lang.org/ instead.

Does anybody use ParaSail here? What are its pros and cons?