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

[Jörg]

Chris

Thx for your view.

In my point of view CHAR is portable if used correctly (I mean: not assuming it is one byte)
I agree: CHR and ORD are not.

SET is a little bit of a can of worms. I would call it "half portable".
"Normal" Oberon usage eg for the Sieve of Eratosthenes is pretty portable:

  CONST
    maxPrime = 1000000;
    bitsPerSET = 8*SYSTEM.SIZE(SET);
  VAR
    odd: ARRAY maxPrime DIV 2 DIV bitsPerSET OF SET; (* store all odd nbrs upto maxPrime *)
  INCL(i MOD bitsPerSET, odd[i DIV bitsPerSET]);

If you use SET low level as overlay to an interrupt mask or similar or for graphics, in addition to the nbr of bits you need to know the bit numbering.
CONST LSB0 = ORD({0})=1; you can find the bit numbering and act accordingly.

br
Jörg


Am 26.07.21, 15:40 schrieb "Oberon im Auftrag von Chris Burrows" <oberon-bounces at lists.inf.ethz.ch im Auftrag von cfbsoftware at gmail.com>:

    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
    --
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
    https://lists.inf.ethz.ch/mailman/listinfo/oberon