Re: backslash-newline substitution (was: Re: Strange behaviour of proc command !)

On Oct 10, 11:08 am, "tom.rmadilo" <tom.rmad...@xxxxxxxxx> wrote:
On Oct 9, 4:32 am, Andreas Leitgeb <a...@xxxxxxxxxxxxxxxxxxxxxxxx>
wrote:



Andreas Leitgeb <a...@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
- braced blocks that are evalled still have their b-n's substed,
    and commands split on multiple lines work just the way they
    do now
- braced blocks that are not (yet) evalled retain their b-n's.

I noticed some possibly misleading formulations in my post:

set a {puts \
       foo}; #  $a would contain the backslash-newlines.

eval $a ;#  no change here: eval *already!* does care for b-n itself.

# afterwards: a is still the same as before eval.  (that's logical,
#  but from my previous wording, one could absurdly think I meant
#  to modify the value of $a during eval.  Not!)

I've been somewhat confused by this thread. Here is the exact language
concerning what you call backslash-newline. Actually, you left off an
important part, the following whitespace. Anyway, from the Tcl
manpage:

\<newline>whiteSpace
    A single space character replaces the backslash, newline, and all
spaces and tabs after the newline. This backslash sequence is unique
in that it is replaced in a separate pre-pass before the command is
actually parsed. This means that it will be replaced even when it
occurs between braces, and the resulting space will be treated as a
word separator if it isn't in braces or quotes.

My guess is that this rule solves a number of problems which if "un-
solved" would slow down parsing and make list normalization difficult.

First, line ending sequences are different on different platforms, so
detecting the end of lines is something which can't be done as easily
as processing all other characters. But end of line detection is key
to Tcl syntax, also Tcl translates line ending sequences when reading
data. This has nothing to do with parsing Tcl code. If you use [gets],
the end of line chars are removed.

That could explain the pre-pass, removing the newline, thus continuing
the line.

But why is the following whitespace collapsed into one space?

My guess is that it makes it easy to construct relatively normalized
lists.

But to understand this, it is first important to realize that the
programmer has just inserted a line continuation sequence. Why would
she do that if the desire is to produce an exact text? She just
inserted a text transformation/replacement sequence indicating that
the line actually isn't ending. It is hard to think of a use case
outside of programming code where you would use a line continuation.
You don't need line continuations in natural language text, and even
if you do, there are not many examples of multiple whitespace chars in
natural language. But there are some. You can insert them using escape
sequences: \r \n \t. So we have eliminated any problems with
reproducing exact text when we need that. Why collapse the following
whitespace into a single char?

% set a [list a\
              b\
              c\
              d]

If we create a Tcl source file send it to a friend to edit in their
editor, save it, send it back to us, it is very likely that the
indentation will get changed, maybe to tabs or spaces from tabs, or
some combination. However, we know that the first time Tcl reads in
this code, a gets set to this value 'a b c d'. That is somewhat
important if you want to use a as part of another list, and then
search for members of the larger list that fit a pattern "a b * d".

Now try creating the same list without line continuations:

% set a {a
         b
         c
         d}

This is still a four member list, which works as expected for most
list operations, but it would fail with the pattern search. According
to the rule in question, I could change this just a little and ensure
an exact result:

% set a {a\
         b\
         c\
         d}

The suggestion is that this should no longer work. The value of a is
not code, it is just a list (or is it?). Of course, data has a
structure as well, not just code. And the structure of data is just as
critical in programming as the code itself.

It is really hard to see why this is a bad rule.

It's especially hard to see if one disagrees :*) I notice it took
about a 100 lines of discussion and a "...my guess is..." sentence to
make
your case. Well, for my part I use \ in order to wrap long messages
and
I do it at a word boundary so the single space is exactly what I want.
Guessing the reason for features is unpersuasive.
.

Relevant Pages

  • Re: Reinventing the iterator
    ... RST returns the rest of the sequence (lazily) ... The main purpose of SEQ is to give the ability to iterate over various ... just use lists (it's the most simple and ...   "The analog of DOLIST for any collection COLL, ...
    (comp.lang.lisp)
  • Re: backslash-newline substitution (was: Re: Strange behaviour of proc command !)
    ...     and commands split on multiple lines work just the way they ... Anyway, from the Tcl ... lists. ... programmer has just inserted a line continuation sequence. ...
    (comp.lang.tcl)
  • TIP #225: Arithmetic Series with Optimized Space Complexity
    ... This TIP proposes to add a new command to generate arithmetic sequences ... The only change from the point of view of the Tcl ... initialized to the first element of the sequence, ... Infinite series and series resulting in lists bigger than the maximum ...
    (comp.lang.tcl)
  • Re: Newbie Question on LaTeX 3 Programming
    ... the documentation is not all written in the same way. ...   at least in comparison with LaTeX 2e. ... Most of the time, token lists are ... - When the stored material might contain # tokens ...
    (comp.text.tex)
  • Re: Choice sequence lessons.
    ... and that their right is just as good as the orthodox mathie. ... a whole system of *generating* a sequence. ... interpretations of things - the difference ... vs     NOT ANY of the students will pass. ...
    (sci.logic)