Re: Manifesto against Vector

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

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

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

It doesn't have to do anything with "slow" (I still can't type that
fast to outperform even a really slow 56K-connection, can you?). It's
just the case that I don't have the cool IDE running there that tells
me everything about my project like "this type's from here, that from
there, etc. pp.".

>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. And nobody seems to
complain about that.

>So far nobody brought any other
>argument in its favor.

It tells me, what I am using, 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.

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

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.

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

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

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

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

Because the people who must write and later understand the source code
*are* humans, not machines or some nifty IDE.

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

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

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

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

>> 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 [*].

I tried to explain it. Of course my view could be totally wrong, I am
trying to be an Ada practitioner, not a language-lawyer. And in my own
personal view this all makes almost perfect sense.

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

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

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

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

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

That's your personal viewpoint. For me its a big package that allows
different "peek" views into it, depending on what is really needed. Of
course this personal view is totally wrong, too, because the whole
purpose of child packages were to be able to extend some package
without even touching the existing one. :)


Vinzent.

-- 
Wenn alle Stricke reissen, kann man sich immer noch erschiessen.