Re: Manifesto against Vector

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

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

So, here you are. You have to mention *all* used packages, or?

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

I hope that it is not Ada's design goal to support programming over modem
connections? Anyway, if you want to use "slow-connection/typewriter-use"
argument, then note that it works against both "with" and full names.

>>>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_*;

No. "without" would be a contract not to use something. At least it would
have some sense. "with" is just a comment. So far nobody brought any other
argument in its favor.

> 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? (:-)) Honestly, I would
agree, they erode the language. But it is an inevitable evil.

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

>>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. For example: 

A.B.C.D.E := 2;
  -- We need A
  -- We need A.B too
  -- Not to forget: A.B.C
  -- And A.B.C.D, of course

>>>(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? ;)

I have asked first! (:-))

>>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". You can replace it with another - "start with "use"". Even if you
want both, fine, Ada supports this too, multiple "uses" of the package are
OK!

> and no human would know about what really *is* used
> without reading the whole source file.

Why a human should know? The point is that "use" helps a reader to
understand the program. If it does not, do not use it. If it does, then its
mission is over, there is nothing to "know" here. As simple as that.

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

Only if it is "with use". I talked about "use" implying with. That would be
compatible with any principle, even with one requiring avoiding "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.

>>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!]

> 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. In
which case you were right. For example:

-- This is not Ada!
package A is
   End_Error : exception is private; -- Will be defined later
private
   End_Error : exception renames Ada.IO_Exceptions.End_Error;

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

This has nothing to do with renaming [*].

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

Then re-read your arguments, and choose something! (:-))

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

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

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

>>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*. And, well,
hire better programmers! (:-))

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

Child packages are just a form of "with/use".

---
*) Except view changing renamings, which alas are also inconsistent in Ada.

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