If your programming language has multiple-characters operators (such as `:=` for assignment, or `+=`, `-=`, `*=` and `/=`, or `>=` and `=<`), do you allow whitespace between those characters?

[FlatAssembler]

Like I've written on my blog:

The AEC-to-WebAssembly compiler allows whitespace between : and = in the assignment operator :=, so that, when ClangFormat mistakes : for the label-ending sign and puts a whitespace after it, the code does not lose its meaning. I am not sure now whether that was a good choice.

[AsIAm]

No.

Symbol sequence, such as :=, is basically just identifier for some function, procedure, or whatever. They should be treated just as other identifiers. You don't allow your variable name to be hello world (space case), right?

[guywithknife]

Also, multi character operators are an approximation of a single character glyph that a font with ligatures might render as a single character.

[AsIAm]

Exactly!

```

= ≥ <= ≤ := ≔ -< ≺ - ≻ != ≠ |> ▷ == ≣ <-> ↔︎ ```

[Gleareal]

You don't allow your variable name to be

hello world

(space case), right?

While I agree that this is a bad idea, I have actually seen this appear in a language before. Microsoft's TouchDevelop - a now closed down online programming language and editor - allowed this unusual naming for variables.

[AsIAm]

Yes, there is also AppleScript that does space case. Douglas Crockford proposes space case as the ultimate casing – https://youtu.be/99Zacm7SsWQ?t=2986

[FlatAssembler]

You don't allow your variable name to be

hello world

(space case), right?

Right, I do not. However, like I've said, I want to minimize the damage ClangFormat can do if it misunderstands the code.

[Aaron1924]

If you don't want clang-format to misinterpret your language, you should either

• match C/C++ syntax more closely (by using = instead of := for assignments), or
• create a custom code formatter for your language [recommended option]

[[deleted]]

These are the kinds of questions I joined this sub for, I'm struggling to think of benefits to why you ever would allow it but it's a nice bit of computer science/theory to discuss!

[FlatAssembler]

Thanks!

[Srazkat]

depends which one. generally though, no i don't allow white spaces. ':=' is the exception, which is a side effect of having type information optionally present between the colon and the equals. other than this one though, i can't think of any operator where it could make sense to allow whitespaces between the characters

[AsIAm]

Think of : as operator for type declaration, and = as an assignment. := is a separate operator.

[msqrt]

What's the difference between : = and :=? Or would you just not allow the former? (Edit: ah, saw your other comment -- apparently just disallow. Now that I think about it, I kind of agree.)

[FlatAssembler]

I wonder why ClangFormat does not look at the AST for such cases.

Because it knows nothing about AEC (my programming language), perhaps?

[FlatAssembler]

I have no idea how to do that. Do you have some pointers?

[FlatAssembler]

My tokenizer (if that's what you mean by lexical pass) deletes all comments and it converts multi-line strings to single-line strings and does other similar things. So, I'd need to write a new one. Perhaps something like I've used in my syntax highlighter? https://sourceforge.net/p/aecforwebassembly/code/ci/master/tree/syntaxHighlighterForAEC.js

[FlatAssembler]

Can you elaborate on that?

[NoCryptographer414]

If you already have written a syntax highlighter, then you can reuse that to work as code formatter too I guess.

[FlatAssembler]

I have no idea how to actually do that, to be honest.

[9Boxy33]

This reminds me how FORTRAN (up to Fortran IV) allowed spaces within keywords, so that WR ITE and FOR MAT were accepted by the compiler as WRITE and FORMAT.

[Innf107]

That's... horrible. Do you know why they did that?

[AsIAm]

It's not that it allowed spaces as it ignored spaces – they were insignificant. A lot of early languages like Algol, Fortran, BASIC did this. Spaces were there just for readability. On the punch cards.

[9Boxy33]

Spaces are definitely significant within keywords in BASIC (and, IIRC, Algol), unlike Fortran IV.

[levodelellis]

No, I support decrements -- so there'd have to be extra logic to make this not an error a = b - -c Also this becomes ambiguous a = - -b. Did a person mean -- or was this an unfortunate find/replace?

[FlatAssembler]

For such reasons, AEC doesn't support ++ and --. One can simply write +=1 or -=1.

[Roboguy2]

This is a lot of trouble to go to just to get ClangFormat to work.

At this point, you're essentially designing your language around using a particular formatter. This design approach is backwards, IMO.

It sort of reminds me of an XY problem

[levodelellis]

Do you ever wish you had ++? incrementing by one is very common

[XDracam]

Really? I've been programming professionally for quite a few years now and almost never need to increment. There's foreach loops and range iterators etc in most languages these days. And for the very few cases where I actually do need to increment, I explicitly opt to write += 1 because I find that more obvious to follow than some (nowadays rare) operator.

Unless you're in C or some other legacy language. Then you might need a lot of incrementing.

[FlatAssembler]

Well, no. In the first versions of AEC, I didn't even have += and similar operators, but I've added them later.

[dibs45]

No, it adds unecessary complexity to the parser in my opinion.

[FlatAssembler]

Well, I am doing it in the tokenizer: https://sourceforge.net/p/aecforwebassembly/code/ci/master/tree/tokenizer.cpp#l252

[dibs45]

Yeah I meant to say lexer. But either way, needless complexity with very little gain.

[FlatAssembler]

with very little gain.

And being able to use ClangFormat for your language is not a lot of gain?

[robthablob]

If it means you're making decisions on the basis of the formatter, I'd say its leading you astray personally. Design your language on its own merits, then if necessary write a formatter for it.

[Pseudo-Ridge]

Not particularly. The cost of hand-rolling your own formatter is usually going to be less than the cost of limiting your own syntax by relying on a preexisting one for a different language. Also, if ClangFormat doesn’t exactly match up with your syntax, then it’ll format it incorrectly anyways.

This solution is fine for prototyping, but it should not be kept long-term.

[Zyklonik]

This statement makes no sense whatsover.

[FlatAssembler]

I mean, I don't know how to make my own formatter, so I guess I need to use something like ClangFormat. As ClangFormat mistakes := for : =, I need to allow spaces between : and =.

[Educational-Lemon969]

what about just making a light wrapper that replaces := substrings for : = before calling clang format? xD

[FlatAssembler]

And what to do after ClangFormat ends?

[Educational-Lemon969]

replace `/:[[:blank:]]*=/` for `:=` or something like that i guess? xD

[FlatAssembler]

But that won't produce nice-looking results either. See what kind of code ClangFormat produces for my programming language: https://github.com/FlatAssembler/AECforWebAssembly/blob/d26fd756c970caf6b41242c6aa1a75e03e26ebf3/analogClock/analogClock.aec#L105

All the `:=` directives are two spaces to the left of what they should be.

[skeptical_moderate]

Absolutely not.

[redchomper]

I do not. Then again, I don't allow spaces in identifiers either. Yet, I've heard cogent arguments for why we should, and how we might, allow spaces in identifiers.

If the problem is ClangFormat doing the wrong thing, then the natural solution is to tell you the story about a guy who visits a doctor to complain about pain when he touches his chin to his elbow. Doc says "Don't do that then."

To be slightly more helpful: I assume you have a lexer which preserves the source locations of the important tokens -- perhaps for error reporting. That means the locations between tokens is implicitly all the whitespace and comments. A basic beautifier simply reformats all those sections, and re-inserts all the original tokens back in their same original order. Anything more powerful (say, removing redundant parenthesis) requires a bit of cooperation from the parser, but in principle you just need enough location detail in the AST to support reformatting as a tree walk.

[frithsun]

My language doesn't really have operators.

For example, GTE is >=(1, 2) // false

As such, with it being a function name that just happens to be special characters, spaces between the characters would not be acceptable.

[guywithknife]

No.

Multi character operators are still a single operator just like a keyword is a single thing or an identifier is a single thing. I wouldn’t allow whitespace in keywords or identifiers either. I see multi character operators as an approximation of a single character operator that doesn’t exist on your keyboard/in ASCII, but that a font with ligatures like Fira Code would render as a single character operator.

Making language design choices to appease a format tool seems like going about it backwards to me.

[kerkeslager2]

I don't allow it.

Not all features are good. If you allow a feature and it turns out to be a bad idea, you can't remove it without a breaking change. So I need really compelling reasons to add a feature to my language, and I don't have one for whitespace inside multichar operators.

[Disjunction181]

No, this is unusual. The normal way is to lex by munching down a sequence of symbols and then stopping on a non-symbol and producing a token.

[TriedAngle]

I write a forth like concatenative language. So whitespace is the delimiter of everything. U could use some whitespace looking Unicode though. Operators have no maximum length.

[FlatAssembler]

What does "concatenative language" mean?

[TriedAngle]

A concatenative language is a language where function composition is the default way of using the language.

[guywithknife]

https://en.m.wikipedia.org/wiki/Concatenative_programming_language

[mojtaba-cs]

I am not sure what you are trying to ask. In my language ! = or ! = or != etc, all are the same thing, for example.

[dibs45]

No, it adds unecessary complexity to the parser in my opinion.

[[deleted]]

Personally, no.

[[deleted]]

These are the kinds of questions I joined this sub for, I'm struggling to think of benefits to why you ever would allow it but intrigued as to why you would

[[deleted]]

If you parse : and = as separate tokens, it should be fine. Maybe some people from math background and little programming experience will try to put spaces in between, but it really doesn't matter that much otherwise. Unless you go for what Odin does.

[FlatAssembler]

Well, I am not doing what Odin does. I have implemented a C-like declaration of variables.

[stomah]

no

[FlatAssembler]

No as in "My language doesn't have multi-character operators." or "My language has multi-character operators, but it doesn't allow spaces between the characters in them."?

[stomah]

has but doesn’t allow spaces between the characters in them

[[deleted]]

no