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: torbenm@diku.dk (Torben Ægidius Mogensen) Newsgroups: comp.compilers Subject: Re: Have we reached the asymptotic plateau of innovation in programming language design? Date: Wed, 21 Mar 2012 11:53:35 +0100 Organization: SunSITE.dk - Supporting Open source Lines: 37 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-03-049@comp.compilers> References: <12-03-012@comp.compilers> <12-03-013@comp.compilers> <12-03-038@comp.compilers> <12-03-046@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1332441615 38358 64.57.183.58 (22 Mar 2012 18:40:15 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Thu, 22 Mar 2012 18:40:15 +0000 (UTC) Keywords: design, history Posted-Date: 22 Mar 2012 14:40:15 EDT 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:516 Gene Wirchenko writes: > On Wed, 14 Mar 2012 09:51:31 +0100, torbenm@diku.dk (Torben Fgidius > Mogensen) wrote: > >>But intuitive syntax can also mean consistent, unambiguous and without >>arbitrary restrictions, which certainly does not apply to C-style >>syntax. In a way, APL syntax is very intuitive: Operators are single >>characters, so you dont have problems parsing things like a+++b, where >>it is not clear where one operator ends and the next begins, evaluation > > Greedy parsing. Fornm the longest token. That is > a ++ + b Indeed. But that requires knowledge of lexing/parsing methods, so it is confusing to a newbie programmer, and even some not-so-newbie programmers can get confused. A programming language should primarily be easy to read (parse) by a human reader and only secondarily be easy to parse by a computer. Ambiguity is a problem for both, but long lookahead is usually not a problem for human readers, but may challenge some parsing methods. Having a huge hierarchy of operator precedences is no problem for most parsing methods (certainly not LR-based methods), but it can make programs hard to read for humans. C++ has (IMO) gone over the top with the number of predefined operators and precedence levels. Most programmers have no problem with the four arithmetic operators, and can fairly easily also remember the precedences of comparison operators and logical connectives. So an idea (employed by, IIRC, OCaml) is to let operators have a precedence that is determined by their first character. So +. has the same precedence as + and so on. 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. Torben