This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Starting a repl within a package


Jost Boekemeier <jostobfe@aubergine.zrz.TU-Berlin.DE> writes:

> Okay, so I think what I really want is a convenient way to define
> scheme modules at run-time,

Probably not.  A module is a source-level construct, so it is
inherently a compile-time concept.  But of course Kawa can compile
"at run-time" (including in a repl).  I think Kawa should have
a define-module or similar concept that would allow modules at a
final granulaity than source files, but I haven't worked out
the issues involved.

Perhaps you could explain what you "really want" in terms of what
you are trying to accomplish, not in how it would be implemented.
What problem are you trying to solve?

> something like define-class.  It seems
> that the basic funcionality of define-class is already there.

Most of it is there.

> Separate namespaces for java/scheme (and for variables and functions).

Not in Scheme.

> Hmm, I think in Kawa a module is both, a dynamic and a static concept.

Module is a static concept, like a class.  There can also be a module
*instance* (except for static module), which is an object.  (Yes,
in Java a Class is also an Object, but that is at a different reflective
level, and in Java a Class is not the same as a class.)

> > What you *can* do is start a repl and *import* bindings from a module.
> 
> Let's assume we're currently in module foo/test.scm and require foo/bar.scm.
> The oly difference I see between test.scm and bar.scm is that test is
> currently open and bar is closed.

I don't know what you mean by "open" and "closed" - I don't use this
terminology.  Also, you cannot require a Scheme source file.  You require a
module, which is *specified* by (and compiled from) a Scheme file.

Note that Kawa has two different concepts: modules and environment.
They are related, an Environment is (run-time) data structure that you
can add bindings to.  A module has a static set of exported names, and
can be instantiated, *resulting* in (something like) an Environment.
That set of exported names can be added to some other Environment.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]