Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!nerds-end From: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: Formally Defining a Programming Language Date: Fri, 2 Mar 2012 22:35:11 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 96 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-03-004@comp.compilers> References: <11-11-039@comp.compilers> <12-03-002@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1330900053 54639 64.57.183.58 (4 Mar 2012 22:27:33 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sun, 4 Mar 2012 22:27:33 +0000 (UTC) Keywords: theory, comment Posted-Date: 04 Mar 2012 17:27:33 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:471 federation2005@netzero.com wrote: > On Saturday, November 19, 2011 7:45:53 AM UTC-6, Seima Rao wrote: >> Can readers of this forum help direct to relevant materials wrt >> Formalism that I can study to learn about Formalisms that will >> help in deciding about my Programming Language? Do you mean formalism in describing the language, or for designing one in the first place? I suppose they are related, but they seem different questions to me. > To expand on a reply given by Kaz Kylheku: it's a dirty little > secret that the front ends of these languages are being > designed by a process that amounts to little more than wading > in the dark -- except the part about it being a secret. It seems te me that many languages could have been designed better in the first place, except that the rules for good design weren't yet known. But even more, trying to extend an existing language, and maintain compatibility with the previous one, tends to be ugly. As I understand it, one of the original goals of PL/I was to be Fortran-like, but not back compatible. (In addition to bringing in features from ALGOL and COBOL.) From "History of Programming Languages," edited by R. Wexelblat: "FORTRAN VI is not intended to be compatible with any known FORTRAN IV. It includes the functional capabilities of FORTRAN IV as well as those capabilities normally associated with "commmercial" and "algorithmic" languages. In order to embrace these capabilities in a usable and practical language, it has been found virtually impossible, and certainly undesirable, to retain FORTRAN IV as a compatible subset." and further: "Compatibility with FORTRAN IV would preclude having a simple elegant streamlined language because FORTRAN IV itself is heavily burdened with curious restrictions and complexities that have accumulated during its long history of additions that maintained approximate compatibility with early versions." (Note that the long history of additions was only about 10 years, as that was in 1963.) In the following 45 years (through Fortran 2008) many PL/I features have been added to Fortran, many restrictions removed, but many of the "curious restrictions" are still there. (snip) > This seems to be starting to take root in the latest revision of C. > Though C is a relatively clean language, in terms of syntax, there > already were several places -- before the 201X revision -- where > constrains found their way into the syntax: the ordinary vs. abstract > declarators, two sets of rules for type specifiers as well, a mangling > of the syntax for cast-expressions, of the assignment operator (in > that case, semantic constraints for the assignment statement were > forced into the syntax by a weird doling out of expression priority > levels). It seems to me that almost has to happen in the case of a language with reserved words. Since users might have used those words in their programs, it is difficult to maintain back compatibility with those programs, and add new features with new words. Fortran and PL/I were carefully (or not) designed without reserved words. In the PL/I case, I believe it was partly to avoid the problems of COBOL, where programmers have to keep nearby the list to avoid using them. (I still haven't written a COBOL program, so I can't say from experience.) > But now we come to 2010-2011, and we find that (last I checked) the > committee who does the ISO standards complete mangled the syntax for > structure expressions, basically duplicating it over, messing up the > syntax for cast-expressions, and forcing semantic constraints for > structured expressions into the syntax itself (e.g. that they can only > be type-cast). Those are thing you normally either (a) design around > by generalizing the language to allow for fewer restrictions, (b) > explicitly stipulating the constraint in the semantics section and > keeping it out of the syntax or (c) a bit of both. It seems that making a readable, usable to programmers, description of a language is often different from a formal language definition. It is nice to have both, and for them not to be too different. Also, as noted above, it gets worse when a language is extended, yet tries to stay compatible. (medium sized snip) -- glen [The plan for PL/I was for it to be adequate to do anything you could do in Fortran or Cobol, which it pretty much was, give or take some serious efficiency issues. IBM had a Fortran to PL/I translator which worked but produced very ugly code to work around small differences in features that worked almost but not quite the same. -John]