[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Remaining Syntax Issues and Revised literal syntax
[Note that an exchange of messages follows below]
------------------------------------------------------------
Dear friends,
regarding the revised list of changes, the unresolved issues
in the first section are still unresolved.
Now I have good news: after a discussion, we decided
to withdraw our proposal wrt. the brackets problem.
Bernd insisted on having implemented Peter's proposal with our
parser, but this now has been done. So we can basically agree on
Peter's proposal, and the first of the unresolved issues gets resolved
(the others, however, remain).
One problem remains. Peter's proposal has been modified by Mark:
>1. PLACE-TOKEN-ID ::= PLACE TOKEN-ID
> should become
> PLACE-TOKEN-ID ::= PLACE TOKEN-ID+
But this leads to an ambiguity:
When parsing "{+__+}", the last "+}" can be either parsed
as one TOKEN, or as two TOKENs which are then combined
within a PLACE-TOKEN-ID.
The ambiguity perhaps could be resolved, but when trying it,
I ran into very complicated grammar changes. So we should
stay with
PLACE-TOKEN-ID ::= PLACE TOKEN-ID
as it was.
Another question is if nested comments
of form
%( ..... %)
should be allowed.
I think it would be a good idea to allow them, as in many
programming languages. The main benefit is that it is
easily possible to comment out sections with comments.
I have also incorporated the literal syntax in our parser
(but without producing the correct syntax trees yet),
so there is some confidence that the literal syntax
makes sense (if there is doubt: Bernd agreed to
incorporate the literal syntax into the summary).
Greetings,
Till
------------------------------------------------------------
Till wrote:
> regarding the revised list of changes, the unresolved issues
> in the first section are still unresolved.
>
> Now I have good news: after a discussion, we decided
> to withdraw our proposal wrt. the brackets problem.
> Bernd insisted on having implemented Peter's proposal with our
> parser, but this now has been done. So we can basically agree on
> Peter's proposal, and the first of the unresolved issues gets resolved
We should point out that although {__} will become a legal ID, {|__|}
will become illegal (since "{" and "|" would have to be separate
TOKENs, but "|" is reserved; similarly for other reserved SIGNS).
> (the others, however, remain).
It seems to me that at least some of the other unresolved issues have
essentially been settled:
* Mark has prototyped the proposal for a less ambiguous grammar for
mixfix terms. Do you have a problem with it in Bremen? Frederic,
have you tried it yet?
* The location of comments indeed remains unresolved.
* The revised proposal for literal syntax looks close to a final
version (see below).
* The changes to the abstract syntax constructor and sort names are
apparently uncontroversial.
> One problem remains. Peter's proposal has been modified by Mark:
>
> >1. PLACE-TOKEN-ID ::= PLACE TOKEN-ID
> > should become
> > PLACE-TOKEN-ID ::= PLACE TOKEN-ID+
>
> But this leads to an ambiguity:
> When parsing "{+__+}", the last "+}" can be either parsed
> as one TOKEN, or as two TOKENs which are then combined
> within a PLACE-TOKEN-ID.
> The ambiguity perhaps could be resolved, but when trying it,
> I ran into very complicated grammar changes. So we should
> stay with
>
> PLACE-TOKEN-ID ::= PLACE TOKEN-ID
>
> as it was.
Mark's modification was motivated by trying to parse a more general
version of mixfix notation than allowed by CASL; he has subsequently
reverted to the original production in his own grammar, see
<http://adam.wins.uva.nl/~markvdb/cofi/zcasl-lexical-sdf2.html.
> Another question is if nested comments
> of form
>
> %( ..... %)
>
> should be allowed.
> I think it would be a good idea to allow them, as in many
> programming languages. The main benefit is that it is
> easily possible to comment out sections with comments.
Bernd had already announced the (conditional) decision that this is to
be included: <
http://www.brics.dk/Projects/CoFI/MailingLists/cofi-language/99/msg00009.html>
[BKB: I approve %( xxx %) to be supported by all tools (unless there
is a major objection) while we should decide about the ignore at some
later date as this is really a minor tools issue]
Till wrote:
> I have revised the proposal for literal syntax according to
> Peter's comments. The new version can be obtained under
>
> http://www.informatik.uni-bremen.de/~cofi/LiteralExtension/literal.[tex,dvi,ps,ps.gz]
and later:
> I have also incorporated the literal syntax in our parser
> (but without producing the correct syntax trees yet),
> so there is some confidence that the literal syntax
> makes sense (if there is doubt: Bernd agreed to
> incorporate the literal syntax into the summary).
- Till is referring to the revised proposal here, of course.
Two queries about the revised proposal:
* how can a QUOTED-CHAR ever be used?
* since a WORD can start and finish with a prime,
it seems that a QUOTED-CHAR like 'c' could also be a WORD?
I may have missed something, but kindly clarify these points by Monday
if possible.
Thanks,
-- Peter
_________________________________________________________
Dear Peter,
> * Mark has prototyped the proposal for a less ambiguous grammar for
> mixfix terms. Do you have a problem with it in Bremen? Frederic,
> have you tried it yet?
I have implemented it and tried with a number of specifications.
> > Another question is if nested comments
> > of form
> >
> > %( ..... %)
> >
> > should be allowed.
> > I think it would be a good idea to allow them, as in many
> > programming languages. The main benefit is that it is
> > easily possible to comment out sections with comments.
>
> Bernd had already announced the (conditional) decision that this is to
> be included: <
http://www.brics.dk/Projects/CoFI/MailingLists/cofi-language/99/msg00009.html>
>
> [BKB: I approve %( xxx %) to be supported by all tools (unless there
> is a major objection) while we should decide about the ignore at some
> later date as this is really a minor tools issue]
Yes, I know, but I meant that *nested* comments of from %( ... %) should
also be supported, i.e.
spec sp =
sort s
%( op f:s->s
var x:s
. f(x)=x %( the fixed point property %)
%)
would be legal.
Moreover, comment signs %%, %(, %) within string should be ignored.
> > I have revised the proposal for literal syntax according to
> > Peter's comments. The new version can be obtained under
> >...
> Two queries about the revised proposal:
>
> * how can a QUOTED-CHAR ever be used?
A QUOTED-CHAR can be used as operation name (the intended
use it to use it as a constant name of type char). Oops,
I forgot to add this:
TOKEN ::= ... | QUOTED-CHAR
The other use of QUOTED-CHARs is via strings, which are expanded
to terms containing QUOTED-CHARs. Here, also the text should
be clarified:
The annotation has the effect that a STRING of form "c_1 ... c_n"
(where n>=0 and each c_i is a CHAR) is translated to the
(abstract syntax of) the term
f(t_1,f(t_2, ... f(t_{n},c)...))
where t_i is the abstract syntax tree for the QUOTED-CHAR 'c_i'.
> * since a WORD can start and finish with a prime,
> it seems that a QUOTED-CHAR like 'c' could also be a WORD?
Indeed, I ran into this ambiguity when revising the scanner
and resolved it in the way that 'c' is always scanned as a
QUOTED-CHAR.
But maybe it is better to require that a WORD always starts
with a letter.
I will update the text along these lines.
Thanks for all the detailed comments.
Greetings,
Till
_________________________________________________________
Dear Till,
> > * Mark has prototyped the proposal for a less ambiguous grammar for
> > mixfix terms. Do you have a problem with it in Bremen? Frederic,
> > have you tried it yet?
>
> I have implemented it and tried with a number of specifications.
Good; unless there are last-minute objections, let us consider that
point resolved.
> > > Another question is if nested comments
> > > of form
> > >
> > > %( ..... %)
> > >
> > > should be allowed.
> > > I think it would be a good idea to allow them, as in many
> > > programming languages. The main benefit is that it is
> > > easily possible to comment out sections with comments.
> >
> > Bernd had already announced the (conditional) decision that this is to
> > be included: <
http://www.brics.dk/Projects/CoFI/MailingLists/cofi-language/99/msg00009.html>
> >
> > [BKB: I approve %( xxx %) to be supported by all tools (unless there
> > is a major objection) while we should decide about the ignore at some
> > later date as this is really a minor tools issue]
>
> Yes, I know, but I meant that *nested* comments of from %( ... %) should
> also be supported, i.e.
>
> spec sp =
> sort s
> %( op f:s->s
> var x:s
> . f(x)=x %( the fixed point property %)
> %)
>
> would be legal.
> Moreover, comment signs %%, %(, %) within string should be ignored.
Right, sorry - my reading was too hasty...
Of course, allowing nested comments would put lexical analysis out of
the scope of regular grammars/expressions and finite state machines.
Do we really want to do that?
I see from your example above that you intend to use %( ... %) not
just for multi-line comments but also instead of the original %% ...
and %% ... %% notation. It may be confusing for both readers and
writers that we now have so many alternatives!
So if we are indeed to allow %( ... %), we should also consider
removing the %% ... %% form altogether. That would leave us with:
* %% ...
always terminated by the end of the line
* %( ... %)
never terminated by the end of the line
It is unfortunate that there is no time left for a proper discussion
of the above issues before the new release of the Summary. I'm
reluctant to make last-minute changes. In accord with Bernd's
previous decision, I can add something about non-nested %( ... %) in
App. C.5.1 (replacing the original %<ignore> ... </ignore> notation)
but I'd better not make any further changes in this release, other
than those announced in the revised list of changes.
Thus in the forthcoming new release of the Summary - unless Bernd
rules otherwise by Monday - %( ... %) will not be nestable, and the
short %% ... %% form will still be allowed. (This also corresponds
exactly to Mark's current lexical grammar, I think.)
> > > I have revised the proposal for literal syntax according to
> > > Peter's comments. The new version can be obtained under
> > >...
> > Two queries about the revised proposal:
> >
> > * how can a QUOTED-CHAR ever be used?
>
> A QUOTED-CHAR can be used as operation name (the intended
> use it to use it as a constant name of type char). Oops,
> I forgot to add this:
>
> TOKEN ::= ... | QUOTED-CHAR
>
> The other use of QUOTED-CHARs is via strings, which are expanded
> to terms containing QUOTED-CHARs. Here, also the text should
> be clarified:
>
> The annotation has the effect that a STRING of form "c_1 ... c_n"
> (where n>=0 and each c_i is a CHAR) is translated to the
> (abstract syntax of) the term
> f(t_1,f(t_2, ... f(t_{n},c)...))
> where t_i is the abstract syntax tree for the QUOTED-CHAR 'c_i'.
OK, that's what I suspected...
> > * since a WORD can start and finish with a prime,
> > it seems that a QUOTED-CHAR like 'c' could also be a WORD?
>
> Indeed, I ran into this ambiguity when revising the scanner
> and resolved it in the way that 'c' is always scanned as a
> QUOTED-CHAR.
> But maybe it is better to require that a WORD always starts
> with a letter.
Right, let's remove the ambiguity - assuming that nobody was really
wanting to write words starting with primes anyway...
> I will update the text along these lines.
Thanks. I'm very busy this weekend with other things, so I won't be
needing it until late on Monday.
Cheers,
-- Peter
_________________________________________________________
Dear Peter,
I have again revised the Literal Syntax document,
according to your comments. It is availabe under
http://www.informatik.uni-bremen.de/~cofi/LiteralExtension/literal.[tex,dvi,ps,ps.gz]
Greetings,
Till