From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM, STOX_REPLY_TYPE autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 5b1e799cdb,3ef3e78eacf6f938 X-Google-Attributes: gid5b1e799cdb,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!cyclone01.ams2.highwinds-media.com!news.highwinds-media.com!pe1.news.blueyonder.co.uk!blueyonder!text.news.virginmedia.com!53ab2750!not-for-mail From: "bartc" Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.modula3,comp.lang.pascal.misc,comp.programming References: <4a6a2335.7649091@news.individual.net> <0NXam.60897$OO7.41820@text.news.virginmedia.com> <87my6rinr5.fsf@galatea.local> In-Reply-To: <87my6rinr5.fsf@galatea.local> Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Message-ID: Date: Sun, 26 Jul 2009 15:43:11 GMT NNTP-Posting-Host: 82.42.208.18 X-Complaints-To: http://netreport.virginmedia.com X-Trace: text.news.virginmedia.com 1248622991 82.42.208.18 (Sun, 26 Jul 2009 16:43:11 BST) NNTP-Posting-Date: Sun, 26 Jul 2009 16:43:11 BST Xref: g2news2.google.com comp.lang.eiffel:434 comp.lang.ada:7365 comp.lang.modula3:117 comp.lang.pascal.misc:315 comp.programming:12055 Date: 2009-07-26T15:43:11+00:00 List-Id: Pascal J. Bourguignon wrote: > "bartc" writes: >> "tm" wrote in message >> news:ffe34647-ed6d-4349-beb1-3f613351439d@v36g2000yqv.googlegroups.com... >>> On 25 Jul., 00:29, "bartc" wrote: >>>> The Pascal design is elegant but I've done parsers where >>>> potentially thousands of tokens need to be processed after a >>>> parenthesis before it knows >>>> exactly what it's dealing with. It's not a problem. >>> >>> The problem is not that it is not doable. >>> The problem is that human readers must also process >>> thousands of tokens to know exactly what is going on. >> >> This really means it needs to look ahead a complete expression, >> which can be of arbitrary complexity, especially if expressions can >> include statements as my design did. Examples: >> >> (expr) # ordinary parenthesised expression >> (expr | a | b) # if-then-else select >> (expr | a,b,c | z) # n-way select >> (expr, a,b,c) # list >> >> a[expr] # normal indexing >> a[expr..expr] # slicing >> etc... >> >> In practice expr will be short and only a few symbols (such as >> n+1). If the user wants to put almost a whole program in there, >> that's >> up to him. And he could probably do similar things in Pascal and >> Seed7. >> >>> When one symbol tells you, what is going on, reading is easier. >>> Complicated parsing with lookahead is IMHO an indication >>> for hard to read constructs. >> >> You can't argue the above construct's aren't easy on the eye. On the >> other hand: >> >> switch n >> when x then a >> when y then b >> else c >> end [i]:=k >> >> is probably ill-advised. It's not until the end that you realise >> it's an assignment to an array element (ie. assigning k to one of >> a[i], b[i] or c[i]). > > It's ill-advised, but because of the ill-definition of that language. > There's no reason why such an expression couldn't be written and read > easily. You just need to design your language with prefix operators > (Polish Notation) so you always know up-front what you're parsing: > > (setf (aref (switch n > (x a) > (y b) > (else c)) i) k) > > Which is even simplier than what Wirth was about. If you're going to use Lisp-like syntax then you always know what to expect, ie. (, ) or a term. But ultra simple parsing presents it's own problems when trying to read it, because of it's monotony. Richer syntax can make constructions stand out more. > >> (expr) # ordinary parenthesised expression > > expr ; if you take care of always parenthesize > ; expressions, you simplify the syntax > ; rules and don't need to further parenthesize > ; expressions. > >> (expr | a | b) # if-then-else select > > (if expr a b) > > >> (expr | a,b,c | z) # n-way select > > (select expr a b c z) > > >> (expr, a,b,c) # list > > (list expr a b c) > > >> a[expr] # normal indexing > > (aref a expr) > > >> a[expr..expr] # slicing > > (slice a expr1 expr2 > etc... Sure, you have to do some of the language's work for it by telling it what's coming up. Those forms look more like an intermediate language than original source code. It's a bit like looking at plain text representing markup instructions, then looking at the output. Clearly many people are happy working directly with s-expressions, but others aren't. -- Bart