Re: difficulty of writing translators

[Maciej Stachowiak <mstachow@mit.edu>]

jimb@red-bean.com writes:
> 
> > I believe the current guile maintainer is opposed to adding variable
> > tracing to Guile on the Scheme level. (IMO wrongly, because variable
> > traces can be used to create a really nice magical interface for
> > global configuration parameters. They'd look just like variables (you
> > could directly access or set! them), but the app could react
> > appropriately to changes in its parameters. I think traces are one of
> > the best ideas in Tcl.)
> 
> Yes, I'm opposed to adding variable tracing to Guile at the Scheme
> level.
> 
> People need to have some sense of which code could be run in response
> to a particular action; if setting a variable causes new font metrics
> to be downloaded (for example), or some other huge and complicated
> action, then that principle is kind of broken.
> 
> If an operation is going to do something weird and expensive, it
> should be syntactically apparent; it could look like a function call,
> for example.
> 
> I don't see a major advantage to writing:
> 
>     (set! parameter value)          and             parameter
> 
> instead of 
> 
>     (set-parameter! value)          and             (parameter)
> 
> especially since it's clear that the latter might do significant
> work.  The payoff isn't worth the ugliness it adds to the language.

Jim and I have had this exact same discussion before, and I doubt
either of us will ever convince the other, However, for the record,
here are the reasons I think the above _is_ a problem:

* For a program with many configurable settings, the user should not
have to know, care or remember which parameters, when set, will
trigger extra processing immediately. It's often not even intuitively
obvious which will and which won't.

* Many configurable settings are done just plain wrong because it
would be more of a pain for the implementor as well as the user to
write to procedures rather than define one variable.

For example, hooks are implemented as variables expected to contain
lists of procedures, in Guile as well as in Scwm (for consistency). 

As another example, paths "%load-path", e.g. are implemented as
variables that contain lists of strings, forcing any path-searching
code to scan the list twice on each path search, first to make sure it
really is a list of strings (and save their lenghts), and then to do
the real work.

In both of these cases, it would be nice for the variables in question
to get typechecked when assigned, rather than on each use. Separate
setter and getter procedures might be better from a language
cleanliness point of view, but they are not really being used, even by
guile core, when they should be.

* Macros exist which do interesting manipulations of variables; they
are unusable on getter-setter pairs (unless Guile gets a generic
setter facility like Common Lisp's setf and starts using it, which I
think is also a good idea. In fact, I wrote one in Guile Scheme a
while back, but I'm not sure if anyone is interested).



If any of this for some miraculous reason convinces Jim, and I am
pretty sure it won't, I wouldn't even suggest making _each_ variable
traceable, just add a special traceable-variable type. In fact, with
syncase you can already make things that look like variables but don't
act like them. This change would only add a facility to do this
efficiently and access it from C.


 - Maciej