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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: Build language with weak typing, then add scaffolding later to strengthen it? Date: Tue, 26 May 2015 09:46:00 +0200 Organization: A noiseless patient Spider Message-ID: References: <127b004d-2163-477b-9209-49d30d2da5e1@googlegroups.com> <59a4ee45-23fb-4b0e-905c-cc16ce46b5f6@googlegroups.com> <46b2dce1-2a1c-455d-b041-3a9d217e2c3f@googlegroups.com> <3277d769-6503-4c7f-885f-3a730762b620@googlegroups.com> <3e343282-202d-48e0-b8ab-2f427c1d8c3c@googlegroups.com> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 26 May 2015 07:44:50 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="17284"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Z/KdqgX38jMIh4hWeCozqumd+m1XRElY=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <3e343282-202d-48e0-b8ab-2f427c1d8c3c@googlegroups.com> Cancel-Lock: sha1:lShqG9jZSAn5KhtbGZ5w52tKLnI= Xref: news.eternal-september.org comp.lang.ada:25995 Date: 2015-05-26T09:46:00+02:00 List-Id: On 25.05.15 21:54, jan.de.kruyf@gmail.com wrote: >> One simple instance of this is case-coverage -- Ada is one of the [relatively] few languages that requires all possibilities to be specified, this is due to the prevalence of C and its influence on language design (in particular its choice to make enumerations an alias for int-values) -- wich is a feature Ada has had since its inception. > It is also in the 17 pages, notwithstanding Georg's doubts. If it is not it is an oversight in the editing. > The CASE construct of the Oberons should be what the reports say it is. Any the report does establish a foggy idea. Reiser and Wirth repeat the same in their accompanying text book from 1992(en)/1994(de). In 9.5, "The Programming Language Oberon" states for CASE: "If the value of the expression does not occur as a label of any case, the statement sequence following the symbol ELSE is selected, if there is one. Otherwise it is considered as an error." Difficulty arises from the report's language here: the pronoun "it" just does not clearly point to anything serving as a noun. The word "error" has no definition. What is the programmer to expect? (C-style approach, of course: be pragmatic, try it with your implementation, do what a proper engineer does, etc. etc..) But the style of the report blends well with the idea of one person writing and entire system, including OS, compilers, GUI, and tools alone, since case coverage seems a bit more demanding than Wirth's pragmatic shortcut would allow. Oberon-07 does not even address the issue, since ELSE is gone. Easy. So, I guess, CASE acts like an IF-ELSIF-... without an ELSE. The report does not say. But it adds some other uses of CASE for type extensions, quite clearly quoting from some unknown contexts, and not introducing things like Si. Not surprising, then, that the report can be shorter than usual.