Re: Alternative E loader

On Feb 19, 2010, at 12:23, Thomas Leonard wrote:

> That certainly looks relevant! Though instead of having it download
> things via HTTP I was going to just implement the local case in E, and
> use an existing package system (0install.net) to actually download
> things, resolve dependencies, select versions according to policy,  
> etc,
> as an optional extra.

There are really two parts:

1. Given that some client wants module X, how do we locate the  
appropriate definition of X to load? This could be downloading or just  
local files.

2. Given a module definition, how do we turn it into objects in  
memory, what properties do they have, what are their interconnections,  
what are their connections to other modules, and how are they  
addressed by the client?

What is at issue here is mostly the second part: assume there is no  
doubt about what to load, and make it possible to load into an running  
process, and safe to load at all.

>> On Feb 19, 2010, at 10:45, Thomas Leonard wrote:
>>
>>> If accepted, it could also be used by rune to load the main program.
>>> This would allow all E programs to import emaker files from the same
>>> directory without any extra configuration (e.g. rune -cpa ...).
>>
>> Per capability design principles, programs should not get automatic
>> read authority to what happens to be in the same directory.  
>> However, a
>> "run the program which consists of this module-directory's main entry
>> point" or other invocation mechanism which explicitly specifies *that
>> the directory access should exist* would be reasonable.
>
> OK. Though I'm not too worried about this case. If it's a single
> script.e then it already has <file>, and using <this:...> is just a  
> way
> to pass the read authority to other files, as it could have done  
> anyway.

Oh. Right. That is not an issue, yes.

Incidentally, I feel it is a mistake that <file:.> refers to the  
current directory, and that <file> is different from <file:/>; I think  
that the current-directory access ought to be a different object. I  
forget the detailed rationale at the moment. There are issues with  
accepting conventional pathnames as input then, though.

(There is also the issue of file URL vs. host pathname syntax, and of  
pathname references vs. filehandles, and ...)

>> Also, I note that your system still re-evaluates on every get/1;
>> eliminating this (though it raises shared-state issues until such  
>> time
>> as the results are audited DeepFrozen) ought to also be a speedup for
>> the situation where many other files use the same library emaker.
>
> Yes, caching does speed it up further, but I thought that was too much
> of a change from the normal E behaviour.

In the ideal world of the current import system, everything importable  
is DeepFrozen and cached (the cache could be weak-valued).

In the ideal world of a well-designed module system -- I'm not sure  
whether everything-is-DeepFrozen or not. This is one of the issues  
which bogged down my progress on designing and implementing the module  
system.

>> (3) You should not bind "safeScope" to the file env; the name
>> "safeScope" (should be safeEnv) denotes the *particular* env which  
>> has
>> no interesting authority, whereas yours does.
>
> I copied this pattern from the default safeScope (which also includes
> the interesting "traceln"), but I don't mind either way. What should
> safeScope["traceln"] be, then?

Not sure, actually.

But the issue is actually not relevant for traceln, because by  
definition the difference between tracelns is not observable other  
than their having different identities.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>