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


> In my option, symbol-properties should be removed, as they are wholly
> redundant with object-properties. source-properties and procedure-properties
> have special semantics for some fields, so they ar enot strictly
> redundant, but I think the ability to use them as general purpose
> information buckets shoudl be removed.

What I wonder is if the special aspects of procedure-properties and 
source-properties would be better represented as something less 
dynamic.  procedure-properties has, as I remember, an arity field 
and a name field.  Why not just have (procedure-arity some-
procedure) and procedure-name ?  You can't manipulate them like 
you might manipulate other properties, and it's a little misleading.

If they can't be (or shouldn't be) arbitrary data-stores, then there's 
no point in having them appear as though they are.  

The result would also be clearer to document, since there's a 
functionality/procedure pair instead of falsely general mechanisms.

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

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

> 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

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 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.  Really, the viability of it can only be 
answered by doing it... but there are many potential problems.  
Corba isn't thick *just* because it was done by commitee: it was 
solving a hard problem.



--
Ian Bicking <bickiia@earlham.edu>