From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fce663eaf40b52f6 X-Google-Attributes: gid103376,public Path: controlnews3.google.com!news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Vinzent 'Gadget' Hoefler Newsgroups: comp.lang.ada Subject: Re: Manifesto against Vector Date: Fri, 07 May 2004 14:38:24 +0200 Organization: JeLlyFish software Message-ID: <8bsm901f05g3iuskrddo4b5uqt4i3760to@jellix.jlfencey.com> References: <7v9k901htdtm86kg9umqhptirt7vmjcr3m@4ax.com> <12dk90h0dif5h4phes8n9m9p7jo1u5gqc8@jellix.jlfencey.com> <1qem901e1v178lr2nc9lsn7hu7d46ciuea@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Complaints-To: http://news.individual.net/abuse.html X-Trace: news.uni-berlin.de Y1gLEDenfFECBf7GvCTqkgXea3+e/GQyvz0ck6Gc4wW62MbgJD X-Newsreader: Forte Agent 1.8/32.548 Xref: controlnews3.google.com comp.lang.ada:364 Date: 2004-05-07T14:38:24+02:00 List-Id: Dmitry A. Kazakov wrote: >On Thu, 06 May 2004 15:30:42 +0200, Vinzent 'Gadget' Hoefler > wrote: > >>Dmitry A. Kazakov wrote: >> >>>On Thu, 06 May 2004 11:41:11 +0200, Vinzent 'Gadget' Hoefler >>> 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 =3D> >>> -- This is OK, multiple views of same thing >>> ... >>> when End_Error =3D> >>> -- 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. --=20 To err is human, to forgive beyond the scope of the operating system.