SCOOP-A3: Compiler adaptation: Difference between revisions
Jump to navigation
Jump to search
m Added a new category: compiler |
m →Decisions: Added notes on CECIL and storable |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
[[Category:Concurrency_(SCOOP)]] | [[Category:Concurrency_(SCOOP)]] | ||
[[Category:Compiler]] | [[Category:Compiler]] | ||
Team: Alexander, Ted | Team: [[User:Alexander Kogtenkov|Alexander Kogtenkov]], [[User:Ted|Ted]] | ||
= Summary = | |||
* '''Parser''' | |||
** Support only separate type declarations (exclude separate class declarations). | |||
** Provide syntax to refer to the processors (not supported in [[EiffelStudio_6.7_Releases|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 <e>detachable separate ANY</e>. | |||
#* Formal generic is considered non-separate if at least one constraint is not separate, otherwise it is considered separate. | |||
# Code generation | |||
#* 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. | |||
# 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 = | ||
* Shall separate types be supported in CECIL? If yes, how is this done? | |||
= Progress = | |||
{| border="1" style="border-collapse: collapse; border-width: 1px; border-style: solid;" | |||
|+ SCOOP support in compiler | |||
! 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 || | |||
|} | |||
Latest revision as of 15:18, 25 August 2010
Team: Alexander Kogtenkov, Ted
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 |