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: 
 border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ludovic Brenta <ludovic@ludovic-brenta.org>
Newsgroups: comp.lang.ada
Subject: Re: Oberon and Wirthian languages (was: Heartbleed)
Date: Sat, 19 Apr 2014 13:50:11 +0200
Organization: A noiseless patient Spider
Message-ID: <8761m535e4.fsf_-_@ludovic-brenta.org>
References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net>
 <51c7d6d4-e3be-44d5-a4ce-f7e875345588@googlegroups.com>
 <li9g34$9q8$1@dont-email.me> <%J32v.70539$kp1.45343@fx14.iad>
 <lic17o$re4$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx05.eternal-september.org;
 posting-host="4ca13d5833e8df6f1aa13db9c9e957d3";
 logging-data="16323"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX18i2/3BQKWYC3i3rPgZfP4L"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:aHVFq/fAb/SLU+3TOF7faKDxi2Y=
 sha1:6rn3X2wld6JIdF4YQZ1UGRoK4eI=
X-Original-Bytes: 3386
Xref: number.nntp.dca.giganews.com comp.lang.ada:185848
Date: 2014-04-19T13:50:11+02:00
List-Id: <comp.lang.ada>

Simon Clubley writes:
>>> What may be a viable option would be if a simpler Wirth style
>>> language existed and whose compiler generated object code compatible
>>> with gcc and used binutils for it's assembling/linking phase.
>>
>> Oberon?
>
> Something based on one of the Oberon variants is _exactly_ the kind of
> thing I was thinking of. I would modify some of the syntax elements to
> make them more Ada like however.
>
> You know, Oberon-14 sounds like a nice name for a new programming
> language. :-)

The problem I have with Oberon and its descendants is that they removed
the subrange types from Modula-2 (they are similar to Ada's subtypes of
numeric types).  Also, TTBOMK, no Wirthian language allows the
programmer to define new numeric types from scratch and make them
incompatible at compile-time (i.e. requiring explicit type conversion).
According to John McCormick's famous reseach paper[1], the most
desirable features of a programming language are, in order of
importance:

- Modeling of scalar objects.
     Strong typing.
     Range constraints.
     Enumeration types.
- Parameter modes that reflect the problem rather than the mechanism.
- Named parameter association.
- Arrays whose indices do not have to begin at zero.
- Representation clauses for device registers (record field selection
  rather than bit masks).
- Higher level of abstraction for tasking (rendezvous rather than
  semaphores).
- Exception handling.

And personally, I share his opinion :)

So, Oberon-14 or whatever its name is should not only reinstate
subranges but also allow the definition of incompatible scalar types.
If it did support all of the desirable features above then it would
effectively almost become Ada :)

Notable features absent from that list include generics, type extension,
dynamic dispatching, subtypes of non-scalar types, nested subprograms
and overloading.  A subset of Ada omitting these features would require
a compiler and run-time system much simpler than full Ada and still
bring huge benefits to the safety of programming.  Access types are
required no matter what :/

[1] http://archive.adaic.com/projects/atwork/trains.html

-- 
Ludovic Brenta.