Meeting 5 Minutes

Teleconference, May 10th, 2004

A quorum of 17 out of 20 voting members present.
Attended: Will be indicated on the web site roster

1. Call to order

Meeting was called to order at 9:04

2. Approval of minutes from meeting 4

Darren Galpin moves to approve the minutes.
Matan Vax seconds.
No objections/abstainers. The motion to approve the minutes was carried.

3. Election for Chair

The position of Chair is advised by DASC to be voted upon after a period of 6 months from the start of the WG. As no proper elections with a proper nomination period have thus far been held the elections for Chair are now due.

DASC advise a returning officer to hold the elections – Serrie-justine Chapman has agreed to serve in this role and will be mounting a 2 week nomination period. Those wishing to propose themselves for the role or wishing to nominate candidates should send the proposed names to Serrie at serrie.chapman@infineon.com. The names will be accumulated within the two weeks at the end of which the names of all the candidates will be posted. There will then be a two week voting period.

All voting members will receive an approval e-mail from Serrie giving the voter the right to approve or disapprove of each of the candidates. Voting rights will be based on the current eWG bylaws. Each member has the right to approve/disapprove as many candidates as they wish – there is no limit.

At the end of the two voting weeks the accumulated totals will be tallied and the results posted along with the announcement of the results. Details of all the individual results will also be available on the website.

The election process will begin shortly after this call. Please can all members stay tuned to e-mail messages and we hope that you will all participate.

No Concerns or Issues were brought on this matter.

4. Revision of Bylaws

As part of the DASC governance revision process, there are now model bylaws for working groups that are recommended to all WG’s. These model bylaws are available on the DASC website. The current Bylaws that the group abide by have nothing special so it is suggested that it may be simpler to adopt the DASC Bylaws. The Idea is to take the DASC Bylaws and add a couple of our own
- that we have some extra officers other than those advised by DASC
- that our members are requested to attend 3 out of 4 meetings as opposed to 2 out of 3 for voting rights.
Yaron will put together a draft based on this model and propose it as the draft bylaws for this group. The move to accept the draft will be made after the chair elections so it will become the responsibility of the new Chair to carry that vote.

5. Strategy for dealing with Keywords

Some supporting documents were posted with the agenda (see Keyword Discussion), on Whether Keywords should be reserved in the language, or identified depending on context.

The meeting is turned over to Cristian Amitroaie from the Basic Language Taskforce who is championing the issue.

Cristian Amitroaie:

The problem that we are trying to address is that of which are reserved words in Specman.
A reserved keyword – word with meaning in reserved names is an ID and cannot be used
KeyPhrases – maybe keyphrases may become reserved such as “is only” ?

One solution is to leave the language in its current form where there is nothing reserved but Keywords have special meaning in specific context but may be used freely outside this context. This may need to be changed as it causes an issue with parsing, is error prone, difficult and causes programming errors.

Solution Two is to have every Keyword reserved such as “is” and “empty”. This would be a strong reserve, however this may cause difficulty with local variables for example local variables “a” or “C”. This may cause issues with a lot of existing code as most people may be using local variables frequently in this way.

Solution Three is to reserve all keywords, but when there are consecutive keywords they would form reserved keyphrases, with the component words not being reserved. This solution is the one proposed and the parsing is not complex but the group is unsure to what extent it may break existing code. There are still a few issues that will need to be addressed.

Ken Sailor : But there is already a solution available – after all e allows you to redefine a Keyword so what is the issue with the current approach?

Yaron : It allows you to re-use keywords but everything is context dependant so a keyword may still be used as an identifier. This is the current solution basically then there is the option to make everything reserved or there is the third option which is midway between option one and option two in that all keywords are reserved but when multiword phrases are used they will not be broken down into individual reserved words.

Christian : The first one essentially makes parsing more complex from the tool development point of view currently used by Specman

Matan : Why even consider option 2? – Why would you break phrases into individual parts

Christian : This is a very strong approach I agree the keyphrases option was just a consideration

Yaron : If you looked at it naively – such as a student just learning to write a compiler this might be the approach that they would logically see as most appealing.

Matan : If there are keyphrases in other languages maybe, since we have them it seems like a natural generation of words so what would be the point of breaking them into parts?

Christian : Reserved phrase would make it clean and will look very familiar to all

Matan : You can recognise a keyphrase lexically as you can in lexical syntactic dichotomy.

Yaron : Yes but what would we allow between words? Anything that falls into blanks ie comments – multiple lines etc??

Matan : so is, “is empty” any number of white spaces??

Christian: It can also have comments in between

Matan : That would be tricky with comments

Christian : another question is how we would categorise a reserved phrase – perhaps using white space tokens?

Matan : so you could have, for example, something which took 2 tokens?

Christian : yes – and then use methods such as collapsing tokens into one another

Matan : I know you can do that but the natural way to do it is to make them with simple syntactical rules i.e. alphabetical characters with white space in between.

Yaron : Perhaps we can move onto option 3.

Christian : The recommended option is the third one proposed. The reserved words and reserved phrases can be easily implemented, however we are unsure what the effect of it would be on any existing code. It would mean that all keywords would become reserved words, so any current code using keywords out of context may well be affected by this. We tried to compile a list of keywords and keyphrases in the language using the BNF as a good starting point for it. Looking at this we found some that didn’t exist currently within the language and would be subject to further discussion. i.e dut_error and get_enclosing_unit. The recommendation would be to consider these as keywords.

Matan : Before you go into discussing particular cases I want to present what maybe more problematic. 1st – that it would cause existing code to become unusable

Christian : This has already been mentioned.

Matan : 2nd - also that you have an enormous number of words functioning syntactically as keywords such as ten times as many as any other language has. Most programmers would not be aware of them all and reserving them all would be problematic. With other languages, due to the smaller reserve word list, programmers tend to know them all. It is bad style to use keywords for identifiers.

Christian : Should we use reserved keywords for defines as well? i.e. maybe some words might be naturally commonly used for things such as hand written macros etc – also if we were to extend the language?

Matan : Its really an extensible language and you can have many user defined keywords – there really is no clear cut line.

Yaron : I’d like us to focus on giving guidance to this task force, discuss how the language looks and feels to the user. We are not really looking for a solution at this time more just for guidance from the group.

Matan : I would promote some restrictions. The list of reserved words should be as small as possible.

Darren : I tend to go with option 3 – as when you start to use keywords as variables you can end up with unexpected return types and also it avoids bad programming practises.

Yaron : any other opinions – or is there any additional information which could be used in this discussion?

Christoffer Amlo : It would help me to know what affect this would have on 3rd parties which support e? Would the impact be greater or lesser between options 2 and 3 and which would be easier to work with? Is there a benefit with using option 3?

Matan : We would need to balance the implementation effort and the robustness. The parser needs to parse the code available.

Christian : The obvious answer or 1st approximation would be to go all the way with keywords – but it may not work with any existing code. What do they want – something which is easier for implementing a parser or a parser which already works on existing code?

Yaron : Christian is putting together a parser currently so this is a valid case in point for anyone who is trying to implement a parser

Christian : One could implement a parser – which is what I have been doing. We can then try and measure the impact, so we would need some numbers, an analyser or something like it – some way of collecting the information maybe search and count the keywords?

Christoffer : My Point is that we shouldn’t make the language difficult for this.

Darren : For option one this could mean that we have different parsers giving us different results. Option three would be more likely to give the same result from different parsers thus allowing the users to move between parsers without any issues.

Christian : There are no known issues with this currently as keywords are still known an example might be “list of list of “ where “of” is a struct.

Yaron : re Darren’s Question – unless the definition of the context is very clear we may end up with a different result. This weakens the standard (although none are 100% precise due to the necessary ambiguity’s) this would however leave a wide crack in the definition if we were to go with option one.

Matan : How far are we committed to supporting the existing e code? What if optionthree is incompatible with existing e code??

Yaron : The only constraint is the PAR – there is nothing about backward compatibility but the study group did advise backward compatibility. As far as common sense goes it would help to improve the language and not abolish existing code.

Christian : When proposing to go with option one and with my tool I would want to reserve all the keywords anyway.

Matan : In reality there are many keywords which are useful but are not recognised, not just inside the defines or macros, but some that are widely used.

Yaron : I propose that this goes back to the task force and that they may then put forward a proposal after exploring option three some more and closing the open questions to complete the proposal.

Christian : The only question still open is – what existing code may be broken with option three? There is no problem with reserving some keywords.

Yaron : Agreed this is a decision to be made but with no definite decision on that I propose that we take it to ballot once a complete proposal is made without the question marks. My Thanks to Christian for presenting the issue.

Christian : Is this not the point where we need to make a decision?

Yaron : My concern is that there are still some open questions which make the decision difficult for people – should we take it to a vote straight away?

Matan : Maybe to assist people with making a decision we should post a list of what keywords may be reserved and which words may be keywords but not reserved?

Yaron : You already have them - please see the document mentioned above.

Matan : As for reserving built in method names, they cannot just be part of a routine or a method call syntax as some have non legal expressions as arguments. Some take varying numbers of arguments and cannot be parsed because of these.

Yaron : syntactically this is not a problem re the number of arguments – is there anyone in the meeting with a different viewpoint on the subject?

Darren : Routines shouldn’t be keywords as you may wish to extend them, maybe on a company wide basis

Yaron : Thank you – is that a strong enough reason for everybody?

Avi Bloch : Concurs

Christian : in the final vote we will have a list of pros and cons etc.

Plan of action : Christian will finalize a proposal that will be submitted to an e-mail ballot.

6. LRM Revision Schedule

Currently there are over a hundred issues posted on the tracking system. Quite a few of them are now ready to be updated by the editor.

The new revision of the LRM (v 0.2) will be available mid July.

Matan : When is the deadline for inputs into the LRM 0.2 inclusion?

Yaron : Probably the end of June, but the bulk of the issues should be submitted before that time, especially any issues requiring a major revision.

7. Task force updates

Yaron : there have been a few coordination meetings in between eWG meetings to discuss Task Force progress.
The individual task force leaders then discussed current TF status

2. Basic language task force (BL_TF)

Chris Macionski:
Doing well – many issues have been submitted to the issue tracker. The Keyword issue is the main issue being currently dealt with.

3. AOP task force (AOP_TF)

Matan Vax:
A couple of meeting have been held. A couple of issues have been generated although the progress is generally slow. Plan to pick up pace for the June revision deadline.

4. Constraints and generation (TG_TF)

Ken Sailor:
No meetings since club V – they consider the issue to be smaller that the current LRM, as only language aspects are to be covered and not implementation.

5. Coverage task force (COV_TF)

Andy Piziali - not present.

Yaron: Aware that this task force have been active and are submitting issues

6. Temporal expressions (TE_TF)

David Van Campenhout:
No work last month but will pick up ready for revision deadline.

7. TCMs and concurrent semantics (TCM_TF)

Matthew Morley - not present.

Yaron : no actions that I am aware of

8. Foreign (HDL) access and interfaces (FI_TF)

Pitchumani Guruswamy - not present

Yaron: This group have had several meetings and have submitted a few issues about HDL access. The work is now moving to focus on ports.

The following task forces lack membership:
9. e libraries (LIB_TF)

Yaron: This task force is still not fully started – I repeat the request for volunteers and for a lead.

8. Patent policy

As required by the IEEE SA, this is a reminder regarding the IEEE patent policy. Please 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 registered.

Please DON'T send these e-mails to the reflector
Use the e-mail address you registered with

In about a week, the on-line roster should be updated

Yaron : I propose to have the next meeting on Tuesday, July 6th at 9:00 AM pacific (same time as today's meeting).

No other business to discuss.

10. Adjourn

Motion to adjourn by Darren
Second: Serrie

IEEE/SA home
IEEE Standards Association

DASC Home
Design Automation Standards Committee

VLSG Home
Verification Language Study Group

The 1647 PAR
Project Authorization Form

(Updated Wed Oct 11 16:18:23 PDT 2006)