Re: a note on notations

[John (Most modern computers would break if you stood on them) Mackin <john@ civil.su.oz.au>]

Here are my first-cut comments on the issues raised in this thread.
I'm writing to the list about this at once since Paul asked for
quick reactions; I don't normally like to fire from the hip, so
I'd ask your indulgence if I haven't quite thought it all
through.  On the other hand, I do have VERY strong feelings about
all this, otherwise I'd keep silence.

I will try to progress from the general to the specific.

I believe that a redirection operator that opens for read and
write is an excellent idea and definitely belongs in the shell.
I once had to code a C program merely because the shell I was
using lacked that very ability.  I agree, it is not used all
that often -- I have only needed it that once, I think, in fourteen
years of working with UNIX.  On the other hand, I really felt
put out when I had to write that program.  This is the sort of
thing the shell should do for us when we need it.

Regardless of former art, I think that any such operator should
certainly NOT truncate the file.  If you want truncation, it's
as easy as writing ">file; command <>file".  Open for read and
write means just that, open for read and write.  It does NOT
mean "with truncate".  Three-argument open() sucks.  The
redirection should give us access to open(..., 2).

I have always agreed, and have said publically before, that the
<>{ ... } syntax bites the big one.  On the other hand, I haven't
been able to come up with a better suggestion before now.  I would
be very pleased to see <> become a redirection operator and the
return-value syntax become something else.

I will spit flaming blue comets if ":" as a word becomes special.
es has already departed from the path of righteousness in making
backslash special again (all in favour of rc's backslashes, shout AYE!);
making colon special would be totally intolerable for me.  The reason
is that I use the Pike prompt style, where : as a word introduces a
functional comment terminated by semicolon.  So I can have

: some-stuff; 

as my prompt and mouse up the whole line and send it.  Pike came
up with this idea under sh where : was built in; rc, and now es,
don't need a : builtin to support this since you simply define :
as a null function.  I will be MOST unhappy if this is broken
by changes to es.  I admit that the stench of xterm is somewhat
implicated here, but even with the best-designed terminal program
in the universe it is always going to be easier to mouse up a whole
line than a partial line.

I'm not very keen on ${foo} either.  My reasons for disliking that
are more inchoate; basically (1) it looks too much like foul mechanisms
from other bad shells; (2) $ is for variables and I wouldn't like to
see it overloaded this way.

The syntax %{foo} was indirectly suggested.  This gets my vote.  I
don't know why I didn't think of this myself; well, I do, but I'm
not going to admit to it in public.  Someone said that this was
a new and distinctive mechanism and should have a new and distinctive
syntax.  %{foo} fits the bill.  Easy to type, looks nice (as definitely
opposed to <>{foo}, and definitely new and distinctive.  Use the
Percent, Luke :).

I can't comment on the names of the hooks now; no more time.

OK,
John.