|
From: Arthur N. <ac...@ca...> - 2025-11-05 11:59:38
|
On Wed, 5 Nov 2025, Prof Tony Roberts via Reduce-algebra-developers wrote:
> Hi,
> I have come across two problems with Reduce trying to enable lower- and
> upper-case together. These occur with all three versions of Reduce that I
> have access to, versions spanning releases over the last five years.
>
> * First, csl-reduce seems to ignore "off raise"---it has no effect that I can
> see. For example,
>
>> Reduce (CSL, rev 6657), 10-Dec-2023 ...
>> 1: off raise;
>> 2: (x+X)^6;
>> 6
>> 64*x
Let me report on this history and through that explain the current state:
In the beginning only upper case existed. Well when I started the 5-track
teleprinter paper tape only had upper case, but the 7-track flexowriters
that were only for use by those more senior to me not only had both cases
but they could backspace and overtype to get yet more glyphs. So the world
look4ed as if it was moving towards mixed vase. But then interactive
servives began and the teletype model 33 took one back to upper case only.
After a while "glass teletypes" supported both upper and lower case. Other
places that used punched cards had similar experiences say until well
through the 1960s with that legacy persisting very much beyond then.
So Lisp obviously started off as an upper case language and McCarthy's
m-notation was usually expressed in lower case but did not go near a
computer. So early REDUCE had all internal symbols in upper case. As lower
case input devices became available it introduced a flag *raise such that
if that was set all input was case folded into upper case. Output would be
likely to come back in upper case.
Some years later use of upper case felt ugly and archaic so the PSL lisp
system (with Reduce on its back) migrated to internal use of lower case
for all the names of functions. In a way that is maybe odd it kept the
variable *RAISE (or perhaps *raise??) but now made it fols things to lower
case. The effect was that while *raise was set things continued to behave
pretty much as they did. At that time and indeed for many years later the
various packages making up Reduce sources and contributed from around the
world were not tidy wrt case sensitivity. Some remained all in upper case.
In other cases the developers knew that case would be folded but for
source code readability styled some of their identifiers in CamelCase or
just Capiralized. But they were not 100% consistent in this.
When CSL (and its predecessor Cambridge Lisp) joined the fray it wanted to
use lower case internally but it hated *raise doing a downcase, so it
introduced a variable *lower that when set case folds input to lower case.
That choice was made AGES ago now and perhaps before communication and
discussion between people was as easy as it can be now - and anyway the
expectation was that *lower would always be set so eveyrhing would
continue to work as before.
Originally both *raise and *lower were global, so if some fragment of code
needed to disable case folding for a bit (eg after seeing a "!" while
reading) it needed some mess like
begin
scalar save;
save := !*raise; (or !*lower or (!*raise . !*lower)!!!)
do stuff
!*rause := save
end;
and if doing stuff exited with an error the *raise flag would not get
repaired. So eventially CSL and PSL agreed to make both flags fluid not
global so the code could be
begin
scalar !*raise, !*lower;
do stuff
end;
and eg on PSL rebinding *fluid was meaningless but harmless. Changes
through the sources to do things that way may or may not have caught all
cases! Well your message points out that rlfi did not get reviewed, and I
expect we will in the coming days!
The above is the long story. The short one is
(1)
in PSL "off raise/on raise" enable or disable case sensitivity, but
with "on raise" input gets folded to lower case not upper.
in CSL "off lower/on lower" does much the same. And in CSL if you
have "odd" combinations of both *raise and *lower set you may
get what you deserve!
with Common Lisp at the Lisp level usually a standard input map folds
all input to upper case and then printing displays the upper
case data in lower case again for you. But there are an amazing
range of options to adjust precise behaviour. I think that the
fact that in the 1980s the Common Lisp team ended up with that
sort of excuses the Reduce confusion for having found input &
output case a muddling issue.
(2) "rlfi" claims to date from 1995. The initial comments in its source
read:
%***** Program can be used only on systems supporting lower ******
%***** case characters through OFF RAISE. ******
%***** Note that in REDUCE 3.6 one has to input REDUCE commands ******
%***** in lower case!!!!! ******
so even by then lower case astonished some. And the code in that file was
clearlky written by somebody used to working in an upper case world - eg
observe "mstyle!*:='!d!i!s!p!l!a!y!m!a!t!h;" where the exclamation marks
are to preserve the lower caseness of the characters there. I hope I have
just checked in a small change that (as you suggest) saves *raise and
*lower at the start and puts them back at the end.
It is plausible that the whole file should be reviewed so that it says eg
"mstyle!*:='displaymath;" and that as a group of developers and
maintainers we agree that while building the system the default case will
be lower.
At one time I had tried scanning all the sources to find any places where
names that were identical apart from case were present. I know I tidied up
some but am not confident that all are fixed - and if we distributed
Reduce in a case-sensitive form (just by making the default values of
*raise and *lower nil) I would expect that to hurt some users. But perhaps
it would be the right thing to do?????? Thoughts everyone...
Arthur
|