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


> > 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 don't know if I like it, but it does solve certain problems.  Or, 
rather, means that the problems are already solved and I just need 
to fit the translator into the pre-existing system.  What 
procedure(s) do you use to create a keyword-object from a string?

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

Um... I sense something got cut off here...?

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

It could be the default, but I'm not too enamoured with defaults.  It 
isn't a string in the Scheme sense, so it could be deceptive to treat 
is as though it was.  "file3" is probably a port, not a string.  "23" is 
probably a number, etc.  It's interchangable in the Tcl world, after 
all.  When you move to a world where it isn't interchangable there 
should be a conscious decision made by the programmer.

[container type stuff...]
> 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.

The container stuff is pretty important, since containers are used 
so much.  It's not too hard with homogenous containers, but more 
complicated things I'll leave until later.  Association lists are 
probably another exception that would be nice to deal with.

In a couple days I'm going to put together another package, mostly 
containing code cleanup, but also some new primitives and stuff.  
You might want to wait for that.

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

At least for intra-VHLL translation.  The Language-X->C translation 
is popular, and X->assembly is what compilers do.  But 
Tcl->Scheme isn't a big simplification.


--
Ian Bicking <bickiia@earlham.edu>