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 06:18, 25 August 2010
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 | 

