RE: MSC-News: Proposed changes to MSC'96 grammar to make it parsa ble. (more feedback wanted)


Subject: RE: MSC-News: Proposed changes to MSC'96 grammar to make it parsa ble. (more feedback wanted)
From: Jan Docekal (jan.docekal#telelogic.se)
Date: Mon May 18 1998 - 15:12:13 GMT


Hi guys,

When I hoped that you would remain friend with me I assumed would imply
that you would agree with my propositions ;-)

As Oystein correctly pointed out my solution is not backward compatible,
but (in my opinion) my solution is more "readable" when MSC reference
expression becomes more complicated since both the parenthesis and the
keywords marks the end of an MSC's substitution. This example compares
the old grammar with my proposal

(r1 subst s1 by s2, s3 by s4 alt r2 subst s5 by s7) par (r3 subst s8
by empty alt r4)

(r1 (s1 := s2; s3 := s4) alt r2 (s5 := s7)) par (r3 (s8 := empty ) alt
r4)

If syntax highlighting is used I think the new proposal is still clearer
(see attachment in HTML).

Note that to achieve backward compatibility with the original grammar
that the parenthesis would only be added for timers and conditions in
the case they the substitutions do not contain commas i.e.

r1 subst msg s1 by s2, s3 by s4
r1 subst cond c1 by (c2, c3), (c5, c6) by c7

Unless, of course the possibility to optionally add parenthesis around
names in the original MSC'96 grammar. The changes will however not make
the grammars especially simple and the use of MSC reference expressions
might be confusing (when should/must I use parenthesis in
substitutions). I also suspect that "real life" substitutions might
become quite long, and in that case a terse notation is an advantage.

Unfortunately I must admit that Oysteins proposition has one (important)
merit! It is backward compatible! In my opinion it is not a problem to
break backward compatibility if there are no actual implementations
(tools, books, etc.). If on the other hand there exists implementations
to which backwards compatibility is crucial (e.g. nontrivial tools or
examples), I have no problem accepting Oysteins propositions.

Since some of you perhaps are not allowed to say WHY backward
compatibility is important (e.g. just finishing a tool etc.) it is
enough if you write if backward compatibility is important (but
naturally I AM interested in the reason).

Oystein also mentioned another important issue. The semantics of
substitutions. If any of You have any information/suggestions that might
change any of the two grammar proposals above, feel free to do so.

As I see it, we have two main alternatives:

1. I like the new way of writing substitutions. We should drop the
subst keyword and write all substitutions in parenthesis.
2a. Backward compatibility is crucial, add parentheses where needed.
Keep the subst keyword
2b. <Some other reason>. Keep the subst keyword.

Sincerely, Jan

PS I would also like to point out that I am only able to answer
questions regarding the Z.120 grammar and that I have no expertise in
the grammar of Z.105 and will thus admit no knowledge of that sort.

        -----Original Message-----
        From: Oystein Haugen [SMTP:etooha#eto.ericsson.se]
        Sent: den 15 maj 1998 11:19
        To: Jan Docekal
        Cc: 'mscnews#sdl-forum.org'
        Subject: Re: MSC-news: Proposed changes to MSC'96 grammar
to make it parsable.

        The originator of this message is responsible for its content.
        -----From Oystein Haugen <etooha#eto.ericsson.se> to mscnews
-----

        Jan Docekal wrote:

> The originator of this message is responsible for its content.
> -----From Jan Docekal <jan.docekal#telelogic.se> to mscnews
-----
>
> Dear MSC friends,
>
> I hope that you will remain friends after you have read this
letter.
>
>

        Dear JanYou are still my friend after this, and I believe your
work will
        make MSC an even more friendly language.

> Problem 1: Substitutions
> ====================
>
> The problem with this grammar is that an LALR(1) parser (and
possibly
> a
> human reader) has a problem with deciding when substitution
elements
> that may contain commas end (This is due to the fact that
<replace
> xxx>
> rules may contain commas and that <substitution list>s are
separated
> by
> commas. Consider the following substitution example:
>
>

        When it comes to substitutions, we have the following
challenges:1. The
        grammar is not properly parsable as pointed out above, and it
must be
        corrected.
        2. The formal semantics of substitution is still not finalized.
(i.e.
        the current Annex B just standardized omits substitution)
        3. The practical writing of substitutions is space consuming
partly due
        to the use of keywords "subst" and "by".

> Proposed solution:
>
> The keyword subst should be dropped. The following syntax
should be
> used
> for substitutions (examples analogous to the two substitutions
above):
>
> reference R (a1, b1, c1 := a2, b2, c2; d1, e1, f1:= d2, e2,
f2)
> reference R (a1, b1, c1 := a2, b2, c2, d1, e1; f1:= d2, e2,
f2)
>
> No grammar will be given for this syntax proposal at this
point since
> the syntax might be changed base on Your feedback. If the
syntax is
> accepted by the MSC community, a grammar will naturally be
provided.
>

        I do not suspect that the work on the semantics of substitution
will
        affect this discussion, but in principle the semantic
exploration may
        result in minor modification desires as well.There is no doubt
that we
        should make the grammar parsable, but we need not do this as
thoroughly
        as Jan suggests. As far as I can see, parentheses can do the
same job
        and we may be backwards compatible with the original MSC-96,
meaning
        that the example would read:

        reference R subst (a1,b1,c1) by (a2, b2,c2), (d1,e1,f1) by
(d2,e2,f2) ;

        The grammar is trivial to update.

        One problem with my solution is that the size of the clause will
        increase and not decrease. Still I think that the backward
compatibility
        and the general style of MSC point in the direction of using
"subst" and
        "by".

> Problem 2: Event "labels"
> ==================

        ....

>
>
> Proposed solution:
>

        Do whatever you find practical since it is not seen by real
users.

        Yours
        Oystein Haugen
        Rapporteur MSC

        --
        ------------------------
        Oystein Haugen, Ericsson as. , P.O. box 34, N-1361 Billingstad,
Norway
        Tel: +47 66 84 23 46 Fax: +47 66 84 19 15 E-mail:
etooha#eto.ericsson.se

        -----End text from Oystein Haugen <etooha#eto.ericsson.se> to
mscnews -----
        For help, email "majordomo#sdl-forum.org" with the body of your
email as:
            help
        or (iff this does not answer your question) email:
owner-mscnews#sdl-forum.org




This archive was generated by hypermail 2a23 : Wed Jun 19 2013 - 13:16:38 GMT