22 Sept 2008 - Workgroup Meeting Minutes

• Workgroup: P1778 - Esterel v7 language standardization
• Location: Teleconference (see Next Meeting to connect)
• Date: 22 Sept 2008
• Chair: Gerard Berry
• Vice Chair: Stephen Edwards
• Secretary: Sylvan Dissoubray

Attendance

• Present: Gerard, Marc Perreaut, Sylvan, Ramesh, Eric, Charles, Luigi, Klaus, Raphael, Stephen, Mike, Marc Duranton, Shyam
• Excused: Claus, Jean-Philippe, Badr
• See Attendance Record for meetings participation history

Agenda

1. Agenda and process
2. IEEE tkwiki site open
3. Statements chapter
4. Next meetings

Process

• Start: Chair declares the meeting open at 4:06
• Agenda: The agenda is approved by participants
• Minutes: No objections about last meeting minutes -- they are approved
• Patents: No new item . The page IEEE Patent Policy holds the call for patent, and workgroup status.

Technical topics

Brief summary of discussion, pros and cons, and conclusions

Statements chapter comments

• Comments were contributed on the wiki and on annotated pdf by the workgroup (Claus, Ramesh, Luigi, Shyam, ...). All reviewed and discussed during the meeting.

• General impressions
  • EB: quite clear now.
  • SE: some imprecisions need to be fixed.
  • MD: comment about tags. semantics is good.
  • SE: semantics at the end ? GB: tradeoff, big chapter this way makes it more readable. Too many examples? (with default, without default).
  • MK: new presentation is nice, in general.

• Tags: explicit toplevel section, the program conceptually has tags, etc. Move 12.1.4 after 12.2 (belongs to semantics).

• KS: 12.1.5 Too detailed?

• MD explain synchronous earlier than chapter 12 ? Think about what to define in the introductive overview and definitions

• Semicolon Nobody wants semicolon as separator, everybody wants it to be a terminator. Agreed.

• Brackets must be in syntax rules

• Traps are necessarily outside parallel add a note

• for dopar: shall be positive. If not, it is either a compile-time or run-time error. Better decide what kind of error. Also possible to decide that if not positive then is considered as nothing This seems a better option. Semantics is static expansion, compile-time or run-time: whichever (implementation choice). This question is related to to static_if and static_for. static_for and for (not expanded). The interest is because of the need to generate linear VHDL wrt Esterel source size.
  • SE: static statements are appreciated (discussed in C++). Just syntactic concern.
  • do seq has been asked. Only way seems to be static.
  • static before expression or before statement? nested expressions too complex.

• repeat, positive or not. mandatory for dependency analysis. repeat until would be clearer. Think about index usage inside the repeat
  • similar to static discussion

• clarify delayed suspend defnition

• concurrent traps (trap T1, T2 in) have been removed to simplify the statements. No practical objection.

• Discussion about static instructions:
  • A static instruction, e.g. static if or static for has the same semantics as the non-static form, expect that it requires the intruction to be performed statically, i.e. at compile-time.
  • The static if instruction is a clean form of #ifdef and makes static run module recursion possible.
  • The static for makes it possible for the user to specify whether the for loop must be expanded at compile-time. The static for is useful to handle carry array dependencies over modules under for loops, which cause static cycles without the compile-time for loop expansion. There are several possible syntaxes:

static_if e then
...
static if e then
...
if_static e then
...
if static e then
...

• Propositions for while-do and do-while instructions

trap done in
  loop
    if e then exit done;
    p
  end loop
end trap

do
  p
while e
<=>
trap done in
  loop
    p;
    if e then exit done
  end loop
end trap

To be experimented before. We have experiment of "nice" instructions that have been added but never proved to be useful.

• Constructiveness and causality issues. The standard will say nothing about that. Compiler may have different point of views and accept different programs. The important point is that when a program is accepted by two different compilers, then it does the same.

Motions and actions items with name and due date

Adjournment and Next meeting date

• Next meeting will be about signals. Monday 20th October - 4 PM Paris time
• Meeting is closed at 5:45 PM.