|
|
Meeting 11
Meeting 11 Minutes
Teleconference, April 4th, 2005
A quorum of 13 out of 15 voting members present.
Attendance is noted on the web site roster.
1. Call to order
Meeting was called to order at 09:00 PST/16:00 GMT.
2. Approval of minutes from meeting 10
David Van Campenhout moves to approve the minutes as posted.
Darren Galpin seconds.
No objections/abstainers. The motion to approve the minutes was carried.
3. Review of the Load Order Issue
Yaron : A work paper was posted on the website authored by Matan, and
that document deals with the way load order is to be handled in e, the
way the e files are loaded. Matan is invited to provide an
overview.
Matan : You all heard about load order being something of an issue in e
being aspect oriented. The point is that while in any other
language if you use a type before its introduced then the compiler will
just shout that the type is not recognized. The order of analysis
or the order of introduction of entities and the initialization of
entities is much more significant - it does not concern all the
semantic correctness of a program but also - how it behaves in many
different respects. The most trivial example is, if you have a
method and it has extensions in different modules in different
extensions of the struct then the extensions would run in the order of
analysis.
What is the exact order in which source code is being analyzed by the
parser? Which boils down to the question : In which order modules
are loaded and this is determined by the equals statement between
modules, you know the equals statement is the way in which to declare
dependency between two modules so if you're supporting some entity that
is declared in another module you're supposed to express this
dependency by import statement and all these imports are meant to
determine in which order the modules are loaded. This is the
overall idea of order management and specifically load order of
modules. But there's two intertwined issues here, one is the
issue
of cyclic dependencies between modules which happens when you have two
modules presupposing entities defined each in the other, so you would
have the first one importing the second and the second one importing
the first, its got to be serialized somehow and still you should be
able to do it, even if there's no forward declaration construct in e
like there would be in C. So this is one issue - what happens in
cyclic dependencies and another, very closely related issue is the
preprocessed directives in e - you have C like defines, all these
constructs have the look and feel of C preprocessor's and from this
prospective import statements are not treated as just declaration of
dependencies between modules they're rather treated the same as
includes statements or include directives in C. Here is where it
complicates further because now this introduces a different order, the
real semantics analysis order would be that determined by import
statements taken as declarations of dependency between modules. In
summary, e requires a clear definition of this issues for good reasons
- that is for aspect orientation and for some harder maybe, not so good
reasons, having these preprocessor like type language in it.
Yaron : Matan can you say what the recommendation is?
Matan : I don't know - it's a strange question - this document tries to
define a document or define how e is actually being used in the
world. So it determines how the import statement is very loosely
defined in the LRM and there's much more to import statements and this
is elaborated in this document. One thing is that it amends the
part of the LRM that discusses import statements another part of it
elaborates more on the principles of sub language another discusses a
topic which isn't even treated in the LRM and that is what conditions
you can forward reference entities. So it's a set of very tightly
related issues which are not big cases. There's no recommendation
as far as I can see - its just filling in holes that's the objective of
this document. I'm just hoping that it would be read by those
who know about these issues and by those who are not very knowledgeable
but can give feedback on it and would make it very gradually into the
language definition in its current format or in any other format that
you or the editor might suggest.
Yaron : Ok so essentially this is just tightening the definition, a
bunch of definitions that are either missing or are loosely defined in
the current version of the LRM. Any discussion - anybody who has
read the document and has any comments at this point.
Yaron : Ok - here's what we'll do - we'll keep the document posted for
a
few more weeks for people to be able to read and comment on it.
Obviously you can input directly to Matan or you can post it on the
reflector and I will try and get some comments directly from Christian
and once we feel that this is mature enough then we'll just transfer it
to Joe and maybe get some advise on where the various pieces need to
fit in the LRM. There doesn't seem to be a real decision point
here - we don't intend to change anything really fundamental in the
language just improve the description of it.
Joe : I think you really are discussing the fact that you are trying to
suggest or mandate restrictions in the firing order doing the
things in the language and therefore that might be its own chapter but
more likely it will go in the more relevant piece parts as you see the
three points that you have identified.
Matan : Right - I can see it work well for some of the parts of the
document but I think that other parts don't have a terribly natural
place for example forward references within a module or within what I
call a dependency unit which is a bunch of modules which
are mutually dependent currently have no natural place within the
LRM.
Jo : Correct and that is why I think it is something for the work group
to consider and why we'll try to keep all this material together and
then I'll essentially do an edit to with all the material staying
together and make references to other part chapters before
deciding whether to break it out more - but for sure you're introducing
some new material that I think is helpful and probably shall at least
have its own, we use the IEEE term ' clause'. Each of these
things become a clause as time goes by, I think it's a beneficial
set of information to have in because of what you're pointing out that
its raising issues to problems for people to try to do implementation
otherwise. Generally speaking in a language you want to say - did
you want to use it, you have to do it this way and there's a benefit in
the case of this particular document that you've developed to doing it
in the manner that you're describing and that's the part that we want
to play out most. So if its better to keep it all together but to
that and just add references to the other clauses then that might be
the simpler step - but I'd like the work group to advise me on this
decision.
4. Proposal to remove certain Verilog and VHDL statements
The WG has in front of it a recommendation to remove Verilog and VHDL
specific declarations from the LRM, this proposal made by the Interface
Task Force. It was discussed it briefly at the last call at that point
there wasn't enough time to consider that. Since that there was
another Interface TF meeting where there was a discussion about this
proposal and there was a decision to leave the proposal as it stands.
Pitchu : Thanks for mentioning the meeting about the proposal. We
had a meeting after the last workgroup meeting we decided to go with
the proposal to the WG meeting. Is there anything that anyone
wants us to explain re the proposal??
Yaron : I think at this point we would like to potentially invite a
motion to adopt the recommendation, here it doesn't need discussion on
the topics.
Matan : I have a question which was discussed in the last meeting ,
from which I was absent - I guess you don't bother to update.
Getting rid of all these constructs would have implications on the BFM
in general and the set of keywords - was that considered or discussed?
Yaron : This was not brought up as an issue - is this a problem
as if we remove some constructs from the language then obviously the
keywords and the BFM shrinks but that's not necessarily a bad thing is
it?
Matan : No no no its just hat it wasn't mentioned in the
document. The proposal was just get rid of these chapters I was
just saying that lets not forget the verification of the BFM and the
set of reserved keywords. About 10 or 11 derivation rules and just as
many keywords.
Yaron : That's a good point that will have to be addressed. We'll
have to update the BFM and the list of keywords. Any further comment on
this?
Avi : Move to adopt the TF proposal as posted
Discussion?
Matan : Seconds
No objections, no abstains - the motion to adopt the FI-TF
recommendation carries.
5. Task force updates
Yaron : As for the generation TF you may recall at the previous meeting
Ken Sailor asked to step down. I've asked Vitaly Lagoon to take
the position. For those who are not familiar with Vitaly, he provided
the following bio.
Since we consider Task Force leads as officers of the work group we
actually require a work group vote for acceptance.
Darren : Moves to nominate Vitaly as CO-TF lead
David : Seconds
No objections or Abstains, the motion carries.
Yaron : The other taskforce that
requires some help was the library taskforce, there are essentially
three or four large chapters to do with libraries things like file
methods and so on. Those are very very structured and contain
many little details and I don't think they've had any serious attention
yet. I don't currently have a formal lead to do this work but
several people in the Verisity R&D language team agreed to help out
with the review. This work is supervised by Amos Ziv.
Chris : The Basic Language group doesn't have anything to report.
Pithu : The interface TF had a meeting for the Verilog/vhdl related
chapters and
we're looking forward to our next scheduled meeting.
5. Editors updates
Yaron : Note that 3 new chapters are posted already, the variables
chapter, chapter 16 as well as the units and the ports chapters -
chapters 5 and 6. They're all in the new format, everybody whose
working on the LRM should take a look and note in particular the way
in which the format is now more condensed and the way the syntax is
presented the fact that there are supplementary examples so those
fundamental to the section are reduced and that the issues that have
been fixed are numbered and are noted on the pages as well as the new
format of marking issues so that they stand out.
Joe Daniels : Currently the focus is on the chapters and clauses where
the work is
solid and more people have put in a decent amount of time, where the
material is more substantial and continue to refine that more than
anything else. What I'm doing is I go through each of them work out
where there were any issues in the database by using a little box in
the side column to indicate where that issue has been edited or
resolved now, in some cases where material has been deleted we made the
decision to show
the deleted part in the box. If the workgroup feels that it would
be better to show the actual original material with lines through it
then we could do it that way too. I also have an outstanding
question for each of the taskforce heads to probably respond to Yaron
directly, which is what items are you still all working on and what's
the expected time line.
Once that material comes back I'll start working on
that, there may not appear to be a rhyme or reason to look at this in
general, I'm just trying to go through and take very stable well
defined material and get that more into the IEEE format and suggest you
all take a look at the posted revised chapters and take a look at the
differences. Especially in regard to page count which is some 50%
reduced - most of which is just removing white space and condensing a
lot of the presentation of the syntax, in particular most of the
examples are gone and therefore if I felt that the rest of the
remaining
text did not include a significant definition I inserted a question -
which I believe in PDF stands out in red with a question mark. If
I've got a comment or if I want to cross reference to something else
that I know needs to show up but I'm doing that more as an editorial
reminder. That's it - its more grinding away and dealing with
IEEE format which I'll need to do in the future.
Matan : I have a question you're taking the chapter and reworking into
this new format, you are integrating the issues that were reported in
the issue tracking ?
Joe : As far as I can tell on the most obvious example that would be
clause 6 reports we integrated about 20 issues
Matan: Do you say what's already been done in the second draft and
issues that weren't taken care of?
Joe : These previously have not been added to draft 2 - basically draft
3
should include any issues that have been identified prior to me
implementing that chapter
Matan : So those little numbers in boxes are the issues that were
identified between drafts 2 and 3
Joe : The box number actually corresponds to the issue number so like
124 box will correspond to database issue 124.
7. Other Business
No other business to dispense of,
8. Patent policy
The chair has issued a call
for essential patents, in compliance with current IEEE/SA PatCom
guidelines. The WG members are advised to review the call for
essential patents and the patent related slide presentation posted on the web site .
9. Next meeting
Please remember to send e-mail to rollcall@ieee1647.org so that your
attendance on this call is recorded.
• Please DON'T send these e-mails to the reflector
• Use the e-mail address you registered with
Next meeting is set to Monday, May 9th at 9:00 AM pacific (same
time as today's meeting).
10. Adjourn
|
