Re: Have we reached the asymptotic plateau of innovation in programming language design?

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Thu, 22 Mar 2012 21:17:55 +0100

          From comp.compilers

Related articles
[24 earlier articles]
Re: Have we reached the asymptotic plateau of innovation in programmin federation2005@netzero.com (Rock Brentwood) (2012-03-17)
Re: Have we reached the asymptotic plateau of innovation in programmin cr88192@hotmail.com (BGB) (2012-03-18)
Re: Have we reached the asymptotic plateau of innovation in programmin mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2012-03-18)
Re: Have we reached the asymptotic plateau of innovation in programmin genew@ocis.net (Gene Wirchenko) (2012-03-19)
Re: Have we reached the asymptotic plateau of innovation in programmin eijkhout@tacc.utexas.edu (2012-03-19)
Re: Have we reached the asymptotic plateau of innovation in programmin torbenm@diku.dk (2012-03-21)
Re: Have we reached the asymptotic plateau of innovation in programmin mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2012-03-22)
Re: Have we reached the asymptotic plateau of innovation in programmin jgk@panix.com (2012-03-23)
Re: Have we reached the asymptotic plateau of innovation in programmin johann@2ndquadrant.com (Johann 'Myrkraverk' Oskarsson) (2012-06-06)
Re: Have we reached the asymptotic plateau of innovation in programmin gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-06-06)
Re: Have we reached the asymptotic plateau of innovation in programmin bc@freeuk.com (BartC) (2012-06-07)
Re: Have we reached the asymptotic plateau of innovation in programmin robin51@dodo.com.au (robin) (2012-06-08)
Re: Have we reached the asymptotic plateau of innovation in programmin Pidgeot18@verizon.invalid (Joshua Cranmer) (2012-06-07)
[17 later articles]
| List of all articles for this month |

From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.compilers
Date: Thu, 22 Mar 2012 21:17:55 +0100
Organization: cbb software GmbH
References: 12-03-012 12-03-013 12-03-038 12-03-046 12-03-049
Keywords: design, syntax, history
Posted-Date: 23 Mar 2012 18:13:56 EDT

On Wed, 21 Mar 2012 11:53:35 +0100, Torben Fgidius Mogensen wrote:


> That is a
> fairly neat idea, and by allowing all combinations of characters from a
> subset of the non-alphanumeric characters in operator names, you also
> avoid C's problem of parsing +++: It is parsed as a single operator, and
> if it is not defined in the program, that is reported as an error.


A better approach is restricted association rules requiring explicit
brackets when some operands are shared by some operators. Typically it is
the cases like:


      A and B or C
      -x^y


etc. This method will work here as well. Provided, there are


1. infix +
2. prefix ++
3. postfix ++


The rule would be that 1 cannot be associated with either 2 or 3. This
would make both interpretations illegal:


      a ++ + b (a is shared by 3 and 1)
      a + ++ b (b is shared by 1 and 2)


So the programmer would have to use brackets to disambiguate:


      (a++) + b
      a + (++ b)


--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de


Post a followup to this message

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