For what it is worth, we're byte coding the following in L and I see no 
reason the code couldn't be used by tcl.  We overload L's foreach so
that

	string	c, buf, lines[];
	int	i, vector[];
	float	f, floats[];

	foreach (c in buf)	// char by char iterator
	foreach (buf in lines)	// line iterator
	foreach (i in vector)
	foreach (f in floats)

Only the char by char one is unimplemented.  If you guys are going to do 
one we'll use yours or we can do it and you can use ours.  Seems silly
to do both, right?

On Sun, Apr 27, 2008 at 02:48:30PM -0400, Kevin Kenny wrote:
>  Trevor Davel wrote:
>  > Perhaps I do have a suggestion: a "string foreach c $str $startofs 
>  > $endofs { ... }" would be the equivalent of the for/string-index 
>  > approach but not suffer from having to do a 'string index' on each 
>  > iteration.  And a way to provide a hint about the expected size of a 
>  > non-shared string may also help?
>  
>  I like the [string foreach] idea, particularly now that we have
>  extensible ensembles. (I'm not sure without source-diving whether
>  [string] is broken into an ensemble yet, but that's in the plan.)
>  An extensible [string] ensemble would mean that [string foreach]
>  could be piloted as an extension and then tracked into the Core.
>  
>  The chief problem with the approach of piloting it as an extension
>  is that it wouldn't get the full performance of a Core implementation,
>  because to get the utmost performance, the bytecode compiler needs
>  to be aware of it.  Otherwise, the 'script' argument in
>       string foreach $varname $string $script
>  would not have access to the local-variable table, which is one
>  of the chief benefits of bytecoding.
>  
>  On the other hand, Miguel says he's working on *that* problem; he
>  has some ideas for how to make code embedded in an [uplevel]
>  (which is essentially what is going on with the 'script' argument)
>  as fast as code inside a 'proc'.  Between a fast [uplevel]
>  (or, equivalently, a fast Tcl_EvalObjEx) and extensible ensembles,
>  spike solutions for this kind of problem should get to be
>  easy to implement.
>  
>  I'm eager for this for other reasons, as well. (I'm working
>  on TIP #308, and the 'foreach' and 'transaction' methods on
>  TIP #308 objects need it badly.) So I can easily see a [string
>  foreach] fitting into the roadmap quite nicely.
>  
>  -- 
>  73 de ke9tv/2, Kevin
>  
>  
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
>  Don't miss this year's exciting event. There's still time to save $100. 
>  Use priority code J8TL2D2. 
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  Tcl-Core mailing list
>  Tcl-Core@[...].net
>  https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core