Re: Oberon and Wirthian languages

[Shark8 <OneWingedShark@gmail.com>]

On 19-Apr-14 11:35, Jeffrey Carter wrote:
> On 04/19/2014 04:50 AM, Ludovic Brenta wrote:
>>
>> 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 :)
>
> That would make the language unsuitable for its intended purpose of
> replacing C for S/W like OpenSSL.
>
> My experience (unfortunately on more than one example) of Ada designed
> and written by coders is that they eschew user-defined numeric types and
> numeric subtypes. They pick a few numeric types, predefined if at all
> possible, and use them for everything, just like C.

One of the problems is that specs have become dependent on C and C-ish 
terminology as an example, let us examine the basic definitions in TLS:

> 6.2.1.  Fragmentation
>
>    The record layer fragments information blocks into TLSPlaintext
>    records carrying data in chunks of 2^14 bytes or less.  Client
>    message boundaries are not preserved in the record layer (i.e.,
>    multiple client messages of the same ContentType MAY be coalesced
>    into a single TLSPlaintext record, or a single message MAY be
>    fragmented across several records).
>
>       struct {
>           uint8 major;
>           uint8 minor;
>       } ProtocolVersion;
>
>       enum {
>           change_cipher_spec(20), alert(21), handshake(22),
>           application_data(23), (255)
>       } ContentType;
>
>       struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           opaque fragment[TLSPlaintext.length];
>       } TLSPlaintext;

As we can see here the 'length' should not be "uint16", but instead:
	Range 0..2**14 {with a Size specification of 16 bits.}
Another illustration comes from the enumerations; for "ContentType" 
there are 4 possibilities, which means we could fit them into a 2-bit 
field -- but the size is unintuitively specified by the null-enumeration 
with a value of 255.