ThePythonicCow1 (6) [Avatar] Offline
#1
From section 2.3.1:
Newline escape sequence
Newline \n is not allowed in a character literal as it may be composed of
multiple characters on some platforms. On Windows, it is \r\l whereas
on Linux it is just \r.

The line feed, aka newline, on Linux is just '\n', not just '\r'.

In other words, coming from C and Linux, I will remember to write '\l'
in Nim when I would have written '\n' in C.

For a C/Linux reader, that last quoted line above might more precisely be written as:
On Windows, it is \r\l whereas on Linux it is just \l (written in C as \n.)

I suspect that the above is a more trivial correction than would be useful
at this point ... feel free to say so if that's the case ... so that I can better
tune any further feedback that I might consider for this most excellent book.
dom96 (75) [Avatar] Offline
#2
I suspect that the above is a more trivial correction than would be useful
at this point


Nope, this is one type of feedback that I am looking for. Keep it coming!

You're absolutely right, it should be \l. I should really make it more clear by writing the name of the character as well.

Thank you for taking the time to let me know about this!
ThePythonicCow1 (6) [Avatar] Offline
#3
Ok - well continuing - you write a page or two later:
There is no way to include 3 double-quote characters in a triple quoted string literal.

Well ... there is a way ... there's always a way <grin>.

For example:

echo """hi"""""&'\x22'&"""mom"""

will produce code that writes out:
hi"""mom

But I don't have a good suggestion as to how to avoid such grungy details at this point in the book.

Perhaps adding the qualifier "convenient" would suffice, as in:
There is no convenient way to include 3 double-quote characters in a triple quoted string literal.


Or perhaps one could invoke the legalistic excuse that the above &'\x22'& is not "in" a literal (as it separates two such literals).

Or perhaps one would be better off just ignoring my fussiness ... though I will confess a fondness for writing that is both technically exact, while at the same time appearing clear and concise (a challenge not always achievable).
ThePythonicCow1 (6) [Avatar] Offline
#4
My version (Nim Compiler Version 0.12.0) of the strutils unindent() proc defaults to eatAllIndent = false, so I have to pass a "true" argument to it to get it to remove indentation, as in:
echo multiLine.unindent(true)

Even then, it does not remove leading tabs, which those of us accustomed to Makefiles and shell here documents might well consider as "indentation".
dom96 (75) [Avatar] Offline
#5
Or perhaps one could invoke the legalistic excuse that the above &'\x22'& is not "in" a literal (as it separates two such literals).


Indeed. That is what I meant. There are plenty of ways to get around not being able to include three quotes in a triple quoted string literal.

My version (Nim Compiler Version 0.12.0) of the strutils unindent() proc defaults to eatAllIndent = false, so I have to pass a "true" argument to it to get it to remove indentation


Interesting. What output do you get otherwise? Perhaps you are testing it with output that isn't the one I show in the book? As a side note: you may wish to upgrade to Nim 0.13.0.

Even then, it does not remove leading tabs, which those of us accustomed to Makefiles and shell here documents might well consider as "indentation".


True, might be an oversight in the stdlib. Possibly worthy of a bug report smilie
ThePythonicCow1 (6) [Avatar] Offline
#6
Regarding legalistic wording of the statement that you can't embed triple quotes in a triple quoted string, how about adding one word "single", as in:
There is no way to include 3 double-quote characters in a single triple quoted string literal.

That would assure us retarded retired language lawyers that you meant what you said, without unduly distracting the rest of the world.

===

Regarding the incomplete unindenting, I prepared an example that I posted at https://gist.github.com/ThePythonicCow/23ef4a1a6a4620199a78
This example shows that instead of removing the two leading spaces from the two lines " bar" and " baz", unindent only removed zero spaces
from " bar", and one space from " baz".

Is this likely a bug in Nim strutils?
dom96 (75) [Avatar] Offline
#7
You're right. I think that true must indeed be passed into unindent, this may be a bug and I will investigate. Thank you and sorry for the late reply!


Edit: Reported on Github https://github.com/nim-lang/Nim/issues/4037