[Oberon] SYSTEM Modules

[eas lab]

You are all solving the WRONG problem;
except:Diego Sardina wrote:
> My idea in general is to avoid any change to the language,
> especially those constructs that demonstrated to create problems
> in maintainability.
> Why don't enhance IDE capabilities?

Yes, didn't AOS start enhancing the IDE with syntax-coloring?

I've evolved strong feeling on this topic, and would like to relocate
the <swiss-author> who formally wrote about HumanComputerInterfacing.

Appeciate that Oberon "comes from PARC" [as does wily below].
Here are your problem descriptions:-

> restrict the typing overhead to the minimum under the current syntax.
> ... I wouldn’t use aliases just to save typing.

> ...interfering with the readability.
? HOW ? Don't confuse arty/looks-cool with readability.

"Oberon is a language and an *OS* ...". 2 separate aspects !
Compare our <baby style syntax>:
  C := SYSTEM.VAL(Connection, ConnTab[i]);
a function Named:VAL in Module:SYSTEM which takes 2 args ....

with eg. <shell>:
  find /PATH/File -name "*key*"  >> C
also has 2 InputArgs, but needs EXPENSIVE familiarisation to use.

Or even worse Haskell:
    (>>=) :: Monad m => m a -> (a -> m b) -> m b

Reading the documentation proves that the laguage/s is determined by
the designers' subjective FEEL.

I can't know if/that:
 the need to look/search between screen & keybrd,
 the 2-hands need to input eg. F-keys,
 the non-standard Laptop vs 101kybrds, etc.
FEELS bad to you, as it does to me -- and error prone;
because users [other than HCI specialists] don't want to analyse
and discuss their subjective feelings.

Eg. since I like to save typed-in-text very frequently:
both for ETHO & wily, removing the need to reach for the mouse for the
trivial/repeated <Store> by eg. <F2 = Store previously stored frame>
would reduce the error prone work load.
But don't mess with the language syntax.
-----------
IMO wily is an even superior 90s-PARC inspired IDE  (but lacking
ETHO's color/font versatility) :-
   Stepping through an example session might best illustrate this:

     Susan has fetched the file frob.tar.Z. She clicks with B1 in the file
     name, and with B2 in the word untarz. The utility untarz uncompresses
     and untars the file, verbosely printing file names as it goes. She
     clicks with B3 on one of the file names, INSTALL, which opens the file.
     The INSTALL file suggests that she run configure then make. She clicks
     B2 in each of these words to run the suggested programs, but there's a
     problem. The make fails when gcc quits with the error message
     keyboard.c:4: strings.h: No such file or directory.
     She clicks with B3 in the first part of the error message, which opens
     the file and selects the line. On Susan's system there is a string.h but
     no strings.h. She removes the last s with a B1-B2 chord. When she
     modifies the file, Wily sets the ``file modified'' indicator, and adds
     the word ``Save'' to the tag for this window. Susan clicks B2 on the
     word Save to write the file, clicks B2 on make again, and she's done.

   This whole process uses about ten mouse clicks and no typing.
...
   For comparison, below are the sizes of three stripped, dynamically linked
   executables on the author's sun4d Solaris system:

    167264 wily
    234272 vi
   1873336 xemacs
PS. I've got wily's simple patch, to reverse the
 <mouse frame-scrolling-direction> to match ETHO's.

==crg