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=unavailable autolearn_force=no version=3.4.4 Path: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Build language with weak typing, then add scaffolding later to strengthen it? Date: Tue, 26 May 2015 12:36:47 +0000 (UTC) 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Tue, 26 May 2015 12:36:47 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="6589e8f5d3c3d9872579721a7c86f373"; logging-data="18547"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/GbvadCU1htTvt+aRdeDuxw+uBONDbVj0=" User-Agent: slrn/0.9.9p1 (Linux) Cancel-Lock: sha1:sXDvCNm+Fme6FkthjOQLWExLpzA= Xref: number.nntp.giganews.com comp.lang.ada:193315 Date: 2015-05-26T12:36:47+00:00 List-Id: On 2015-05-26, J-P. Rosen wrote: > > "What remains unsaid is mostly left so intentionally, either because it > is derivable from stated rules of the language, or because it would > unnecessarily restrict the freedom of implementors." > > Translate: we don't care for portability. > The latter bit made me uneasy as well. > Another good one: Oberon's definition of a static expression: > "A constant expression can be evaluated by a mere textual scan without > actually executing the program." > > And the list of missing features is stunning, just some of them: > No user defined integer types (only two integer types: BYTE and INTEGER, > and they are /not/ incompatible), no enumeration types, no fixed points, > arrays indexed from 0, no variant records, no exceptions, no tasking, no > generics, no representation clauses, structural equivalence for array > parameters, no user defined operators, no overloading, no overriding, etc... > Be careful you don't turn Oberon into another Ada with slightly different syntax. While Oberon is too minimal, there is real potential for a easy to learn lightweight language which is safer than C and which can be used for all the things C is currently used for. When I was thinking about the possibility of a half-way language between C and Ada (I was thinking about something safer than C which wasn't as heavyweight as Ada) the above was the list of things I came up with which was missing from Oberon. I would have certainly added things like user defined integer types with ranges, enumeration types and a user definable array base index. (Basically the core low level features of Ada). I would not have added tasking or generics (this was a C language replacement). Given potential implementation issues (code written in this Oberon variant would have to interact with other languages), I wasn't sure about exceptions. Maybe local exceptions only. I was undecided about how strict to make the type conversion as well. I would never have tolerated silent conversions which cause data loss (integer to byte for example) but I was undecided about how strict to make things when going in the other direction. Given the goal in this theoretical exercise was to create a language to attract C programmers I was wondering how much the type system could be relaxed without compromising safety too much. (The language doesn't have to be as safe as Ada, it just has to be a lot better than C.) In addition, I would also have added syntax to implement atomic updating of partial aggregates as per my proposal which was turned into an AI (ai12-0127). This would allow you to get rid of C style bitmasks when updating device registers. I would also have dropped Oberon's case sensitivity or at least made the keywords lower case. I/O would be via an I/O library, not as part of the language. > Looks more like a slightly improved Pascal appropriate for teaching than > an industrial language. > But with the correct amendments, there's potential for growth just as happened with Pascal. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world