Raw string statement (proposal)

[bartc]

On 25/05/2018 05:34, Mikhail V wrote:

> Proposal
> -----------
> 
> Current proposal suggests adding syntax for the "raw text" statement.
> This should enable the possibility to define text pieces in source
> code without the need for interpreted characters.
> Thereby it should solve the mentioned issues.
> Additionally it should solve some issues with visual appearance.

> General rules:
> --------
> - parsing is aware of the indent of containing
>    block, i.e. no de-dention needed.
> - single line assignment may be allowed with
>    some restrictions.
> 
> Difficulties:
> --------
> - change of core parsing rules
> - backward compatibility broken
> - syntax highlighting may not work

I had one big problem with your proposal, which is that I couldn't make 
head or tail of your syntax. Such a thing should be immediately obvious.

(In your first two examples, what IS the exact string that you're trying 
to incorporate? That is not clear at all.)

The aim is to allow arbitrary text in program source which is to be 
interpreted as a string literal, and to be able to see the text as much 
in its natural form as possible.

One problem here is how to deal with embedded non-printable characters: 
CR, LF and TAB might become part of the normal source text, but how 
about anything else? Or would you only allow text that might appear in a 
text file where those characters would also cause issues?

Another thing that might come up: suppose you do come up with a workable 
scheme, and have a source file PROG1.PY which contains such raw strings.

Would it then be possible to create a source file PROG2.PY which 
contains PROG1.PY as a raw string? That is, without changing the text 
from PROG1.PY at all.

Here's one scheme I use in another language:

    print strinclude "file.txt"

'strinclude "file.txt"' is interpreted as a string literal which 
contains the contents of file.txt, with escapes used as needed. In fact 
it can be used for binary files too.

This ticks some of the boxes, but not all: the text isn't shown inline 
in the program source code. If you send someone this source code, they 
will also need FILE.TXT.

And it won't pass my PROG2/PROG1 test above (because both strincludes 
need expanding to strings, but the compiler won't recognise the one 
inside PROG1, as that is after all just text, not program code).

As for a better proposal, I'm inclined not to make it part of the 
language at all, but to make it an editor feature: insert a block of 
arbitrary text, and give a command to turn it into a string literal. 
With perhaps another command to take a string literal within a program 
and view it as un-escaped text.

-- 
bartc