Re: New environment/module patches

[thi <ttn at mingle dot glug dot org>]

Jost Boekemeier writes:

 > >  >	       (export a b c internal)
 > >  >        (public a b c))
 > >
 > > this is confusing to me; i tend to think of "export" and "public"
 > > synonymously.
 >
 > My english is quite bad, but what about `(protect internal)' and
 > `(public a b c)'?
 >
 > > why not use "evalable" or something like that instead of
 >
 > I would call the eval-environment bindings "evalable".  Those in the
 > protect-environment are protected by the package boundary and those
 > in the expor-environment are visible to the world.

looks like if a symbol is found in FOO-environment, it is said to have
attribute FOO.  if this is the case, naming the tags after the various
environments would be the most straightforward way.  so, yeah, "protect"
sounds good, but now the task is to educate users (like me) on what that
really means.

(1) could you explain the usage difference between {exported, protected}
and {exported, non-protected} symbols?

(2) does it make sense to have {non-exported, protected} or
{non-exported, non-protected} usage outside the module in question?
my guess is no.  (but it seems that `internal' corresponds to
{non-exported, protected} -- how can that be?)

more guessing: the fundamental attributes we're talking about is
"readable" and "writeable", yes?  so protected means not-writeable?  if
this is the case, i see the root of my confusion: i take "exported" as
ALSO implying "writeable", whereas perhaps that is not the case in the
new module system.  so, (1) would be RO vs RW ?

thi