Other anticipated changes for 0.8.5, Part 1

Mark S. Miller markm@caplet.com
Fri, 22 Oct 1999 15:13:22 -0700

Rather than waiting for the release notes to enumerate all the changes in 
the next release, at which time it's too late, it seems more prudent to post 
draft release notes prior to release, so y'all can catch any screw ups 
before it's too late.  Such as my abortive "^" syntax for reveal.  When I do 
a release, I will then edit the draft release notes into accurate release 
notes for the release.

Swing Version & Package

We've switch from the swing jar we used to distribute to the more recent 
swingall-1.1.1b2.jar, in which all non-sun-specific classes have been moved 
from the com.sun.java.swing package to the javax.swing package.  With this 
change, all our user interface code should be equally happy under all 
Java's >= 1.1.7.

Declarations of Passing Modes

At the E-language level, all objects are by default pass-by-proxy.  
(Actually, at the moment, all E-language objects are pass-by-proxy, but this 
will be fixed.)  At the ELib level, objects by default are not passable.  
They are only made passable by declaring how they should be passed.  At some 
point, I need to audit all my Java code for this issue, but in the meantime 
I'll fix cases as I notice them.  The cases fixed so far?  I've made the following PassByProxy:

     FlexList, FlexMap, ReadOnlyList, ReadOnlyMap

Removed Legacy Code

Chip, I removed your entire org.erights.e.extern.file package, except for the Console class.  The only functionality it seemed to provide that wasn't provided by E's wrapping of the file classes was readOnly access, both transitive and not.  Which brings us to:

ReadOnly Files & Directories, Transitive and not

java.io.File objects have been extended (from E's point of view) to respond to the messages "readOnly" and "transReadOnly".  Both of these return a ReadOnlyFile object that designates the same file-system file or directory, but only responds to the non-modifying subset of the File protocol.  If the designated file is not a directory, the two messages do the same thing, end of story.  

If the designated file is a directory, then the "readOnly" message will produce a ReadOnlyFile that gives non-modifiable access to this directory, but access to its contents as modifiable as was the original access to the directory's contents.  By contrast, "transReadOnly" produces a ReadOnlyFile that also restricts the access to the directory's contents to be the transReadOnly of the original access.

Syntax Changes

"reveal" as is being discussed.

when/latch/catch as is being discussed.

I took Ping's suggestion of changing the "same magnitude" operator from 
|=| to <=>.  As Ping noticed, the equivalence between "a <=> b" and "a <= b && a >= b" makes this quite mnemonic.

I took Danfuzz's suggestion that "throw" need not be a special form but merely a primitive function available in the universal name space.  As a result, parens are now required around the argument.

     throw "I'm unhappy"

is now a syntax error, whereas 

     throw("I'm unhappy")

was and is fine.

Visitor Pattern for Parse Nodes

(Before anyone complains, no I really mean Kernel E AST nodes.  But can't we call 'em parse nodes?  Or something more pronounceable than "AST nodes"?)

In any case, all my parse nodes now respond to "welcome(visitor)" by invoking the visitor with one of these messages http://www.erights.org/javadoc/org/erights/e/elang/visitors/ETreeVisitor.html

The org.erights.e.elang.visitors package contains a small number of visitors, some of which are extracted from code that used to be scattered among my parse nodes.  Geez, it looks better to but the logic for these in a visitor than in the nodes themselves.  I've also made a deflector for ETreeVisitor so we can write visitors in E as well as Java.  

The CopyVisitor, written in Java, can be decorated by a program transforming visitor written in E or Java.  In either case, the program transforming visitor need only supply methods for the parse node types it wishes to transform.  The CopyVisitor copies the others, recursively invoking its decorator on the pieces of these others.  A transforming visitor in E would be a distinct object provided to the CopyVisitor object it is decorating, and it would delegate all messages it does not understand to this CopyVisitor.  A transforming visitor in Java would subclass CopyVisitor so it wouldn't need to declare the methods it delegates to the CopyVisitor.  This is a small demonstration of the equivalence of Java's inheritance and E's static delegation http://www.erights.org/elang/blocks/inheritance.html

Timer Rationalization

Writing the covered call options example http://www.erights.org/elib/capability/ode/ode-bearer.html stimulated me to cleaning up the old Timer abstraction.  I removed its support for synchronous events, as I think it's unmotivated, and would prevent deterministic replay.  I added "now" and "date", as this is a non-surprising object to get those services from.  I also renamed "noticeTimeout()" to "run()" and "noticeTick(tick)" to "run(tick)", to enable simple functions to be provided as observers.  

I hereby declare this to be proper E style: a "noticeFoo(observer)" that is only to inform the observer of one type of thing should do so with a "run" message.  The "whenResolved" discussed earlier follows this pattern.

Simple Bug Fixes

"[] asMap" no longer blows up.

A future (optimistic remote result) whose resolution is a non-passable object now properly cases a BROKEN future.  It used to leave the future unresolved.

Jed and Elmer now flag when they think the edit buffer is dirty in the traditional Windows way, by appending a "*" after the file name in the title bar.

This revealed that my when-am-I-dirty logic was buggy.  It's now fixed.

When the E interpreter read from an input stream, it closes the input stream on end-of-file.

The Elmer Icon, Ping's carrot horribly mangled by MarkM, is now more properly transparent where it should be, but a decent carrot would be a great improvement.

More later....