Difference between revisions of "SCOOP-A3: Compiler adaptation"
m (→Open questions: Cosmetics) |
m (→Decisions: Added notes on CECIL and storable) |
||
| Line 25: | Line 25: | ||
#* Separate and non-separate class types are generated separately, i.e. <e>ANY</e> and <e>separate ANY</e> get different code. | #* Separate and non-separate class types are generated separately, i.e. <e>ANY</e> and <e>separate ANY</e> get different code. | ||
#* Generic derivations with separate and non-separate generics are generated separately, i.e. <e>ARRAY [G]</e> and <e>ARRAY [separate G]</e> get different code. | #* Generic derivations with separate and non-separate generics are generated separately, i.e. <e>ARRAY [G]</e> and <e>ARRAY [separate G]</e> get different code. | ||
| + | # User interface | ||
| + | #* CECIL does not support separate types in [[EiffelStudio_6.7_Releases|6.7]]. | ||
| + | #* Storable does not support separate types in [[EiffelStudio_6.7_Releases|6.7]]. | ||
| + | |||
= Open questions = | = Open questions = | ||
* Shall separate types be supported in CECIL? If yes, how is this done? | * Shall separate types be supported in CECIL? If yes, how is this done? | ||
Latest revision as of 07:18, 25 August 2010
Not Ready for Review: This Page is Under Development!
Team: Alexander Kogtenkov, Ted
Contents
Summary
- Parser
- Support only separate type declarations (exclude separate class declarations).
- Provide syntax to refer to the processors (not supported in 6.7).
- Take into account the possibility to use anchors.
- Type checking introduces new
- Conformance rules that affect type system
- Validity rules that require good description of errors
- Code generation is closely connected with work on the scheduler (A1, A2) and should target
- bytecode
- C code
- CIL code
Decisions
- Syntax
- Drop support of separate classes, only separate types are supported.
- Separate mark is allowed not only for class types, but also for other types.
- Semantics
- Default formal generic constraint is
detachable separate ANY. - Formal generic is considered non-separate if at least one constraint is not separate, otherwise it is considered separate.
- Default formal generic constraint is
- Code generation
- User interface
Open questions
- Shall separate types be supported in CECIL? If yes, how is this done?
Progress
| Functionality | Status |
|---|---|
| Syntax for separate types | rev#84252 |
| Separate status in conformance tests | |
| Validity rules specific to separate types | |
| Bytecode generation | |
| C code generation | |
| CIL code generation |
