Difference between revisions of "EDT:Discussion topics from the language meetings"

Revision as of 15:33, 5 July 2011

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

mentioned the desire to be a bit more in line with RBD & CE

one option is to leave stuff out of "base EDT" but also create a separate build/package which includes the support

revisiting some decisions from last meeting...

still no structured records, we can 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, they 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...needs more discussion

use byteS not byte!!!! and for the footnote "Byte(N) is a value type similar to RBD's hex. N indicates the number of bytes in the value." compare what N means for hex

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, update up top...it's not a flag the thing is really null, so if

 you say myNullRecord.field it'll throw

math & logical operators with nullable types (and more operators???) should throw if an operand is null don't return null

no support for is/not

like and matches are replaced by functions on string

TODO: regular expression matching on string

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

July 6 Meeting

...insert notes here...