[Oberon] [EXT] Re: A new dialect? Oberon+ (OBX)
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 ;-)
More information about the Oberon