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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: pjb@informatimago.com (Pascal J. Bourguignon) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.modula3,comp.lang.pascal.misc,comp.programming Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Sun, 26 Jul 2009 15:21:02 +0200 Organization: Informatimago Message-ID: <87my6rinr5.fsf@galatea.local> References: <4a6a2335.7649091@news.individual.net> <0NXam.60897$OO7.41820@text.news.virginmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net 8Vr2djcN6AzRonl3LMELHQVy5dHQz5AGfowqFU8dyd4q+Nl7Nt Cancel-Lock: sha1:YzNkM2YzOGM4MmI5NzhkOGVmYmU2ZjlmODc5YWFhYjQ3NjkyZDkxNQ== sha1:yiR04u9S+kCkfKrqPIR9fnwztDg= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en X-Disabled: X-No-Archive: no User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (darwin) Xref: g2news2.google.com comp.lang.eiffel:433 comp.lang.ada:7364 comp.lang.modula3:116 comp.lang.pascal.misc:314 comp.programming:12054 Date: 2009-07-26T15:21:02+02:00 List-Id: "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. > (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... etc... > So it all depends. Parsing this stuff is trivial. Might as well make it > available, and trust the user to use it sensibly. -- __Pascal Bourguignon__