On 2017-11-22T20:57:31 +0100
Per Bothner <per@bothner.com> wrote:

> On 11/22/2017 12:10 PM, Mark Raynsford wrote:
> > I have the following questions after playing with the Kawa API a bit:
> > 
> > 1. Is it possible to restrict the initially available symbols in a
> > kawa.standard.Scheme instance to a tiny core subset (such as lambda,
> > if, define, begin, etc)? A default Scheme instance in Kawa has 807
> > symbols in the environment.  
> 
> The default Kawa environment is defined by the (two) calls to
> loadClass("kawa.lib.kawa.base", xxx) in kawa/standard/Scheme.java.
> So all of the initially visible names are defined by kawa.lib.kawa.base
> (defined in kawa/lib/kawa/base.scm).  So you can replace kawa.lib.kawa.base
> to a "smaller" initial library.
> 
> I suggested creating sub-classes of kawa.standard,Scheme and
> kawa.standard.SchemeCompilation.
> 
> In addition you need to override checkDefaultBinding from
> SchemeCompilation.  The easiest and most reliable is just have it return null.

Right.

> > 2. Is it possible to restrict the interpreter to only working with a
> > single java.nio.file.FileSystem? I'd like it if any attempt to do I/O
> > went through a given filesystem instance. I don't mind if I have to
> > implement my own I/O library to do this.
> > 
> > 3. Is it possible to restrict the classes that the interpreter is
> > allowed to access or import? For example, right now nothing stops the
> > someone from writing (java.lang.System:exit 0).  
> 
> Both of these require disabling "backdoors" to Java classes, methods,
> fields.  Overriding ,checkDefaultBidning and maybe the colon
> operator should do that.

OK, thanks! I'll try those as a first pass implementation.

-- 
Mark Raynsford | http://www.io7m.com