[TCLCORE] TIP proposals

[Andreas L. <av...@lo...>]

Jeff Rogers <dv...@di...> wrote:
> * in-place modification of binary data
> An extension to the [binary] command to allow direct modification and 
> destructive scanning of binary data

I don't quite understand the "destructive scanning"...

I've become used to using the following pattern:
  set pos 0
  ...
  binary scan $data "p${pos} I" num ; incr pos 4
  binary scan $data "p${pos} a${num}" text ; incr pos $num

Removing bytes from the start or middle of $data appears to me
as necessarily worse performant.

For "overwrite"-style editing, 

  binary edit data "@${pos} Ia*" $num $text

would be a clean shortcut for

  set data [string replace $data \
                $pos [expr {$pos+4+[string length $text]-1}] \
                [binary format "Ia*" $num $text] ]

Insertion or deletion are different beasts, and I'm not 
convinced that binary was a good place for it.

Finally, a new way to specify the initial offset such as to
avoid the number->string->number detour would be nice, too.

If binary scan allowed a space between a character and its 
count, then it could be internally changed to recognize a
list of specifiers and counts and treat them consistently
as if the list were a string, just a bit faster for being
able to use some integer objects directly rather than re-
parse them from the string.
e.g.
   binary scan "abc" [list @ $pos H2] var
(currently says: missing count for "@" field specifier)


> * deprecated functionality
> 
> a compile-time flag to cause warnings or errors when functionality 
> marked as deprecated is used.

The aspect of "what is deprecated in Tcl??" has already been raised.
I've once thought about some "lint"-mode for tclsh, that would warn
about legal but heuristically dangerous code.  My pet-peeve in that
domain is words with unbalanced (and non-backslash-escaped) braces,
that only accidentally work due to the matching brace appearing 
in another word: (for proc, all words are fine, but once foo is called,
then list gets called with the kind of bad words I'm speaking of)

  proc foo {} { puts [list \ { }] }

This is *unfortunately* legal, and I'd have liked some specially lint-
enabled tclsh to barf about it, (while still doing it, anyway).

About the barfing: essentially such barfing could easily be activated
by registering a command prefix that would then be called with some
parameters(tbd), and which could do anything the developer wants it 
to do, like reporting the incident to a logging facility, or exiting 
the current process to prevent further damage from a buggy script...

some examples(alternatives) for how to register it:

   trace add debug [list mylog ...]

   trace add debug * [list mylog ...]
   trace add debug braces [list apply {args {puts stderr $args; exit 99}}]

What extra information can and should be lappended to the given
prefix is tbd.   

> * call stack is a string too
> 
> a way to serialize the current call stack and restore it in the same or 
> a different interpreter.  (probably absurdly complicated and of limited 
> utility)

I understood this as a tcl-pendant for setjmp/longjmp, but others
seem to understand it differently...

> * call chaining
> 
> A syntax extension for chaining calls together, ala jquery 
> object.call1().call2().call3() where the return from each method is the 
> object for the next chained call.  (not tclish, much simpler approaches 
> possible)

There has been some discussion about saving previous command's return
value. A patch appeared for interactive shells, where (after upvar'ing
a particular namespaced variable to e.g. "_") one could write:
% ... create ...         (returns some object)
% $_ call1  ...
% $_ call2  ...
as long as each call returns the object for the next call...

I wouldn't mind if there was some idiom to retrieve previous command's
return value for scripts. This need not be a magic variable. Could just
as well be a command [info lastresult], that could be interp-aliased to
something shorter. It just would have to work within scripts, not
just on interactive prompt.