Re: Build language with weak typing, then add scaffolding later to strengthen it?

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

On 2015-05-26, J-P. Rosen <rosen@adalog.fr> 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