Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: gah4 Newsgroups: comp.compilers Subject: Re: What attributes of a programming language simplify its implementation? Date: Mon, 3 Oct 2022 12:28:56 -0700 (PDT) Organization: Compilers Central Lines: 57 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-10-017@comp.compilers> References: <22-09-026@comp.compilers> <22-10-002@comp.compilers> <22-10-004@comp.compilers> <22-10-012@comp.compilers> <22-10-014@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="61940"; mail-complaints-to="abuse@iecc.com" Keywords: design, history, syntax Posted-Date: 03 Oct 2022 16:30:48 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <22-10-014@comp.compilers> Xref: csiph.com comp.compilers:3189 On Monday, October 3, 2022 at 11:15:17 AM UTC-7, rob...@dodo.com.au wrote: (snip on some use of PL/I) > Yes, STRINGSIZE,** like STRINGRANGE***, SUBSCRIPTRANGE, SIZE, > FIXEDOVERFLOW*, etc > are not enabled by default. > Originally, these were not enabled because it took extra instructions > to implement the test on S/360. (and our moderator wrote) > [I agree that adding two numbers and getting three spaces was bad > practice, and there were ways to avoid shooting yourself in the foot. > My point was that there were situations where each individual step was > reasonable, but the combination was absurd. Those are hard to > completely avoid. PL/I had a lot of them for entirely understandable > reasons. That didn't mean it was a hard language, rather that you > had to understand what you were doing. -John] The reason for mentioning PL/I was because, in comparing to Fortran it is easy to see where Fortran was designed for ease of implementation (even though the designers will disagree), and PL/I for ease of use (even though it is easy to find counterexamples.) PL/I, in all the places where it makes any sense, allows for the completely general form of expression. To do that, it allows for some conversions which give surprising results. Fortran instead restricts you from doing things that make sense, to stop you from doing things that don't. In the case of ENTRY (a rare language feature by now), Fortran EQUIVALENCEs the different return values, where PL/I allows for the appropriate conversion. PL/I has (only) generic intrinsic functions. You can give any data type, including CHAR, to SQRT. Fortran added generic intrinsic functions in Fortran 77, though not quite completely. Yet you still can't use SQRT on an integer type. It can't be that hard to implement the conversion to floating point, but it might cause other changes to the language. In Fortran 77, they added the ability to use floating point data type in DO loops. In Fortran 90, they removed that ability. It can't be all that hard to implement, and there are problems in using it, but they aren't all that bad. Since PL/I allows the same type of expression everywhere, compilers only need to implement it once. Fortran has complicated rules on what kind of expression you can use where. Even though it simplifies each one, compilers have to implement them all, and use each one in the right place. Users have a hard time remembering which one goes where. In the end, Fortran rules meant to simplify the implementation actually make it harder.