Re: Formally Defining a Programming Language

On 2011-11-19, Seima Rao <seimarao@gmail.com> 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<int, 3> 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.

Return to the comp.compilers page.
Search the comp.compilers archives again.