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: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-17 22:16:44 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!sn-xit-01!supernews.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc2.on.home.com.POSTED!not-for-mail Message-ID: <3B7DFA37.70534817@home.com> From: "Warren W. Gay VE3WWG" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c++ Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <9kbvsr$a02@augusta.math.psu.edu> <3B69DB35.4412459E@home.com> <9kp9n7$ivm$1@nh.pace.co.uk> <3B73337F.862F8D93@home.com> <9lb7hu$72h$1@norfair.nerim.net> <3B7C6977.3648F061@home.com> <3B7C79FA.89E62321@globetrotter.qc.ca> <3B7C9288.6CD8C288@home.com> <3B7D2033.1C780DF5@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 18 Aug 2001 05:16:40 GMT NNTP-Posting-Host: 24.141.193.224 X-Complaints-To: abuse@home.net X-Trace: news1.rdc2.on.home.com 998111800 24.141.193.224 (Fri, 17 Aug 2001 22:16:40 PDT) NNTP-Posting-Date: Fri, 17 Aug 2001 22:16:40 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:12088 comp.lang.c++:83627 Date: 2001-08-18T05:16:40+00:00 List-Id: Kaz Kylheku wrote: > In article <3B7D2033.1C780DF5@home.com>, Warren W. Gay VE3WWG wrote: > >Kaz Kylheku wrote: > >> In article <3B7C9288.6CD8C288@home.com>, Warren W. Gay VE3WWG wrote: > >> >When you can show the compiler's yacc grammer that specifically > >> >addresses specific aspects of the STL (ie. specific to certain > >> >class names), then you might have something. > >> > >> The C++ language is no defined by a yacc grammar. > > > >I'd be _real_ surprised if gcc does not use yacc to implement the C++ > >compiler. But even so, then let's move on.. > > GCC uses bison. GCC does not define the C++ language. Oh, whine about big differences please. Bison is a yacc knock-off if you havn't noticed. Good grief.. I don't believe I had to address that here. And of course GCC does not define the C++ language -- stop putting words in my mouth. But GCC is a good implementation to look at, since source code is readily available for it. > >> In the terminology that I'm using, a programming language is a broader > >> container which contains components like ``grammar'' and ``library''. > >> > >> To call the language a grammar is to mistake the part for the whole. > > > >I agree with you on this, but you are putting words in my mouth. The > >grammer does indeed help to define the language (its form and its > >rules), but obviously is not the language itself. > > > >But what about this: What language does the STL use? > > Use in what sense? What is it written in? > The library is kind of lexicon which makes available > certain identifiers in certain categories. These categories come > from the C++ syntax. You tried hard not to say "language" here, didn't you =) > Because those identifiers are available, the rest of my program which > uses those identifers has a meaning which can be inferred from the > semantic descriptions of those identifers in the standard. Bzzzt! None of those identifiers would have any meaning without a language that defines how they are assembled together. > >Hmmm.. lemme guess, it's probably C++ and perhaps a sprinkling of > >is a _translated_ library, that is shipped with "include" files. > >Again, the "include" files are written in C++. > > I can't infer this requirement in the C++ standard. Can you cite > a reference that standard headers must be files that are written in C++, > or that there must must exist previously translated libraries > as visible components? Again, tell me what you call the source code that is contained in the header files. Their written in C++ of course. > As far as I can tell, when you write #include that is > simply a magic incantation Magic now? > which makes certain identifiers > available. Those identifiers behave ``as if'' they were introduced > by C++ declarations. Again, none of those declarations would have any value if there were no language predefined that identified how they were assembled and put together to create a translation (which is the object of this process). > >But wait a minute? You cannot define something in terms of itself. > >So this leads to one of two conclusions: > > > >The language that the STL is written in is: > > The language that the library it's written in is English. Oh... so now someone is using a "English-to-object code translater" to produce your STL libraries now? You mean your STL is not written in any computer language? Don't be rediculous. > How it's > implemented is just an artifact of an implementation. I'll concede that your STL could have been entirely written in Ada, or assembler language. But we both know that no implementation of it will be done that way. You say its unimportant. I say its very important to this discussion, but you don't want to face it because it works against your argument. > Such artifacts do > not define the language and do not necessarily provide a framework for > clear, platform-independent reasoning about a language. > > Note that many components of a standard library cannot be written in > that language. Only their interface can be expressed as a declaration > that language. (How can you write, say, the time() function in C > without invoking some platform-specific system service, or > accessing clock hardware?) I already said that parts of it will not be C++. So what's your point? > The C99 standard has introduced a new header containing type-generic > macros for math functions . There is no way to write these > type-generic macros in C99! So tell me, what language are they > ``written'' in? I have to confess ignorance on this feature, because I have not seen this C99 feature yet. > Lastly, same languages have very little syntax at all; But we're not talking about some languages, but C++. > everything is > done with standard functions, or forms that resemble them. But even they have a language (which includes rules, grammer) that defines how those functions are invoked. > You could > argue that (cons ...) is not part of Lisp, but merely a library function > for constructing and initializing a cons cell; the only things that are > part of the language are parentheses, macro characters, quotes and a few > other elements of the read syntax. Yet, the majority of programs would > lose their meaning if (cons) were removed. There are special operators, > but any of those could be implemented using macros. So there is no way > to draw the division about what is core and what can be implemented as a > library. I know what you're saying above, but this last statement is simply rubbish. Admitedly, there are some grey areas but as a practicle concession, everyone (else) uses a division between language and library for very practicle reasons. You for some reason, have an aversion to it. > The syntax alone doesn't provide that core, because you'd have > nothing to bootstrap with. There are may ways of choosing the core subset > of special forms that will be intrinsic; it's an implementation choice. But without the core language, and a compiler that supports it, you cannot compile your STL _library_. The STL is written in something, which is not English. I mean, what do you call that source code that makes up the STL? Not english, not object code, hmmm, source language code, yes-- and what source code is that? -- its C++. > > - or the STL is not part of the C++ language proper. As such, it > > only enhances the usefulness of the C++ language, as a _library_ > > ``language proper'' is just a synonym for ``grammar'' or ``syntax''. > It's not a synonym for ``language''. So you say... but that is not completely what I said. In conclusion, and this will be my last word on it, since I can already see that whatever I post here, you'll just reject anyway. For the benefit of the other readers, I'll just conclude with this thought, and move on: I know the point that you are making.. yes, there is a sense that libraries and other tools (macros) enhance the use of the "facility", if you will. Language standards may even mandate that certain library facilities be provided (as does Ada95), but you'll note that these documents usually recognize that these components are library components (or macro facilities). So there is still a practical distinction between the language and the libraries, even though they may be specified in a language standard, or standards document. As someone else has pointed out, the standards committees have already made these distinctions between language, library and environment(?). This by itself shows a practical recognition by the defining standards committe that these are valid classifications to make, and used for very practical purposes. -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg