From Newsgroup: comp.lang.misc

Lacking some basic standard libraries in Algol 68 I'm at a point
where I'd like to build separate modules/includes/libraries that
can be accessed in various application contexts without doing a
copy/paste of the complete library code. I've read that such
things have been done in some variants or proposed as extension
(e.g. Lindsey https://www.algol68-lang.org/docs/algol68-mr.pdf).

I'm using Marcel's Genie Algol 68 system and failed to find any
way to achieve that. The closest I came across in the documents
that sound like something like that was using 'pragmats'...

• some previously compiled portion of the particular-program
is to be invoked, e.g., PR WITH segment FROM album PR;
• the source text is continued on some other document, e.g.,
PR READ FROM another file PR;

but I'm not sure it does what I'm looking for, nor how it shall
interact with other external items (like "segment" or "album"
as given with the example above), how it's actually used/done.

Has someone experiences with this Genie-specific mechanism, or
any other suggestions how to achieve modularization with Genie?

I'm (at the moment) not too picky about the mechanism, whether
it's, say, a supported built-in syntax, a working Genie pragmat,
or a primitive include mechanism.

If there's nothing supported with the Genie system I'd probably
just work around the requirement with an external tool like CPP.

Janis
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 16/08/2025 01:36, Janis Papanagnou wrote:

[...] The closest I came across in the documents
that sound like something like that was using 'pragmats'...
• some previously compiled portion of the particular-program
is to be invoked, e.g., PR WITH segment FROM album PR;
• the source text is continued on some other document, e.g.,
PR READ FROM another file PR;
but I'm not sure it does what I'm looking for, nor how it shall
interact with other external items (like "segment" or "album"
as given with the example above), how it's actually used/done.

Those are from the Revised Report, and are suggestions for
what a compiler might do in this sort of area, not part of A68G.

Has someone experiences with this Genie-specific mechanism, or
any other suggestions how to achieve modularization with Genie?
I'm (at the moment) not too picky about the mechanism, whether
it's, say, a supported built-in syntax, a working Genie pragmat,
or a primitive include mechanism.

As far as I know, the only relevant pragmat in A68G is the
"include" mechanism:

PR include "some_file_name" PR

whereby the contents of "some_file_name" are textually included in
place of the pragmat. If you want/need something better, I suggest
that you contact Marcel; I have always found him prompt and very
helpful, and open to suggestions.

Andy
--
Dr A. N. Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Marpurg
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 16.08.2025 12:29, Andy Walker wrote:

On 16/08/2025 01:36, Janis Papanagnou wrote:
[...]

Has someone experiences with this Genie-specific mechanism, or
any other suggestions how to achieve modularization with Genie?
I'm (at the moment) not too picky about the mechanism, whether
it's, say, a supported built-in syntax, a working Genie pragmat,
or a primitive include mechanism.

As far as I know, the only relevant pragmat in A68G is the
"include" mechanism:

PR include "some_file_name" PR

Ah, I somehow missed that in the huge documentation. Something
like that is exactly what I was looking for. - Thanks!

whereby the contents of "some_file_name" are textually included in
place of the pragmat. If you want/need something better,

Of course "something better" would be useful; thinking of name
spaces to not get into naming conflicts when merging different
libraries with own main code. (Or maybe pre-compiled libraries.)

I suggest
that you contact Marcel; I have always found him prompt and very
helpful, and open to suggestions.

Well, with my recent more extensive Algol 68/Genie activities
I stumbled across a couple questions (and also across some
Genie issues), so I exchanged already quite some emails with
him. Some issues and suggestions got addressed by him already,
some not. He had by the way mentioned that Genie is a 20 years
old "spare time project" and I've got the impression that he
has a Real Life as well, so I try - but not very successfully,
I fear - to master my passion concerning Algol 68 and Genie.

Not all questions (or suggestions) got answered; e.g. the one
posted here not. - So thanks again!

More powerful library mechanisms (and a couple of other things)
would certainly be very useful, but I'd think - given the reach
of Algol 68 - it's not worth spending too much effort on that,
and especially if that effort would have to be done by Marcel;
I think we cannot and should not expect that from him. Genie
is already so comprehensive that we can consider us enthusiasts
lucky that Marcel had done this great job!

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 16/08/2025 13:14, Janis Papanagnou wrote:
[...]

Of course "something better" would be useful; thinking of name
spaces to not get into naming conflicts when merging different
libraries with own main code.

OK. I suspect something could be lashed up without too
much difficulty; perhaps by means of a shell script.

(Or maybe pre-compiled libraries.)

A68G compilation is so fast [~20000 lines/s on my desktop]
that I've never felt the need to pre-compile anything. YMMV, esp
if you need heavy optimisation. [I don't have many programs of more
than 1000 lines.]

[...] Genie
is already so comprehensive that we can consider us enthusiasts
lucky that Marcel had done this great job!

Indeed. As previously noted, by the 1990s I was so fed up
with the infelicities of C and its relatives that I was using shell
scripts for the most unsuitable of purposes [eg, timetabling]; the
advent of A68G reminded me of the joys of programming, and I haven't
looked back over the past 20+ years.

Andy
--
Dr A. N. Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Marpurg
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 16.08.2025 18:44, Andy Walker wrote:

On 16/08/2025 13:14, Janis Papanagnou wrote:
[...]

Of course "something better" would be useful; thinking of name
spaces to not get into naming conflicts when merging different
libraries with own main code.

OK. I suspect something could be lashed up without too
much difficulty; perhaps by means of a shell script.

I was already thinking about some sh/awk preprocessing here, but
quickly dismissed it when I thought deeper about identifying all
those many identifiers in various syntactical positions, while
ignoring others. That's too much hassle, if you ask me, when your
preprocessors would need only a minimum of syntactical knowledge
of the Algol 68 language.

(Or maybe pre-compiled libraries.)

A68G compilation is so fast [~20000 lines/s on my desktop]
that I've never felt the need to pre-compile anything. YMMV, esp
if you need heavy optimisation. [I don't have many programs of more
than 1000 lines.]

Oh, don't get me wrong. I have absolutely no problem with Genie's
speed. Moreover, I consider the speed of the programming task much
more important than speed of execution; and, IME, in Algol 68 the
time span to get a _correct program_ is much shorter than in many
other and quite common languages!

What I meant with "precompiled libraries" was more with respect to
supporting modularized systems; precompilation and dynamic binding
would be one way to achieve that. If I'm not mistaken Genie already
employs such mechanisms for its "standard" extensions; plotting, DB
support, curses, math libraries, etc.

Having a standard means to incorporate externally compiled sources
(also from other languages) would be very useful; that way we could
even incorporate functions on system level that are yet unavailable
in Algol (or in Genie). Thinking here about a mechanism like, e.g.,
Simula's "external", something like... (here adjusted for Algol 68)
EXTERNAL "C" char getkey() IS PROC getkey = CHAR;
(Or extended to whole modules with types/classes and its functions.)

[...] Genie
is already so comprehensive that we can consider us enthusiasts
lucky that Marcel had done this great job!

Indeed. As previously noted, by the 1990s I was so fed up
with the infelicities of C and its relatives that I was using shell
scripts for the most unsuitable of purposes [eg, timetabling]; the
advent of A68G reminded me of the joys of programming, and I haven't
looked back over the past 20+ years.

Yeah, it's indeed amazing. I must say that I had about four decades
"paused" with Algol 68, having no access to a compiler and only very
recently I learned about Marcel's Genie project. Due to Algol 68's
coherence and orthogonality it needed not much time to continue with
it even after that long span of time.

But there's of course also a couple of things I'm missing in Algol 68
that I learned to appreciate from other languages, and a few things
in Algol 68 are, while very powerful, not that easy to get into, IMO,
and some things also appear a bit anachronistic or bulky.

But as you say, compared to those issues you *have* to deal with in
languages like "C" etc., things that are not related to the problem
domain but to the inherent deficiencies of the "C" language, such
things need no attention any more in Algol 68; it doesn't distract
one from the primary task and doesn't waste your time unnecessarily.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Sat, 16 Aug 2025 17:44:04 +0100, Andy Walker wrote:

... by the 1990s I was so fed up with the infelicities of C and its
relatives that I was using shell scripts for the most unsuitable of
purposes [eg, timetabling] ...

Other people (including me) were discovering the usefulness of Perl for
such tasks. There was also Tcl/Tk, which came with its own cross-platform least-common-denominator GUI toolkit. I was even an AppleScript champion,
for a while.

These days Python has taken over pretty much that entire segment.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 16.08.2025 14:14, Janis Papanagnou wrote:

On 16.08.2025 12:29, Andy Walker wrote:

On 16/08/2025 01:36, Janis Papanagnou wrote:
[...]

Has someone experiences with this Genie-specific mechanism, or
any other suggestions how to achieve modularization with Genie?
[...]

As far as I know, the only relevant pragmat in A68G is the
"include" mechanism:

PR include "some_file_name" PR

Ah, I somehow missed that in the huge documentation. Something
like that is exactly what I was looking for. - Thanks!

Now implementation decisions are made, that "ratlib" is consolidated,
and one question left...

I have a regression test set up based on ASSERTs, and this file is fed
with the "ratlib" by using 'PR include "ratlib.a68" PR' . So far it's
fine; since all "ratlib" PROCs/OPs are used in the regression tests.

But if I 'include' the lib to use it in some other Algol applications
there's the typical "XYZ not used" warnings. Disabling *all* warnings
(by setting the '-no-warnings' option) is of course not the solution.

...is there a way to disable those warnings for the PROCs/OPs of the
library source code without generally disabling the warnings for other entities?

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 18/08/2025 21:51, Janis Papanagnou wrote:

But if I 'include' the lib to use it in some other Algol applications
there's the typical "XYZ not used" warnings. Disabling *all* warnings
(by setting the '-no-warnings' option) is of course not the solution.
...is there a way to disable those warnings for the PROCs/OPs of the
library source code without generally disabling the warnings for other entities?

Not as far as I know. "PR no-warnings PR ... PR warnings PR"
around the library source "ought" to do it; but each such pragmat seems
to supersede all earlier ones and apply to the whole program. I expect
that's to do with the compiler being multi-pass. I suppose there is a
kludgy solution, which is to use all the "XYZ" in the library as part of
the library:

( FALSE | XYZ a := ...; ...; print (a) );

[tweak to taste!]. You can find out what to put in place of "..." by
running

PR include "ratlib.a68" PR SKIP

to see what warnings you might get from the library.

Andy
--
Dr A. N. Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/West
--- Synchronet 3.21a-Linux NewsLink 1.2