Subject: RE: Return or raise in a task symbol
From: Prinz, Andreas (prinz#DResearch.de)
Date: Wed Dec 13 2000 - 07:51:55 GMT
Dear all,
Thomas wrote:
> There seems to be no harm in allowing this. Albeit the flow
> of control won't
> ever get to what follows the task I don't see much difference
> to, e.g.,
>
> task if(not true=false) return; else output S;
>
> Again, flow of control will never go beyond the task. Ruling
> these cases out
> by conditions seems very hard.
to Ricks comment:
> > As far as I can determine, it is allowed to have a return or
> > raise statement
> > in a task symbol with no other statements.
> >
> > This does make sense to me, because a task symbol always has to
> > be followed
> > by another symbol.
> >
> > Why is there not a condition that prevents this?
In this context it might be worthwhile to reconsider the shape
of the grammar as well as the abstract grammar. Currently there
is a distinction between action-nodes and terminator-nodes.
The understanding is that terminators must always appear as
last nodes. The problem is, that currently in the concrete
grammar decision is an action whereas in the abstract syntax
it is a terminator.
This is only possible because we have some transformations
handling the decisions. This introduces some non-intuitive
labels.
However, already with the introduction of the statement list,
the distinction between action and terminator appears to be
arbitrary and not necessary.
We could give semantics to terminators followed be actions
easily (just ignore them) and we could even handle the case
of unterminated action sequences (disallow them statically
or define some kind of default).
So I would opt for dropping the distinction between
actions and terminators.
Tools could generate a warning in case of actions after terminators.
Regards,
Andreas
---------------------------------------
Andreas Prinz
DResearch Digital Media Systems GmbH
prinz#dresearch.de
Tel.: +49 30 { 515 932 256 | 386 26018 }
This archive was generated by hypermail 2a23 : Mon May 05 2008 - 20:30:55 GMT