Hi Per,
Per Bothner wrote:
You really don't want to do non-trivial programming in bash ...
Also, remember it's a different niche. If you try to combine bash
and scheme, you might get something that sort-of-works but has
terrible performance, debugability, etc.
But this is precisely what I'm aiming at. Something that is like bash,
but with scheme syntax and other language features. It would be very
useful to combine the power and elegance of scheme with bash's easy
access to programs that others have written. However, of course you
wouldn't want to do non-trivial programming with it. I'm not proposing
to do so. But not wanting to do non-trivial programming in bash hasn't
kept it from being one of the most useful and most used languages on a
GNU box.
I doubt that the performance will be that bad (for scripting). The
debugability might be more of an issue, but no more so really than with
bash itself.
So, what "that we can see" means is anything which eval is already
and normally able to resolve to some value.
The problem is you're killing lexical scoping. You can no
longer tell statically if an identifier reference resolves to
a lexical binding. This means the compiler has to be extra
conservative. It makes harder for people to reason about the
program. And it makes it harder for a compiler to issue useful
error messages.
These are features not to be easily given up.
I'm certainly not proposing to add this to guile scheme as an integral
part of the language. It would be a module, an add-on, to be used when
you want to use it, and devoutly to be ignored otherwise. Besides,
IIRC, guile is not a compiling scheme in any case! Anyway, I'm not sure
how what I am proposing would be noticeably different from adding
bindings for the symbols ls, cd, etc, etc, etc at the toplevel. You
first look in the innermost lexical environment. Do we have a binding
for this symbol here? No? Then look one lexical environment up. No
binding there? Eventually get to the top level. Is there a binding for
this symbol here? No? Well then, look at the filesystem and see if
there is an executable in path with this name. It would not be any
different from having another lexical environment which is one level
higher than what we call toplevel, really, except that the actual symbol
lookup mechanism for this lexical environment is slightly more messy.
But really, I suppose the same effect could be achieved by running, in
.guile I suppose, a bit of code which bound, to the result of
string->symbol on every executable in the path, a function (perhaps
macro) which executed that program with the semantics for the arguments
that I described earlier. Of course, that would take an enormous amount
of time, and you run the risk of stepping on the toes of other things
that are defined already when guile starts up. However, if this were
what was done, then I don't see how it would possible screw up scoping
in the slightest. At any rate, it would certainly not screw up scoping
any more than any other top level define of a procedure (or perhaps macro).
Regards,
Jon
_______________________________________________
Guile-user mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/guile-user
