From Newsgroup: comp.lang.misc

One of the things I don't find too easy to get into in Algol 68 is the formatted I/O with the FORMAT objects and its own formatting language. Meanwhile I solved all the initial obstacles... - All obstacles? - No.
There's a "simple" one left (simple in "C") where I'm still clueless!

This (probably profane) question is best described with the 'printf'
equivalent from Kornshell (not quite the behavior of /usr/bin/printf)

$ printf "v=%.1f m/s\n" .45 12.35
v=0.5 m/s
v=12.4 m/s

i.e. it shall have the properties
* one digit after the decimal point (rounding excess digits)
* one leading 0 before decimal point (for -1 < value < +1 )
* minimum required space (no blanks or other padding)

In Algol 68 I'd have to negate the first parameter of g(), but -0
doesn't work (it's considered positive) and any number like -5 would
pad the data (or create the error pattern if the number doesn't fit)

$ genie -x 'printf (($ "v=" g(-0,+1) " m/s" l $, .45, 12.35))'
v=.5 m/s
v=12.3 m/s
$ genie -x 'printf (($ "v=" g(-5,+1) " m/s" l $, .45, 12.35))'
v= 0.5 m/s
v= 12.3 m/s

Where's the trick, what am I missing?

It's (currently) not "critical", I can go with the "ugly" results of
g(-5,+1), but I'm curious whether this case is impossible to formulate
(which I doubt), or whether it's yet just hidden from my mind.

Janis

PS: I don't want to work around that problem (be it string processing,
or by using Genie's (non-standard) feature of using "C" formatting).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 24.08.2025 01:58, Andy Walker wrote:

On 23/08/2025 16:49, Janis Papanagnou wrote:
[...]

FTAOD,

(Sorry, I'm not familiar with the non-very-trivial "TLA"s or "FLA"s.)

I too [and virtually the whole of RightPondia] would
write "0.5" rather than ".5", But ".5" is legal, and is shorter.

I know, and especially in IT it's often used and certainly supported.

A single "." would be even shorter if you want to represent "0.0". :-/
Or "", which would be even compatible to Peano or Roman representations.
I'm exaggerating, of course (especially with ""). But you see my point.

A68
resolves this in favour of the third, you want it resolved in favour
of the second.

You're explaining Algol 68 mechanics. Right? - I got it; as it had
been defined in Algol 68 it's impossible to achieve directly. Right?

Right.

But, finding it difficult to resist a puzzle, I produced

$ genie -x 'OP F = (REAL x) STRING: ( x < 0 | "-" + F -x
| fixed (x, ( x < 2 | -3 | 0 ), 1)),
F = (INT x) STRING: F REAL (x);
printf (( $ "v=" g " m/s" l $, F .45, F 12.35, F 1, F -0.45 ))'
v=0.5 m/s
v=12.3 m/s
v=1.0 m/s
v=-0.5 m/s

which I hope is not too much string handling for your purposes.

I have no problem with string handling. I'm even scraping completely
trashy HTML pages for actual payload data.

I have a problem with a language/library/software design that didn't
cover a common application case. And where the solution is to work
around the problem (like you did with your hack). When I'm actually
better off writing my own [more consistent] I/O framework.

Concerning I/O Algol 68 wanted to avoid the mistake of Algol 60. Yet
there's IMO the upthread mentioned oversight? It could be handled by
a syntactical/parsing differentiation; if they'd not have interpreted
a "g(-0,+1)" as <zero>,<one>, but rather as <minus><zero>,<plus>
<one> to make it possible that the hack of formatters being part of
the numbers be effectively used to not open the gap that occurs with
"-0" being considered equal to "+0" (where -0 still is +0 of course).

There
are still a couple of edge cases which may or may not be to your taste;
left for your investigation.

I'm not inclined to spend any time to such hacks, just to circumvent
an inherent issue, in a language I use just for fun. :-)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 24.08.2025 04:49, Lawrence DrCOOliveiro wrote:

On Sun, 24 Aug 2025 00:27:33 +0100, Andy Walker wrote:

We could get 95% of the power with no new syntax at all by
moving to a [formatting] model more like C.

The drawback of the C printf model is its notorious type-unsafeness.

Indeed.

The type-safety I've got with C++'s stream output. But there you
have this bulky syntax for other properties to control I/O, etc.

What I appreciate a lot in the "C" print formats is that they're straightforward, easy to understand, learn, and memorize. The
defaults make sense (e.g. like "%d" requiring just minimum space
and if I want some specific width or precision I just add these
values). In Algol 68 we have " +42" as default
format for integers.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 24.08.2025 01:27, Andy Walker wrote:

On 23/08/2025 18:28, Janis Papanagnou wrote:

[...]

Agreed completely. But the way transput is done in the
Revised Report is a botch.

(I've never read this standards paper on transput.)

"FORMAT" adds around 50% to the A68
syntax charts [eg from one page (the Watt-Peck-Sintzoff chart) to
a page and a half]. We could get 95% of the power with no new
syntax at all by moving to a model more like C.

Well, C's model is very primitive compared to Algol 68's.
There's really interesting things you can do with that
FORMAT "sub-language".

[...]

[...]

I've tended to go the other way of declaring some new
operators in my code to get better formatting.

Well, back to Algol-like (less cryptic than "C") languages
I'm now used to even more procedure-oriented structuring,
so that I'm writing hierarchies of print_xyz procedures
that organizes the higher level structures of the data.

The lower-level structuring, though, shall be part of the
print framework/library or the language. And having here a
"gap" (as I perceived it) just hurts [me].

FORMATs don't
mix well with ordinary string-handling code IMHO. I know how
to use FORMATs, I just don't like them.

I've never considered FORMAT as (or compared it to) string
handling; these always were two completely different things.
I learned to appreciate it when I got aware that it's an
own special purpose language embedded as first class item
in that language. C's printf format is also an interpreted
language, but much more primitive than Algol 68's. C's is
also cryptic but simpler and thus more easily manageable.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 25/08/2025 00:49, Janis Papanagnou wrote:
[I wrote:]

FTAOD,

(Sorry, I'm not familiar with the non-very-trivial "TLA"s or "FLA"s.)

"For the avoidance of doubt".

[...]

I have a problem with a language/library/software design that didn't
cover a common application case. And where the solution is to work
around the problem (like you did with your hack). When I'm actually
better off writing my own [more consistent] I/O framework.

Sadly, you're half a century too late to have even a slight
influence on what is in the Revised Report. There are lots of aspects
of A68 transput that are, IMO, botched. It wasn't entirely a mere afterthought, but the primary effort went into getting the two-level
grammar sorted out. I recall commenting to one of the authors of the
RR about some lack of orthogonality; he agreed, but added that they
were so tired after getting the really hard work done that the detail
never got properly sorted. There is much of relevant interest in the
pages of Algol Bulletin [qv].

Concerning I/O Algol 68 wanted to avoid the mistake of Algol 60. Yet
there's IMO the upthread mentioned oversight?

There were lots of oversights in the RR. Most of the actual
errors got corrected [though quite a few, inc some that I reported,
did not]. It's too late. At least you have sources for A68G, and
much of the RR is also in source form.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Bach,CPE
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 25/08/2025 01:14, Janis Papanagnou wrote:
[I wrote:]

"FORMAT" adds around 50% to the A68>> syntax charts [eg from one page (the Watt-Peck-Sintzoff chart) to
a page and a half]. We could get 95% of the power with no new
syntax at all by moving to a model more like C.

Well, C's model is very primitive compared to Algol 68's.
There's really interesting things you can do with that
FORMAT "sub-language".

Yes, but you could do ~95% of them without having a mode [type] "FORMAT" that has a special syntax. There are a very few things that
would become somewhat harder, but virtually nothing that becomes really difficult.

To be clear, I'm not opposed to formatted transput [though
I don't personally make much use of it], nor to having a pre-defined
library of formatting commands; only to the invention of a special
type "FORMAT" to implement it. Also to be clear, I'm not advocating
completely unstructured transput -- A68 provides conversion routines
for parametrised conversions from numbers to strings.

C shows how you can do the simple things by using a perfectly
normal string as a formatting parameter to "printf" and its friends.
By contrast, even lexing a FORMAT denotation is a right mess -- you
can't simply go from "$" to a closing "$" because the denotation may
include nested formats that may include arbitrary amounts of A68 code, including nested strings, comments and formats [that may include ...,
to arbitrary depth]. It's not impossible [obviously!], just a lot
harder than it ought to be.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Spindler
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 27.08.2025 01:58, Andy Walker wrote:

On 25/08/2025 01:14, Janis Papanagnou wrote:
[I wrote:]

"FORMAT" adds around 50% to the A68>> syntax charts [eg from one page
(the Watt-Peck-Sintzoff chart) to
a page and a half]. We could get 95% of the power with no new
syntax at all by moving to a model more like C.

Well, C's model is very primitive compared to Algol 68's.
There's really interesting things you can do with that
FORMAT "sub-language".

Yes, but you could do ~95% of them without having a mode [type]
"FORMAT" that has a special syntax.

Well, having the FORMAT (effectively a sub-language) being an own
first-class element fits quite well into the language paradigm. I
also think that if you'd use (as "C" does, but unlike Awk [modulo
dynamig regexps]) plain strings as "transfer-syntax" element would
lead to inherent logical problems with formatted transput in cases
where you intersperse data with format information. Separating and distinguishing an own language/syntax syntactically is also nothing
bad. A separate type of language element (like FORMAT) could also
be handled differently - e.g. similar to, say, Awk regexp constants
precompiled (but I don't know whether that is actually done by the
tools.) I also passed FORMAT entities to generalized procedures.
As own language element type they can be statically syntax checked.

There are a very few things that
would become somewhat harder, but virtually nothing that becomes really difficult.

Well, "difficulty" lies in the eye of the beholder, but in my recent applications I used quite some features that would, say, in "C" be
possible only with explicit programmed loops outside of the printf
function. A comparably [in Algol 68] simple formatting was, e.g.,
printf (($ n(UPB pattern_array)(2x g) l $, match (...) ))
to print the elements of an array returned from the match function,
here simply separated by blanks, but more elaborate output possible.
I've yet more such examples where ordinary "C" formatting would not
help.

[...]

C shows how you can do the simple things by using a perfectly
normal string as a formatting parameter to "printf" and its friends.
By contrast, even lexing a FORMAT denotation is a right mess -- you
can't simply go from "$" to a closing "$" because the denotation may
include nested formats that may include arbitrary amounts of A68 code, including nested strings, comments and formats [that may include ...,
to arbitrary depth]. It's not impossible [obviously!], just a lot
harder than it ought to be.

What you explain as a burden is what I consider its expressive power
(compared to, say, "C"). - You don't need to make use of that power
in your programs. You pay only for what you decide use from FORMAT's
features. But all that you don't use you have to implement in other
ways, say by writing procedural code like loops (as depicted above).

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 27/08/2025 07:23, Janis Papanagnou wrote:

On 27.08.2025 01:58, Andy Walker wrote:

On 25/08/2025 01:14, Janis Papanagnou wrote:

[...]>>> Well, C's model is very primitive compared to Algol 68's.

There's really interesting things you can do with that
FORMAT "sub-language".

Yes, but you could do ~95% of them without having a mode [type]
"FORMAT" that has a special syntax.

Well, having the FORMAT (effectively a sub-language) being an own
first-class element fits quite well into the language paradigm.

No it doesn't! Revised Report section 0.1.2:

" Orthogonal design

" The number of independent primitive concepts has been minimised
" in order that the language be easy to describe, to learn, and to
" implement. On the other hand, these concepts have been applied
" 'orthogonally' in order to maximise the expressive power of the
" language [...] "

That is, in essence, the primary mission statement for the language
[after only "Completeness and clarity of description"]. There is a
reason why "FORMAT"s were commonly omitted from early compilers!

[...]

I've yet more such examples where ordinary "C" formatting would not
help.

I wasn't suggesting that "ordinary" C formatting replace A68's "FORMAT"s; rather that the formatting routines should be implemented
by using strings and structures rather than by using "$ ... $". Eg,
your example

printf (($ n(UPB pattern_array)(2x g) l $, match (...) ))

might look more like

printf ((" n (2x g) l ", UPB pattern_array), match (...) )

[where the parameter to "n" is the next item in a structure rather
than inside the format string].
[...]

What you explain as a burden is what I consider its expressive power (compared to, say, "C").

You don't need to compare with C, but rather with what A68 would
look like if formatting had been controlled in other ways than "$....$".
The burden is not so much what you, the user, have to learn, but what
the implementer has to do. Functions, strings, structures and so on
have to be provided anyway; formats are a serious added burden esp in
the lexing [for which standard tools such as Lex and Yacc are suitable
onlu with some difficulty]. [Note that the actual code for "printf"
and friends is largely given in A68 in the RR -- the difficulty is not
in providing much the same functionality, but in the parsing.]
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Spindler
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 28.08.2025 00:23, Andy Walker wrote:

On 27/08/2025 07:23, Janis Papanagnou wrote:

[...]

That is, in essence, the primary mission statement for the language
[after only "Completeness and clarity of description"]. There is a
reason why "FORMAT"s were commonly omitted from early compilers!

Algol 68 is already a comparably complex language. FORMAT is yet
another complex sub-language. It's quite obvious to me why this
feature might not have been implemented at first. OTOH, I thought
this would have been a basic inherent component of the standard,
so how could that have been omitted. (Unless you spoke about the
very early time, ~1968 vs. ~1976?)

[...]

I've yet more such examples where ordinary "C" formatting would not
help.

I wasn't suggesting that "ordinary" C formatting replace A68's
"FORMAT"s; rather that the formatting routines should be implemented
by using strings and structures rather than by using "$ ... $". Eg,
your example

printf (($ n(UPB pattern_array)(2x g) l $, match (...) ))

might look more like

printf ((" n (2x g) l ", UPB pattern_array), match (...) )

[where the parameter to "n" is the next item in a structure rather
than inside the format string].

Ah, I see. - Actually like the '*' in C's 'printf'. (Where in "C"
it's a (about the sole) higher level operation in printf formatting
syntax. And Algol 68 supports a lot more beyond that.)

Although I have to say that the form you depicted isn't too different
from the current standard one. It just hasn't the language part in the
format. Granted, it may make the work for compiler writers easier.


Though using a "string" object instead of a $format$ object would
take away FORMATs as first class object and would remove the option
to control formatting in a stream like (here just in a simple example)

$ genie -x 'printf (($ g(0) $, 42.67, $ g(0,1) l $, 42.67))'
4342.7

Note that here my point is not that you could write that differently
(say as in "C" demand the format just in a single mandatory argument
at position 1).

You couldn't tell apart a literal string from a format string. (Or
only by [unsafe] "inference", with the problem to make the language
less safe.)

(That are points why I mentioned Awk and GNU Awk in my post. GNU Awk deliberately added (and rather late) first class regexp objects into
the language; so we can (for example) pass these to procedures without
the necessity for using dynamic regexps (with their own problems that
they come as strings). And the first class regexps are also strongly
typed. An advantage compared to using strings as carrier primitive.)


I'm also curious how the format hierarchies would be achieved then;
having examples in mind where you have an outer format that defines
the structure representation of, say, an array, and an inner format
that (dynamically set) controls the formats of the actual elements'
types formatting. (I suppose you'd need a procedural approach then.)


But okay. We have what we got. Some programmers (and the compiler
implementers) may dislike it. I acknowledge that.

[...]

What you explain as a burden is what I consider its expressive power
(compared to, say, "C").

You don't need to compare with C, but rather with what A68 would
look like if formatting had been controlled in other ways than "$....$".
The burden is not so much what you, the user, have to learn, but what
the implementer has to do. Functions, strings, structures and so on
have to be provided anyway; formats are a serious added burden esp in
the lexing [for which standard tools such as Lex and Yacc are suitable
onlu with some difficulty]. [Note that the actual code for "printf"
and friends is largely given in A68 in the RR -- the difficulty is not
in providing much the same functionality, but in the parsing.]

Yes, I agree that the language implementers have a larger and more
demanding task to do.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 28/08/2025 06:35, Janis Papanagnou wrote:

Algol 68 is already a comparably complex language.

It's a comparatively simple language [simpler than its main competitors] that was badly mis-marketed. No-one wrote an "Easy
Guide to A68", so for several years the only way to learn it was
to read the Report [and later the Revised Report], 200-ish pages
of largely impenetrable two-level grammar. Even the first textbooks
were either full of mistakes or had a level of "cleverness" and
abstraction that was completely unsuitable for student use. The
size of the language was widely mocked, until it became clear that
formal descriptions of other languages were bigger [look at the
latest C standard and weep!], despite not being sufficiently formal
to describe the language properly [look again at C and weep!]. [I
could (and sometimes do) go on about this; sorry.]

FORMAT is yet
another complex sub-language. It's quite obvious to me why this
feature might not have been implemented at first. OTOH, I thought
this would have been a basic inherent component of the standard,
so how could that have been omitted. (Unless you spoke about the
very early time, ~1968 vs. ~1976?)

It was always "a basic inherent component of the standard",
but it was equally always one of the first things to be left out of implementations.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Praetorius
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 29.08.2025 01:43, Andy Walker wrote:

On 28/08/2025 06:35, Janis Papanagnou wrote:

Algol 68 is already a comparably complex language.

It's a comparatively simple language [simpler than its main
competitors] that was badly mis-marketed.

Hmm.., well. I commonly only heared about it's been considered
huge and hard to (fully?) understand, sort of; IOW, "complex".
Personally I think its coherence compensates that "complexity".
(I put it in quotes to not stress those subjective feelings.)
The original topic of this thread, the FORMAT sub-language, is
IMO an obvious example for this complexity. (There's a couple
other things I see here, but I don't want to stress that now.)

(And we have to differentiate between complexity of a language
and its standard description, independent of the grammar type,
that you mention below.)

No-one wrote an "Easy
Guide to A68", so for several years the only way to learn it was
to read the Report [and later the Revised Report], 200-ish pages
of largely impenetrable two-level grammar. Even the first textbooks
were either full of mistakes or had a level of "cleverness" and
abstraction that was completely unsuitable for student use.

I've never read and language standard document to *learn* any
of the programming languages I know. - My opinion on that is
that language standards - the ones I've seen, at least - are
written in a way probably useful for language implementers but
typically much less suitable for programmers. (Mileages probably
vary.) I already find the texts that heavily use and rely on
standards-specific language problematic. (Concerning Algol 68
Genie, BTW, these parts of its documentation I consider the
most repelling aspects of the otherwise fine manual.)

The
size of the language was widely mocked, until it became clear that
formal descriptions of other languages were bigger [look at the
latest C standard and weep!], despite not being sufficiently formal
to describe the language properly [look again at C and weep!]. [I
could (and sometimes do) go on about this; sorry.]

(Well, inconsistent languages have an inherent problem anyway.)

I wouldn't think, though, that languages like Pascal would have
more complex definitions. (But I've just read a text-book that
was heavily relying on the standard, not the standard itself.)

Or Simula, which was built upon Algol 60. So the "Common Base
Language" could just define the OO (and other extensions) and
refer to the Algol language base for all the language basics.

Janis

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 27.08.2025 01:58, Andy Walker wrote:

On 25/08/2025 01:14, Janis Papanagnou wrote:
[I wrote:]

"FORMAT" adds around 50% to the A68>> syntax charts [eg from one page
(the Watt-Peck-Sintzoff chart) to
a page and a half]. We could get 95% of the power with no new
syntax at all by moving to a model more like C.

Well, C's model is very primitive compared to Algol 68's.
There's really interesting things you can do with that
FORMAT "sub-language".

Yes, but you could do ~95% of them without having a mode [type]
"FORMAT" that has a special syntax. There are a very few things that
would become somewhat harder, but virtually nothing that becomes really difficult.

To be clear, I'm not opposed to formatted transput [though
I don't personally make much use of it], nor to having a pre-defined
library of formatting commands; only to the invention of a special
type "FORMAT" to implement it. Also to be clear, I'm not advocating completely unstructured transput -- A68 provides conversion routines
for parametrised conversions from numbers to strings.

C shows how you can do the simple things by using a perfectly
normal string as a formatting parameter to "printf" and its friends.
By contrast, even lexing a FORMAT denotation is a right mess -- you
can't simply go from "$" to a closing "$" because the denotation may
include nested formats that may include arbitrary amounts of A68 code, including nested strings, comments and formats [that may include ...,
to arbitrary depth]. It's not impossible [obviously!], just a lot
harder than it ought to be.

I want to take up that sub-thread for another approach of my argument.
In the past I may have spread bits and pieces and hoped to trigger the associations that were sprouting in my mind. I hope this example below
shows why I think (most of all) that the FORMAT concept adds to A68's orthogonality and coherence, and (as a secondary issue and spin-off)
why some parts of the syntax were rightly chosen the way they are.

The example(s) use(s) "controlled" formatting and nested formats...

For output I'm using, e.g.

FORMAT fmt = $ "Diagnosis " b("positive", "negative") l $;
printf ((fmt, act_state));

or inlined

printf (($ "Diagnosis " b("positive", "negative") l $, act_state));

we can remove the controlled expression to the arguments side (like "C")

printf (($ "Diagnosis " g l $, (act_state|"positive"|"negative") ));

or then just avoid formated output

print (("Diagnosis ", (act_state|"positive"|"negative"), newline ));

Now I'd wonder how I'd read in such formats. - To make it short; we'd
need the programmer write a generally complex, bulky, thus error-prone
parser. For complex formats that gets even nastier. Let's extend it to

FORMAT fmt = $ "Diagnosis " b("positive", "negative") l $;

FORMAT fmt_spec = $ c("coughing", "cold", "headache", "belly aches") $;
FORMAT fmt_sev = $ c("imaginary", "slight", "strong", "very strong") $;
FORMAT fmt_details = $ f(fmt_spec) ":" f(fmt_sev) l $;

This also shows another property; you can simply build structures,
that are also usable individually (substructures, say, fmt_spec).
(And nesting of '$' symbols is also unnecessary, BTW.)

And if we use that for the _output_, say,

BOOL act_state = TRUE;
INT act_type = 3, act_severity = 4;
printf ((fmt, act_state, fmt_details, act_type, act_severity)); #A#

we can just use the same - exactly the same! - format definition(s) to
_read_ in the data

BOOL old_state;
INT old_type, old_severity;
readf ((fmt, old_state, fmt_details, old_type, old_severity)); #B#

here including all the non-trivial parsing that would otherwise be
necessary - imagine a "C" scanf that would be required to read and differentiate string variants in input (here for example "positive", "negative", in the bool-controlled example; it's just not possible
I'd say, so an overly complex user defined parsing will be required).

This coherence between formatted output #A' and formatted input #B#
is a great property, and simple to use, and without any overhead.

So given that the controlling elements b(), c(), n() make sense that
way we also notice what it would mean to *not* use a unique symbol '$'
to delimit the FORMAT expressions. Using a string delimiter '"' would
require means (as known of other languages) to escape or quote inner
strings (unless we would employ what you already identified as a
problem; allowing nested '"'). For FORMAT the nested '$' are actually
no problem if you use just separate format identifiers. But the '"'
interferes with other _string_ literals! So having two symbols, one
for FORMAT standard delimiters, and a disjunct '"' for strings makes
sense.

To summarize;
PROS: orthogonality, coherence (symmetry of input/output use),
structured definitions (including avoidance of delimiter nesting),
no necessity for (generally non-trivial) parsing when reading input,
no syntax-conflict/disambiguation with strings, and some elsethread
mentioned properties...

From a user (not implementer) perspective it's great as it is, IMO.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 30/08/2025 04:40, Janis Papanagnou wrote:

Hmm.., well. I commonly only heared about it's been considered
huge and hard to (fully?) understand, sort of; IOW, "complex".

Yes, for the reasons previously stated in this thread --
no introductory/student texts in the early years, emphasis on the
"clever" things you could do, no compilers, poor marketing, and
active rubbishing by experts with rival languages to peddle. Cf
Pascal, where there were decent texts from the start, compilers
from the start, and clever marketing -- it was described as a
"teaching" language [whatever that meant], and students had access
to full source. Cf also Unix, which was free to universities and
came with source. So guess what universities taught CS students.

[...] I already find the texts that heavily use and rely on standards-specific language problematic. (Concerning Algol 68
Genie, BTW, these parts of its documentation I consider the
most repelling aspects of the otherwise fine manual.)

Well, quite. But you were never expected to learn A68 or
A68G from the Revised Report. [I didn't. Well, not entirely. I
started with the example programs, which seemed pretty cool (not
that "cool" meant that in those days) and typographically neat,
then gradually picked up the syntax from semi-obvious bits like

assignation: destination ":=" source

(OK, it doesn't exactly say that, but the rest of RR5.2.1 is merely
explaining how the grammar checks that the assignment is correct),
and gradually worked out (most of) the rest of it. Most of us had,
perforce, to do much the same.]

I wouldn't think, though, that languages like Pascal would have
more complex definitions.

Pascal is usually described by 6-12 pages of "railway track"
syntax charts or by several pages of BNF. The Watt-Peck-Sintzoff
syntax chart for A68 is one side [admittedly crammed in a bit], and
the BNF for A68-R is a page-and-a-half. Go figure. Of course, the
syntax charts aren't the only measure of complexity. What, apart
from "FORMAT", do /you/ find "complex" in A68, and in what way is
equivalent Pascal simple?
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Strauss
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 30/08/2025 05:54, Janis Papanagnou wrote:

I want to take up that sub-thread for another approach of my argument.
In the past I may have spread bits and pieces and hoped to trigger the associations that were sprouting in my mind. I hope this example below
shows why I think (most of all) that the FORMAT concept adds to A68's orthogonality and coherence, and (as a secondary issue and spin-off)
why some parts of the syntax were rightly chosen the way they are.

Then you have a different meaning for "orthogonal" from me and
from the Revised Report; section 0.1.2 [which I quoted on Wednesday].
See also below.

The example(s) use(s) "controlled" formatting and nested formats...
For output I'm using, e.g.
FORMAT fmt = $ "Diagnosis " b("positive", "negative") l $;
printf ((fmt, act_state));

[... equivalent C or unformatted A68 snipped ...]

Now I'd wonder how I'd read in such formats. - To make it short; we'd
need the programmer write a generally complex, bulky, thus error-prone parser.

(a) If you replace formats by strings, then there would be the equivalent "parser" in the standard library. There's no need to get rid
of the utility; if it's generally useful, it would be provided [and the
RR virtually codes it up for you -- see section 10.3.4.8.1bb and cc].

(b) Having it as a special mode [type] means that you can't just replace it by a more useful "parser". For example, these days it would be useful to allow regular expressions in the strings, eg to allow arbitrary spacing around the words. You're stuck with what the implementer gives
you. To revert to a previous example, if you want "fixed (0.32, 0, 1)" to produce "0.3" instead of ".3", you can roll your own. If you want a "g"
format to do the same, it's much harder.

[...]

(And nesting of '$' symbols is also unnecessary, BTW.)

May be "unnecessary", but the language allows it, so a lexer has
to work around that.

[...] imagine a "C" scanf that would be required to read and
differentiate string variants in input (here for example "positive", "negative", in the bool-controlled example; it's just not possible
I'd say, so an overly complex user defined parsing will be required).

As above, if the facility is sufficiently useful, it will be
provided as a library routine. You seem again to be assuming that the
whole concept of formatted transput would be zapped, and/or reduced
to what C provides. Not so. But in accordance with RR0.1.2, there's
little if any need for the [specific] "$ ... $" formats; much the
same functionality can be provided [more flexibly] by format strings,
and [therefore] with no new syntax.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Paderewski
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 30.08.2025 21:38, Andy Walker wrote:

On 30/08/2025 04:40, Janis Papanagnou wrote:

[...]

Cf
Pascal, where there were decent texts from the start, compilers
from the start, and clever marketing -- it was described as a
"teaching" language [whatever that meant], and students had access
to full source.

Well, I know many languages that had been advertised as "teaching"
language. Incidentally at university we started with Algol 68, and
then continued with Pascal, then had options to also learn a couple
other languages, e.g. "C" and Simula. Simula had been intended also
as "teaching" language (e.g. in Scandinavian countries), and I think
that's okay; it's Algol 60 based and the OO concepts are marvelously integrated, though a bit bulky in some respects. And Pascal was also
a very lean, clean, and in some respect an expressive language. But
from all these language I'd think that Algol 68 was the best suited
"teaching" language (mainly because of its coherent basic design!).
But not if you were seeking e.g. the OO concepts that I've got from
Simula back these days (and later from "C++").

Cf also Unix, which was free to universities and
came with source. So guess what universities taught CS students.

I can only speak for "our" University. Here at some stage we also
got access to Unix (on a mainframe); Amdahl's UTS (through IBM's
VM). The fact that there were cheap licenses certainly contributed
to it's invention. But availability of source code was certainly
not a relevant reason (neither for the languages nor for the OS).
In fact the professors advertised Unix because of it's concepts!

(OTOH, later (at the DLR), the DEC people ridiculed Unix WRT its
[lacking] security compared to VAX's VMS, as they said. I haven't
had the knowledge to judge about that.)

[...]
perforce, to do much the same.]

I wouldn't think, though, that languages like Pascal would have
more complex definitions.

Pascal is usually described by 6-12 pages of "railway track"
syntax charts or by several pages of BNF. The Watt-Peck-Sintzoff
syntax chart for A68 is one side [admittedly crammed in a bit], and
the BNF for A68-R is a page-and-a-half. Go figure. Of course, the
syntax charts aren't the only measure of complexity.

What, apart
from "FORMAT", do /you/ find "complex" in A68, and in what way is
equivalent Pascal simple?

Well, several things on different levels and topics (with varying
"severity" levels)...

First it was in comparison an extremely "large" language. (PL/I gave
me a similar impression but I never programmed it.) Other languages
appeared to me rather small and simple in comparison. (Pascal, for
example, was such an extremely simple and very small language.)

Then some of the syntax; we already spoke about the syntax aspect of
FORMAT definitions. But also so "strange" appearing syntax parts like
the ((...)) in the basic transput functions; to be honest, no one had
told us why there's no simple (...) possible. (Now I know of course.)

Then the bulky legacy structures; compare the indexed 'case' with the
variants we see elsewhere. In Pascal we could even compare arbitrary "enumerable" types in case comparisons. And Algol 68 supported only
the positive integral numbers as selection criterion. A similar sort
of code could be found e.g. in Simula's 'switch' that also indexed
with natural numbers a sequence of labels. (There's also in other
languages back then such legacy structures; e.g. jump on -1/0/+1.)

There's various forms of loops existing in programming languages.
Pascal supports a comparable simple to use and very readable form,
but allows to use any scalar type for it. Other languages provide
yet more options in loops; e.g. Simula. To model things that are
easy in those languages now in Algol 68 we do need to completely
other means, additional code and types.

The 'flex' "anomaly" was something that raised questions. (Here
the Pascal's from these days weren't better, or were even worse.)

Array relocations ('@', 'at') and its syntax appeared confusing,
yet more if there's array slicing applied in such contexts. (To be
fair; Pascal just didn't support such powerful features. But OTOH,
Pascal indices could again be any "enumerable" type. Very legible
code can be written in Pascal with this and other features.)

The practical use of 'union' types appeared to me to be unnecessary
complex with its somewhat bulky type qualification syntax.

The practical effects of redefining priorities of non-user defined
operators for user defined types appeared dangerous.

The necessity (or also its absence, depending on context) of array
bounds irritated me back then.

The full specification of declarations is (while coherent) complex.
Luckily there's the abbreviated forms, but sometimes it's important
that you know the "formally complete" form to understand things.

The transput model (books, channels, files, pages, etc.) wasn't
too "inviting" for my taste; it certainly appeared more complex
than what we had, e.g., in Pascal. Another thing is the "action"
controlled operations on files; using Pascal's I/O was simpler.
In addition there's some details necessary in Algol 68, how to
write such handlers correctly; I recall some subtle scope issue
you have to consider, and also using jumps wasn't too elegant in
the days of structured processing (cf. Pascal's way).

And, for completeness, the complexity of the FORMAT sub-language
we already spoke about should not be missing in my ad hoc list.

Generally - since you specifically ask about Pascal vs. Algol 68 -
the Pascal programs appear to me to be much better legible, while
the Algol 68 programs appear to be better "formally legible". (If
you understand what I mean by that.) In a similar vein, my Simula
programs are better readable and easier to model real world tasks
than in either of Pascal or Algol. And if I'm doing "low-level"
programming I'm better off with some "cryptic" "C" code patterns.

This is off the top of my head, so there's likely some more to say.
But I hope you get an idea about where I see (likely historically
justifiable) deficiencies or at least some "rough edges".

PS: This post got longer than intended, any may leave a bad taste.
But all that said and enumerated; my positive valuation of Algol 68
isn't affected by that. Other languages with interesting properties
have their own "flaws or problems".

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Sun, 31 Aug 2025 00:44:09 +0100, Andy Walker wrote:

As above, if the facility is sufficiently useful, it will be
provided as a library routine. You seem again to be assuming that the
whole concept of formatted transput would be zapped, and/or reduced
to what C provides. Not so. But in accordance with RR0.1.2, there's
little if any need for the [specific] "$ ... $" formats; much the
same functionality can be provided [more flexibly] by format strings,
and [therefore] with no new syntax.

How would you ensure type-safeness? That is a notorious lack in the C-
style printf.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 31.08.2025 01:44, Andy Walker wrote:

On 30/08/2025 05:54, Janis Papanagnou wrote:

The example(s) use(s) "controlled" formatting and nested formats...
For output I'm using, e.g.
FORMAT fmt = $ "Diagnosis " b("positive", "negative") l $;
printf ((fmt, act_state));

[... equivalent C or unformatted A68 snipped ...]

Now I'd wonder how I'd read in such formats. - To make it short; we'd
need the programmer write a generally complex, bulky, thus error-prone
parser.

(a) If you replace formats by strings, then there would be the
equivalent "parser" in the standard library. [...]

(It seems I could not make my point clear. Since I don't know how I
could make it clearer than with the elaborated example that I derived
I'll abstain from a further try.)

[...]

(And nesting of '$' symbols is also unnecessary, BTW.)

May be "unnecessary", but the language allows it, so a lexer has
to work around that.

[...] imagine a "C" scanf that would be required to read and
differentiate string variants in input (here for example "positive",
"negative", in the bool-controlled example; it's just not possible
I'd say, so an overly complex user defined parsing will be required).

As above, if the facility is sufficiently useful, it will be
provided as a library routine. You seem again to be assuming that the
whole concept of formatted transput would be zapped, and/or reduced
to what C provides.

No, I wasn't assuming that.

(I was merely trying to tailor my explanations with the occasional
"C" references we had in our discussion and with the syntactical
dislikes that I meant to have understood in your presentation.)

Not so. But in accordance with RR0.1.2, there's
little if any need for the [specific] "$ ... $" formats; much the
same functionality can be provided [more flexibly] by format strings,
and [therefore] with no new syntax.

I thought with the example I would have made the problem clear.

Anyway. Algol 68 is as it is, and there will be no change. Genie
provides two variants; the FORMAT variant had that gap, and the
"C" variant obviously has bugs (as I noticed) - thus unreliable
to use (for my taste). Well...

I'll certainly continue with FORMAT, now that I better understand
that somewhat difficult feature.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 31.08.2025 10:12, Lawrence DrCOOliveiro wrote:

On Sun, 31 Aug 2025 00:44:09 +0100, Andy Walker wrote:

As above, if the facility is sufficiently useful, it will be
provided as a library routine. You seem again to be assuming that the
whole concept of formatted transput would be zapped, and/or reduced
to what C provides. Not so. But in accordance with RR0.1.2, there's
little if any need for the [specific] "$ ... $" formats; much the
same functionality can be provided [more flexibly] by format strings,
and [therefore] with no new syntax.

How would you ensure type-safeness? That is a notorious lack in the C-
style printf.

This is basically true; but aren't the modern "C" variants capable
of inspecting these strings (as formerly [only] external tools did)?
Algol 68 could do that as well.

What do we (or Andy) want...?

No first class FORMAT object, but a string? - What would we gain
from that? What would we lose?

Or just a syntactical reduction '$' -> '"' - What would we gain
from that? What would we lose?

Or a formatting language simplification, by relocating the more
complex formatting entities (n(), b(), c(), f()) into library
functions outside of the format string? - What would we gain
from that? What would we lose?

Or something else? - What?

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 31/08/2025 09:12, Lawrence DrCOOliveiro wrote:

On Sun, 31 Aug 2025 00:44:09 +0100, Andy Walker wrote:

As above, if the facility is sufficiently useful, it will be
provided as a library routine. You seem again to be assuming that the
whole concept of formatted transput would be zapped, and/or reduced
to what C provides. Not so. But in accordance with RR0.1.2, there's
little if any need for the [specific] "$ ... $" formats; much the
same functionality can be provided [more flexibly] by format strings,
and [therefore] with no new syntax.

How would you ensure type-safeness?

A68 is type-safe by design. You always know what type an object
has. Admittedly, this can get a little hairy in the case of coercions,
but the compiler can keep track. There is no C-style type punning. That
would not change if "$ ... $" formats were replaced by equivalent C-style string formats. NB, "C-style", not "exactly like C".

That is a notorious lack in the C-
style printf.

C, OTOH, /does/ have C-style type punning.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Paderewski
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Mon, 1 Sep 2025 00:10:09 +0100, Andy Walker wrote:

On 31/08/2025 09:12, Lawrence DrCOOliveiro wrote:

How would you ensure type-safeness?

A68 is type-safe by design.

But not if it adopts C-style printf-formatting. How would you ensure consistency of types between format descriptors in an arbitrary string and
the corresponding arguments?
--- Synchronet 3.21a-Linux NewsLink 1.2