Stargate LLC is a "shovel" project [Great Ocean Road?] (Was: long live DGCs: Prolog systems before Stargate LLC in 2025)

Irony of the Starget LLC project, it is again a
Japan collaboration, but in more commerical clothes,
i.e. SoftBank. An introduction is found here, its
less a software project than a “shovel” project:
Inside OpenAI’s Stargate Megafactory with Sam Altman
https://www.youtube.com/watch?v=GhIJs4zbH0o
Just building large data centers, I guess world wide.
The above video circles around Abilene, Texas which
has the Dyess Air Force Base close by,
established in 1942.
The project reminds me a little bit of the Great
Ocean Road, finally work for USA Soliders returning
from Afghanistan? The Great Ocean Road occupied
returning World War I, soldiers to work on roads
in sparsely populated areas.
Great Ocean Road - Construction
https://en.wikipedia.org/wiki/Great_Ocean_Road#Construction
Mild Shock schrieb:

 If you are lucky the original DCG rules will
work in your modern Prolog system at the beginning
of Stargate LLC in 2025. Lets see what was the
problem at the time, and whether this problem
has disappeared:
 /* ROKs Prolog system */
command(delete(A), B, C) :-
     'C'(B, rm, D),
     file(A, D, C).
 /* SWI-Prolog 9.3.24 */
command(delete(A), [rm|B], C) :-
     file(A, B, C).
 The SWI-Prolog DCG translation abandons ‘C’/3,
and tries to move the input list into the head.
If you are lucky this will work in your Prolog system
if a couple of things kick in:
 - just in time indexing:
   We didn’t place any indexing declaration, so lets
   hope that the prolog system does some automatic indexing.
 - multi argument indexing:
   Oh yeah, the DCG input list is not a first argument,
   but a second argument, so the Prolog system needs to do that.
 - deep term indexing:
   Oh yeah, the rm token is inside the head of the DCG
   input list, so the Prolog system needs deep indexing as well.
 SWI-Prolog provides all these things. The easier
way would have been to automatize the ROK transformation.
In my Prolog system I just do the ROK transformation
 here and then manually, it gives ultra fast DCG, possibly
faster than the SWI-Prolog machinery, since it is much more
simple, simplifies JITing and does less often list unpacking,
so that one can write a couple of things in 100% Prolog
 which are usually not written in 100% Prolog.
 Mild Shock schrieb:

 > Parse the lines using a DCG
>
This was a quite popular subject around the time
Fifth Generation Computer Systems (FGCS) in 1982
and made it into a couple of Prolog books from
the same decade. It was before the relaunch of
>
FGCS in the form of Stargate in 2025, and from
the time were people reading books and not simply
asking ChatGPT. One of these Prolog books
is THE BOOK by ROK:
>
The Craft of Prolog
Richard O’Keefe - 1990
https://mitpress.mit.edu/9780262512275/the-craft-of-prolog/
>
His DCG somehow assumes there are already tokens,
and he then starts discussing these DCG productions:
>
command(delete(File)) -->  [rm], file(File).
command(copy(From,To)) -->  [cp], file(From), file(To).
command(print(File)) -->  [lpr], file(File).
>
He then basically goes into head scratching rampage
about the current state of DCGs at that time, ultimately
suggesting some workaround by a cleaner technique
that promotes the first token
>
/* ROKs transformation */
command(Cmd) --> [Token], command(Token, Cmd).
>
command(rm, delete(File)) -->  file(File).
command(cp, copy(From,To)) -->  file(From), file(To).
command(lpr, print(File)) -->  file(File).
>
into argument indexing. Basically obviating the very idea to
use the input DCGs in the first place.