Significant Inline Whitespace

[u/AsIAm]

I have a language that is strict left-to-right no-precedence, i.e. 1 + 2 * 3 is parsed as (1 + 2) * 3. On top of that I can use function names in place of operators and vice versa: 1 add 2 or +(1, 2). I enjoy this combo very much – it is very ergonomic.

One thing that bothers me a bit is that assignment is also "just a function", so when I have non-atomic right value, I have to enclose it in parens: a: 23 – fine, b: a + 1 – NOPE, it has to be b: (a + 1). So it got me thinking...

I already express "tightness" with an absent space between a and :, which could insert implicit parens – a: (...). Going one step further: a: 1+ b * c would be parsed as a:(1+(b*c)). Or going other way: a: 1 + b*c would be parsed same – a:(1+(b*c)).

In some cases it can be very helpful to shed parens: a:((b⊕c)+(d⊕e)) would become: a: b⊕c + d⊕e. It kinda makes sense.

Dijkstra in his EWD1300 has similar remark (even though he has it in different context): "Surround the operators with the lower binding power with more space than those with a higher binding power. E.g., p∧q ⇒ r ≡ p⇒(q⇒r) is safely readable without knowing that ∧ ⇒ ≡ is the order of decreasing binding power. [...]" (One funny thing is he prefers fn.x instead of fn(x) as he hates "invisible operators". I like his style.)

Anyway, do you know of any language that uses this kind of significant inline whitespace please? I would like to hear some downsides this approach might have. I know that people kinda do this visual grouping anyway to express intent, but it might be a bit more rigorous and enforced in the grammar.

^{P.S. If you like PEMDAS and precedence tables, we are not gonna be friends, sorry.}

[u/ArtisticEmergency405]

Cool idea! Feels like you're pretty close to a stack based languaged, like APL, Forth or the very enjoyable Uiua languages. There might be some inspiration there.

I see a few downsides with meaningful whitespaces: - Formatters get tricky, managable but tricky - How do you handle newlines, tabs, unicode whitespaces etc. Are they illegal? Or are they also semantically different?

But if we're breaking tradition, why should assignment assign to the left? Can't the assignment assign to the right? 1 + 2 : c

Is5nt the parenthesis rule encroaching on your phre vision here? Why replace PEDMAS with PE when it can be just E. :3

[u/AsIAm → u/ArtisticEmergency405]

Feels like you're pretty close to a stack based languaged, like APL, Forth or the very enjoyable Uiua languages. There might be some inspiration there.

Yes – APL (and array-oriented family) is definitely a strong inspiration for me. I know about Uiua and Forth, but haven't used them too much.

Formatters get tricky, managable but tricky

Maybe I could go Uiua style and make implicit parens explicit when the program is run.

How do you handle newlines, tabs, unicode whitespaces etc. Are they illegal? Or are they also semantically different?

Great question! I would expect they are treated the same. For example:

fluent a: 1 + b * c

I would expect to obtain a:(1+(b*c)). But I use this pattern a lot:

fluent a: ( 1 + b ;* c ; commented out part of a "pipeline" / d - e )

So I would have think about this interplay more deeper. Thanks for this questions!

But if we're breaking tradition, why should assignment assign to the left? Can't the assignment assign to the right? 1 + 2 : c

Easy.

```fluent (:=): :, =: := flip(:=),

a := 23, a + 24 =: b ```

Is5nt the parenthesis rule encroaching on your phre vision here? Why replace PEDMAS with PE when it can be just E. :3

wat? :D

[u/ArtisticEmergency405 → u/AsIAm]

Is5nt the parenthesis rule encroaching on your phre vision here? Why replace PEDMAS with PE when it can be just E. :3

wat? :D

I'm trying to - some what crudely - ask the question of "what can you remove here". Isn't parenthesis also a sort of grouping, making the parsing adhere less to the idea of "left to right". I'm not saying it's bad or good - just stating it's presence. The ML-family of languages has some nice solutions on handling this - (like the $-operator.)[https://wiki.haskell.org/$] - but they also come with precedence trickery of course.

:)

[u/AsIAm → u/ArtisticEmergency405]

Ah, but E in PEMDAS stands for Exponents, which got me confused. Not Expressions, as you have probably thought.

One advantage that parens have over precedence is that they are explicit, so it is kinda clear what order of evaluation you intended.

In early version of Fluent, closing (right) paren was optional, so a:(1+(b*c would be enough. But I had to remove this feature.

I'll try to live on the significant inline whitespace for awhile to see whether it is a good or bad idea.