On Sun, 17 Mar 2002 16:36:06 -0700, Nathan Torkington <[EMAIL PROTECTED]> wrote:
>While "well-developed" may be a matter of opinion, "it is rarely done >in practice" is nothing but a steaming pile of horseshit that makes me >wonder at the balls they must have to tell such an enormous lie. I >wonder how Activestate could fail to have heard of CPAN. Probably the >same way perl.com failed to hear of Tcl 8 :-) Please note that http://tcl.ActiveState.com is a Tcl community site that is just being hosted by ActiveState since the Scriptics site disappeared. The content is *not* generated by ActiveState, but by the Tcl developer community. Please address any concerns to [EMAIL PROTECTED] As to the discussion at hand, I think it all depends on what your understanding of "language extension" is. In Tcl it is trivial to implement your own switch statement (if it didn't already have one), or other control construct, probably even without going to the C level. Of course this is simple in Tcl for exactly the same reasons it is simple in Lisp or Forth: the language structure itself is extremely simple. For example, assuming Perl didn't have "unless", you can't just define it like this: sub unless { my ($cond,$block}; eval $block if not eval $cond; } unless (defined $foo) { # do something } and expect it to work. In Tcl you can (and it does work). So I think it is fair to say that it is easier to extend the *language* in Tcl than it is in Perl (source Filters are just a kludge IMO). If this is really relevant in practice is a different thing. I personally haven't tried to embed a Tcl interpreter into another program, but I do believe the claim that that is easier with Tcl than with Perl too. Tcl has been designed as an embedded "Tool Command Language", not as a stand alone interpreter. I would still prefer Perl over Tcl (most) any time, but to pretend that everything the Perl developers did is superior to how the Tcl developers did things is just nonsense! Cheers, -Jan
