Re: A case where Ada defaults to unsafe?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Ted Dennison<dennison@telepath.com> writes:

> In article <wccwuyycht9.fsf@shell01.TheWorld.com>, Robert A Duff says...
> >If you're looking for cases where Ada makes the default less safe, I can
> >think of a few.  Here's one: "X: T := ...;" is a variable, whereas
> >"X: constant T := ...;" is a constant.  IMHO, it should be the other way
> >around ("X: var T := ...;" for a variable), since constants are safer
> >than variables.

> I think this is another example of the *real* design principle here,
> which is to make the more common and more general form take the least
> syntax, and use added syntax to specify a more constrained and/or less
> common form.

I do not agree with that design principle.  The default should be the
thing that is safer/less-powerful.  To use the
more-powerful/more-dangerous option should require extra syntax.
What's more common is irrelevant.

Of course, one hopes that the safer thing is also the most common thing.
For example, if programmers have to do type conversions or unsafe casts
on every other line of code, then something is wrong with the language
design -- whether those casts are explicit or implicit.  So in practise,
your principle will often come up with the same answer as mine.

Many Ada programs use variables where they should use constants.  Making
the default the other way around (i.e. not punishing the safer case with
verbosity) would somewhat alleviate that problem.

The choice of "variable by default, constant requires explicit notation"
is particularly annoying to me because it is inconsistent: for
parameters, it's the other way 'round.

An interesting question is whether variables are more common than
constants in Ada.  I have no idea.  If you adopt a "mostly functional"
style, you'll have a lot of constants...

> If I try real hard I can come up with reasons why just about any
> design decision might have error-prone implications (particularly if I
> start with the postulate that everyone thinks like a C programmer).

My point above has nothing to do with C or C programmers.

- Bob