Re: Manifesto against Vector

[Vinzent 'Gadget' Hoefler <nntp-2004-05@t-domaingrabbing.de>]

Dmitry A. Kazakov wrote:

>On Thu, 06 May 2004 15:30:42 +0200, Vinzent 'Gadget' Hoefler
><nntp-2004-05@t-domaingrabbing.de> wrote:
>
>>Dmitry A. Kazakov wrote:
>>
>>>On Thu, 06 May 2004 11:41:11 +0200, Vinzent 'Gadget' Hoefler
>>><nntp-2004-05@t-domaingrabbing.de> wrote:
>>>
>>>>Dmitry A. Kazakov wrote:
>>>>
>>>>>Why that should be told? I'd say that "with" is superfluous.
>>>>
>>>>No! If at all then it is "use" which is superfluous. ;-)
>>>
>>>How so? "Use" has some semantical sense. It changes visibility. You
>>>might claim that this is not necessary, but that would be another
>>>story. On the contrary "with" has no other sense than being just a
>>>hint to the compiler/linker.
>>
>>And a idea to me which packages another one is using.
>
>Either you agree on that IDE could tell you that better, or I would
>claim that all packages with-ed implicitly should be made explicit!
>(:-))

Well, call me old school or so, but most of the times the only IDE I
use is just a simple text editor.

And sometimes I am just using the ssh-connection to a simple
text-based terminal to change some lines of code. No place for a big
IDE keeping track of everything here.

>>This is
>>especially useful with some of the more "evil" parts of Ada like
>>Unchecked_Conversion. :)
>
>Then it it should be "without"!

Hmm.

You mean instead of:

|with Elan520.Basic_Types;
|with Elan520.CPU_Registers;
|with Elan520.MMCR;
|with Elan520.Programmable_Address_Region;
|with Elan520.Registers;
|with Elan520.SDRAM_Controller_Registers;
|
|package body Elan520 is [...]

I should simply write:

|without Ada.*;
|without System.*;
|without Unchecked_*;

? ;-)

>BTW Ada will now have a notion of profile (like Ravenscar). It would
>be nice to have an ability to define a profile, a contract of using
>some definite subset of Ada. Like one without instantiations of
>Unchecked_Conversion.

You've never read Annex H.4?

|pragma Restrictions (No_Unchecked_Conversion);

Well, it's not exactly a profile, but seeing how many of these you
could combine just to define this or that specific profile...

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.

>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.

>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.

>>(BTW, for that discussion it might be funny to note that these days
>>even more and more of the C++-folks consider "using some_namespace;"
>>to be evil. And now we want to encourage to do exactly the opposite of
>>that in Ada?)
>
>Because Ada was designed with "use" in mind!

Hmm. What's wrong with that? ;)

>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 and no human would know about what really *is* used
without reading the whole source file.

>>For me it is still the same principle: Make something as local as you
>>can. No matter if it is a variable, a procedure, ... or a namespace.
>
>I didn't object this principle.

Well, the "with use Something;" (or whatever someone might like to see
instead) which was proposed would violate this principle. :)

It would throw me back to the old days of good ol' Turbo-Pascal where
each "uses" of a unit put the whole thing into view.

>>>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.

>When you use something twice, that does not
>create additional views.

Well, right. If you do it inside the same namespace.

>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. 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.

Remember that Ada is about software engineering and this includes
being able to compile something even without having the actual
implementation of some other packages as long as the interface is
known.

Consider when you just change the definitions in packages A and B you
will have the same problem of having three entities with the same
short name and then the compiler *really* can't know which one you
meant.
So now suppose in the former case the compiler would compile package C
(like you want it to) and now your junior co-programmer decides to
change A.End_Error and declares it as its own exception, not a
renaming because the first attempt was just a quick prototype to get
the rest of the project to compile. Now your package C would just
suddenly *not* compile, although nothing really changed considerably,
the interface of the other packages remain the same (after all,
A.End_Error is still an exception) and package C wasn't even changed a
single bit. That would cause horrible confusion.

So the current behaviour is indeed very consistent.

>>I don't know what this has to do with renaming. If you'd declare
>>End_Error separately in the packages you would run into the same
>>problem, so in fact it is a "use" problem.
>
>>Well, you might argue, just because you renamed it and thus in fact is
>>exactly the same,
>
>Yes I do.

As I am trying to argue above, this behaviour is absolutely correct.

>>the compiler could figure this out by itself. But if
>>it would really do that, it then would be me to call this behaviour
>>inconsistent.
>
>Don't you agree that there is a difference between views and viewed
>things?

Well, sort of. Yes.

>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.

>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, just because they were at the very moment you used
them?

>What is the sense of the
>conflict? Something unresolved, ambiguous, what?

The possibility that a simple change would break the project that
compiled perfectly.

>There is no problem. Just if you were consistently against any view
>management,

Oh, view management is ok.

>then you should have gone further:
>"Never use child packages, they are globally using their parents!"

Yes, they do. Of course they do: Logically such a package hierarchy is
just a big single package. The fact that you *do* break it into more
small packages and thus be able to control the views into it in some
finer granularity doesn't break anything here.

A subroutine inside a soubroutine can see its "parent", too. I don't
see any problem involved here.


Vinzent.

-- 
To err is human, to forgive beyond the scope of the operating system.