||Java Access ||Language ||Work Areas & Persistence ||Nested Databases ||Configuration Options ||Functions ||Scripts ||Local Variables ||Method Invocation ||Compiled Lazy and Variable Number of Arguments Functions ||Constructors ||Scoping ||Type Checking ||Lazy Evaluation ||Overloading Functions ||Dynamically Compiled Classes ||User Level Classes ||Casting ||Dynamic Class Location ||Loading Classes ||Array Initialization ||Subsettting ||Utilities ||Dynamic CORBA ||Compilation ||Signal Handlers ||Prompt Evaluation ||Multiple Evaluator Classes, Instances and Threads ||Others ||Lexers and Parsers ||Substitute ||Comments ||Language Changes ||Input Continuation Separator ||Internal Utility Functions ||
||Missing/Future Features ||

Features

Java Access

Where fields or methods are not public but necessary, we have provided proxy methods in the evaluator which act as Internals. There is now support in the method calling mechanism to invoke public methods in protected classes. This allows us to access objects such as UNIXProcess which are not directly accessible in the earlier reflectance setup. This is the preferred way to provide access to these methods unless additionally functionality is to be provided.

Language

Object Databases & Persistence

The searchPath is an ordered list/table of database objects maintained by an evaluator. Each can be shared across multiple evaluator instances. Similarly, elements of one search path can be elements of another search path.

There are several different types of databases, all of which can be used in the basic evaluation interchangeably. What differentiates them is the level of support they provide for 1) persistence, 2) program support.

Persistence is provided essentially by the Java serialization with a little bit of bookkeeping. There are two models for persistence: 1) the S-style of individual objects stored in separate files, and 2) collections of objects serialized as a single unit (more similar to the R style). These different models are implemented by related but different classes - PersistentObjectDatabase and ObjectDatabase. Assignments in the first model are immediately committed to disk. When the databases is first attached, its contents are filtered and "matching" filenames are taken as objects and the database (partially) populated.

To serialize an object, one can use the family of serialize() methods in the evaluator. Basically, specify the object and the destination (i.e. java.io.File or String filename) So, the following works

 ? serialize(1::10, "/tmp/foo")
 ? in = new ObjectInputStream(new FileInputStream("/tmp/foo"))
 ? in.readObject()

? serialize(defaultDatabase(), "/tmp/foo")

 ? attach(new File("/tmp/foo"))

 ? attach(new File("/tmp/foo"), 0)

The biggest difference between the two models is what is stored. In the first scenario, if the object being serialized contains references to other objects, their contents will be serialized in the serialized version. When it is restored, these associated objects will not be restored into the database. This means that dynamic links will not be conserved and more disk space will be used.
The second form of persistence does preserve links and takes minimal copies. This is provided for free by Java. For example,

 ? x = y = 1::10
 ? x[0] = 100
 ? y[0]
 100
 ? serialize(defaultDatabase(), "temp.ser")
 ? exit()
 % omega
 ? attach(new File("temp.ser"))
 ? x[0]
 100
 ? x[0] = 20
 ? y[0]
 20        // still reference to the same object as x.

Either persistence model can use compression. The GZIP output streams can be applied at an object level. A simple flag controls this in the PersistentObjectDatabase. For serializing the entire object, simply construct the ObjectOutputStream with a GZIPOutputStream and the input stream in a corresponding manner.

Programming support is provided by several different database classes. All databases can be attached as read-write or read-only. This status applies to the collection indicating whether new elements can be added or existing values removed from the collection. The class ReadWriteDatabase allows individual elements to be specified as read-write or read-only. This allows one to allow new elements be written to a database while ensuring that certain others are not removed or overwritten. (This is how final variables are implemented.)

The default class of database can be specified in the OmegaOptions file as defaultDatabaseClass

Databases are used extensively in the evaluation of statement blocks. The LazyFunctionDatabase is for use in evaluating functions with lazy arguments (as the name suggests) and hides the details of delayed evaluation of specific arguments. These evaluation frames are temporarily attached to the Evaluator's searchPath.

The different database classes implement the Database interface. One can substitute entirely different implementations of this interface into the evaluator's search path.

Databases also support listeners. Other objects can register to be notified of assignment and removal events. Additionally, they can receive notification of attachments and detachments.

Database Nesting

[13] a = newDatabase("Foo")
{}
[14] a.b = 1
1
[15] a
{b=1}
[16] a.c = 2
2
[17] a.d = newDatabase("bar")
{}
[18] a.d.a = 1
1
[19] a
{c=2, b=1, d={a=1}}
[20] a.d.a
1

This is an example of the more general Omega DynamicFieldAccessInt interface which allows an object to reflect fields dynamically rather than supporting real Java Fields.

Options

Initialization Script

Local Variables

  for(i=0;i <k;i++) {
    Date x = 1
       ..
  }

In order to handle this, we can use the "reserved word" "local" to identify that a variable should be created locally. This is much like the my in Perl. The above statement would look like

  for(i=0;i<k;i++) {
    local x = 1;
       ..
  }

The choice of the word local is not fixed as one can change the value of the field LocalDeclarator in the class Omega.Parser.Parse.LocalVariable

Constructors

 x = new StringBuffer()

 y = x.getClass()
 z = new y()

The evaluation model may make this understandable. We treat both as Name expressions. Evaluating a Name resolves an omega variable or a class name. The order of the search may lead to surprising results. Suppose, we have a variable named String. Then, new String() may fail because it will use the value of the variable String rather than treating it as a name of a class.
We may change this in the future to iron out this precedence. In the example above, to obtain an object of class String one can use x = new lang.String()

Scoping Rules

Optional Type Checking

The exception to the optional type declaration arises in cases such as

 static Object x = 2;

In the near future, I will add the abilitity to optionally and dynamically require declaration of variables. We can do this without type checking using the local keyword introduced in omega. The dynamic aspect allows the feature to be applied to certain blocks, or expression trees, when debugging errors that may be caused by misspelling variable names, etc.

Lazy & Eager Evaluation

When defining a function, a parameter name can be qualified not only by a type but also by the keyword lazy. This ensures that the value of this argument provided in a function call will not be evaluated until it is needed. For example,

function foo(x, y= x.size()) {
     ..
    show(y);
}

In some cases, (e.g. the switch function again), it is more convenient to declare all the arguments of a function as lazy, rather than having to qualify each one individually with lazy. This can be done by qualifying the function definition with the keyword lazy as in

 lazy function foo(x, y=x.size()) {
   ...
 }

Given the ability to specify the ``mode'' of an individual argument and a default mode as lazy, we have also introduced the keyword eager which is used in exactly the same places as lazy but has the opposite effect - namely, the argument is evaluated at the time of the function call. For example, in the following, all the arguments will be evaluated only when they are accessed except the first one.

 lazy function Switch(eager condition, ...) {
   ..
 }

We can also introduce a deferred which might indicate to evaluate at the time of the function call but not at the time of the function definition. The Quote() method can be used for this.

For an alternative to interpreted functions, see Utility Functions

Compiled Lazy and Variable Number of Arguments Functions

Classses that are to be used as entries in the function table list, either directly or indirectly via instances, can implement either or both of the interfaces LazyFunctionTable and VarArgsFunctionTable The first of these indicates that the arguments should not be evaluated, but passed directly to Java method as a list. Such methods must be declared

 public return type foo(org.omegahat.Environment.Parser.Parse.List args,
                               org.omegahat.Environment.Interpreter.Evaluator evaluator)

The second interface, VarArgsFunctionTable implies that the arguments should be evaluated (unless the object or class implements the LazyFunctionTable interface as well as this one). However, they are passed as a single List

For some examples of classes, see

• OmegahatLazySystemFunctions for the time() and Quote() functions.
• OmegahatVarArgsSystemFunctions for the Switch() function.
• TimedEvaluation
• TimedExpressionEvaluation

This setup changes the search order for symbols. Now we search the function tables before the regular databases for functions.

We do not necessarily (or currently) return the reflect.Method associated with a method in a lazy or variable argument object.

Function Overloading

 > function foo(x,y) {...}
 > method foo(Vector x, Vector y) {}

  foo(a,b)

Handling ... and lazy evaluation is not very well supported at present to say the least!

Compiled Classes

User Level Classes

There are now two implementations of these classes. See Interpreted Classes. The newest mechanism generates compiled Java classes to represent the user-level classes and implements the declared methods by calling the associated method. This neccesitated facilities for identifying unqualified method calls by looking in the instance itself rather than in the global list and

The entirely interpreted version does support multiple inheritance. Additionally, linkage between the parent classes and fields is supported so that changes to base classes are propagated to the children, by default, but with events which allow the right of veto.

Classes are represented by templates or prototypes which absorb the fields and methods from the parent classes. Instances transfers copies of these fields on instantiation (allowing changes to the prototypes between instantiation) for regular fields and references for the static fields shared across instances of the class. Similarly, method tables (named collections of Method objects) are shared across instances.

A class can be defined by directly instantiating `free' AbstractUserClass or UserClass objects and adding fields to it. In this case, they are not visible to the evaluator and cannot be used for method and field dispatching. To introduce the class to the system, one can use the evaluator methods defineClass(AbstractUserClass) and defineClass(String name, Vector superclasses) and add fields with the return value. This has the effect of putting the AbstractUserClass into a table which manages packages of classes in a multi-way hierarchy. These tables are evaluator-specific but inherited from the parent evaluator when available.

As with most of the larger features added to the interpreter/evaluation model, support for User Level classes is optional and does not impact the performance of the basic evaluator which does not support it. This is done basically by providing classes that extend field and method access and instantiating those in an extended parser that overrides the factory methods for creating such objects.

Casting

1. modifying the method selection in a method lookup
2. method dispatching for methods in ancestor classes
3. accessing shadowed variables in ancestor classes

In Java 1.1, we can get around this limitation of the JVM and implement casting of types for arbitrary method invocation. Consider the class A

public class A {
  public String foo()  {
   System.err.println("In A");
    return "A";
  }

  public int val() {
   return(1);
  }

  public boolean bar() {
   return(true);
  }
}

public class B extends A {
  public String foo() {
    System.err.println("In B");
    return "B";
  }

  public int val() {
   return(-1);
  }

  public boolean bar() {
    return(false);
  }
}

[] b = new B()
[] b.foo()
In B
B
[] ((A)b).foo()
In A
A
[] b.val()
-1
[] ((A)b).val()
1

Casting Arguments

  public void A(Hashtable tb) {
    System.err.println("In hashtable");
  }

  public void A(Omega.Utils.OrderedTable tb) {
    System.err.println("In ordered table");
  }

>  t = new OrderedTable()  // extends Hashtable
{}
>  x = new Cast()
Cast@1dce4700
>  x.A(t)
In ordered table
null
>  x.A((Hashtable)t)
In hashtable
null
>

Casting for Element Access

Field Access

 x = CastA();
 x.foo   // CastA
  CastA
 ((Cast)x).foo //
  Cast

Casting also works in the very special case of a method call invoking getClass() and the qualifier being a CastExpression. In this case, the return value is the class to which the object has been cast.

 
 > x = new CastC();
 > ((Cast)x).getClass()
  class Cast
 > x.getClass().getField("foo")
  public int CastC.foo
 > ((Cast)x).getClass().getField("foo")
  public java.lang.String Cast.foo

Methods

 x = new CastA();
 ((Cast)x).A()
  CastA

Note also that a call such as

   ((super)x).f

Class Name Completion

Dynamic Class Loading

• addition of new classpath components/elements,
• reordering of existing classpath elements,
• dynamically generated classes without intermediate files written to directories in the search path.

Now, system level classes (i.e. those used by the classes in the Omega distribution) must be in the classpath but classes referenced only by the user are loaded by a separate class loader. This is done by adding new directories or jar/zip files to the object returned by the method localClasses() as follows:

  localClasses().add(new File("/home/duncan/Java/extensionDirectory"));
  localClasses().add(new File("http://www.omegahat.org/extensions.jar"));
  localClasses().add("/home/duncan/Java/extensionDirectory");
  localClasses().add(new URL("http://www.omegahat.org/extensions.jar"));

  u = new URL("http://tigger/Java-SSH.zip");
  localClasses().add(new LocalURLClassList(u,new DeferredEagerURLClassLoader(u)))

  l = localClasses().add("http://www.omegahat.org/Java-SSH.zip")

URLs in this context are slightly different from regular files in that they are expected to be Zip or Jar files, rather than directories. When the URL is such a container, the ClassList mechanism reads the list of contained classes. The classes are now identified and can be referenced using partial qualification. There are three different URL-based class loaders which resolve the class references.

1. The first (URLClassLoader) is entirely lazy and loads the bytes for a class when it is referenced. This incurs the cost of reestablishing the URL connection for each class and traversing the list of ZipEntrys until the appropriate one is found.
2. A second version (EagerURLClassLoader) allows a single connection to be established and all the classes contained in the URL to be loaded immediately. This trades the speed of establishing the connection with the possibility that most of the classes will never be used and would not have been loaded.
3. A third version (DeferredEagerURLClassLoader) changes the tradeoff by loading the bytes for each class but not actually defining the class. When the connection is first established to read the list of classes, the bytes are also retrieved and cached. When the class is referenced, the bytes are taken from this local table and converted to a class definition.
   The tradeoff here is again loading bytes that may never be used and also storing these. This class can be used to store all the byte arrays and then immediately after initialization the extraneous classes can be removed from the local byte table.

Dynamic classes are created and loaded by writing byte-code (via the Jas packages) and a special class loader. This allows the classes to be written to disk for cached use in future sessions or to be written into a buffer directly loaded. The latter means that the file does not have to be written into one of the elements in the classpath (local or system).

The following illustrates how to create a new class, named FunctionActionListener and

> dynamicClassLoader().defineClass("java.awt.event.ActionListener", "FunctionActionListener")
class FunctionActionListener
> v = new FunctionActionListener(function(x) {x++;})
> btn.addActionListener(v);

The different class loaders and locators are fields in the basic evaluator. These are shared across parent and children when new evaluators are created from the parent evaluator. They can of course be immediately overwritten or different constructors can be invoked to alter this behavior.

Array Initialization

Subsetting

1. multi-index single dimension/subscripting
2. single index, multi-dimension
3. a hybrid of both

The mechanism works for some of the core Java classes (as special cases). These are currently Vector, Hashtable Enumeration. (Assignments are not done on Enumeration.) The mechanism is extensible in that new classes can be created that provide methods implement the subsetting and the assignment to subsets as is appropriate for the class. To offer this, a class implements one or either of the interfaces Subsettable and AssignableSubset (These methods here are selected/invoked in preference to the built-in methods for Hashtables, Vector, etc.)

The subsetting mechanism is implemented in the methods get and assign in ArrayAccess in the Parser.Parse package.

Examples of classes that implement these two subsetting interfaces are OrderedTable and DataList This mechanism illustrates the more general notion of operator overloading. This will be added for the different operators +, -, *, /, etc.

A new mechanism now allows the subsetting to be performed by functions or compiled utility functions. When we fail to find an appropriate method for the subsetting, we search for a function or compiled method in the internal function list of the evaluator for a method named subset which takes 3 arguments:

• the objet being subsetted/indexed
• a List containing the evaluated arguments of the call such as a number,string, or collection of same
• a boolean indicating whether it is [[ or [ - true and false respectively.

Database Element Access

  db = new ObjectDatabse()
  db.x = foo(z)
  db.x    

If the particular instance of the Database has a publically accessible field of the given name, the last component of the field access is not considered as a key. Instead, the field in the object is used and either returned or assigned the new value. (Of course, public access is not encouraged and should be provided via accessor functions.) One can explicitly assign an object to the Database using the assign() method or via the subsetting operators, rather than this syntactic shortcut.

This can be easily used to provide easy access to assignments to specific databases. When a database is attached, it can be assigned to an object in the default database. It currently provides its own name by default and can be provided one. Thus, having attached a database named "X", the command

  X.y = 1

  assign("y",1,getDatabase("X"))

Rather than polluting the name space of the default database, newly attached database do not have to be assigned to an Omega variable. Instead, the search mechanism for the FieldAccess can be modified to traverse the search path of Databases in the event that a variable is not found.

The current implementation allows arbitrary nesting of access to database elements. For example,

 d = new ObjectDatabase()
 d.table = new ObjectDatabase()
 d.table.element =  1
 d.table.element
 d.table

Optional new

  x = String[3]; // works
  x = String[3][]; // doesn't work
  x = String[]{"a","b","c"}; // doesn't
  x = new String[]{"a","b","c"}; // does

  x =  Vector

Method Invocation

1. function invocation
2. method dispatching
3. internal methods provided by the evaluator
4. casting to an arbitrary class from which an object is derived.

This mechanism has been extended to handle method dispatching on Omega functions.

show(i) maps to evaluator.show(i) i.show() is the way to invoke the method show() on i.

Additionally, the code is now used to implement the S/R to Java interface. Calls from S/R are made Java objects and classes and arguments are "converted" to Java objects.

A feature has been added that allows promoting an object to an array in order to match a method. The object is contained in an array of length 1 and the arrays component type is identified by the matching method. For example, consider the class

public class foo {
 static public int doFoo(String[] x) {
  System.err.println("In String[]");
  return(x.length);
 }

 static public int doFoo(int[] x) {
  System.err.println("In int[]");
  return(x.length);
 }

 static public int doFoo(int[][] x) {
  System.err.println("In doFoo int[][]");
  return(x.length);
 }

 static public int doBar(int[][] x) {
  System.err.println("In int[][] "  + " " + x[0].length);
  return(x.length);
 }
}

 foo.doFoo("my string")
 foo.doFoo(1)
 foo.doBar(new int[]{1,2})

This also works in the same way for constructors. It is is especially useful in the S/R to Java interface where S and R have no actual scalars but vectors of length 1. Thus the automated conversion of such an object is ambiguous. By converting to simple primitives, the Omegahat method dispatching will perform the appropriate promotion to arrays.

Non-public (i.e. explicitly protected/private and "inner") classes provide complications for this dynamic reflected invocation. For example,

 > p = Runtime.getRuntime().exec("cat some-file")
 > p.getClass()
 class java.lang.UNIXProcess
 >  p.getOutputStream()
class is not public - class java.lang.UNIXProcessEvaluation Error: inaccessible method public java.io.OutputStream java.lang.UNIXProcess.getOutputStream()java.lang.IllegalAccessException: java/lang/UNIXProcess

In Java2, there is a mechanism to temporarily make a reflected object (Field and Method) accessible, in spite of the permissions. For cases like the one above, this is not a security or programming issue. The non-public nature of the class is a feature of the Java implementation, not a design of the class.

The facility is used in the following manner.

 Method m = findMethod(.....);
 m.setAccessible(true);
 m.invoke(....);

Gaining access to fields for write permission and internal methods which are intended to be called only by other methods of that class or object is a potentially a bad thing. As a result, we wait until there is an access error and only then do we test that the method is public but the class is not. This is not currently implemented for static methods as it is assumed they are either public or not by design.

Casting is now honored. Suppose we have an instance, named x of class C which is derived from a class B which in turn extends A. Then, calls of the form

  x.foo()
  ((B)x).foo()
  ((A)x).foo()

The implementation of this requires dynamically generating and loading a new Java class. As a result, this might be an expensive operation. In the future, we might cache these classes.

Graphical Interfaces

Omega can be ...

Thought has gone in to displaying results of commands in the JTextPane with different colors for the different components using an HTML-like language. There is a relatively abstract mechanism that requires a particular instance of a filter that will convert the Omega output into HTML.
VRML output could be cute in other contexts.

Class viewers

There are some very nice graph viewers for classes and methods.

Data editor

A DataGrid or spread-sheet like frame which allows one to

The Quote() operator which protects expressions. This will allow user-level thread creation and invocation.

Utilities

Variable expansion.

I have just added a parser that allows one to traverse a string and replace "terms" of the form ${VARIABLE} with the value in a Properties table indexed by the String VARIABLE. While this is used to expand environment variables in-line, it can be used for arbitrary purposes with any table.

Archive Files - ZIP and JARs

We can now read the contents of files that are themselves contained in zip or jar files. A particular instance of this is the way we read the default scripts that control the initialization and termination of an Omega session in the binary/JAR release. This is available as a source() method in the evaluator and via the class Omega.IO.ArchiveEntry.

Compilation

Listeners

In order to allow functions and expressions act as listeners in the event model (both AWT/Swing and class-specific events), we need a mechanism to generate a class that implements the listener interface but evaluates the function/expression in response to the event-handler method being invoked.
This is done in the GUITools/ package. A class there generates byte code dynamically which can be immediately loaded.

For distribution and portability purposes and the interest in speed, we want to be able to compile Omega scripts and functions.

This should be quite straightforward using Jas to generate the byte code from the data structures currently in the generated by the parser. The quality of the generated byte code will of course require a significant intellectual effort. But this does allow us to implement features such as tail recursion, etc. not only in the interpreter/functions but also in the byte compiled code.

Prompt Evaluation

Now consider the prompt expression string. This can be a simple expression that access variables in the databases or in the evaluator itself. For example, we may choose to emit the task number as the prompt surround by [] pair. This might be done (depending on the evaluator class and features) as

Alternatively, we may just keep a count of the number of prompts emitted. An expression of the form

 function() { static int count = 0;
              return("[" +  ++count + "] ");
             }

Multiple Evaluator Classes, Instances and Threads

Signal Handlers

Users can provide their own signal handlers in the form of Omega expressions or functions for different signals and have these be evaluated when the signal is raised. This is done in the UserLevelSignalHanders class which is a separate Evaluator. Usually, a single instance of this class is created in the startup scripts and populated with the appropriate handlers.

In the near future, we will support specification via named properties of the form

INT: function(sig) { ......}
HUP: rereadInits()

Miscellaneous

Sequence operator

The (current) sequence operator is :: It can be used something like 1::10, foo(x)::20 0::(x.length-1)

The expression objects each have a method apply() which takes an Omega function and applies it to each of the elements in the parse tree rooted at that expression. This is recursive and currently returns a java.util.Vector. In the future, we will support returning trees with the same structure and other features.

Coming to a cinema near you!

Byte compilation

One of the most important aspects of this language is that we will be able to bridge the divide between easy-to-use interactive languages and compiled low-level languages used for performance. We should be able to use jas, jasmin, etc. to byte-compile the Omega code into Java byte code and realize these improvements in performance. Some modification to the interactive languages may be necessary to obtain optimal performance rather than leaving all types, etc. to be dynamically determined.

Lexers and Parsers

The class of the default lexer is now configured to be read from the OmegaOptions file. This allows different lexers to be easily instantiated without recompiling. In fact, setting the value in the options() object of the evaluator allows us to change the lexer dynamically.

The primary motivation for having two lexer classes (omegaJavaLexer and omegaNestedStringLexer) is to provide different ways of handling escaped strings. The orginal lexer (omegaJavaLexer) cannot handle escaped strings without some modification, and more importantly, the user interface for such nesting must be simple. So, the second and default lexer omegaJavaLexer now treats the " " and ' ' pairs as mutually-nestable. We still of course require balanced pairs (so a string cannot start with " and end with ' or vice-versa). Using this, the following works parse(" x= 'abc';") and gives an expression containing the literal string "abc".

In order to handle this nesting, we have to sacrifice the the Java syntax for speciying characters - e.g. 'a'. At the moment, I don't think this is a problem. However, there is a chicken-egg problem in that we don't use characters much in statistics because we use strings instead because the languages encourage this. To use this syntax, set the default lexer property defaultLexerClass to omegaJavaLexer. As mentioned above, this can be done dynamically and temporarily - for the duration of one command. For example,

[] x = 'a'
a
[] x.getClass()
class java.lang.String
[] options().put("defaultLexerClass","omegaJavaLexer")
omegaNestedStringLexer
[] x = 'a'
a
[] x.getClass()
class java.lang.Character
[] 

The current complicated framework (or maze) of calls to parse a string in the Evaluator class is intended to allow us to reuse previously initialized lexers and parsers. Currently, we have to instantiate a new lexer and parser for each line of input. If we want to handle split-lines of input and just be generally more efficient, we have to find a way to convince See ResettableLexer and the lexer methods in Environment/Parser/AntlrParser.

Substitute

[1] db = new Hashtable(); db["x"] = parse("foo(2);")[[0]]; p = parse("if(x > 1) { foo(x); }")
if(x > 1) {
	foo(x);
}
[2] p.substitute(db)
if(foo(2) > 1) {
	foo(foo(2));
}
[3] 

Comments

  /** Comment */
  for(i=0; i < 3; i++) {
     /* another comment */
   x = 1;
     // 
   y = foo(x);
  }

 if(x == 1 // test for something
      && y < 2)

Note that these statement-level comments may not be printed currently. The toString methods of the different expressions need to handle these. Note also that each expression class has two linked lists of comments - pre and post.

Language Changes

Exponentiation is specified using expressions of the form 3^2

The ^ symbol in Java is the binary XOr operator. Currently, the precedence in Omega is the same as the same symbol in Java.

Subsetting [ now returns an object of the same class as the container object. [[ returns a scalar where appropriate.

This may change.

Input Continuation Separator

function foo(x) { //
    y = x+1;   //
    x*(y+x);   //
}

Internal/Compiled Functions

  foo(x,y)

1. look for a function named foo
2. if not found, look for suitable method named foo in are now resolved in a different mannerevaluator
3. if not found, consider call as
   new foo(x,y)

See Utility Functions for a more complete description and an example session.

Missing Features that ought to be added soon!

Method dispatching doesn't convert Integers, etc. to their corresponding primitives!

This is done now.

Operator overloading

The subset operators [ and [[ are done. Overloading of other operators such as +, *, /, etc. will work in much the same way and each requires an interface and recognition of objects implementing that interface in the expression class in Omega.Parser.Parse. See Addable, are now resolved in a different mannerSubtractable, etc.

Labels for continue, break and goto.

We won't miss the last one.

Other Utilities

File search mechanism via used defined search path.

Like the X-windows userfilesearchpath, Java's import statement, users should be able to say load,source, etc. which invokes a locateObject() method. This is done via the FileLocator class which takes a list of directories (or Jar files) and searches within these when a "file" is requested.

Help

The Evaluator class currently has a collection of help() methods which display the tree of HTML documents using the latest JHelp package from Sun. There is little content, but the structure is mapped.

We may generalize this to use XML based documentation which we can either process into HTML or use directly with specialized browsers. The latter allows us to offer "live" functionality in the browser such as interactive plots, drag and drop of objects onto plots, updating of results, etc. The JEditorPane in the Swing/JFC package is a well designed starting point for our customization. See the new documentation in S as a prototype model. The Java XML package from Sun provides the necessary tools for parsing and processing XML documents and trees.
Alternatively, we might use the flexible Doclet approach in JDK1.2 or merge the XML and Doclet approaches.

Templates, or Generics, as available in GJ are covenient. These may be added soon. They can of course be used to create Java byte-code that is used in Omega.