/ download

Download and Install E 0.8.18i

Jump to

Download by Platforms & Versions
Highlights this Version
Variants and Subsets of E
Dependencies
Environment Variables

Are you sure you want the 0.8.18i version?

Download by Platforms & Versions

Earlier versions of E have been tested and run on MSWindows (95, 98 FE, 98 SE, NT, 2K), Linux, Solaris, FreeBSD, and now Mac OS X (which is really a FreeBSD platform with its own GUI toolkit and JDK). It should run on other UNIX platforms as well, given an adequate version of Java and bash (see below). It should also run without problems on MSWindows ME, but as far as we are aware, no one has tried this. If you experience any problems, or have any other informative experiences, please let me know, or report a bug.

The Installing links below describe how to install, and run various forms of the binary distribution. The Building links describe how to build E from the source release. The Download links will download each corresponding form of the release to your machine.

Highlights of this Version

Security Fixes

Many of the security vulnerabilities found by the Darpa-sponsored security review of E, CapDesk, and the DarpaBrowser have been fixed -- the ones showing a icon rather than a .

Syntax Changes

The biggest news on syntax changes aren't the changes that did happen, but the change that didn't -- Dot-based property access.

For a lively discussion, see (Track this issue...)

Dot-based Call

As of this release, the conventional dot-based syntax for immediate calls is phased in to replace E's earlier, Smalltalk-like, juxtaposition-based syntax (or no-dot-call syntax).

Both syntaxes are still supported as of this release, but the no-dot-call syntax is now deprecated. We expect to stop supporting no-dot-call in a later release. To check that your code no longer uses this feature, turn off the property e.enable.no-dot-call in eprops.txt, or say "-De.enable.no-dot-call=false" on the command line. To turn it off on a per-module basis, say

pragma.disable("no-dot-call")

at the top of the module.

We expect to shortly release a tool, based on the E-language parser, that will accurately convert E and Updoc code from the no-dot-call style to the dot-call style. Until such a tool is made available, we will continue to support both syntaxes.

(Track this issue... )

Unary Prefix Now Composes with Unary Postfix

In the C syntax tradition, unary prefix operators and unary postfix operators can be used in the same expression, with unary postfix binding tighter than unary prefix. In prior releases of E, we took a more restrictive policy because 1) the standard rule is hard to remember, and worse 2) when we used juxtaposition for call, which is a unary postfix operation, it was visually counterintuitive for calls to bind tighter than unary prefix operators.

Now that we've switched to the conventional dot-call syntax, objection #2 has gone away. Though objection #1 is still valid, we've now decided to go with tradition on this one. Between this and the above change, Ping's Python example:

if guard.name not in frozenGuardNames:

can now be written in E as:

if (! frozenGuardNames.contains(guard.getName())) {

assuming that guard has a getName() method. While this is still visually more noisy than the Python original, it's not fatally bad, and it can be instantly understood by someone coming from C syntax tradition languages (modulo the difference between properties and instance variables).

(Track this issue...)

Retired Switches

The following text is taken from the comments at the bottom of eprops.txt:

• The e.enable.define switch has been retired, since we are now committed to spelling this keyword only as "def".

• The e.enable.no-paren-call switch has been retired, since no-parens following a dot are now an object-property access, and no-dot-calls are now deprecated.

• The e.enable.no-paren-method switch has been retired, since it makes little sense without the availability of e.enable.no-paren-call.

(Track this issue...)

Break, Continue, and Return

Prior to this release, the for and while loop shorthands would define variables named break and continue as ejectors for exiting the loop, or loop body respectively. By convention, when E programs needed an ejector for exiting a method body, they would name the variable holding this ejector return. Code explicitly invoking these ejectors would obtain the conventional effect, but as Ping explains (see example #4), a C-syntax-tradition programmer would expect that simply using any of these names without a following open paren would still cause the corresponding non-local exit. Of course, when these were just variable names, this did not occur.

As of this release, these three names are now keywords, to be used as shorthand for invocations of the corresponding variables __break, __continue, and __return. For example, the for loop

for i in 1..5 {
    println(i)
    break
}

now expands to

for i in 1..5 {
    println(i)
    __break()
}

whose further expansion includes an "escape __break" which defines the ejector invoked above.

To support conventional syntax for return, any of these ejector keywords can be invoked with an argument without having to enclose the argument in parentheses. An example from E's libraries:

/**
 * Is the predicate true for any member of the list?
 */
def anyOf(list, pred) :boolean {
    escape __return {
        for v in list {
            if (pred(v)) {
                return true
            }
        }
        false
    }
}

When exiting a loop with "break expr", the loop as a whole evaluates to the value of the expression.

Zooko and Dean have each made suggestions that would allow the programmer to omit the explicit "escape __return", but this release does not yet incorporate any such proposals. Some of these proposals may likewise require one to write "return false" rather than "false", but both work in this release.

(Track this issue...)

Disabling Implicit Guards

This release introduces the three properties

• e.enable.implicit-final-guard
• e.enable.implicit-var-guard
• e.enable.implicit-result-guard

All of whom are set to true by default. The following text is taken from eprops.txt:

In reaction to the bug "need type guard on data from renderer", these three switches exist so an individual module may elect to turn them off for itself, forcing itself to be more explicit.

When on, the corresponding guard declarations may be omitted, in which case a default guard is provided. When off, those guard declarations must always be explicitly provided. The official E language allows all these kinds of guards to be omitted, and therefore these switches must be 'true' by default.

Note that the definition of an object name in an object definition expression does not allow a guard, so none of these switches will cause one to be required there.

As with all pragmas, these pragma switches are not part of the official E language. In fact, we expect to retire these switches and migrate the ability to ask for this extra check into an advisory static checker.

These switches are demonstrated by the following example session:

? pragma.disable("implicit-final-guard")
? pragma.disable("implicit-var-guard")
? pragma.disable("implicit-result-guard")

? def x := 3
# syntax error: The optional e.enable.implicit-final-guard \
#               feature in eprops.txt is currently off.
# def x := 3
#        ^

? def x :integer := 3
# value: 3

Variants and Subsets of E

A complete E system is persistent, distributed, and capability-secure both within and between processes. Incomplete variants of E are tagged by which of these features are left out.

A non-persistent E is called time-local since an object only exist as long as its hosting process does. A non-distributed E is called space-local if an object and all references to it only exist within its hosting process.

E by definition provides distributed capability-security -- the ability for objects in mutually suspicious processes to safely cooperate. If it looks like E and it quacks like E, it might be a duck; but if it doesn't provide distributed capability security, it's not E. A system that's otherwise equivalent to E, but doesn't provide distributed capability security, is called daffE. A distributed E can only be implemented by means of strong crypto, of course, for which we are using code derived from the Cryptix library (in accord with the terms of their open-source license). In a space-local system, no distributed insecurity can arise, so such a system would be an sl-E rather than an sl-daffE.

E is designed to provide local capabillity-security -- the ability for mutually suspicious objects hosted by the same process to safely cooperate, and the use of capability discipline to determine which of its hosting process's authorities it may exercise. Such objects could be executing untrusted code -- code that the hosting process (or its owner) doesn't need to fully trust.

This is a "complete" release of E. "complete" is in quotes, because both the persistence and the distribution leave much to be desired, as explained here and here. However, these are close enough that this release that doesn't need qualifiers in its name.

Dependencies

Versions & Types of Java

In refering to various versions of Java, we follow Sun's terminology and numbering. A Java Runtime, or jre, is adequate to run standard Java binary programs (class files & resources). A Java Development Kit, or jdk, is adequate both to build a program from sources and to run it. A jdk is a superset of the corresponding jre, and their version numbers are always in synch. Each successive version of the jdk/jre from Sun effectively defines a new version of the Java & JVM standards, except that Sun has introduced a numbering inconsistency: The Java/JVM 2.x standard corresponds to Sun's jdk/jre 1.2.x. We ignore this inconsistency and refer to both as 1.2.x.

This version of E requires a jre >= 1.3.1. E no longer supports Java < 1.3.1. To build E from sources, a corresponding jdk is required.

Note: E does not install correctly when using JDK1.4beta on Windows2000 -- it fails to exec the "winfo.exe" executable, used during install time to gather info about your Windows system. It seems to be a more general problem in execing executables. If you experience this problem, we suggest you install using a JDK1.3.* or a JDK >= JDK1.4.0-rc. ("rc" means "release candidate" and is post-beta.) Once installed, E should work fine with any JDK >= 1.3.1, except for the inability to exec other programs if you're using the 1.4 beta.

Some places to get a jre or jdk:

Obtaining Bash

To build E requires a bash available as "/bin/bash". If bash is unavailable for your platform, it seems to work better than it should to make a symbolic link from "/bin/bash" to "/bin/sh". If you try this and run into problems, please report these problems.

To run the E driver script "e" requires a bash >= 2.01 available on your PATH, and the env program available as /usr/bin/env. The E driver script is required (and must also be on your PATH) in order to be able to run E scripts (*.e files) directly as executables. To check your bash version, type

$ echo $BASH_VERSION

to your bash shell. A bash (2.05 as of this writing) for Mac OS X is available for download from Savage Transcendental Studios.

On Windows, both bash and env are available as part of the Cygwin distribution, as explained below.

Build-Only Dependencies

If you are only installing E from a binary distribution, or only rebuilding the Java portion for your own use, you can ignore this section. However, if you wish to build an E distribution from sources, then you will need the equivalent of the following tools as well.

The Cygwin Distribution

The E building process relies on a number of UNIX tools. These are available for Windows from Cygnus Support as the Cygwin package. If you wish to build E on Windows, you should download and install a version >= 1.0.

BYacc/Java (Berkeley Yacc for Java)

The E source distribution contains the executable binary program byaccj.exe for Windows, and byaccj for Linux/386/glibc. These are actually BYacc/Java from Bob Jamison and others. BYacc/Java is the Berkeley Yacc program extended with a "-j" flag and others for producing Java output. BYacc/Java is covered by the Berkeley License. The sources to byaccj are bundled with the E sources, and byaccj is optionally made as part of making E.

BYacc/Java is only needed if you wish to remake the parsers as part of making E. Usually, this is only necessary of you wish to edit the *.y files in the source tree (term.y and e.y). Since BYacc/Java is a C program, it was causing porting headaches, and most people interested in rebuilding E won't need to rebuild the parsers anyway. So we've added a switch: If you set the environment variable "MAKE_PARSERS" to "true" before running "make", then make will try to build BYacc/Java on your system, and then use it to rebuild the parsers. Otherwise, it will just use the parsers included in the source tree.

Zip Files

Our build process packs up the *.zip files in the distribution by using Info-Zip's highy portable, and highly ported, zip program. Info-Zip's zipping tools are open-sourced with a license that seems to resemble the X11 license, but before redistributing it, you should read it for yourself. The E distributions do not bundle in these tools.

Environment Variables

The following are the main environment variables controlling building, and normally the only ones you will need to be aware of if something goes wrong. Others variables are documented in the various makefiles, especially makerules.mk.

• OSTYPE - To determine whether we are compiling on the Cygwin platform, we check whether this is set to either "cygwin" or "cygwin32" (both have been encountered). If so, we set CYGWINOS to "1". All other conditionals test CYGWINOS.

• CYGWINOS - See above. If you actually are on a Cygwin environment, but OSTYPE has yet a different value, you probably shouldn't change it for fear of screwing something else up. So just set CYGWINOS to "1" yourself.

• JAVA_HOME - If set, it should be set to the directory where the JDK is installed. This is used to find certain executables and jar files that come with the JDK distribution.

  If not set, then the needed executables (eg, "java") are assumed to be on the PATH, and the jar files directly known to the makefiles are assumed to be adequate for building. This is known to work when compiling with javac, and known not to work when compiling with jikes 1.15. See below.

• JAVAC - If set, should be set to executable for the Java compiler. The Java compiler is assumed to be command line compatible with javac or jikes. If the executable is on the PATH, then simple names (like "javac") can be used rather than full pathnames. This can also include some initial compiler options to appear before the others. I normally build with JAVAC set to "jikes +E +F". I'm using Jikes 1.15, and at least that version needs to be provided with the JDK's rt.jar file as an explicit component of the -classpath argument. The makefiles do this automatically if JAVA_HOME is set to the JDK's install directory.

  If not set, this defaults to either "javac" or "$(JAVA_HOME)/bin/javac", depending on whether JAVA_HOME is set.

• JAVACMD - If set, should be set to an executable for running Java that's command-line compatible with the JDK's "java" executable.

  If not set, this defaults to either "java" or "$(JAVA_HOME)/jre/bin/java" depending on whether JAVA_HOME is set.

• JAVADOC - If set, should be set to an executable for generating Javadoc documentation that's command-line compatible with the JDK's "javadoc" executable.

  If not set, this defaults to either "javadoc" or "$(JAVA_HOME)/bin/javadoc" depending on whether JAVA_HOME is set.

• MAKE_PARSERS - E contains a small number (two as of this writing) of *.y files, which are compiled into parsers written in Java using BYacc/Java (see above). The generated parsers are included in the source distribution as sources, even though technically they are not, because most people interested in rebuilding E will not care to rebuild these parsers.

  Those that do wish to rebuild these parsers should set MAKE_PARSERS to "true". This will cause the BYacc/Java executable, byaccj, to be rebuilt from sources, and will cause these parsers to be rebuild from their *.y files using byaccj. The BYacc/Java sources seem to have problems compiling on some platforms. If you encounter such problems, and especially if you figure out how to fix it, please let us know.

  If not set, this defaults to not rebuilding byaccj or the parsers, but just using the generated parsers included in the source distribution as sources.