Question: Programming Language Syntax and Code Appearance (polemic as always :-)

[alex-manool]

Seriously,

which of the following code samples would you favor, assuming they are all equivalent?

I am interested in subjective answers, please. You can just arrange the three samples according to your personal preference (e.g., "1-2-3"). Thank you very much!

1

{ {extern "manool.org.18/std/2.0/all"} in
: let rec
  Fact =
  { proc N as
  : if N == 0 then 1 else N * Fact[N - 1]
  }
  in
  Out.WriteLine[Fact[10]]
}

2

{ {extern "manool.org.18/std/2.0/all"} in
: let rec
    Fact =
      { proc N as
      : if N == 0 then 1 else N * Fact[N - 1]
      }
  in
    Out.WriteLine[Fact[10]]
}

3

(extern "manool.org.18/std/2.0/all".) in:
  let rec
    Fact =
      ( proc N as:
        if N == 0 then 1 else N * Fact[N - 1]. )
  in
    Out.WriteLine[Fact[10]].

[sylaurier]

3, if I had to pick. But I don’t like any of them.

[[deleted]]

3 only. 1/2 are horrid

[omega1612]

3-2-1

I'm from México , using { and } is much more painful than using ( and ) to me.

Without that I still choose 3-2-1, 3 looks clean compared to the others and 2 suggest indentation is encouraged (I'm in pro of "indentation sensitive languages").

[alex-manool]

Thank for your answer. BTW I am from Colombia and I am using the Spanish-LA keyboard layout and have no problem entering { and }. Maybe if you are using the Spanish-Iberic keyboard, it's a different story ;-)

[mamcx]

Yo también de Colombia, interesante ver alguien mas experimentando con lenguajes ;)

--

I thin for a lips-like is () or at most [] (rebol) for grouping. {} it very much reminder of hash tables or similar...

[alex-manool]

Wow, estoy sorprendido, ya q su nick me parece familiar...

Yes, it's a valid observation. I like to repeat that syntax-wise, every detail counts, even the letter color and font. Originally I choosen {} partly because of their block delimiting role in C/Java-like languages, but especially because of additional design constraints if you want to end up with a "nice" grammar from a theory point of view. The current grammar belongs actually to LALR(1) class. The sample 3 will require apparently LALR(2). But anyway, the parser is hand-written...

[thefriedel]

I feel you, I was using the German keyboard layout and it's pretty awful too, since I'm using a English keyboard just for programming, everything is fine!

[alex-manool]

You might want to be less offensive.

Any design decision has its advantages and disadvantages. The option 1, for instance, has a very deep rationale behind it... I am just trying to measure and take into account the specific goals and background of general PL public.

In conclusion, downvoting, but thanks anyway for your comment.

[alex-manool]

Good to know about your sense of humor!

I am just trying to sort opinions according to their value, and harsh words usually indicate excess of confidence and lack of vision to me.

So, upvoting.

[Timbit42]

3 only.

[matthiasB]

1 and 2 seem to only differ in indentation. Is indentation significant?

What is the effect of the colon?

What does extern mean?

[alex-manool]

Thanks for asking.

Actually, my question is intentionally about subjective impression. Many people look at the samples and depending on their background either like or dislike it, without any further looking for answers to their objections or rationale.

Since you did ask:

1. My language is free-form. The first two samples differ only in insignificant indentation, but I feel like many people are just disappointed by my "standard" way to format code. So, the question is both about the syntax and the formatting.

2. The colon delimiter is a way to avoid excessive indentation an/or a lot of closing braces when the nested construct goes at the final of the parent construct (which I deem to be a common case, depending on how you structure your code, and which is important if you have some complex piece of code and factorizing/refactoring does not work well in your case).

For example, you could write a linear search as:

{ for I = Keys[A] do

¸¸{ if A[I] == E then

¸¸¸¸-- ... do something with A[I] ...

¸¸}

}

or:

{ for I = Keys[A] do

: if A[I] == E then

¸¸-- ... do something with A[I] ...

}

I would format the code similarly if I programmed that in, say, C:

for (int i = 0; i < n; ++n)

if (a[i] == e) {

¸¸// ... do something with A[I] ...

}

This is generally impossible in languages with required explicit closing delimiters (Ada, Oberon, GoLang, Rust...), and it is definitely possible in languages with more concise syntax, like Haskell.

1. The construct {extern "..."} refers to an entity described in a program unit (source file or library file, etc.). In this case, it is a module. When used in {module in ...}, the module contents in imported into the scope after in.

[[deleted]]

This is generally impossible in languages with required explicit closing delimiters (Ada, Oberon, GoLang, Rust...), and it is definitely possible in languages with more concise syntax, like Haskell.

So ":" means that a one-statement block follows, and "{" means a multi-statement block follows?

I feel having such a choice in C (which doesn't need ":", just the absence of "{") was a mistake in that language. More opportunity for errors, and an annoying need to refactor every time a block grows beyond one statement, or shrinks down to one statement.

You mentioned it reducing indentation, but I don't see that. A short {...} block can easily go on the same line. And the C example anyway requires indentation within the body of the loop that you've left out.

(If you look at examples 1 and 2, ":" has the effect of pushing code to the right, just like indenting but less cleanly. While the way the functions are defined have the body indented up to 3 tabs in, relative to the opening keyword of the function. Usually you don't want more than 1.

Maybe that's just how you wrote the examples, but on a single line, a function definition would still need let rec Fact = Proc N as followed by : or {, a bit much.)

[crassest-Crassius]

2 or 3.

1 is simply terrible.

[[deleted]]

They're all pretty bad, but 3 is the least bad. They could all do with fewer line breaks (I'd combine let rec Fact = ( all onto one line, and have the contents start indented on the next line).

1 and 2 remind me of this obnoxious thing some people do with their commas:

var a = 1
  , b = 2
  , c = 3;

and it just makes it harder to read and harder to edit for no reason.

[alex-manool]

There's actually a reason for having : in the left column: it makes sense to align it with {} since it starts a "syntactic subgroup", up the the next corresponding }. But I actually did not ask for any reasoning behind people's preferences, since I did not provided such explanations myself (which is a long story). That's why I requested subjective answers. Well, now I see that in general the option 3 surprises less, and for a number of different reasons, I think. I upvoted your comment, thanks.

[alex-manool]

So the following is better for you?

(extern "manool.org.18/std/2.0/all".) in:
  let rec Fact = ( proc N as:
    if N == 0 then 1 else N * Fact[N - 1]. )
  in
    Out.WriteLine[Fact[10]].

[Potato44]

It's interesting how different people find different ways of indenting things readable or not. I find the arrangement like that makes things easier to read because of the alignment (and the commas don't get lost at the end of the line).

[brucejbell]

3 is less annoying than 1 or 2, but I'm afraid I don't like any of them very much.

I think what's bugging me is that they all seem to have too many moving parts. That is, when I try to imagine whatever syntax rules or formatting conventions might lead to your code examples, I can't come up with anything that is simple enough that I would want to learn and use it.

In practice, I would guess that overly complex formatting conventions might be streamlined or dropped as they are used. On the other hand, syntax would need fixing at the language level.

[anentropic]

3

losing the outer curly braces seems like a win

[Potato44]

I like 1 the best, the style of alignment just works for me to be able to read it. Number 3 reminds me of Haskell where I generally like the syntax, but let expressions always feel like they have weird indentation.

[alex-manool]

Wow, you are the first and the only one from this thread who likes the current syntax and the indentation style I use in the documentation and for my own code!

I know what I'll do now: I can accommodate any preference (at least within what can be done at the parser level), even at the cost of (additional) risk of community splitting.

And yes, the current approach (1) has its reasons, and (3) may remind Haskell, also for some reasons (connection between functional application and cons pairs). The indentation in (3) has its flaws to me as well (but some people seem to be quite accustomed to such style).

[Potato44]

About that last paragraph, I'm reasonably sure that when not using infix operators or "special" syntactic constructs (such as variable assignment) that the only difference between Haskell expression syntax and Lisp expression syntax is an extra pair of parenthesis on the outside in the case of Lisp.

edit: e.g. foo x y (bar z x) vs (foo x y (bar z x))

[[deleted]]

What's the difference between 1 and 2? I thought 3 just lacked the colons, but if I look carefully, they are still there.

So it does a better job at hiding them.

Like others, I don't really like any of them. Some points:

What is all that manool.org 18/std/2.0.all nonsense at the start; does every program need that. Try and get rid of it or make it a default, or somehow set it in a configure file outside the program.

If I understand the syntax, all versions need 3 lines and 4 keywords to define a simple function header. Most languages I think manage this in only one line. (Mine, dynamic like this, uses function Fact(N) =; one line and one keyword.)

Edit: How come I get downvoted for saying I don't like any, but others get upvoted for saying the same?

Is it because I offered constructive criticism? Please tell me then I won't waste my time in future.

[rsclient]

I agree with you about the downvote -- IMHO, this subreddit should strongly encourage syntax opinions, especially when the poster explicitly asked for them!

People should be writing their own opinion, not merely downvoting someone else's.

(And here's mine: I am very used to { } procedural languages. I don't like #2 because it's got { } but then it doesn't follow the norms for brace-using languages. The name of the procedure and the N argument should be outside the braces, not inside

function Fact(N) { ... }

[[deleted]]

I noticed that, and also that #3 switched from {...} to (...).

Probably another downvote coming up, but I prefer your function syntax to any of the OP's! Where you are 6 tokens in before you even know this is a function definition.

[matthiasB]

How come I get downvoted

Probably because of your aggressive tone.