Re: exiting a bloc

[Ted Dennison <dennison@telepath.com>]

Philip Anderson wrote:

> Ted Dennison wrote:
> >
> > arrays (particularly strings) dynamicly on the stack. I think I've also used
> > them in the "accept" alternatives of server tasks or in branches of large
> > command-processing case statements to declare local variables that are
> > unique to that alternative.
>

> anyway - no dynamic arrays, tasks or exceptions.  Branches of case
> statements could arise, but it would seem more readable to call a
> procedure if one is that complicated.

That's quite true for a complicated branch. But I wasn't talking about a
complicated branch. I was talking about a simple branch in a large case statement
(like one I wrote for a embedded device using Alsys's SPARK compiler :-). This
kind of thing happens in command processors a lot. Many of the branches may need
variables that no other branch requires. You could make each small branch a
subprogram. But that would give you tons of little 3-line subprograms, and you
*still* have the huge case statement.

Of course one way to handle this now is to use tagged types and dynamic
dispatching. But if the commands come in from outside the Ada system (as they did
in the system I mentioned above) that won't work. There's no simple way to convert
a command ID into a tagged type's tag.

I'd also dispute the idea that since SPARK disallows a lot of Ada constructs, its
OK to disallow more of them by fiat. To the contrary, I think you *need* all the
language features you can get in SPARK. For instance, pointers are *not*
disallowed in SPARK (at least not by the compiler I used). The allocator "new" was
not available, but that's not the same thing. But I found it invaluable to be able
to use pointers (which I acquired by unchecked_conversion'ing addresses). Many
other developers on the project acted as if pointers were prohibited. So they had
to achieve the same effect using "for use at" overlays, which caused no end of
troubles during integration (in addition to being erronious code when the types
weren't always the same).

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591