This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: object-properties


> > I'm thinking about changing the object system in Tcl->Scheme to
> > something based on object-properties.  I believe Maciej(?) was
> > saying that object-properties was going to become much slower.
> > How much slower is that?  With the version of Guile that I am using
> > it seems to work about as fast as normal list access (i.e., it's not a
> > big win to make a special object type when I can put all the extra
> > information in object-properties).
> 
> I think it was procedure-properties we were discussing. object-properties
> will probably continue to be implemented as a hash table on the object
> to an association list of the properties. You may be able to tweak a bit
> more speed out of it by using only one property which is a hash table,
> but that may slow things down instead.

All these properties get confusing.  Is there a reason for the 
difference between procedure-properties, object-properties, and 
source-properties?  (and how can I manipulate source-properties?)  
Couldn't they all be implemented as object-properties?

> I really should look at integrating the auto-resizing hash tables
> that were worked on on this list a while back, that should make things
> more useful.

Hash tables show up a lot -- they are definately worth doing right.

> > If object-properties stays reasonable fast or something like it can
> > do the same thing, this would make Scheme/Tcl data integration
> > fairly seemless (though almost too seemless -- in particular, in-
> > place mutation like string-set! is quite incompatible with Tcl's strict
> > call-by-value)...
> 
> Can you make that actually keep the values as different types properly
> in sync in light of arbitrary Scheme manipulation?

Hmmm... I'm not sure how to parse that sentence.

But, it's possible that cached translations of a value could confirm 
a hash of that value, to make sure there's been no change.  That's 
a bit more overhead.  Copy-on-write, of course, could also keep 
things in sync, but that's not a mechanism that is readily available 
at the moment.

Theoretically Tcl should be making copies of things all the time, 
but I avoid that by making sure the primitives all make copies when 
necessary.  This might be a bad assumption, however, because I 
must be inclusive of all the Scheme primitives as well and I cannot 
control them.

It breaks a lot of Tcl assumptions to use something like string-set!, 
not just the caching.  OTOH, it can confuse things quite a bit when 
you do the same sorts of things in Scheme (e.g., set-car! on 
something that is directly contained in code with '(a list)).

So, I guess the answer would be no.  The integration can't be 
perfect, but it would be nice if broke in easily recognizable ways.

> PS, this Tcl stuff is really cool. When it gets reasonably useful and stable,
> I want to try to make a scwm configuration file in Tcl, that should be something
> of an acid test of usefulness.

What I'm concerned about is whether such Tcl would just look like 
Scheme with Tcl syntax.  And, if it is, if that is good enough or if it 
reduces translation to cosmetics.


--
Ian Bicking <bickiia@earlham.edu>