Re: object-properties

[Maciej Stachowiak <mstachow@alum.mit.edu>]

Ian Bicking wrote:
> 
> > > 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. 

It's fair game in Scheme as well. Doing

(define op #:fg)
(window-style "*" op "red")

works (and not even just accidentally).

> 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).
>

I suspect some special support will be necessary for procedures that
take keyword and/or optional arguments. It may be helpful to look at
the procedures
 
> > 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).

Perhaps it would be nice if it were a proper Scheme string, although that
would probably only be useful in rare cases.

> 
> > 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.

These cases will be rather unpleasant indeed, but I suspect you can go a long
way without needing it. I think I will download your package sometime soon
and see how far I can get on translating the default scwm config file.

> > 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.

Yes, I think application extension languages are actually the most
important use for translators, as otherwise you always have a choice
of using the canonical implementation of your language of choice.

 - Maciej