[Oberon] Question about Oakwood guidelines and design choices

[Joerg]

Robert

Since the invention of Out.Mod (book: Programming in Oberon, 1992)
Out.Real had two parameters (r: REAL, n: INTEGER). This is because Out.Real(r, n) just calls Texts.WriteReal(W, r, n)
For human output you specify the size of the field your result is right-aligned.

Files.WriteReal(R: Rider, x: REAL) however is not for human output but machine output and just dumps the real in binary.
"Just dumping" is not totally correct: The real is written in little endian. The file can be correctly transferred between systems with different endianness.

br
Jörg

Am 06.06.21, 20:40 schrieb "Oberon im Auftrag von Robert Doiel" <oberon-bounces at lists.inf.ethz.ch im Auftrag von rsdoiel at gmail.com>:

    Good Morning,

    I was looking at the Oakwood Guidelines this morning trying to sort out 
    why an implementation of `Out.Real()` might only accept a single 
    parameter versus two (like `Out.Int()` ). The Oakwood guidelines I am 
    reading in PDF form are from Oct. 20, 1995 (URL 
    https://www.math.bas.bg/bantchev/place/oberon/oakwood-guidelines.pdf 
    downloaded on 2021-06-06) and indicate that two parameters are expected.

    Next I looked at how the Oxford compiler implemented Out and saw that it 
    was a very thin wrapper on Files using STDOUT instead of a user supplied 
    file handle.  That makes complete sense to me, at least from a POSIX 
    point of view.  But Files WriteReal() in Oakwood on;y has one 
    parameter.  Does anyone know the history behind why Oakwood as to why 
    Out.Real() and Files.WriteReal() would be different?

    I noticed in Native Oberon 2.3.6 that Files.WriteReal() does have two 
    parameters. Just curious to know the story behind the evolution from 
    1995 to Native Oberon 2.3.6.

    All the best,

    Robert Doiel

    --
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
    https://lists.inf.ethz.ch/mailman/listinfo/oberon