How to create a 'Hello world' example for environments

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How to create a 'Hello world' example for environments

Chris Cunnington-4

>I can confirm that this works. Curious, it seems like
>#evaluate:environment: implicitly looks up names in the default
>Environment as a fallback. The created WbSrvr Environment does not
>have a binding for Object:

>   env valueOf: #Object => nil.

>But:

>   Compiler evaluate: 'Object' environment: env => Object
>   Compiler evaluate: 'Object environment' environment: env => Smalltalk
>   Compiler evaluate: 'WebServer environment' environment: env => WbSrvr

>That is probably the kind of stuff that must be documented.

I don't know that it's a fallback. I think an Environment only has access to the policy you give it. More specifically to what the Compiler is allowed to see. And an Environment cannot exist without being compiled. I think that's what the binding policy is. In Nicolas's example he had:

spanish := Environment withName: 'Spanish'.
spanish importSelf.
spanish from: english import: #Transcript.

I think the #importSelf creates an AllNamePolicy and the #from:import: an ExplicitNamePolicy. If you take the last line out (#from:import:) his example works just the same. I don't think you need to specify you want Transcript. The compiler can see it already from the #importSelf in the AllNamePolicy.

So, your three examples basically make sense to me. I think your line of reasoning is solid, though, because understanding the nature of the barrier between Environments is both essential and at the moment pretty hazy. I just want to say 'fallback' may be the wrong word. It can only fall back on any policy it's given and AllNamePolicy doesn't sound too discriminating. I think that may be what's happening.

I guess the compiler doesn't check to see if what you want to do is possible. It just plays along or shrugs. If there were tests for an Environment or the the compiler acted like C and said "I see what you're trying to do there, but that's not going to happen." Then the nature of the barrier between environments would become tactile. The errors would teach the nature of the barrier. 

>As for the "for added fun" part: In my image there is no accessor for
>the Process environment (and it is not a fully-fledged Environment
>instance, but a Dictionary, when you use Process>>environmentAt: and
>friends), so I had to add that accessor myself. 
Right, yea. Exactly. I just used the "add accessors" menu item to add it. I noticed somebody wrote into Process an #env ivar already, and it looked unused, so I supposed I could employ it when each process is initialized. Then I could inspect a process in the ProcessBrowser.

Your change to Compiler>>evaluteCue:ifFail: looks great. I'm looking forward to trying that out. I had a feeling that if I threw that question out there that a better programmer could solve that.

Chris



Reply | Threaded
Open this post in threaded view
|

Re: How to create a 'Hello world' example for environments

Jakob Reschke-2
2016-10-03 16:44 GMT+02:00 Chris Cunnington <[hidden email]>:
> Your change to Compiler>>evaluteCue:ifFail: looks great. I'm looking forward
> to trying that out.

Thank you, but I doubt that my change is really correct. You might
want to compile an expression in Environment A and evaluate it in
Environment B (like the Monticello loading methods: they are compiled
in the default Environment, but it would be nice if they installed the
methods from the loaded package into the current dynamic Environment).

Since #evalueCue:ifFail: is called not only by #evaluate:environment:,
that dynamic Environment binding should probably go "outside".

You could also place that [ ... ] on: CurrentEnvironment do: ...
around the `Compiler evaluate: 'WebServer exampleBrowse' environment:
env.` do-it to gain the same effect.

This is not required for the fileIn because it happens underway in
EnvironmentLoader>>evaluate:logged:.