[Oberon] [EXT] Re: A new dialect? Oberon+ (OBX)

Chris Burrows cfbsoftware at gmail.com
Mon Jul 26 15:40:10 CEST 2021


On Mon, Jul 26, 2021 at 10:22 PM Jörg <joerg.straube at iaeth.ch> wrote:
>
> What do you think of these restrictions?
> * identifiers with _ only allowed when SYSTEM is imported  (* to underline the non-portability of this feature *)

No. I prefer to restrict SYSTEM to denoting unsafe features (VAL, ADR
etc) rather than non-portable. For example CHAR, ORD, SET etc. can no
longer be considered to be portable.

Also, It would also be a new concept to import SYSTEM but then not
having to qualify the relevant items. That would be potentially
confusing to a reader leading them to wonder why SYSTEM was imported.
I've also just implemented a feature which warns if there are
unreferenced items in IMPORT lists - it would confuse that also ;-)

> * an identifier with _ is not allowed to be exported  (* to underline the locality of this feature *)

I don't like that idea. In Astrobe we have a module called MCU which
is used solely to contain all of these peripheral register definitions
e.g. for the non-vectored interrup controller

  NVICBase* = 0E000E000H;
  NVIC_ISER* = NVICBase + 0100H;
  NVIC_ICER* = NVICBase + 0180H;
  NVIC_ISPR* = NVICBase + 0200H;

We have a different version of MCU for each different microcontroller
that we support - the names are the same but the actual addresses are
often different :(

That module is then imported into the modules (SPI, I2C etc.)  that
then accesses these register values.

> * an identifier is not allowed to start with an _    (* changes in ORS are marginally easier *)
>

I agree. That is how we have implemented it. Identifiers that start
with an underscore irk me more than ones that include them ;-)

Regards,
Chris Burrows
CFB Software
https://www.astrobe.com


More information about the Oberon mailing list