Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #471

Re: Formally Defining a Programming Language

Show all headers | View raw

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]

Back to comp.compilers | Previous | Next — Previous in thread | Find similar

Thread

Formally Defining a Programming Language Seima Rao <seimarao@gmail.com> - 2011-11-19 19:15 +0530
  Re: Formally Defining a Programming Language Kaz Kylheku <kaz@kylheku.com> - 2011-11-21 17:16 +0000
    Re: Formally Defining a Programming Language "s_dubrovich@yahoo.com" <s_dubrovich@yahoo.com> - 2011-11-27 20:58 -0800
  Re: Formally Defining a Programming Language Christophe de Dinechin <christophe@taodyne.com> - 2011-11-22 20:45 -0800
  Re: Formally Defining a Programming Language federation2005@netzero.com - 2012-02-29 17:11 -0800
    Re: Formally Defining a Programming Language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-02 22:35 +0000

csiph-web