Re: How could this be implemented?

[Jon Wilson]

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