[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    Re: [E-Lang] E Authorities was: Pending revision of E in a
From:       "Mark S. Miller" <markm () caplet ! com>
Date:       2001-08-23 17:10:32
[Download RAW message or body]

At 08:55 AM Thursday 8/23/01, Wesley Felter wrote:
> On Wed, 22 Aug 2001, Marc Stiegler wrote:
> 
> > Trying to sum up Paul's message here in one line, my attempt is, "whence
> > comes the first authorities in E?" This question has 3 answers, one for E
> > programs, one for eMakers, and one for caplets.
> 
> What about stuff typed in to the REPL? Is that considered the same as a
> program?

Yes, with only the differences explained below.  A program and a command 
line session both consist of a sequence of top-level expressions.  In honor 
of the familiar name "command line interpreter", and because "top level 
expression" is a mouthful, these are now called "commands".

In both cases, each command is evaled separately, in the scope left behind 
by the previous command evaluation.  

(Implementation note:  The current interpreter does this directly. Dean's 
"compiler", and by extension, Darius' compiler, do their work behind the 
scenes within this eval -- transforming the expression tree before executing 
the transformed program on the provided scope.  By caching these 
transformations, we have separate compilations.  The requires the 
compilation to be independent of the provided scope, which Dean is doing.)

More important for the current discussion, the conventional contents of the 
initial default scope for both contexts is the same, modulo only the 
redirection of the bindings of stdout, print, println, and stderr to suit 
the interests of the REPL spawner.

The differences are:

1) Whereas a REPL is a read-eval-print loop, the execution of the top level 
program is a read-eval loop.

2) If a command terminates in a thrown exception, this will terminate a 
program, but a REPL will report it and go on.

3) The "outer" scope -- the scope provided to commands -- has different 
mutability.
http://www.erights.org/javadoc/org/erights/e/elang/scope/package-summary.html 
http://www.erights.org/javadoc/org/erights/e/elang/scope/Scope.html#bindSlot(java.lang.String,%20org.erights.e.elib.slot.Slot)
 Both kinds of outer scope hold only Slots, and Slots may be mutable of 
course.  This is no different.  But while the scope provided to a 
program-command is itself immutable, and processes top-level definitions by 
returning a variant of itself,  the scope provided to a REPL-command is 
itself mutable, processing top-level definitions by redefining them in place. 

This has the interesting effect that conflicting top level definitions in a 
program are rejected (causing, by rule #2, a program to terminate at that 
point), whereas such a conflict in a REPL environment merely causes the 
latter definition to override the earlier one.  Some care must be taken 
(which we are) to ensure that objects defined in this scope, and using such 
top-level names freely, always see the latest redefinition of these names, 
rather than the name-to-slot binding in effect when the object was defined.

Although #3 is interesting, and there's more to say about it, I take it it's 
not relevant to the point of your question?


A REPL is not just for interactive use, but also for "simulated" interactive 
use.  Updoc follows REPL rules rather than program rules, since the examples 
it's replaying must be faithful to what would happen in a REPL.


        Cheers,
        --MarkM

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang


[prev in list] [next in list] [prev in thread] [next in thread]