From: gwlester@cpu.com (Gerald W. Lester)
Subject: Re: Planning for Tcl 7.0
Organization: Computerized Processes Unlimited, Metairie, LA, (504)-889-2784
Date: Thu, 8 Oct 1992 14:34:20 GMT
Reply-To: gwlester@cpu.com

I have no problems with any of the changes.   However, I would like to voice
support for some of them:

In article <1avu22INN5ao@agate.berkeley.edu>, ouster@sprite.Berkeley.EDU (John Ousterhout) writes:
> ...
>3. Clean up backslash processing in several ways:
>    - Change backslash-newline to eat up all the whitespace following the
>      newline and replace the sequence with a single whitespace character.
>      Right now it only eats up the newline character and replaces it
>      with an empty string.  Rationale:  this would be more consistent
>      with other programs that process backslash-newline sequences.

	YES!!!!

> ...
>    - Change \x (where x is not one of the characters that gets special
>      backslash treatment) to expand to x, not \x.
>      Rationale: the current behavior is inconsistent with all other
>      programs I know of that handle backslashes, and I think it's
>      confusing.

      	YES!!!!	YES!!!!	YES!!!!	YES!!!!

>...
>4. Change "regsub" so that when no match occurs it sets the result
>variable to the original string, rather than leaving it unmodified.
>Rationale:  the current behavior results in extra tests of the regsub
>result that could sometimes be avoided with the proposed new behavior.
>I doubt that there's much code that will break with the change (this
>would have to be code that depends on the result variable *not* being
>modified).

	Suggestion, make this an option (i.e. "-setvar")

>...
>6. Change glob to return only the names of existing files.
>Rationale:  at present "glob */foo" expands * and generates a result
>without checking to see if each directory has a "foo" file in it.  This
>makes the current behavior incompatible with csh, for example.  One
>question is whether constructs like "glob {a,b}.c" should also check for
>the existence of each of the files.  At present they don't (i.e. a.c and
>b.c will be returned even if they don't exist), but neither does csh.  My
>inclination is to make the behavior match csh (names containing *?[] are
>checked for existence, others aren't).  I'd be interested to hear
>opinions on this one:  check all names for existence, check only names
>including *?[] (for csh compatibility), or keep it as it is?

	Always check!

>7. Change "gets" so it returns 1 for success and 0 for failure.  At present
>it returns the line length for success and -1 for failure.
>Rationale: this would allow slightly simple Tcl scripts:  you could just
>say
>    while [gets $f line] {...}
>instead of
>    while {[gets $f line] >= 0} {...}
>I'm not really convinced that this one is important enough to justify the
>incompatibility, so it won't take much negative feedback to kill it.
>

      	YES!!!!	YES!!!!	YES!!!!	YES!!!!
	While it is *not* C like.  It *IS* much more tcl like in flavor.

>....

	How about the recent discussion (it was on tk but..) on adding a file
handler.  That is, being able to set up a procedure to automatically get called
when input is ready on a file.

==========================================================================
* Gerald W. Lester                        !   Voice:  (504)-889-2784     *
* Computerized Processes Unlimited        !   FAX:    (504)-889-2799     *
* 4200 S. I-10 Service Road, Suite #205   !   E-Mail: gwl@cpu.com        *
* Metairie, LA  70001                     !                              *
==========================================================================