🚀 go-pugleaf

In article <1635@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:

>As you see the argument is not simple. My own hunch is that mmap is
>definitely superior for things that require an arraysh view of the world, as
>it encourages taking notice of important things like the existence of pages,
>the problems with locality, etc... It is by no means the only view of the
>world, though. Terminals, tapes, etc.. you cannot mmap() (even if Mach tries
                ^^^^^^^^^
>hard with "memory objects", fake memory segments). You have to live
>with multiple paradigms or adopt the LCD of them.

But a screen *is* an arrayish device (even if your hardware connects to
it with a bit hose instead of a bitmap).  You wouldn't know it from
programming languages though, other than spreadsheets and 4GLs.

A keyboard maps more sensibly into a streamish paradigm.  Until you throw
in cursor keys or a mouse and allow the user to navigate freely...

(In another posting you referred to a block-oriented terminal as a "card-
like" device.  I realize it wasn't your choice of terms in the first place,
but don't you think a terminal with a form on it is more like a piece of
paper than a card?  A paper tape is 0-dimensional because you just get
to read/punch the current character; a card is 1-dimensional and a form
is 2-dimensional.)


On the subject of mmap() vs read(), I think there is a deeper issue.
If support for arraylike file access is included _in the
language_, 1. you don't need VM hardware, 2. if you have it you can
use it transparently, and 3. the compiler is free to do whatever magic
it wants, knowing what you are up to.  So in this case I think we could
actually learn from (shudder) PDP-11 FORTRAN by including in C support for
virtual arrays and for pointers into virtual arrays.

--
Gord Deinstadt  gdeinstadt@geovision.UUCP