Re: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

The QVT 1.1 EBNF is

<except> ::= 'except' '(' <scoped_identifier_list> ')' <expression_block>
<scoped_identifier_list> ::= <scoped_identifier> (',' <scoped_identifier>)*

This does not allow an empty list. The proposed QVT 1.2 EBNF does not allow an empty list either. So allowing an empty list is a new issue.

Given that the CS does not allow an empty list, the change in the AS to enforce what is required in the grammar seems sensible.

Even if a new issue relaxes the EBNF to allow a default, the AS should still expand the default in the interest of minimizing run-time/analysis complexity.

So I see no need for a further change to the resolution.

If you want to allow an empty except in the grammar, raise a new issue.

    Regards

        Ed

On 07/02/2014 05:55, Sergey Boyko wrote:

Hi Ed,

An empty 'except' statement

   try {}

   except() {};

is just shorthand for

   try {}

   except(Exception) {};

I don't see any reason why this should be prohibited. Both snippets above implement so called "catch all" semantics. In C++ such semantics has representation in concrete syntax as 'catch(...) {}'. For QVT simplicity is not of the least importance and an empty 'except' clause is good choice.

Also note that currently QVTo 1.1 defines 'CatchExp::exception: Type [*]' with unbound multiplicity. Eclipse QVTo implements that.

Regards,

  Sergey.

On Wed, Feb 5, 2014 at 9:08 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi Sergey


Ballot 3 has only just started, so there is plenty of time for voters to consider changes. In 12526, 15977 of course you are correct about exceptionVariable, but I don't agree with an empty exception clause. Please start a new thread urgently if you want to discuss this.

    Regards

        Ed

On 05/02/2014 16:35, Sergey Boyko wrote:

QVT 1.2 Revision Task Force

Ballot 3 “Preview 1”

Issue 12526: Errors and anomalies in QVT 1.0 07-07-08 ZIP imperativeocl.ecore.

Property 'CatchExp.exceptionVariableName' is incorrect. There should be 'CatchExp.exceptionVariable : Variable {composes} [0..1]' in order to preserve type also.

Changing multiplicity of 'CatchExp.exception' from '*' to '+' is incorrect. Multiplicity for 'CatchExp.exception' should be '*' (so that empty 'except' statement is handled).

Issue 15977: abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught.

First, revised text for 'CatchExp.exceptionVariable' should be:

  In 8.2.2.14 CatchExp and the QVT 1.1 models add

    exceptionVariable : Variable [0..1]

Second, revised text incorrectly alters description for 'CatchExp.exception'. It should be:

  In 8.2.2.14 CatchExp and the QVT 1.1 models change

    exception: Type [*] {ordered}

Third, EBNF for '<except>' is incorrect. It should be:

   In 8.4.7 change

     to

  <except> ::= 'except' '(' <except_type_list_opt> ')' <expression_block>
  <except> ::= 'except' '(' IDENTIFIER ':' <type_list> ')' <expression_block>
  <except_type_list_opt> -> <type_list> 
  <except_type_list_opt> ::= %empty

Regards,

  Sergey.

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7068 - Release Date: 02/06/14