Re: Manifesto against Vector

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Mon, 10 May 2004 10:26:38 +0200, Vinzent 'Gadget' Hoefler
<nntp-2004-05@t-domaingrabbing.de> wrote:

>Dmitry A. Kazakov wrote:
>
>>Vinzent 'Gadget' Hoefler wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>> 
>>>>On Thu, 06 May 2004 15:30:42 +0200, Vinzent 'Gadget' Hoefler
>>>><nntp-2004-05@t-domaingrabbing.de> wrote:
>>>>
>>> Well, call me old school or so, but most of the times the only IDE I
>>> use is just a simple text editor.
>>
>>So, here you are. You have to mention *all* used packages, or?
>
>All directly used ones, yes. And I *want* to mention them. :)

Ah, and you surely would define "directly used" as ones mentioned in
"with". Looks much like a vicious circle! (:-))

>>No. "without" would be a contract not to use something. At least it would
>>have some sense. "with" is just a comment.
>
>No it's not just a comment. Yes, it is sort of redundancy. But
>repeating all the function declaration is, too.

It is necessary because their names can be overloaded. Package names
are also repeated in their bodies. No problem with that.

>And nobody seems to complain about that.

There are warts to complain about:

1. The parameter defaults should not be repeated in the
implementation. C++ does it right.

2. There should be a way to make the defaults private. Presently one
should expose them in the public part.

>>So far nobody brought any other
>>argument in its favor.
>
>It tells me, what I am using,

It does not:

1. See above. An incomplete truth is a lie.

2. It tells that to early, defeating the principle: "declare something
as late as you can".

3. What you are using is already said either in a fully qualified name
or in "use".

>it tells the compiler what I am going to
>intend to use. If there is a discrepancy in that I am trying to use
>something which I didn't say so before, the damn stupid compiler will
>complain. That's a *good* thing.

It will complain anyway. And note that it is quite often non-trivial,
especially for a beginner, to design a correct "with" when generics
are in play. That's a *bad* thing.

>>> Just assuming that each argument to pragma Restriction could have two
>>> options only, you could form up to 65536 different profiles alone from
>>> those 16 restrictions defined there.
>>
>>Is it an argument against profiles and restrictions? (:-))
>
>No. It's just an argument against declaring a profile for each
>possible case someone weird could think of. ;)

True. I am feel myself a bit uncomfortable with the idea of profiles.
But it seems that there is no better way. Though, don't you see that
the set of "with" clauses is a kind of profile? Then ...

>You wanted something that could forbid you to use Unchecked_Conversion
>in a project, here you have it. It's the sort of "without" you've
>asked for before.

I didn't ask for it. It was just an example.

>>>>ARM does not specify how unit library works. So even if you write
>>>>"with X", it does not warranty that X will be with-ed, especially when
>>>>it is not in the library. (:-))
>>> 
>>> Well, if it doesn't, it won't compile in the end.
>>
>>So where is any difference between:
>>
>>with Ada.Text_IO;
>>-- with Ada.Text_IO?
>
>That the compiler can tell me that it agrees with me here.

Agree on what? Again, if you bring this argument, then it should be
"without". An unused "with" clause is not an error.

>>>>You have to set up the project, use -I
>>>>key in gnatmake etc. The point is, if this work has to be done in one
>>>>place, why should it be repeated in the source again?
>>> 
>>> Because I want to fucking *know* about it.
>>
>>Put a comment to remember.
>
>NO! I want to be sure and the compiler is a good tool to give me
>confidence about it. I am the one who is making mistakes, so I don't
>rely on anything I've written. Especially if nobody counterchecks if
>this is eventually a case where I was actually right.

Fortunately the compiler *always* checks all names.

>>>>The difference is that
>>>>Ada allows view management. To drop this idea, essential for building
>>>>and maintaining large layered system, just because of a moss-grown
>>>>language where types and subroutines are global, that would be at
>>>>least unwise.
>>> 
>>> Yes, but this is exactly what "use" without "with" would be then (well
>>> well, not quite). But all the "use"s could then be scattered all over
>>> the source file
>>
>>Sorry, but you support this principle, i.e. "move "use" as far down as you
>>can".
>
>Yes. But before I do that I "with" everything I "use" at the first
>lines of the source. So I *know* if some module is fiddling around
>with the programmable address region registers for instance.

This clearly violates the principle. BTW it would also require that no
"with" be allowed in the bodies.

You should first decide whether "with X" is *always* a contract and
never an implementation detail. Once you agree that it might be the
later, then you should also agree that it would be better to deduce
it, when possible.

My position is that in many cases "with" constitutes no contract. If
it yet appears to do, then probably the package should be made a
child.

>>Only if it is "with use". I talked about "use" implying with.
>
>That's even worse. Now the only way to find out if the source is
>actually messing around with some of the nastier parts of the hardware
>is - to read each whole sourcefile.

I do not understand this. The package name is specified in "use".

>>>>>>Then semantics of renaming is inconsitent with one of "use", or better
>>>>>>to say, simply inconsistent. This is the source of numerous problems:
>>>>>>
>>> [...]
>>>>>>   when X_Error =>
>>>>>>      -- This is OK, multiple views of same thing
>>>>>>      ...
>>>>>>   when End_Error =>
>>>>>>      -- This is illegal, viewing two different views of one thing!
>>>>>>      ...
>>>>>>end C;
>>>>>
>>>>>See. That's a perfect example for a "use"-Problem, which I simply want
>>>>>to avoid (and which I want to do consistently):
>>>>
>>>>No, "use" is consistent.
>>> 
>>> Yes. I didn't say otherwise. I just mentioned that it can cause
>>> problems as you illustrated here.
>>
>>The problems are caused solely by renaming.
>
>The problem is because you have the same name in two packages which
>the compiler is bound *not* to resolve autoamtically in any way.

Names are always resolved.

>>>>What is inconsistent, is that renaming of an
>>>>exception creates a view colliding with a view of the renamed thing.
>>> 
>>> No, not exactly, we're talking about different packages here.
>>
>>It is no matter. [BTW, renaming A to B does not create any new package. If
>>renaming would be consistently inconsistent (:-)), it would clash in
>>"use"-ing both A and B!]
>
>No. It doesn't even clash if you use "Ada.Text_IO" twice. So why
>should it here?

According to your [wrong] theory it should, because once I have
renamed A to B, I have different names A.* and B.* which should
collide.

>>> What
>>> you've created here was:
>>> 
>>> |A.End_Error;
>>> |B.End_Error;
>>> 
>>> and (not exactly created)
>>> 
>>> |Ada.Exceptions.End_Error;
>>> 
>>> Yes, because of the renaming in this example those are all the same
>>> thing.
>>> 
>>> _But_: the compiler does not want to know about the implementation.
>>> So, because nobody can hinder me to change the definition in A and/or
>>> B later, it won't know [and even if it does, it does not *want* to ;)]
>>> that all these names all denote the same entity. So when you said just
>>> "End_Error", the compiler could not know which one to choose, of
>>> course. Really, it does not matter that all these names in fact just
>>> accidently denote the same entity, they are not bound to do this each
>>> time.
>>
>>Wrong. The example was *not* a case of implementation through renaming.
>
>The compiler sees a package. It sees a name for one or more entities
>there and their corresponding type. That's it. It doesn't care about
>any implementation at this stage. This gets resolved later. (At least
>that's what I'd say.)

Wrong. Observe that the following is illegal in Ada:

with Ada.IO_Exceptions;
procedure Test is
   End_Error : exception renames Ada.IO_Exceptions.End_Error;
begin
   null;
exception
   when End_Error => null;
   when Ada.IO_Exceptions.End_Error => null;
end Test;

End_Error and Ada.IO_Exceptions.End_Error is the same thing. And the
compiler perfectly *knows* that. Your theory that renaming is an
implementation is wrong.

>>>>How could names indicating the same thing conflict?
>>> 
>>> Because they are not in the same view.
>>> 
>>> Just because someone writes "Foo : constant Some_Type;" and another
>>> "Bar : constant Some_Type;" and in the private part they *are* the
>>> same that doesn't mean, you will *not* sooner or later run into
>>> problems when you just randomly interchange them in your code.
>>
>>There is absolutely no problem with that, if you mean Foo privately renaming
>>Bar. In public view there are two *different* Some_Type, because you have
>>an implementation through renaming. On the contrary in private view there
>>should be only one object!
>
>So what's the difference here? Why shouldn't the compiler know about
>the more private parts (in fact, at some stage it needs to know at
>least to preserve enough storage space for the type) here?

The difference is that the public part is a contract to fulfil. If it
states that Foo is not Bar, then they should appear as such. The
implementation (private part) may privately change this, if necessary,
but that may have no influence on the contract.

>>>>What is overloaded here to cause the conflict?
>>> 
>>> Common sense?
>>> 
>>> Who tells you that A.End_Error and B.End_Error have to remain the same
>>> in all eternity,
>>
>>They were declared as such. This is the contract, because it happened in the
>>public part.
>
>And where in the contract does A know about that it will be renamed by
>B?

Does that matter?

>>> just because they were at the very moment you used
>>> them?
>>
>>See above. If the program designer had an intention to keep them separate
>>he/she should have chosen other design.
>
>Quick prototyping? Just filling out some blanks so that it *will*
>compile some of the more important rest?

To do that one needs no renaming. One should just declare End_Error as
an independent exception.

>>>>What is the sense of the
>>>>conflict? Something unresolved, ambiguous, what?
>>> 
>>> The possibility that a simple change would break the project that
>>> compiled perfectly.
>>
>>The project will cease to compile. This is what we have *NOW*.
>
>No, not if you don't use "use". So we're back at the evil that causes
>the problem.

See my example. It will never compile, because either with or without
"use" A.End_Error is Ada.IO_Exceptions.End_Error.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de