NEW-LINE Semantics, and NEW-LINE + INFIX functions

Development Semantics
1

Newline semantics are a tricky idea in general.

I keep thinking that it's likely best if there is a generic line-continuation tool in the scanner.

Maybe it's backslash. The point is that backslash would not be something that would be LOAD-ed as a token, rather it would just act at scanner time:

>> transcode "a b^/c d"
== [a b
    c d]

>> transcode "a b \^/c d"
== [a b c d]

>> transcode "a b^/\c d"
== [a b c d]

So you could write it either way:

a b \
    c d

a b
  \ c d

In the model I'm contemplating, you'd still be able to use a GROUP! to continue an evaluation on another line:

x: (
    1000 + 20
)

But this would no longer be legal:

x:
    1000 + 20

You'd have to say:

x: \
    1000 + 20

x:
  \ 1000 + 20

Don't Like It? Dialect It.

You'd be free to interpret newline markers as you like in your own dialects.

 my-dialect [
     x: 
         1000 + 20
     nothing <stopping>
     you :FROM @doing what
     
     -ever- you want
 ]

Custom indentation is lost on loading, but BLANK! lines would be preserved

Inching Toward This, Bit By Bit...

I've been making rules about NEW-LINE markers. One thing is that if a function like RETURN or CONTINUE or QUIT are willing to take 0 or 1 arguments, then when it does take 1 argument that can't come from across a newline.

Another rule that seems to feel pretty sensible is don't allow infix across newlines.

But I anticipate that as these rules are converging on the likely-inevitable "arguments to a function can't span a newline (unless you put the argument in a GROUP! that starts before the newline)

1 Like
2

This has a performance advantage as well. In historical Rebol, if you see

x: 10
...whatever...

There's a lookahead step that considers ...whatever..., in case it's:

x: 10
+ 20

If we rule that out, we speed things up.

But It Would Rule Out ELSE/THEN on newlines...

You'd have to write this:

if condition [
   ...
] else [
   ...
]

And you wouldn't be allowed to write this:

if condition [
   ...
]
else [
   ...
]

That's a slight bummer. The new rules regarding BLANK! lines would still disallow:

if condition [
   ...
]

else [
   ...
]

And I'm fine with that being disallowed. But being able to separate an ELSE by a single line break has a nice aspect in that you un-crowd things:

if condition [
   bunch of code here
] else [
   bunch of code here
]

if condition [
   bunch of code here
]
else [
   bunch of code here
]

Not that you would want to use parentheses, but I'll point out this is a case where you couldn't use parentheses to get your newlines because that would block the visibility of the ELSE to infix lookahead:

if condition [
   bunch of code here
] (
    else [
       bunch of code here
   ]
)

Your only option would be the backslash:

if condition [
   bunch of code here
] \
else [
   bunch of code here
]

if condition [
   bunch of code here
]
\ else [
   bunch of code here
]

I don't actually think the first form of that looks so bad. Arguably it helps you realize the next thing is infix (with ELSE you know, but maybe other functions aren't so obvious if you don't know them)

I think the benefits of the "no-newlines in mid expression unless mitigated by lists" rule outweighs the advantages of newlined ELSE/THEN.

1 Like
Iterating "NEW-LINE" Markers (and BLANK! Lines)