>  As I understand it, the concerns revolve around performance:
>  
>     - the time that a reimplemented [clock] would require
>       for interpreter initialization.
>     - the time that a reimplemented [clock] would require to
>       scan and format times, beyond what today's C implementation
>       requires.
>     - the additional disk space, and more important, download time
>       required for the files that support l10n.
>     - the additional memory footprint required for the Tcl implementation
>       as opposed to the C one.
>  
>  These concerns appear to drive a general policy argument, "is 
>  it acceptable for core Tcl functionality to be itself implemented in Tcl?"

I didn't actually see this as a concern raised (I didn't raise
it for sure), and I think you missed the main motivation behind
my concerns.  I was thinking in terms of modularity.  L10N
stuff can grow immense in size.  Look at how large the encodings
are in the Tcl core (400KB - *compressed*).  My interest was in
seeing that the L10N part of clock could be completely optional
in a distribution, just as the extra encodings are in the core
currently.  The base implementation should function equally at
least as well as it does now, having a fallback to the base L10N
bits (just as Tcl has utf-8, unicode and iso8859-1 built in).

>  As far as the performance concerns go: No functional 
>  improvement is achievable at zero cost.  We no doubt need to 

Runtime performance was not as critical as load time performance,
but I did point out that I didn't want to see 'clock clicks'
runtime perf decrease significantly (and you mentioned that
using ensembles and such that should not be the case).  The
issue is that the 'clock' command is used as often for the
unrelated, but equally important, time measurement stuff as it
is for the scanning and formatting of human readable dates.

>  With respect to the general policy question about 
>  implementing parts of Tcl in itself, permit me also to raise 
>  a marketing issue. If Tcl isn't "good enough" to use it at 

Again, false assumption on concerns.  I'm perfectly happy with
http and related libraries.  But I also know that I can ship a
starkit, or drop Tcl onto an embedded platform, where http is
not required and nothing will break.

Jeff



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&opÌk
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core