From Newsgroup: comp.lang.prolog

Dear All,

Up until now it was quite time consuming to run your code snippets across different Prolog engines. Imagine you want to test some corner case of
goal expansion, but you would really like to know how other Prologs
behave, and what is a common practice if any. That's why I wrote a simple program that will act as a common CLI for different engines. So now you
can just call:

prologs -g my_goal my_test.pl

And this will run `my_goal,halt` with all installed Prologs, so in a less
of a second you can see how your code is handled by other engines.

My first release v.0.1 is available at <https://github.com/hurufu/prolog-

, but currently the only supported way of using it is via AUR

repository (https://aur.archlinux.org/packages/prologs) or a Docker
container (https://github.com/hurufu/prolog-docker)

I hope my program will help at least a little bit with interoperability in
the Prolog community.

P.S. I know that not a lot of people use Prolog and even less people use
both Prolog and Arch Linux (and read Usenet), but I still hope that this project will be helpful for somebody else but me ;)
--
Alex
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

An alternative minimal approach, which already
works on many Prolog systems is to only require:

<prolog system> <prolog script>

And inside the Prolog text <prolog script>:

:- initialization(my_main)

The initialization/1 directive is from the
ISO core standard. You find some words

about it here:

:- initialization(:Goal) https://www.swi-prolog.org/pldoc/man?predicate=initialization/1

Bye

P.S.: Next level is option processing, the
minimal being:

<prolog system> <prolog script> <option 1> ... <option n>

But things get very hairy here, for example
SWI-Prolog allows multiple prolog scripts depending
whether it sees an extension .pl on the command line.

And inside the Prolog text you can access the options via:

my_main :-
current_prolog_flag(argv, L),
/* your option logic */

Its not in the ISO core standard but also quite common:

argv(list, changeable)
List is a list of atoms representing the
application command line arguments. https://www.swi-prolog.org/pldoc/doc_for?object=current_prolog_flag/2

You can then define options that control your Prolog
program semantically without exposing Prolog code.
The command line DSL of your Prolog program can

be anything need not be Prolog goals. This gives
a more flexible command line interface, since you
can more easily change the implementation,

than when you expose Prolog goals. The command
line DSL can also solve escaping problems different
than the way they can happen with supplying Prolog goals.

Aleks Grabowski schrieb:

Dear All,

Up until now it was quite time consuming to run your code snippets across different Prolog engines. Imagine you want to test some corner case of
goal expansion, but you would really like to know how other Prologs
behave, and what is a common practice if any. That's why I wrote a simple program that will act as a common CLI for different engines. So now you
can just call:

prologs -g my_goal my_test.pl

And this will run `my_goal,halt` with all installed Prologs, so in a less
of a second you can see how your code is handled by other engines.

My first release v.0.1 is available at <https://github.com/hurufu/prolog- all>, but currently the only supported way of using it is via AUR
repository (https://aur.archlinux.org/packages/prologs) or a Docker
container (https://github.com/hurufu/prolog-docker)

I hope my program will help at least a little bit with interoperability in the Prolog community.

P.S. I know that not a lot of people use Prolog and even less people use
both Prolog and Arch Linux (and read Usenet), but I still hope that this project will be helpful for somebody else but me ;)

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Oho, now I have two tickets opened and then closed
just for the record of documenting something.

I assume biomake is the new distribution weapon
to compete with apostates like here?

13:00-14:30 Torbjörn Lager: The Role of the Raven in the Prolog
Trinity Ecosystem: Scryer Prolog Agents on the Web https://www.digitalaustria.gv.at/eng/insights/Digital-Austria-Events-EN/Scryer-Prolog-Meetup-2024.html

I am all in for free speech until Donald Trump
misuses it to form a new dictator ship.

Good Luck to everyone in 2024-2028,
may Europe survive and stay autonomous.

P.S.: I assume biomake is a nice example of using the
<option 1> .. <option n> facility of a Prolog system:

Biomake is a make-compatible utility for managing
builds (or analysis workflows) involving multiple
dependent files. It supports most of the functionality
(and syntax) of GNU Make, along with neat
extensions like cluster-based job processing,
multiple wildcards per target, MD5 checksums instead
of timestamps, and declarative logic
programming in Prolog.
https://github.com/evoldoers/biomake

P.P.S.: Recently a man of the street talked about
modern cloud computing to me and had the idea
that today there is no escaping of golang, since

it holds the key for cloud compouting via its
kubernetes implementation. Actually had some doubts...

Mild Shock schrieb:

Hi,

An alternative minimal approach, which already
works on many Prolog systems is to only require:

--- Synchronet 3.20a-Linux NewsLink 1.114