Re: object-properties

["Ian Bicking" <bickiia@earlham.edu>]

> > Hmmm... I hadn't thought about #.option being equivalent to
> > -option... I'll have to think about that.
> 
> Hmm, well that's what Tcl tends to use for keyword-like things.

There's no generalized mechanism for keyword stuff yet.  For each 
primitive that I've done a little ad-hoc deal.  The annoying part is 
that the keyword is part of the structure of the procedure call, not 
just a piece of data.  Yet it should act like data, i.e.:

  set op -fg
  window-style * $op red

Should work.  Dealing with that sort of thing is just annoying, but I 
suppose necessary.  I'm not sure how window-style's types would 
be declared in this instance, since it's based on these 
keyword/type pairs as well as the position/type pairs (e.g., the first 
argument is a string, after a -fg is a string, etc).

> Now that I think about it, it seems to me that most language glue issues 
> can be solved semi-transparently with type declarations on all cross-language 
> interfaces. Actually, I suppose they are only really needed to allow calls from
> languages with fewer types to languages with more types; Tcl procedures
> could be translated into Scheme procedures that call a hypothetical
> `tcl:value->string' on all arguments, performing the usual Tcl conversions.

You do have to tell it what Scheme type the Tcl procedure is 
supposed to be outputing.  You can't even depend on it being a 
string, because it's not actually that everything is a string but that 
everything appears to be a string.  The person writing the Tcl 
program thinks that the output from:

  list 1 2 3

Is actually a string.  They can do string length on it, for instance.  
But it's actually a list.  And depending on how this mechanism is 
done, it might not be any proper Scheme type at all (which is the 
case at the moment).

> The only remaining tricky spots are interfaces that take union types
> of things that look different in the called language but the same in the 
> calling language. In the case of calling from Tcl to Scheme, this would
> be any Scheme procedure that can take either a string or something else
> as one of its arguements. For such cases one would need `sstring', `snumber'
> and the like.

Yes.  The most prominant cases of this is containers, which can 
take any type.  For instance, it's not enough to say that a 
procedure should take a list as an input.  A list of what?  And if the 
type in that list aren't homogeneous (or can't be represented in Tcl  
-- like a cons pair that isn't a proper list)... well, you'll have to make 
some sort of wrapper procedure.

> > Really, the viability of it can only be
> > answered by doing it... but there are many potential problems.
> 
> True enough. I'm trying to provide what I think is a useful test case,
> one that uses Guile in various moderately tricky ways.

That would be good.  I've been implementing this all in a vacuum, 
not having used Tcl seriously myself and probably not spending 
enough looking at real Tcl scripts.

A real test for this is something that is scripting -- not library 
programming or something like that -- and a config file should be 
quite appropriate.  Now I just need to think about keywords...


--
Ian Bicking <bickiia@earlham.edu>