← Back to context

Comment by Athas

7 years ago

Pointers are not even necessary for writing operating systems or memory allocators. The Oberon system writes those low-level components using intrinsic peek/poke functions (like some ancient BASIC!) that are recognised specially by the compiler and turned into direct memory modifications. This is clearly just as unsafe as pointers (probably more so), but it means you don't generally pollute the language to support some very specialised code. The rest of Oberon is memory-safe and garbage-collected (with the garbage collector also written in Oberon).

9 comments

Athas

Reply
josteink  7 years ago

> The Oberon system writes those low-level components using intrinsic peek/poke functions (like some ancient BASIC!) that are recognised specially by the compiler and turned into direct memory modifications. This is clearly just as unsafe as pointers (probably more so), but it means you don't generally pollute the language to support some very specialised code.

How is "val = PEEK adr" and "POKE adr, val" any less polluting than allowing "val = &adr" and "&adr = val" in select places?

  • eterps  7 years ago

    It makes it easier to analyze code (i.e. greppable), and it allows for a distinction between operations that do direct memory modification and regular application code (pass by reference is accomplished with an entirely different syntax in Oberon, same for pointer types).

  • pjmlp  7 years ago

    It shouts to you, "Take care something dangerous going on".

    Hieroglyphs are easy to pass by.

    • josteink  7 years ago

      Lots of languages (like C#) allow pointers, but only inside blocks explicitly declared to be unsafe.

          void DoSomeUnsafeStuffHere()
    {
        // regular code here. pointers verboten.
        
        unsafe
        {
             // pointery stuff here
        }
    }

      I think that is equally clear, if not even more. And again: I don't think this is any more polluting than weird out of place PEEK/POKE statements.

      4 replies →

informatimago  7 years ago

It is as unsafe as pointer, if those PEEK and POKE operations don't perform any control. But there's no reason to allow random PEEK and POKE from random processes. The system process that manage memory may be given the access rights to PEEK and POKE the memory manager registers. But not the IDE registers. And application processes won't have the right to PEEK and POKE anything.