Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!nerds-end From: Kaz Kylheku Newsgroups: comp.compilers Subject: Re: Formally Defining a Programming Language Date: Mon, 21 Nov 2011 17:16:36 +0000 (UTC) Organization: A noiseless patient Spider Lines: 138 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-11-044@comp.compilers> References: <11-11-039@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1321934724 50587 64.57.183.58 (22 Nov 2011 04:05:24 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Tue, 22 Nov 2011 04:05:24 +0000 (UTC) Keywords: design Posted-Date: 21 Nov 2011 23:05:24 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:346 On 2011-11-19, Seima Rao wrote: > Hi, > > n designing my own Programming Language and given the existence > of a lot of programming languages and an infinity of "knowhows" that > is the Internet, I resorted to adhoc adaptation methods that worked > incredibly well! > > However, now, I want to formalize the definition of my programming > language. I find that the Backus Naur Form is a notation but reaching > to that form requires decisions such as the following illustration > would suggest: BNF gives you only syntax, which is far, far from formalizing a language. Semantics is the hard part to formalize. > Illustration of Correct C++ > ----------------------------------- > > function_declaration: > > function_specifier return_type > fct_declarator '(' param_decl ') > cv_qualifier exception_specification ';' > ; > In this illustration, I am inclined to ask: > > i) What is it that contributes to deciding that > 'inline' should be a separate "specifier" > in the grammar? The syntax of C++ is the consequence of designer whim, constrained by backward-compatibility considerations. In general, syntax in computer languages is totally arbitrary: it starts with something that seems like a nice notation, and then over the years, cruft is piled on top of it. Most programming languages do not have a technically designed syntax; it is a process driven by taste, and a (often false) intution for the psychology of the model programmer that the designer has in mind. Syntax and semantics in human languages is arbitrary also. For instance one language, a marker of past tense goes on a verb. In another, tense indication may go onto an adjective. English: ... is red ... was red Japanese ... akai ... akakatta Who decided that? It doesn't matter. In a sentence you have to convey certain things, and how those map to the tree struture of the utterance that is produced doesn't matter at all as long as the convention is reasonably consistent. > ii) How did the designers come up with > something called a "specifier"? This comes from ISO C, and may be a committee-invented retroactive naming for something. I don't have a copy of the first edition of The C Programming Language (a.k.a. K&R1) any more, but Dennis Ritchie himself might have called this a specifier, in which case it was simply inherited into ISO C when it was standardized. ISO C used that book as its principal base document. In a C declaration, there are specifiers and declarators. This is for a reason: multiple declarators, separated by a comma, can share the same "common stem" of specifiers: long int a, (*b)(), c[3]; ^ ^^^^^^ ^^^^ declarators ^^^^ ^^^ specifiers Of course, the declarators also specify something! To specify is to declare something, and to declare something is to specify! If you're passing through a border and you're asked to "declare" any goods in your luggage, you are being asked to specify what is in there: to make a statement which is specific about the contents. But since there are two different components to type specification in C, you need two words. So this is all just a word game. In Java you can do something like: int[3] a; This illustrates how syntax is abitrary. The derivation of an array type does not have to be strictly handled by the declarator syntax. The language designer can easily move it to the specifier part. Dennis Ritchie (arbitrarily!) decided that specifiers will only determine very basic things: storage class and type. All complex type derivation is played out in declarators. (This is no longer the case in C++, in which specifiers can be template types with arguments, and those arguments can be arbitrarily complex expressions: my_array_type a; . But C++ does not deviate so far from C as to give you int[3] a;) About naming, software is complex and people come up with whatever names they can come up with. Sometimes the names are silly. In the Linux networking stack, why are objects which receive notifications called "notifiers"? But everyone working with that code knows what it means. In one project long ago, we called the branches of a protocol stack in a given scenario "trousers". A packet comes in up one "leg", is processed by some routing protocol and then goes out the other "leg" to the other device. The block diagram looks like a pair of jeans. > iii) What is a "specifier" in a non-C/C++ context > by the way? Something that specifies. > Therefore, I suspect that there is a Formal Study of Programming > Languages that occurs in Selected Schools. ROFL! The word "specifier" is just something that popped into someone's head, that's all. You're not going to achieve formality just by mimicing some jargon from C and C++. To define a language formally, you have to say exactly what is the structure and behavior of each construct. It doesn't matter what words you use, as long as you define those words and use them consistently. Specifiers are symbols in a certain area of the syntax tree of a C++ declaration. That is their definition. Forget about what the word means anywhere else. If you want to call them "slepnifiers", that will work too, if you are consistent with the usage everywhere in the document.