Hi Marcel,

(I'll bundle your replies into one here.)

On 3/26/21 11:31 AM, Marcel Taeumel wrote:
> thanks for playing around with Environments. :-)

It's fun! And also I need it, or at least I *think* I need it, for a 
compiler for a data-describing schema language. The use of prefixes is 
getting horribly horribly unwieldy, so short *relative* names make more 
sense to me than long *absolute*(ish) names.

> Of course, you could [allow syntax like E A X new etc] by adding #doesNotUnderstand: to 
> Environment.

This is exactly what the Namespace subclass of Environment does. Well, 
Namespace does three things that plain Environment doesn't, and arguably 
shouldn't, do:

  - #doesNotUnderstand: to act ergonomically, like Self modules

  - configuring self with a small but sensible set of initial imports,
    namely importSelf and import: Environment default

  - managing a "parent" relationship to another environment, and
    enforcing naming invariants wrt the entry for self in that parent's
    binding table.

> environments are not organized in a hierarchy, 
> which means that look up will not fall back:

Yes, and I think this is the correct behaviour. The existing 
import/export mechanism is I think better than a hierarchical lookup system.

The hierarchy of namespaces comes in when you want to explicitly refer 
to something unusual, something not managed via the normal Environment 
import/export mechanism. The usual stuff, like Array, String etc., would 
be imported and so available directly in the local Environment as usual.

> Anyway, I don't follow your comparison with the DOS 1.0 file system. 

Just that Smalltalk's globals are analogous to the root directory of a 
file system, and that like DOS 1.0 and unlike unix, it's a flat, 
structureless collection of names.

> In a regular 
> application, I would never want to explicate an environment name in 
> my classes' methods.

Me neither. The overwhelming majority of name usage is of *relative* 
identifiers. Absolute naming is, ultimately, impossible :-) but also not 
a very good idea.

> Instead, the correct environment should remain 
> implicit. Maybe like a "working directory"? :-D Ha, maybe now I get 
> your metaphor...

Heh, yes quite. So this is how Environments already work, ISTM: most 
name references are relative, to the active Environment. My proposal (? 
it's not really a proposal yet, more just an experiment) is to add 
hierarchical reference to Environments to allow for nonlocal reference 
when needed.

As an example, my schema compiler, done with absolute names, generates 
monsters like this:

   PreservesSchemaCompoundPattern subclass:
     #'PreservesSchemaCompoundPattern_setof'
     "..."

And that's just for the meta-schema! When it comes to real schemas, I 
often have multiple that "import" definitions from one another, leading 
to names like

   NovySyndicateSturdyCaveat_Rewrite

referencing

   NovySyndicateActorRef

etc.

I'd very much like to be able to write

  PreservesSchema CompoundPattern setof

instead. But classes aren't "higher-order" in the right way to have the 
obvious way of doing that work. So Environments was where I ended up 
looking.

Perhaps I'm looking under the lamp, where the light is brightest? Is 
there some dark corner of the system where I should be directing my 
attention? I'd love to hear about it!

On 3/26/21 11:42 AM, Marcel Taeumel wrote:
> if I would implement a hierarchy of environments, I would not exploit
> "globals" or "declarations" but add "outer" and/or "inner" as 
> instance variables. Then #classNamed: needs to be changed to also 
> look in outer environments.

I prefer the way Environments work now, with explicit imports and 
exports to manage the local namespace, and with no particular hierarchy 
enforced. The Namespace idea/quasiproposal adds just one other thing: 
reachability of classes in other environments from some root environment 
using a path, for those situations where an import is inappropriate.

I guess it also adds tooling support which would be, uh, *difficult* 
without some kind of hierarchy.

Marcel, I'd love to hear your thoughts on the EnvironmentBrowser 
experiment in the inbox. I'll post again in a minute with a summary of 
where I'm up to with it.

On 3/26/21 12:41 PM, Marcel Taeumel wrote:
> Yes, indeed. :-) I just added ToolSet cass >> #browseEnvironment:
> and Environment >> #browse to Trunk.

Thank you for those! Much appreciated.

> And I noticed that something
> seems to be missing from empty environments since I cannot compile a
> new class into it through the Browser.

Yes, you have to import: Environment default to get the base 
declarations into scope. I think the "Smalltalk" and "Undeclared" 
entries are red herrings, but I haven't gotten into the details yet to 
understand them properly.

> Maybe
> Environment >> #initializeWithName: is not correct?

I think it's correct. Once you add importSelf and import: Environment 
default to a new environment, things work fine in the Browser.

Best Regards, and thanks again for the responses,
   Tony