Re: object-properties

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

Ian Bicking wrote:
> 
> > What I mean is, if I modify a Tcl value as one type, do I need to do anything
> > special to ensure that its value as other types is kept in sync? If I
> > change the value as a string, will the value as a list, integer, etc
> > show up properly thereafter?
> 
> OK, that's what I thought you meant.  And, no, you just can't do
> that.  It breaks the assumptions of Tcl (the language, not just the
> implementation).  It would be nice if when you did break this
> assumption that the object system caught you and put up big
> flashing lights, instead of just having an incorrect program (the
> most frustrating kind).
> 

Fortunately Schemers are prone to writing interfaces that don't rely on
mutation anyway :-)

> [snipsnip]
> > > 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.
> >
> > I imagine a scwm config file written in Tcl would combine the basics operations
> > of the Tcl language with scwm's window management primitives. In other words,
> > one would use "proc" instead of "define" to define procedures, and so on. Instead
> > of writing
> >
> > (window-style "*" #:fg "red" #:bg "black")
> >
> > I'd write
> >
> > window-style "*" -fg "red" -bg "black";
> 
> 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.

> > This is, on one level, purely cosmetic. But on another level it is extremely
> > useful because it allows users to leverage existing language skills, and helps
> > those who have difficulty with the parentheses. This simple example is pretty
> > obvious, but I am curious to see how well this will scale to more complex things.
> 
> Well, there's some issues here.  The simple example won't work.
> Supposing I fixed the thing for keyword arguments (exactly how
> this would work, I'm not sure, but...)  It would look like:
> 
>   scheme:window-style [sstring *] [skeyword -fg] [sstring red] \
>     [skeyword -bg] [sstring black]
> 
> Or, if you gave Tcl a little information about what types window-
> style was expecting:
> 
>   window-style * -fg red -bg black
> 

I think typical Tcl style would be to quote the things that are
string-like, although you're right that it doesn't matter.

> But the translator would really need the information about what
> types you were expecting for window-style (I have something like
> that working, but not for keywords).  After all, "*" and * are the
> same thing in Tcl: there is only one type, and that type is string.
> Sounds so dramatic, no? :)  Anyway, translation is no panacea.

I can live with adding type declarations for all my procedures, they
would probably be useful to a compiler anyway, and for documentation
pruposes.

> I think it's inevitable that there will need to be some wrapping for
> interfacing Tcl with Scheme.  Hopefully those wrappers will be
> minimal and could be expressed in either language, but they must
> exist.  What I worry about with translation is that the problem is
> going to become combinatorial when you get more languages and
> bind Guile to more programs. 

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.

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.

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

 - Maciej