REBOL3 tracker
  0.9.12 beta
Ticket #0002210 User: anonymous

Project:



rss
TypeWish Statussubmitted Date30-Mar-2015 05:32
Versionr3 master CategoryUnspecified Submitted byfork
PlatformAll Severitymajor Prioritynormal

Summary No invisible whitespace in strings
Description (Please see also #2211 for another related issue)

One thing that has arisen out of viewing code on the web is to emphasize a point that is true about viewing it on paper: you can't really tell where the invisible whitespace is.

{This line has no spaces after the period.
This line has a bunch of them.        
    Did this line start with a tab or spaces?
}

In working with the domain of UTF-8 input for programs, it would seem that putting in a rule that strings must escape any invisibles that are not spaces would give pretty good coverage most of the time.

The next rule could say that the last visible character on a line represents the end of that line. A caret could indicate the end of a line with spaces:

{This line has no spaces after the period.
This line has a bunch of them...        ^
...and this continues the previous line, by default
}

If someone wanted a line break as well, they could use ^_ to escape the last space in the series. Or if they wanted all the spaces to be unescaped, they could escape the line feed instead, and then follow it with a joining caret as ^|^ (or its legacy equivalent ^/^)

Any spaces after a terminal caret would be ignored, and any non-space characters would be illegal.
Example code

			

Assigned ton/a Fixed in- Last Update31-Mar-2015 05:40


Comments
(0004619)
rebolek
30-Mar-2015 14:45

I do not think that this should be handled at Rebol level. Text editors can show "invisible" whitespaces, this looks like unnecessary complication.
(0004625)
fork
31-Mar-2015 05:07

As mentioned in chat, the problem with having each programmer invent a way to handle this are many:

* MOLD-ing or other source-generating functions...that want to obey indentation and "pretty-print"...will not be able to do so. Strings will have to be left as-is due to lack of awareness of whether the programmer intended the spaces to be stripped or not.

* Concern about efficiency and programmer reluctance to lay out the code in the clearest way possible due to memory usage and churn. Formatting to make the clearest program becomes a slave to runtime efficiency concerns; as if we had to worry about how we indented code because of cost and everything were slammed to the left (or on one line)

* Each person re-inventing the escaping and stripping in their own unique way, rather than having a well-thought out standard that everyone can take for granted.
(0004628)
rebolek
31-Mar-2015 05:24

"Each person re-inventing the escaping and stripping in their own unique way..."

There is TRIM for stripping. I'm not saying that TRIM is perfect, but why to reinvent the wheel instead of fixing/improving existing tools?
(0004629)
fork
31-Mar-2015 05:40

@rebolek Please see #2211. There simply is no existing tool and cannot be--developers cannot supply strings that MOLD can output "nicely". That ticket is the more important one, but this issue of eliminating invisibles besides space and making terminal line spaces apparent if they have meaning is "forward-looking".

Date User Field Action Change
31-Mar-2015 05:41 Fork Comment : 0004629 Modified -
31-Mar-2015 05:40 Fork Comment : 0004629 Added -
31-Mar-2015 05:38 Fork Description Modified -
31-Mar-2015 05:24 rebolek Comment : 0004628 Added -
31-Mar-2015 05:07 Fork Comment : 0004625 Added -
30-Mar-2015 14:45 rebolek Comment : 0004619 Added -
30-Mar-2015 05:43 Fork Description Modified -
30-Mar-2015 05:33 Fork Description Modified -
30-Mar-2015 05:33 Fork Description Modified -
30-Mar-2015 05:32 Fork Ticket Added -