tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Will D. <wi...@wj...>]

On Oct 27, 2006, at 11:43 PM, Gustaf Neumann wrote:

> Will Duquette schrieb:
>> Now, given that methods aren't procs, why might we want
>> object- or class-specific procs?  What I mean by this is procs
>> that are defined in the class or object namespace and are callable
>> as bare commands within those namespaces?  Because they are faster!
>>
> do you have some benchmark data to show, how much faster methods  
> are, compared with  procs?
>
> -gustaf neumann

In the benchmarks I run for Snit development, what I see is
that calling a simple proc with two arguments and no
external variable declarations takes about 3.5 microseconds on
average.  An equivalent [namespace ensemble] method call (e.g.,
a Snit 2.1 method call) takes about 7.2 microseconds.  An
equivalent TIP 257 oo:: method call takes about 8.2 microseconds.

If you start declaring instance variables or globals, the length
of the calls starts going up from there, and the dispatch time
is soon swamped.

Will


------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[<ju...@pr...>]

> > I think, Neil was referring to the conceptual similarities between =
an=20
> > object (as in xotcl) and an ensemble, which are lost in current 257.
> >=20
> > Does the oo core language really need object specific procs?
>=20
> This is an important point.
>=20
> While I started out with a goal of implementing methods using normal
> commands, I eventually decided to not do this on the grounds that the
> natural C API signature for a method was not the same as the natural C
> API signature for a command. Instead, methods take an extra parameter
> that specifies the object invokation context (that contains the sort =
of
> thing you'd find out with [self]). The alternatives are to push an =
extra
> stack frame to hold it (which is visible to [upvar] and [uplevel], and
> slows down method invokation quite a bit), place the data in the
> interpreter (maybe you can make the recursive case or the case with
> [upvar]/[uplevel] work right here, but I don't want to have to try to
> figure it out!) or to stash it in an extra hidden argument (this is =
what
> I tried first, actually, but it's ugly). Coupled with a little bit of
> call-frame hacking, this has allowed me to make method invokation,
> especially of deep and complex inheritance hierarchies, very fast and
> easy to use. In particular, people writing methods can treat them just
> like normal procedure calls, and do not need to do anything with [self
> callinglevel] to see the caller.
>=20
> In short, introducing the new "method" stuff make life easier. It =
makes
> the code cleaner, and it makes the _use_ of the code cleaner too; it's
> the second part that makes it really worthwhile. It also makes method
> invokation faster, which isn't a bad thing. :-)
>=20
> Donal.


>Instead, methods take an extra parameter
> that specifies the object invokation context (that contains the sort =
of
> thing you'd find out with [self]).

What I've seen referred to as the 'invocant'.
Is this 'object invocation context' assumed to involve the context of =
just one object?

Whilst I'm not yet sure how these method/proc thingies will operate - =
can you please consider if it makes sense to accept multiple invocants =
for oo systems that may like to use this feature?

ie some oo extension may want to invoke a method in the context of more =
than one object at once.
see http://en.wikipedia.org/wiki/Multimethods

This isn't really a specific request I guess.. just a nudge towards =
generalization of the invocant/dispatch stuff if it happens to make =
sense.

I've been toying with the idea of multiple dispatch for my own oo system =
- but never came up with anything concrete.

Julian

Re: [TCLCORE] oo-oh ... not ready for 8.5

[Kristoffer L. <se...@fi...>]

On 28 Oct 2006, at 03:54, Gustaf Neumann wrote:

> Kristoffer Lawson schrieb:
>>  Naturally many things can be done with filters, but that's not  
>> really the point (otherwise we could have only filters and nothing  
>> else).
> But what is the point, because it can be done with filters, one  
> should not use it?

Except for reasons of speed. By that argument we would not need any  
kind of forwarding mechanism. We would also not need assertions.

>> Besides, in the XOTcl world, if a method does not exist I believe  
>> you get an error no matter what filters are set.
> this is not correct. Otherwise, it would not be possible to  
> implement proxy objects based on filters.

OK, sorry, my mistake. I remember I had that problem at some point  
but maybe it was just my fault.

            /  http://www.fishpool.com/~setok/

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Gustaf N. <ne...@wu...>]

Will Duquette schrieb:
> On Oct 27, 2006, at 1:45 AM, Donal K. Fellows wrote:
>
> Now, given that methods aren't procs, why might we want
> object- or class-specific procs?  What I mean by this is procs
> that are defined in the class or object namespace and are callable
> as bare commands within those namespaces?  Because they are faster!
>   
do you have some benchmark data to show, how much faster methods are, 
compared with  procs?

-gustaf neumann

Re: [TCLCORE] oo-oh ... not ready for 8.5

[Gustaf N. <ne...@wu...>]

Kristoffer Lawson schrieb:
>  Naturally many things can be done with filters, but that's not really 
> the point (otherwise we could have only filters and nothing else).
But what is the point, because it can be done with filters, one should 
not use it?

> Besides, in the XOTcl world, if a method does not exist I believe you 
> get an error no matter what filters are set. 
this is not correct. Otherwise, it would not be possible to implement 
proxy objects based on filters.

-gusaf neumann

Re: [TCLCORE] oo-oh ... not ready for 8.5

[Gustaf N. <ne...@wu...>]

Donal K. Fellows schrieb:
> Gustaf Neumann wrote:
>> there is no need to define a delegate relation. tip#279 supports 
>> exactly this delegaton through a language primitive on the per-object 
>> and per-class level. For SNIT-like wild-cards, one can use te 
>> approaches in http://wiki.tcl.tk/11033 or filter based approaches. 
>> Certainly, the language in the tip#279 can delegate to every tcl
>> command.
>
> That feels like you're thinking "how can avoid taking up this new idea
> by doing a hack" to me. :-)
?? i don't understand the quoted sentence and i don't see any new idea
around. The wiki page is out there since more than two years.
>
> OK, I'm being _very_ unfair here. I was just trying to think what sorts
> of relations might be "missing". The other ones from classic OO analysis
> are 'generalizes' and 'aggregates' but I don't know if they're useful
> here. Suspect not though; generalization is a solution for a problem
> that Tcl scripts blithely ignore anyway, and aggregation is more of an
> organizational feature and not something that drives method dispatch.
if you think, that generalization is ignored, why are you working on 
tip#257?
i don't get the point with the aggregations either.
>> Has tip#257 any own solutions for delegation?
>
> No more than XOTcl has to tell the truth. 
my impression is rather less. if i look at forward, it is a subset of 
xotcl.  same with filters.
> BTW, there's no details
> at all in the TIP of how unknown method names are responded to in
> dispatch, which makes the delegation trick you're using invalid from the
> formal context of the TIP. You ought to plug that specification hole.
you are right, unknown is part of the scheduler, therefore it must be added.

Re: [TCLCORE] Odd 257 behavior

[Gustaf N. <ne...@wu...>]

Will Duquette schrieb:
>
>>> 2.  [info object methods] doesn't seem to be working at all.
>>>       
>> There are no per-object methods attached to fido, and the code does  
>> not
>> do inheritance-hierarchy traversal during introspection. (Should there
>> be introspectors that find who is implementing a particular method?
>> Quite possibly. There aren't at the moment though.)
>>     
>
> Aha!  I naturally assumed that "info object $obj methods"
> (or "info object methods $obj" per the tip) would return the names
> of all available exported methods, regardless of where they came
> from.
>
> Oh, yuck.  Do you really mean that get that list I need to walk
> the inheritance hierarchy?
>   
I mentioned the same problem already in
   http://aspn.activestate.com/ASPN/Mail/Message/3315600

 > TIP 257 is much faster than Snit 2.x in other areas (e.g.,
 > object creation, where it's faster by an order of magnitude).

i don't have the impression that object creation is blazing fast with 
tip#257
(see as well the message above).

-gustaf neumann

Re: [TCLCORE] Odd 257 behavior

[Will D. <wi...@wj...>]

Donal,

On Oct 27, 2006, at 1:56 PM, Donal K. Fellows wrote:

> Will Duquette wrote:
>> Here's what I'm seeing:
>> 1.  "destroy" is not listed by [info class methods]
>
> It's a method of the class "oo::object", and not of the class "dog".

>> 2.  [info object methods] doesn't seem to be working at all.
>
> There are no per-object methods attached to fido, and the code does  
> not
> do inheritance-hierarchy traversal during introspection. (Should there
> be introspectors that find who is implementing a particular method?
> Quite possibly. There aren't at the moment though.)

Aha!  I naturally assumed that "info object $obj methods"
(or "info object methods $obj" per the tip) would return the names
of all available exported methods, regardless of where they came
from.

Oh, yuck.  Do you really mean that get that list I need to walk
the inheritance hierarchy?

It seems to me that 99% of the time, folks are going to want the
full list, regardless of source.  In a few cases, callers are going
to want just the methods defined *in* this class or just the
per-object methods defined *on* this object, and oo:: should support
that.  But I'd think that that's the much rare use-case.

>> 3.  It's impossible to remove the "destroy" method:
>>         % oo::define dog method destroy {} {}
>>         % fido foo
>>         unknown method "foo": must be bark, destroy or wag
>>         % info object fido methods
>>         % fido destroy
>>         % fido
>>         invalid command name "fido"
>
> You're trying to remove it from the wrong place, that's all.

Ah, I see.  That makes sense, unfortunately.

>>      I'd argue that the "oo::define dog method destroy {} {}"
>>      (or whatever syntax is eventually chosen for removing methods)
>>      should either remove *all* methods, including "destroy", or
>>      it should throw an error in this case.
>
> Perhaps. I'll take input from the audience on this topic.

No, now that I understand the behavior it makes sense.  I don't
think an error message is needed.  All I really wanted to do was
remove it from the public interface, and "unexport" does that.  And
if I want to reuse the name, I can explicitly override it.

>>      Note that "unexport" *will* remove destroy from the public
>>      interface, which is probably good enough:
>
> I'd argue for doing that anyway; removing the method from oo::object
> just because a subclass doesn't want it would be Bad!

Well, yes it would.  'Twasn't what I was trying to do, though.

Will

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Kristoffer L. <se...@fi...>]

On 27 Oct 2006, at 23:34, Donal K. Fellows wrote:

> Robert Hicks wrote:
>> Yeah, I think Java is firmly in the "class-based" because that is its
>> central paradigm and not everything in Java is an object. In
>> differentiating the two in Smalltalk (while it has classes)  
>> everything
>> is an object and that is how you think (i.e. passing messages between
>> objects). Although there are a variety of "tags" to check when  
>> looking
>> at what kind of object system a language has. Too many to list  
>> here! :)
>
> It just struck me: in Smalltalk (not a language I know well) are the
> messages passed between objects themselves objects? If not, why  
> not? If
> they are, where does it all ground out? Or is it "turtles all the  
> way down"?

Yes, messages are objects too. I don't know the exact details, but  
they are. I'm not sure how Smalltalk does bodies, but in Self the  
procedure bodies are separate objects too and there was some  
interesting logic there.

            /  http://www.fishpool.com/~setok/

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Andreas K. <and...@ac...>]

> Robert Hicks wrote:
> > Yeah, I think Java is firmly in the "class-based" because that is its 
> > central paradigm and not everything in Java is an object. In 
> > differentiating the two in Smalltalk (while it has classes) everything 
> > is an object and that is how you think (i.e. passing messages between 
> > objects). Although there are a variety of "tags" to check when looking 
> > at what kind of object system a language has. Too many to list here! :)
> 
> It just struck me: in Smalltalk (not a language I know well) are the
> messages passed between objects themselves objects? If not, why not? If
> they are, where does it all ground out? Or is it "turtles all the way down"?

AFAIK they are. Necessary for smalltalks reflection ...

See also
	http://users.ipa.net/~dwighth/
for online copies of old smalltalk papers.

Especially
	http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_imp_toc.html
	chapters 26-30 of the blue book, aka
		Smalltalk-80: The Language and Its Implementation 

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122
 

[TCLCORE] 257: unknown vs. namespace ensemble -unknown

[Will D. <wi...@wj...>]

Donal,

There appears to be a serious gap in oo::'s unknown method handling
relative to [namespace ensemble].

If you define an unknown handler for [namespace ensemble], then
any unknown subcommands get handed to the handler.  The handler may
then reject them by throwing an error, or it may update the
ensemble's dictionary of subcommands, after which the unknown
call is retried (and presumably succeeds, because it's no longer
unknown).  As a result, the (previously) unknown subcommand is
called like any other, i.e., with the same semantics as a proc.

In oo::, it's possible for the unknown handler to to add the
previously unknown subcommand to the object, forwarding it to
any desired target by dynamically calling "oo::define $obj forward".
But there's no way to trigger the redispatch, that I can see.
That means, in order to delegate unknown methods to some other
object, I have to call the delegated methods from the unknown
handler...which means I need to work really hard to give the
call "proc" semantics, i.e., I need to:

* Make sure that "uplevel 1" refers to the caller's stack level,
   not the unknown handler
* Make sure that if the delegated method returns a non-zero
   error code (ERROR, BREAK, etc.) that the unknown handler
   rethrows it.

In short, I need to write a method dispatcher such as I used in
Snit 1.x for delegated methods...which I don't need to tell you
is *much* slower than what [namespace ensemble] does, besides
being a pain in the neck.

Is there anything we can do about this?

Will



------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] Odd 257 behavior

[Donal K. F. <don...@ma...>]

Will Duquette wrote:
> Consider the following class:
>    oo::class create dog {
>        method bark {} { puts "woof, woof!"}
>        method wag  {} { puts "wag, wag!"}
>    }
> 
> Here's what I'm seeing:
> 1.  "destroy" is not listed by [info class methods]
>         % info class dog methods
>         bark wag

It's a method of the class "oo::object", and not of the class "dog".

> 2.  [info object methods] doesn't seem to be working at all.
>         % dog create fido
>         ::fido
>         % fido bark
>         woof, woof!
>         % info object fido methods

There are no per-object methods attached to fido, and the code does not
do inheritance-hierarchy traversal during introspection. (Should there
be introspectors that find who is implementing a particular method?
Quite possibly. There aren't at the moment though.)

> 3.  It's impossible to remove the "destroy" method:
>         % oo::define dog method destroy {} {}
>         % fido foo
>         unknown method "foo": must be bark, destroy or wag
>         % info object fido methods
>         % fido destroy
>         % fido
>         invalid command name "fido"

You're trying to remove it from the wrong place, that's all.

>      I'd argue that the "oo::define dog method destroy {} {}"
>      (or whatever syntax is eventually chosen for removing methods)
>      should either remove *all* methods, including "destroy", or
>      it should throw an error in this case.

Perhaps. I'll take input from the audience on this topic.

>      Note that "unexport" *will* remove destroy from the public
>      interface, which is probably good enough:

I'd argue for doing that anyway; removing the method from oo::object
just because a subclass doesn't want it would be Bad!

Donal.

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Will D. <wi...@wj...>]

Andrew,

Snit 1.x is generally slow.  It is also the version of Snit in general
use.

Snit 2.x is still generally slow, being written in pure Tcl, *EXCEPT*
for its method dispatch, which (in my limited tests) appears to be
comparable to that of TIP 257.  But then, Snit 2.x uses
[namespace ensemble] for all of its method dispatch, which means that
the method dispatch is being done in C code--C code which was also
written by Donal.

TIP 257 is much faster than Snit 2.x in other areas (e.g.,
object creation, where it's faster by an order of magnitude).

Will


On Oct 27, 2006, at 1:32 PM, Andrew Piskorski wrote:

> On Fri, Oct 27, 2006 at 09:45:35AM +0100, Donal K. Fellows wrote:
>
>> In short, introducing the new "method" stuff make life easier. It  
>> makes
>> the code cleaner, and it makes the _use_ of the code cleaner too;  
>> it's
>> the second part that makes it really worthwhile. It also makes method
>> invokation faster, which isn't a bad thing. :-)
>
> I understand that TIP 257's execution speed is not the main thrust of
> your argument, and is hopefully a minor implementation detail which
> can be tuned later, but your "also makes method invokation faster" bit
> above confuses me.  In particular:
>
> 1. In the email excerpted above you said that the TIP 257 method
> dispatch mechanism, coded in C, is faster than some other alternate C
> implementations you tried.  So TIP 257 is fast?
>
> 2. Yet, Will Duquette just said yesterday (below), that SNIT is slow
> in general (presumably including it's Tcl-coded method dispatch), and
> that TIP 257's message dispatch is about that same speed.  So maybe
> TIP 257 is slow?
>
> 3. A few days ago, Gustaf gave some measurements and I think said that
> TIP 257's method dispatch is both a lot slower than he expected, and
> substantially slower than that of TIP 279.
>
> There seems to be some sort of contradiction between these three
> statements?  Or are you all measuring and talking about different
> things?
>
> On Thu, Oct 26, 2006 at 08:01:55PM -0700, Will Duquette wrote:
>> Snit isn't perfect; speed is an issue, especially speed of
>> object creation, and the stack traces it produces are
>
>> On the other hand, I've done some method dispatch benchmarks between
>> the current 257 implementation and Snit 2.1 (which is based on
>> [namespace ensemble]) and so far as I can tell they perform
>> about the same here.  I'm rather surprised, and pleased.  Of course,
>> 257 can probably be optimized further.... :-)
>
> -- 
> Andrew Piskorski <at...@pi...>
> http://www.piskorski.com/
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Donal K. F. <don...@ma...>]

Robert Hicks wrote:
> Yeah, I think Java is firmly in the "class-based" because that is its 
> central paradigm and not everything in Java is an object. In 
> differentiating the two in Smalltalk (while it has classes) everything 
> is an object and that is how you think (i.e. passing messages between 
> objects). Although there are a variety of "tags" to check when looking 
> at what kind of object system a language has. Too many to list here! :)

It just struck me: in Smalltalk (not a language I know well) are the
messages passed between objects themselves objects? If not, why not? If
they are, where does it all ground out? Or is it "turtles all the way down"?

Donal.

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Andrew P. <at...@pi...>]

On Fri, Oct 27, 2006 at 09:45:35AM +0100, Donal K. Fellows wrote:

> In short, introducing the new "method" stuff make life easier. It makes
> the code cleaner, and it makes the _use_ of the code cleaner too; it's
> the second part that makes it really worthwhile. It also makes method
> invokation faster, which isn't a bad thing. :-)

I understand that TIP 257's execution speed is not the main thrust of
your argument, and is hopefully a minor implementation detail which
can be tuned later, but your "also makes method invokation faster" bit
above confuses me.  In particular:

1. In the email excerpted above you said that the TIP 257 method
dispatch mechanism, coded in C, is faster than some other alternate C
implementations you tried.  So TIP 257 is fast?

2. Yet, Will Duquette just said yesterday (below), that SNIT is slow
in general (presumably including it's Tcl-coded method dispatch), and
that TIP 257's message dispatch is about that same speed.  So maybe
TIP 257 is slow?

3. A few days ago, Gustaf gave some measurements and I think said that
TIP 257's method dispatch is both a lot slower than he expected, and
substantially slower than that of TIP 279.

There seems to be some sort of contradiction between these three
statements?  Or are you all measuring and talking about different
things?

On Thu, Oct 26, 2006 at 08:01:55PM -0700, Will Duquette wrote:
> Snit isn't perfect; speed is an issue, especially speed of
> object creation, and the stack traces it produces are

> On the other hand, I've done some method dispatch benchmarks between
> the current 257 implementation and Snit 2.1 (which is based on
> [namespace ensemble]) and so far as I can tell they perform
> about the same here.  I'm rather surprised, and pleased.  Of course,
> 257 can probably be optimized further.... :-)

-- 
Andrew Piskorski <at...@pi...>
http://www.piskorski.com/

[TCLCORE] 257, ::oo::Helpers namespace

[Will D. <wi...@wj...>]

Donal,

I see that the [self] and [next] commands are
defined in the ::oo::Helpers namespace and brought into scope in
each object using [namespace path].  I was rather surprised by
this when I set a new [namespace path] in an object and found that
[self] no longer worked.  Naturally, I'd been assuming that
no [namespace path] had previously been set in the new object's
namespace.

I think you need to either (a) alias [self] and [next] into each
object in some other way or (b) document this use of
[namespace path].  If you choose option (b), I've no doubt
folks will continue to be surprised, but at least they'll have
a fighting chance. :-)

Will

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

[TCLCORE] 257: "unknown" handler

[Will D. <wi...@wj...>]

Donal,

The "unknown" handler, should you define one, is a method that
is called for all unknown methods, e.g.,

   oo::class create myclass {
       method unknown {methodName args} {
           puts "Unknown Method: $methodName $args"
       }
   }

Because it begins with a lowercase letter, it's exported by default,
and becomes part of the object's public interface.  For my part,
I don't think I'd ever want to have the unknown handler be
an exported method; I'd much prefer it to be unexported.  Hence,
I have to write this:

   oo::class create myclass {
       method unknown {methodName args} {
           puts "Unknown Method: $methodName $args"
       }

       unexport unknown
   }

Perhaps the unknown handler should be called "Unknown" or
"_unknown" instead, either of which would make it unexported
by default?

Will


------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

[TCLCORE] Odd 257 behavior

[Will D. <wi...@wj...>]

Donal,

I've been working with 257 (using the ActiveTcl build Jeff made
available a couple of days ago, which has different [info object]
and [info class] syntax than the TIP) and I'm seeing some odd
behavior.  Consider the following class:

   oo::class create dog {
       method bark {} { puts "woof, woof!"}
       method wag  {} { puts "wag, wag!"}
   }

Here's what I'm seeing:

1.  "destroy" is not listed by [info class methods]

        % info class dog methods
        bark wag
        %

2.  [info object methods] doesn't seem to be working at all.

        % dog create fido
        ::fido
        % fido bark
        woof, woof!
        % info object fido methods
        %

     Although, the error message is correct:

        % fido foo
        unknown method "foo": must be bark, destroy or wag

3.  It's impossible to remove the "destroy" method:

        % oo::define dog method destroy {} {}
        % fido foo
        unknown method "foo": must be bark, destroy or wag
        % info object fido methods
        % fido destroy
        % fido
        invalid command name "fido"
        %

     I'd argue that the "oo::define dog method destroy {} {}"
     (or whatever syntax is eventually chosen for removing methods)
     should either remove *all* methods, including "destroy", or
     it should throw an error in this case.

     Note that "unexport" *will* remove destroy from the public
     interface, which is probably good enough:

        % oo::define dog unexport destroy
        % dog create fred
        ::fred
        % fred destroy
        unknown method "destroy": must be bark or wag
        %

Will

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

[TCLCORE] Proper expectations [Was oo-oh ... Not ready for 8.5]

[Virden, L. W. <lv...@ca...>]

> The problem is partially that some of the goodies *have* to wait for=20
> 9.0: we cannot break compat in a point release, and compat makes some=20
> things impossible.

What concerns me is timeliness - if moving from Tcl8.4 to Tcl8.5 took 4
years of work (and I'm not criticizing that - look at all that went into
it), then how long should people expect moving from 8.x to 9.x take,
given the goal is to pursue a point where the APIs are modernized? Since
there is one shot do do this for the 9.x generation (which will be in
place for quite some time, unless we are going to follow 9.0 with 10.0 a
year later, with more API changes), then I'd expect 9.x to take quite a
long time to develop.=20


> It is also a matter of energy and manpower. We now keep two active=20
> branches; opening 9.0 while keeping development for the 8.x means
three=20
> active branches, with one of them diverging constantly. Development of

> new features becomes very hard, porting between the branches difficult

> and extremely work intensive.

> Nothing stops us from=20
> having different teams for 9.x and 8.x, except that we are already too

> small a team for one of them.

And so, when the 9.x work begins, the community should expect that the
queue of their requests will grow even faster, because the current group
of tcl developers working on the core will have their hands full making
the needed changes and rippling those changes through the tcl and tk
core.

--=20
<URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/
>
=20

Re: [TCLCORE] dict changes

[Neil M. <ne...@cs...>]

On 27 Oct 2006, at 14:39, Lars Hellstr=F6m wrote:

> 2006-10-27 kl. 14.17 skrev <ju...@pr...>:
>>
>> *I propose changing all the dict subcommands to take keys grouped as
>> Tcl lists instead of as a seqence of an unknown number of separate
>> arguments*
>>
>> we can then perform the above incr:
>>
>> dict incr tclcore {tipx present} 2
>
> A problem with this, from a usability point of view, becomes clear =20
> when
> you start considering non-constant keys (this is most likely the main
> case; nested dicts with constant keys only are just fancy
> pseudo-structs). It's certainly still easy to build the necessary list
> of keys using [list], but it is longer and obscures what is going on.

Not necessarily. I quite like the visual grouping of key arguments as =20=

with long strings of arguments like:

     dict set foo bar bob jim mary

it takes a moment or two to mentally work out that "foo" is the =20
variable, {bar bob jim} is the nested key, and "mary" is the new =20
value. So the alternative form

     dict set foo {bar bob jim} mary

I actually find slightly easier to read.

> In those cases where I've written procs that took some sequence of
> values as a list that was always being constructed on the fly like
> this, the results weren't appealing. Ungrouped arguments tend to work
> better.

For the case where you have elements of the path stored in different =20
variables, yes, but if you either get passed the entire path in one =20
variable or compute the path by calling a command, then accepting all =20=

keys as a single argument saves you an {expand}. e.g.:

     dict incr var $path 12
     dict incr var [getPath] 12

So it's swings and roundabouts. Either accept all keys as a list and =20
accept that you may have to do occassional [list ...]s, or accept =20
them as separate arguments and accept occassional {expand}s. I =20
wouldn't like to make a guess as to which scenario is more likely.

> If there is anything that worries me about [dict], it is probably
> rather how to deal with nestings where dicts and lists are mixed. I'm
> currently considering a data structure design where there might be
> lists of dicts, the values of which are again lists, and whose =20
> elements
> I'd like to access quickly (both get and set). Turning all the lists
> into dicts is not a solution in this case (amongst other things =20
> because
> the string representations of dicts are not canonical with respect to
> string equality). A [dict lset] would help, but can not completely do
> away with the need to unpack data.

Perhaps a general [path] command that can apply an operation to an =20
element in an arbitrary nested data structure would be helpful? =20
Something like:

     path incr myVar {dict myKey list 12 dict otherKey}

Here the path is a generalised form of {type key} pairs. The type =20
determines how to interpret the key that follows it (e.g. [dict get] =20
vs [lindex]) to navigate down to an appropriate part of the structure =20=

and apply an operation at that spot. (I'm pretty sure I've stolen =20
this idea from Joe English, but I may have misremembered). Likewise =20
you'd have [path set/get/append] etc common operations, and maybe a =20
[path apply/with] for more complex operations (not sure how that =20
works for lists: get $0 $1 etc vars, or a single var with the nested =20
list?)

Lots of details would have to be worked out about how best to =20
implement such a beast, and what the correct interface is etc. (i.e., =20=

probably best done off tcl-core).

-- Neil

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Kristoffer L. <se...@fi...>]

On 27 Oct 2006, at 17:34, Robert Hicks wrote:

> Kristoffer Lawson wrote:
>> On 27 Oct 2006, at 02:57, Robert Hicks wrote:
>>
>>> I would have to see some code for a prototypical system to judge its
>>> Tcl'ness.
>>
>> Try looking at the documentation at
>>
>> http://people.fishpool.fi/~setok/proj/Selfish/
>
> So are you going anywhere with Selfish or what it just a "proof of  
> concept"?

To be honest, I don't know. A large part of it was as a proof of  
concept, but the moment the appropriate project comes up I will  
attempt to see how effectively it works. Ie. when I need objects in a  
pure-Tcl situation or when performance is not important. I am keen to  
hear experiences from others.

I like the concept and I would like to see it developed further.

            /  http://www.fishpool.com/~setok/

Re: [TCLCORE] oo-oh ... not ready for 8.5

[miguel s. <mi...@ut...>]

Lars Hellström wrote:
 > 2006-10-27 kl. 00.30 skrev Donal K. Fellows:
 >> I (reluctantly) agree to not
 >> push for any OO system in 8.5 on the proviso that we stick to that
 >> short
 >> cycle for 8.6 (I hate committing to 8.6, but we need a version out with
 >> an OO system so that it can get extensive in-field testing before 9.0
 >> when it would be nice to see how much of Tk can be founded on objects.)
 >
 > It occurs to me that this "8.5 will be the last 8.x, then it's 9.0 all
 > the way" additude may be the culprit on which most of the blame for the
 > 4 years (and counting?) release cycle of 8.5 should be placed. If
 > something is going to be the last in its kind -- the zenit of
 > technological ingenuity -- then it is hard to let go of it, because
 > there is always some more polishing to do and features to stick in.
 > OTOH, as long as there will be a new model next year, then some of the
 > goodies can get to wait for that.

The problem is partially that some of the goodies *have* to wait for 
9.0: we cannot break compat in a point release, and compat makes some 
things impossible.

Note that our commitment is to maintain source *and* binary compat via 
the stubs mechanism. We also try hard to maintain compat for extensions 
that use internal structures and interfaces (tclInt.h), so that many of 
those are effectively frozen. And many of the things for which we try to 
keep compat are quite unlikely to evolve due to lack of active 
developers - itcl, blt, tix.

I for one cannot and will not take the burden of maintaining those 
working with changed internal interfaces.

 > There have been plans for what should be in various releases along the
 > way (I vaguely recall something about 8.5 should be all about improving
 > Tk), but it's my impression that the TIPs actually submitted didn't
 > match those expectations; there turned out to be a lot that could be
 > improved in Tcl as well. There probably still is (although 8.5 now
 > meets an anstonishingly large amount of the things that have been on my
 > wish list).
 >
 > At the current rate of ingenuity coming in, I wouldn't be totally
 > surprised if there gets to be an 8.7 as well. In that case, it would
 > probably be a good idea to not wait until 2010 to accept the notion,
 > and instead let it come naturally if/when it comes.

It is also a matter of energy and manpower. We now keep two active 
branches; opening 9.0 while keeping development for the 8.x means three 
active branches, with one of them diverging constantly. Development of 
new features becomes very hard, porting between the branches difficult 
and extremely work intensive.

So *my* hope is that

(1) we will have a development branch that is free from any compat 
commitments (especially binary, and not even source for extensions using 
tclInt.h). Which does not mean anybody will break things randomly and on 
purpose.

(2) we will keep 8.x on maintenance: bugfixes mainly.

If there appear volunteers (or paid workers, or the $$$ to create 
volunteers) most features maybe can be backported. But backporting 
should not constrain the design of new features. Nothing stops us from 
having different teams for 9.x and 8.x, except that we are already too 
small a team for one of them.

In short, at least for me: 9.0 is not an excuse not to develop new 
features because they can always go in tomorrow. Rather, 8.x is like a 
cage that stops development or makes it difficult; 9.0 is freedom.

As an example, you can look at some of the tips that target 9.0. Or 
consider that we could possibly make the core much more sparing in 
memory and runtime if we could share the string rep of Tcl_Objs, storing 
also lengths and hashed values in the same struct as the string. Or 
develop continuations, which may imply a change in some public apis. Or 
do automatic expansion of leading words in commands - breaking current 
command names with spaces, but allowing true lambdas and efficient use 
of command prefixes. Or ... the sky's the limit. None of these things 
can be done in 8.x, they would be both very good and fun to do them.

That is my peso.

Miguel

Re: [TCLCORE] dict

[Joe E. <jen...@fl...>]

Martin Lemburg wrote:
>
> I was surprised, that introducing dicts nobody seemed to think about traces o
> n dicts and their elements/keys.
>
> Is it true, that this is the first time, that "traces" on dicts are discussed
>  in this list?

No.  The absence of traces on dict elements is one of
the principal things that distinguishes dicts from arrays.


--Joe English

  jen...@fl...

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Robert H. <si...@gm...>]

Kristoffer Lawson wrote:
> On 27 Oct 2006, at 02:57, Robert Hicks wrote:
> 
>> I would have to see some code for a prototypical system to judge its
>> Tcl'ness.
> 
> Try looking at the documentation at
> 
> http://people.fishpool.fi/~setok/proj/Selfish/
> 
> and also downloading the package. There should be some brief examples  
> there which may or may not be illustrative. I'm not claiming them to  
> be particularly good examples, but perhaps it will give you some idea.
> 
>             /  http://www.fishpool.com/~setok/
> 
> 

So are you going anywhere with Selfish or what it just a "proof of concept"?

Robert

Re: [TCLCORE] dict

[Martin L. <mar...@gm...>]

Hi Neil,

I was surprised, that introducing dicts nobody seemed to think about traces on dicts and their elements/keys.

Is it true, that this is the first time, that "traces" on dicts are discussed in this list?

For me it was clear, haven't thought about its existence, that a trace on a dict behaves like a trace on an array.

But ... looking at the man pages ... there is no token "dict" in the list of possible trace states - read, write, unset, array. I complete overlooked, that dicts are not that integrated in tcl like the "old" primary types "scalars" and arrays.

So - do we have to write a TIP to define the traces on dicts to ensure that their are treated like their pendents?

----

Back to the direct access to list, dict and array elements.

There was no comment about the suggestion to allow the following:

    % set data {4 c 3 a 2 b}
    4 c 3 a 2 b
    % set data<0>; # list element access
    4
    % set data(4); # dict access
    c
    % array set dataArr $data
    % set dataArr(4); # array access
    c

The "<" and ">" characters are currently not usable in variable names. Ok - putting a variable name in braces allows to use "<" and ">".

What's about introducing the scheme varName<numericalIndex> as direct list access?

Ok - if somebody writes today ...

    % set foo 3
    3
    % set faa 4
    4
    % expr {$foo<$faa}
    1

... than the parser must not tell, that it is missing the closing ">".
And if 

Perhabs not that nice. :(

And what's about treating dicts equally to arrays in their element access?

Best regards,

Martin

-------- Original-Nachricht --------
Datum: Thu, 26 Oct 2006 15:57:48 +0100
Von: Neil Madden <ne...@cs...>
An: Kristoffer Lawson <se...@fi...>
Betreff: Re: [TCLCORE] dict

> 
> On 26 Oct 2006, at 14:51, Kristoffer Lawson wrote:
> 
> > On Thu, 26 Oct 2006, Neil Madden wrote:
> >
> >> set foo {a 1 b 2}
> >> .e configure -textvariable foo(a)
> >>
> >> It works for arrays, but is meaningless for dicts or lists as their
> >> elements are not variables (and do not change).
> >
> > But foo is a variable. Why would it not, invisibly, look up foo
> > and treat the contents as a dict to get the 'a' key from that. If a
> > variable is treated as an array, let it be an array.
> 
> OK, I can kind of see a scheme where this might work. Instead of  
> storing traces directly with array elements, you instead store the  
> trace with the containing variable along with a path for what element  
> to report changes for. There are lots of details though, e.g. what  
> happens in the case:
> 
> set foo {a 1 b 2}
> .e configure -textvariable foo(a)
> set foo {b 2)
> 
> Now "a" has disappeared entirely -- do we fire an unset trace on that  
> element? Do we delete the trace? Do we fire a write trace for foo(b)  
> too, even though it hasn't actually changed?
> 
> Now, how about after the first two lines above we do:
> 
> dict set foo a 1
> 
> We've set "a" to the same value as it was before. Do we fire a write  
> trace? If so, what about the further example:
> 
> set foo [dict replace $foo a 2]
> 
> Do we fire write traces on every element? Or just those that have  
> changed?
> 
> -- Neil
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core