continuing the discussion of aleph 0 - comments please!
chris hermansen
clhermansen@gmail.com
Sun Dec 28 06:07:42 GMT 2025
Hello all, recently I wrote to the list as follows regarding ℵ0:
For example, from RR § 25.3.1.1
> >
> > MODE ℵ0 BOOK =
> > STRUCT (FLEXTEXT text,
> > POS lpos ¢ logical end of book ¢,
> > STRING idf ¢ identification ¢,
> > BOOL putting ¢ TRUE if the book may be written to ¢,
> > INT users ¢ the number of times the book is opened ¢);
> >
> > So the RR 25.1.3 states, in Step 2:
> >
> > If, in some form, as possibly made in the step above, ℵ0 occurs followed
> by
> > an INDICATOR (a field-selector) I, then that occurrence of ℵ0 is deleted
> > and each INDICATOR (field-selector) akin {151 .1.3.2.k} to I contained in
> > any form is replaced by a copy of one same INDICATOR (field-selector)
> which
> > does not occur elsewhere in the program and Step 2 is taken again.
> >
> > [The RR] replaced the ℵ0 with the dash-question-mark symbol;
> > but as far as I can tell, ultimately it's not the symbol that's giving me
> > the heebiejeebies here, it's what do do about it.
> >
> > That is, I don't understand - at all - the significance of ℵ0 in the
> > definition of the BOOK mode above.
> >
> > For instance, "ℵ0 occurs followed by an INDICATOR (a field-selector)" -
> how
> > closely is "followed"? "FLEXTEXT text" follows ℵ0 (eventually); does
> that
> > count? Or does the intervening "STRUCT" "OPEN-SYMBOL" preclude the
> > deletion of ℵ0 in this case?
> >
> > Put another way, does
> >
> > MODE BOOK =
> > STRUCT (FLEXTEXT text,
> > POS lpos ¢ logical end of book ¢,
> > STRING idf ¢ identification ¢,
> > BOOL putting ¢ TRUE if the book may be written to ¢,
> > INT users ¢ the number of times the book is opened ¢);
> >
> > ie without the ℵ0, have the same semantic import?
Jose kindly responded:
ℵ0 is just intended to describe "secret" or inaccessible entities. Any
> mode indicant (INDICATOR) or field selector (field-selector) marked by
> it is substituted by some mode indicant or field selector that only
> occur once (in their definition) in the program. i.e. they are
> conceptually replaced by some unique string that is not referred
> elsewhere in the program.
Ok, I think I understand, in general terms. "mode ℵ0" is a way of hiding
the details from users of the mode, similar to what we might call "opaque
types" in more recent programming languages.
What's not completely obvious to me is that, whereas I think Book must be a
publicly known mode (even if its details are opaque), I'm pretty sure that
modes Flextext and Pos are not meant to be publicly known.
Contrast the definition of Book with that of Channel, in the RR pp 141 -
142:
mode ℵ0 Book =
struct (Flextext text,
Pos lpos { logical end of book },
string idf { identification },
book putting { TRUE if the book may be written to },
int users { the number of times the book is opened });
mode ℵ0 Text = ref [ ] [ ] [ ] char;
mode ℵ0 Flextext = ref flex [ ] flex [ ] flex [ ] char;
mode ℵ0 Pos = struct (int p, l, c);
mode Channel =
struct (proc (ref Book) bool ℵ0 reset, ℵ0 set, ℵ0 get, ℵ0 put, ℵ0 bin,
ℵ0 compress, ℵ0 reidf,
proc bool ℵ0 estab, proc Pos ℵ0 max pos,
proc (ref Book) Conv ℵ0 standconv, int ℵ0 channel number);
mode ℵ0 Conv = struct ([1 : int (skip)] struct (char internal, external) F);
proc estab possible = (Channel chan) bool: estab of chan;
proc standconv = (Channel chan) proc (ref Book) Conv: standconv of chan;
Starting with the definition of mode Channel and working back to the
definition of mode Book:
1. proc standconv has no ℵ0 so it is published, correct? and yet it is
only used elsewhere in the RR by proc establish and proc open
2. proc estab possible has no ℵ0 so it is published, correct? and yet it
does not seem to be used anywhere else in the RR
3. mode Conv has ℵ0 so it is non-published, correct? by the way what is
that capital F? unusual to see a capital letter for a structure name in
the RR, is it not?
4. mode Channel has no ℵ0 so it is published, correct? so in theory, we
know that it is a structure but its fields are non-published
5. modes Text, Flextext and Pos have ℵ0 so they are non-published,
correct?
6. mode Book has ℵ0 so it is non-published, correct? and because it has
ℵ0, the fact that it is a structure and the nature of its fields are also
non-published, correct?
Now it seems to me that proc standconv is wrongly published since it
returns a result of proc (ref Book) Conv whereas both Book and Conv are
non-published.
I also doubt that proc estab possible should be published, but since it
does not seem to be called... maybe I'm missing something.
Moving over to van Vliet's version, mode Book is defined as:
mode ℵ0 Book =
Pseudo1 {Some mode, whose values contain at least the following
operating-system-dependent information:
- the identification string;
- some reference to the actual information, and some indication
where to read or write the next buffer (see also section 4.4.1);
- the logical end of the book ;
- information that tells whether the book may again be opened
for input or output. ;
- the maximum size of the book, as set by 'construct book' (f) or
'find book in system' (e).
To avoid excessive copying of information, the implementer is
advised to define the mode {BOOK as a reference to the necessary
data. };
mode ℵ0 Pos = struct (int p, l, c);
Note that van Vliet avoids defining all structure within mode Book with the
exception of mode Pos which is used elsewhere.
mode Channel is defined as:
mode Channel =
Pseudo6 {Some mode, whose values determine at least the
following information:
- the standard conversion key of the channel (d);
- the buffer primitives of the channel (m);
- the access properties of the channel (l);
- whether or not another file
may be "established" (5.2.a) on the channel (c);
- the (next) default identification
string of a book linked via this channel (4.1.2.g);
- the default size of a book linked via this channel (n);
- the maximum size of a book linked via this channel (4.1.2.f). };
mode ℵ0 Conv =
struct (proc (ref File, char) void write char,
proc (ref File, Binchar) void write bin char,
proc (ref File, ref char) bool read char,
proc (ref file, ref Binchar) bool read bin char);
proc estab possible (Channel chan) bool:
bool(Pseudo7) { a routine which returns true if another file
may be "established" (5.2.a) on the channel 'chan' };
proc standconv = (Channel chan) proc (Book) Conv:
proc (Book) Conv(pseudo8) {a routine which may be used to obtain the
default
"conversion key"; note that the actual primitives are not obtained
until some specific book is provided also };
Once again, both procs standconv and estab possible are to be published.
Also notice that, unlike the definition given by the RR, mode Conv is a
structure of read and write procedures that deal with reading a character
from or writing a character to a file.
Given all of the foregoing, I don't see any reason why we cannot follow van
Vliet's code more closely than that of the RR.
I also asked
> > Moving on to a concrete question, Jose, do you see sppp dealing with
> these
> > ℵ0 things? Or will we need some other pre-processor to accomplish what
> is
> > needed? Or can we move to the super-language instead?
to which Jose responded
In our case, in practice, this means that entities marked with ℵ0 should
> not be pub-licized in the module implementing the transput, so:
> module Transput =
> def
> [...]
> proc book_bounds = (ref File f) Pos: skip; { marked with ℵ0 }
> pub proc char_number = (ref File f) int: skip; { not marked with ℵ0 }
> fed
> Same for modes, priorities and operators.
> As for secret field names in structs... thats something not supported by
> Algol 68 even with the modules system: there are no secret fields and
> the user can always refer to them should she find out the names somehow.
> We can probably come with some extension for this if we wanted to, to
> improve security, but when it comes to implement the transput I think it
> is ok to just document these fields as non-public.
So in short, it seems we're not relying on sppp to deal with our ℵ0
occurrences, but rather using modules and published / non-published
components to accommodate this opaqueness, as best as possible.
Thus I guess we can imagine, again following van Vliet's version, that
1. mode Book, mode Pos are not to be published;
2. mode Channel and procs estab possible and standconv are to be
published;
3. and similarly other modes, procs etc whose definition includes ℵ0 are
not to be published;
4. fields of published structures whose definition includes ℵ0 should
not be visible outside the module but, as far as current module features
go, we have no way of defining a published but opaque type, so we will
document the intended hidden nature of the fields.
By way of illustration of the latter, assuming that the eventual definition
of mode Channel follows that of the revised report (recognizing van Vliet
leaves that as an exercise for the implementor), we might expect to see
pub mode Channel =
struct (proc (ref book) bool { hidden } reset, { hidden } set, { hidden
} get, { hidden } put,
{ hidden } bin, { hidden } compress, { hidden } reidf,
proc bool { hidden } estab, proc pos { hidden } max pos,
proc (ref book) conv { hidden } standconv, int { hidden } channel
number);
or perhaps
pub mode Channel = { opaque }
struct (proc (ref book) bool reset, set, get, put,
bin, compress, reidf,
proc bool estab, proc pos max pos,
proc (ref book) conv standconv, int channel number);
The latter appeals to me more than the former, but we may have modes with
some hidden and some published fields (which would be ugly and weird in
principle, but who knows).
Comments, thoughts, criticisms much appreciated.
--
Chris Hermansen · clhermansen "at" gmail "dot" com
C'est ma façon de parler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20251227/efb188f5/attachment-0001.htm>
More information about the Algol68
mailing list