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.

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

...insert notes here...

July 8 Meeting

...insert notes here...