Re: Oberon and Wirthian languages (was: Heartbleed)

[Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>]

On 2014-04-19, Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
> 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.
>>

[Note: There's a Ada language lawyer question below for those of you
who like such things. :-)]

>> 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).

I can't speak for all Wirth style languages, but that's certainly true
for Oberon-2 and it was true for things like the dialects of Pascal
I have used in the past.

In Oberon-2 however, if you create two record types, each with a single
INTEGER within the record, then you can't assign one record to the other:

obc -o typetest typetest.m
"typetest.m", line 25: record type 'rectype2' is needed on the RHS of this
assignment
>       rec2            := rec1;
>                          ^^^^
> This expression has record type 'rectype1'

I got round to double checking this today with the very latest version
of the the Oxford Oberon-2 compiler, which I wanted to do before posting.
You also can't perform a plain assignment which would result in the
loss of data by moving a integer into a smaller sized integer.

This is unlike how Free Pascal apparently behaves, BTW. From:

	http://www.freepascal.org/docs-html/ref/refsu5.html

|Free Pascal does automatic type conversion in expressions where different kinds
|of integer types are used. 

I'm going by the documentation as I have never used Free Pascal (and
after reading the above I'm not exactly motivated to try it now. :-))

The suggestion of a Oberon variant as a base was to choose something
as close to C as possible, which would then have some basic Ada style
functionality added into it.

> 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.

Agree with all those, and they are something I would want to see in a
C replacement language.

> - Representation clauses for device registers (record field selection
>   rather than bit masks).

Getting rid of C style masks should be a major goal and the above is
required but not sufficient.

To remove all the usage cases for C style masks, we would need atomic
access to registers when using bit fields and a way to update a specified
list of bit fields at the same time (in a read register/modify bitfields
/write back to register operation); either in code:

        atomic using uart0.config1
                .flag1  := 0;
                .enable := 1;
                .txdis  := 0;
        end atomic;

(I'm not too sure about the leading dots however.)

or with a Atomic attribute on the register in question. The problem with
a Atomic attribute is that the bit fields would be updated in isolation
if the statements were separate and this is sometimes _not_ what you want
as well as being far less efficient than C style masks.

Using the above construct allows you to update a subset of related bit
fields as one operation.

Language lawyer question time:

What I have not checked however is if a record assignment in Ada to a bit
field record variable marked as Atomic would result in all the bit fields
listed in the assignment being _guaranteed_ to be updated at the same time
or whether there would just be a atomic update of each component in
isolation.

(Unfortunately, as I need my bare metal code to run on a large range of
platforms, it's usually written in C so I've not actually tried to write
the above construct. Cohen appears to be silent on the issue and the
Ada 95 RM didn't help either.)

Any Ada language lawyers around who could answer the above question ?

> - Higher level of abstraction for tasking (rendezvous rather than
>   semaphores).

Tasking should not be a part of a C replacement language. You want
something which is going to be able to replace, in existing applications,
libraries written in C.

> - Exception handling.
>

Exception handling would be nice, but it would have to be a local to the
current module exceptions model only. How would you push the exception
back to the caller when the caller could be written in any language ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world