EDT:Discussion topics from the language meetings

What the heck is this page?

I've pasted in my notes from the EDT language meetings, where we discuss what should and should not be part of EGL in EDT. In some cases I've gone back and made updates, but beware! this might be very out-of-date. Topics that need more discussion are italicized.

June 16 Meeting

Tim's list of differences between RBD and EDT

• not all types supported?
• math rules, overlfow, etc. will be native to the target language
• nullable is not a value of a variable (no AS/ISA nullable type)
• not all part types (datatable)
• not all statements (openui, forward, move)
• operators (new bit operators, all ops semantic is defined by the types)
• types are defined in egl, including operators
• system libraries...e.g. System not SysLib...they won't all be there, they're just types
• would rather put functions in types, in place of StrLib, DateTimeLib, etc.
• stereotypes from RBD may or may not be there

Core vs. Everything else
Core is the language minus all the data types
Core is a grammar, syntax and semantics of execution
Core includes the statements
Order of execution...and so on
Test framework *could* define its own types, just for the purposes of the test
The core spec will talk about "architypes" for primitive types without being specific, for example there should be a type to represent true and false (otherwise can't talk about if/while/etc.) but the spec won't say exactly what Boolean has to look like.
Also have literals for numbers and string, but that doesn't mean those are in core
Core includes the stereotypes because they're necessary for defining your types

We don't have to support all of the conversions that RBD supports
(don't like string to numeric, date/time, etc.)
(don't like conversions controlled by variables)

Tim will start writing the core spec very soon

Parts are really just types
Parts in core: everything...program library handler record datatable dataitem etc.
But we don't have to support all of them in all of the implementations

All of our types outside of core should be under org.eclipse.edt, there is no egl.* for things outside of core.

Take the case of int divided by int. Java's native / yields int, but in JS the fractional part is kept. The return type of the / operator comes from the int.egl file. We could have one int.egl for Java and another for JS, or we could pick one and make the generators deal with it. Which is better? This has a big impact on our test framework.

Tim says take what's supported by JS in RBD and use it as the basis for EDT Java & JS.

June 17 Meeting

We're starting to go over each part of EGL now...most of that's in the EGL Language page.

We should decide what can be thrown, and when.

Tim might have some new ideas about array initializers.

Should the arg list in main take string[] or string...?  What if I don't want any args?  Allow more than one main?

The parser can't tell if foo(3) is a type or a function invocation so Tim considers a change to the declaration syntax, maybe by adding a colon as in "x : foo(3);" no it looks like a label on a function call. Have to change the parser, allow types & function calls in both places & then do a semantic check later.

Should we allow ? on reference types?  If it's there they can be null, otherwise they can't be null.

We'll talk about subtypes (SQL, CSV, Exception, etc.) when we discuss stereotypes.

Since we're supporting top-level functions, we should support IncludeReferencedFunctions.

July 5 Meeting

We mentioned the desire to keep things "pretty much" in line with RBD & CE. One option is to leave stuff out of "base EDT" but also create a separate build/package which includes many of the other features.

revisiting some decisions from last meeting...

still no structured records, we will have a way to call native cobol/rpg/etc without them still no date, time, char, etc.

do support some variations of move: between two references, move-byname, move-for ...move-byname is crazy for structured records, the way it's done now isn't very clean

rather than set empty and set initial, have setEmpty and setInitial functions on records and handlers and arrays and anything else...this needs more discussion!

literals: null, bool, numbers, string, string w/ux prefix, bytes literal is 0x folllowed by a hex string for example 0x03AB is bytes(2)

operators and expressions

<<, >>, >>> bitwise shifting on bigint, smallint, int...and shift=

~ for bitwise not on bigint, smallint, int...and ~=

add ternary ?: hurray

some way to put an annotation on something without putting it in curlies normally you wrote x int { myAnnotation = 3 }; another way to do this is x int {@myAnnotation{3}}; in EDT we will allow that to be outside of curlies and before the declaration, for example @myAnnotation{3} x int;

don't allow substring as an L-value or an inout parameter

as and isa: can't include ? in the type

nullable types: it's not a flag, the thing can really be null, so if you say myNullRecord.field it'll throw a NullValueException

operators will behave differently with nullable types than in RBD: they'll throw a NullValueException if an operand is null

no support for is/not

like and matches are replaced by functions on string

for future discussion: regular expression matching on string

in operator is replaced by a function Array, but can't do "value in myRecordArray.field"

July 6 Meeting

we're talking about conversions

result of conversion errors? -- document them, as we said for operators and expressions

implicit conversions? (e.g. what RBD does for int = boolean, string = any) they're not in the model until the generator or tooling calls makeCompatible()

support conversions between non-primitive types? (record to record?) Tim sez: no

defaultNumericFormat, defaultMoneyFormat, defaultTimestampFormat, defaultDateFormat, defaultTimeFormat Tim sez: don't use them, can call a library function called "format" to do this, we could have an RBDString type which does this under the covers

SUPPORTED CONVERSIONS all to any any to all boolean to string: gives true/false string to timestamp: the string is parsed, fields come from the timestamp's declaration, we'll pick a format...no conversion to ts w/o pattern allowed because it's ambiguous string to numbers: follow our literal syntax for numbers string to bytes: use the underlying bit pattern to make a bytes value timestamp to string: we'll pick a format all numbers to all numbers all numbers to bytes...use the number's bit pattern...if the bytes has a length it must match the size of the number in bytes bytes to numbers...same in reverse

BYTES = BYTES...valid even when only one has a length, and when both have a length & they're different...truncate longer values on the right...if the source is shorter then don't pad just don't update what was there before...so if your bytes(3) is 0x123456 and you assign it a bytes(1) of 0x99 then the bytes(3) ends up with 0x993456

BYTES COMPARED-TO BYTES...they have to be the same size, compare bytes from left to right, until you find a difference, the operand with a one instead of a zero is greater (UNSIGNED!)

OVERFLOWS...normally a conversion doesn't have any special check for overflow, we do whatever the underlying language does...there will be special syntax for overflow checking...what is the syntax, and what happens on overflow when you're checking for it? our philosophy is that we can't make edt behave the same in every environment when there are edge cases...so if you're really concerned about overflows you have to tell us specifically to check for it...places where we truncate are an overflow?...support the RBD option to round instead of truncate?...syntax for a checked assignment looks like a function call, but it's a builtin thing, an operation

it's OK to use substring operator on a bytes

converting xml, json, format function for ts->string, numbers->string, and so on...we'll have libraries for this kind of thing (needs to be defined in the future)

a timestamp declared without a pattern means it can hold any timestamp, there's no implicit pattern

date/time math will be done with functions defined on timestamp

lots of RBD system functions will move to the types, for example DateTimeLib stuff should be functions on timestamps

we need to discuss all libraries we need, and the functions in all the types we haven't talked about yet

July 7 Meeting

We're talking about stereotypes and annotations, we'll say no to most of them now, and add them back (possibly changed) as we decide that we need their features

Program stereotypes: only support BasicProgram, but remove msgTablePrefix

Library stereotypes: none supported (we thought about using native libraries for DLLs, but decided ExternalTypes should be used instead)

Record stereotypes: support Exception

Handler stereotypes: support RUIHandler, RUIWidget, BirtHandler

ExternalType stereotypes: support NativeType, JavaObject, JavaScriptObject, HostProgram

Since we're supporting top-level functions, we should support IncludeReferencedFunctions.  It's an annotation in RBD but should be a field of the stereotypes in EDT.

Some interesting ideas and questions from Tim.

1. Should we add class as a part type?  It's in the model already.  It lets you have single inheritance and implement interfaces.  It could replace handler altogether.  Example:

class Square extends Rectangle implements Shape, TwoDimensional

    private lengthOfSide int;

    function area() returns( int ) return ( lengthOfSide * 2 ); end

end

2. Should we expand the way you can use the embed keyword?  Ways to make it more powerful: embed things that aren't records, use it to embed fields from other parts, etc.

3. Dynamic access lets you look up fieds, why not functions too?

4. Types as values, such as having a field of type Record.  Similar to the Class class in Java.  Helpful in defining annotations and stereotypes, since they refer generically to records and fields.

Soon, very soon, we need to go through all of the types defined in EDT and RBD, come up with all of the functions & fields & libraries & types for EDT.

Now talking about Language Compliance Testing.  What exactly should we test?  EDT has a core of EGL, and our own extensions.  Just about everything we're doing here falls into the category of extensions.  The core is always the same.  Compliance testing of core stuff, for example the if statement always runs the "then" block when the condition is true.  How variables are initialized.  The order of execution.  Can't actually test these things without using a particular extension.  Only testing core isn't very interesting or useful.  But maybe Core needs to be specific about the architypes so real tests can be written.  The tests shouldn't be coded to run in a particular environment or expect results which only come from a particular environment.

We decided to start writing tests based on the API/extension stuff, not Core.  Base our expectations on what RBD does.

We can't expect to write tests for somebody else's extensions.  But we can test that the implementation of the architypes works properly, for example all booleans must do boolean things.

Tests can be generated from the MOF model.

July 8 Meeting

egl.lang is EDT CORE, includes definitions of only ~4 types (string, int, boolean, ...), keep these as compact as possible and then we extend them in eglx.edt (which is NOT CORE), and put the other types there too the extensions will include much of what we really want the type to have (more conversions, functions, operations, etc.)

RBD types and libraries (FUTURE) can go in eglx.rbd

each type should be in its own file fully commented in egldoc including what is thrown & why

move RBD system functions from Libs into types when it makes sense to do so we need *Libs for things that don't belong in types continue to use SysLib but verify it only contains "system" things

August 23 Meeting

1. Reference-type variables support nullability

Yes! Reference variables declared with a question mark can be null, and their initial value is null. Reference variables declared without a question mark are never null, and their initial value is an object of the appropriate type.

Curly braces on the declaration of a nullable reference variable will cause it to be initialized to a non-null value.

A validation check will be added to ensure that things which can't be instantiated (interfaces & things with private default constructors) must be declared nullable. Constructors can be in ETs and (soon) handlers.

This change means people have to add ? on their reference type variables when moving code from RBD.

2. Changes to arrays

2a. Arrays can't be declared with an initial size

The size of an array isn't part of its type. That's why in RBD you can declare an int[5] and then assign [1,2,3] to it -- you change its length from 5 to 3. In EDT, all arrays must be declared without an initial size.

A size is still allowed on a new expression when you create an array.

Here are some example array declarations for EDT:

• a int[] = new int[3];
• a int[] = [1, 2, 3];
• a int[]; // This is an array of length zero.
• a int[]?; // Initially null.
• a int[]? {}; // This is an array of length zero.

2b. Initializing arrays with literals

Array initializers must be efficient. "a int[] = [1, 2, 3];" means make an array of three elements, values 1 then 2 then 3. Do not make a zero-length array, then make an array from the literal, and throw away the original zero-length array.

2c. Initializing arrays with set-values blocks

In EDT, a set-values block on an array declaration causes the values within the block to be appended to the array. For example "a int[] { 1, 2, 3 };" results in [1, 2, 3]. The block has a different effect in RBD: it sets elements rather than appending them, so you'd get an index out of bounds exception on the declaration "a int[] { 1, 2, 3 };".

3. Equality operators

In the past == and != on reference variables have always tested if the two variables point to the same underlying value.  We made string, number, timestamp (with no pattern), and decimal (with no length) be references in EDT, but we want == and != to do a string/numeric comparison.

We discussed adding === and !== operators for testing if two variables point to the same thing.  It wouldn't be possible to redefine them, just as you can't redefine the meaning of = for assignment.  We decided not to add these operators right now.  We might add them in the future.