Re: [TCLCORE] Re: Notes about Perl6 ideas - good to read

[Andreas K. <a.k...@we...>]

--------; charset=us-ascii

> Also sprach Jeffrey Hobbs:
 
>> ...  Sure, Tcl is great as it is, but for a lot of people its only
>> great when they have itcl, blt, tix, patches for better C++
>> compatibility, more data structures, etc etc.  Fewer and fewer are
>> truly satisfied with what the "core" provides.

> This is just slightly off the point, but I don't understand this
> last couple of sentences.  It seems like you are implying that the
> fact that the core of Tcl, by itself, is an incomplete solution for
> most complicated tasks is a bad thing.  Is that right?
 
> I thought the aim was to get more stuff out of the core (making it
> thereby even LESS satisfactory by itself) and then making the
> process of acquiring & deploying extensions so easy that you would
> never hesitate to do so...  That is still our goal, right?

I can't speak for the others, but for me this is one of the goals to
pursue and quite high on the priority list.


> As for introducing backwards incompatibilities, I agree with Brent a
> bit that we should not break Tcl compatibility unless there is some
> really compelling need.  I don't see any evils of the Tcl language
> that we are likely to cure in a good way (as opposed to, for
> instance, introducing some other comment syntax that breaks the
> current Tcl mold), that would require backwards incompatilibilities
> at the syntax level.  But in any case, this should be approached
> with some caution.

As can be seen in the discussion on c.l.t about {}$ and {}[ by Paul
Duffin.  I certainly like the basic idea behind that but the chosen
syntax was something which felt like syntactic salt to me (in opposition
to the syntactic sugar Richard Suchenwirth is so fond of).

> It would, on the other hand, be nice to rearrange some of the
> commands to be a little more coherent.  It would be good to gather
> all the list commands together,

Part of that is already done through the 'listx' command.

> and maybe even make the open & socket commands return objects, so we
> can get rid of this horrible mess of fconfigure, fblocked, eof...
> But I don't think that any of the subsystems are so badly designed
> right now that we couldn't provide wrappers for the old syntax...
 
> As for C level changes, this should really be a community vote type
> thing.  We need to balance the desire to clean up & make more
> powerful the new internals that were introduced in 8.0 & friends,
> with the need to carry along most of the major extensions.  So
> before we start wholesale changes like this, we should have a
> discussion of the merits, and make sure we have easy transition
> paths for all the many bits of C code out there...
 

-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------