From Newsgroup: comp.lang.prolog

Hi,

How SWI-Prolog went down hills. Its
very easy to see. It lost the following
hotshots over time:

- Paulo Moura (Logtalk)
- Markus Triska (CLP(Z))
- Ulrich Neumerkel (ISO)
- Who else?

With whom is SWI-Prolog now collaborating?
Manuel Hermenegildo on PIPs. I don't see that
SWI-Prolog and Ciao Prolog make can even

make a single coherent proposal, that would
satisfy the critera at least 2 systems implement
the feature. They are too different.

So PIP is abused for corrobation, of possible
harmonization, where it should be really
proposals, and not discussion.

Bye
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Lets not forget that SWI-Prolog is now doomed
to have professional moron Julio Di Egidio
on board. Lets see what he says about dicts:

- The syntax <atom>{<key>:<any>,...} for rCLstructsrCY
(i.e. where the name is the functor name);
- The syntax <var>{<key>:<any>,...} for attributed vars.

LoL, I guess he has never heard of unification.
The beautiful thing about SWI-Prolog dicts is
that you can use Variable Tags for matching.

This here works:

?- X = foo{bar:123,baz:abc},
Y = Tag{bar:Value1,baz:Value2},
X = Y.
X = Y, Y = foo{bar:123, baz:abc},
Tag = foo,
Value1 = 123,
Value2 = abc.

Such things might even be in use in the wild, like
for example in a CSV reader , or who knows what. The
only common thing between SWI-Prolog dicts and

attributed variables is that usually the state of
attributed variable is organized as a dict. But
the variable tags in SWI-Prolog are not automatically

attributed variables. On the other hand some Prolog
systems provide SSU (Single Sided Unification) which
allows accessing attributed variables states via the

Variable Tag syntax. Thats a relative old thingy, that
you find in some older papers and in some existing
Prolog systems. But as soon as an attributed variable

is instantiated, its dict state doesn't interest
anymore, unless you rollback the instantiation in
backtracking. That instantiated variables are invisible

in a Prolog systems, as it transpired to me when discussing
with Julio Di Egidio, is knowledge for him burried deep
in a book of seven seals. What can you expect from

a person who has never seen the innards of a Prolog system?

Bye

Mild Shock schrieb:

Hi,

How SWI-Prolog went down hills. Its
very easy to see. It lost the following
hotshots over time:

- Paulo Moura (Logtalk)
- Markus Triska (CLP(Z))
- Ulrich Neumerkel (ISO)
- Who else?

With whom is SWI-Prolog now collaborating?
Manuel Hermenegildo on PIPs. I don't see that
SWI-Prolog and Ciao Prolog make can even

make a single coherent proposal, that would
satisfy the critera at least 2 systems implement
the feature. They are too different.

So PIP is abused for corrobation, of possible
harmonization, where it should be really
proposals, and not discussion.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

On 27/09/2025 20:10, Mild Shock wrote:

Lets not forget that SWI-Prolog is now doomed
to have professional moron Julio Di Egidio
on board. Lets see what he says about dicts:

-a- The syntax <atom>{<key>:<any>,...} for rCLstructsrCY
-a-a-a (i.e. where the name is the functor name);
-a- The syntax <var>{<key>:<any>,...} for attributed vars.

LoL, I guess he has never heard of unification.

You just mangle quotes and go out on an insane and
abusive, even personally abusive, tangent: as usual.

Welcome back to my kill-file, under the rubric
stupidity is a moral defect.

*Plonk*

-Julio

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

The PoC (Proof of Concept) aspect of a PIP
gets totally ignored. A PIP should be backed
by a small number of systems implementing

the proposal. This has implications on what
topic can be chosen and what staff can work
on a PIP. Ask Boris the Loris for the semiotics

of a PoC. Now PIPs have been perverted into
a forum to siphon Money into the Nowhere:

- Some discussions are going on in the PIP
working group related to synchronize (as a
lightweight standardize) some aspects
between Prolog systems.

So PIP has become ISO-2. Its not anymore
a PIP, which would modularly maybe conflicting,
collect proposals. One could very easily

jigsaw different dict efforts into separate
PIPs, when then work inheritly different.
Instead the goal is now "lightweight"

standardizing. It shows in this mess:

Dictionaries in Prolog (dynamic) https://prolog-lang.org/ImplementersForum/0102-dicts.html

Terms with named arguments (static dicts) https://prolog-lang.org/ImplementersForum/0104-argnames.html

Not a proposal at all. Just a big big mess.
Theretically when we assume that a PIP has
already PoCs, namely at least 2 Prolog systems

that implement something.


Bye

Julio Di Egidio schrieb:

On 27/09/2025 20:10, Mild Shock wrote:

Lets not forget that SWI-Prolog is now doomed
to have professional moron Julio Di Egidio
on board. Lets see what he says about dicts:

-a-a- The syntax <atom>{<key>:<any>,...} for rCLstructsrCY
-a-a-a-a (i.e. where the name is the functor name);
-a-a- The syntax <var>{<key>:<any>,...} for attributed vars.

LoL, I guess he has never heard of unification.

You just mangle quotes and go out on an insane and
abusive, even personally abusive, tangent: as usual.

Welcome back to my kill-file, under the rubric
stupidity is a moral defect.

*Plonk*

-Julio

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

I big advantage of PoC derived only PIPs is a
firm scope. Put PoC first, derive PIPs bottom up,
and not the other way around use PIPs to spark

PoCs top down. A PoC would surely have a strong
boundary scope. On the other hand these PIPs now
have very weak fuzzy scopes.

They should put Boris the Loris into the
steering board, he was very good when
it came to community, and fuzzy versus

non-fuzzy. PoC based PIPs would probably
have clean descriptions, and not this horror
of Fuzzyness, where PIPs don't know their own Scope!!!

APPENDIX: META-DISCUSSION FOR THIS PIP
What should be covered in this PIP? https://prolog-lang.org/ImplementersForum/0102-dicts.html

TBD: relate with current_struct/1 ECLiPSe?
TBD: Discuss it
TBD: useful for portray, translation to dynamic dicts (Jan) https://prolog-lang.org/ImplementersForum/0104-argnames.html

Such discussion would be find in the GitHub
of a PoC, in case the PoC was developed
with GitHub. Nowadays the GitHub could even

contain longwinding discussions, since GitHub
offers discussions, its even not necessary
to put discussions into issue tickets.

Bye

Mild Shock schrieb:

Hi,

The PoC (Proof of Concept) aspect of a PIP
gets totally ignored. A PIP should be backed
by a small number of systems implementing

the proposal. This has implications on what
topic can be chosen and what staff can work
on a PIP. Ask Boris the Loris for the semiotics

of a PoC. Now PIPs have been perverted into
a forum to siphon Money into the Nowhere:

- Some discussions are going on in the PIP
-a working group related to synchronize (as a
-a lightweight standardize) some aspects
-a between Prolog systems.

So PIP has become ISO-2. Its not anymore
a PIP, which would modularly maybe conflicting,
collect proposals. One could very easily

jigsaw different dict efforts into separate
PIPs, when then work inheritly different.
Instead the goal is now "lightweight"

standardizing. It shows in this mess:

Dictionaries in Prolog (dynamic) https://prolog-lang.org/ImplementersForum/0102-dicts.html

Terms with named arguments (static dicts) https://prolog-lang.org/ImplementersForum/0104-argnames.html

Not a proposal at all. Just a big big mess.
Theretically when we assume that a PIP has
already PoCs, namely at least 2 Prolog systems

that implement something.

Bye

Julio Di Egidio schrieb:

On 27/09/2025 20:10, Mild Shock wrote:

Lets not forget that SWI-Prolog is now doomed
to have professional moron Julio Di Egidio
on board. Lets see what he says about dicts:

-a-a- The syntax <atom>{<key>:<any>,...} for rCLstructsrCY
-a-a-a-a (i.e. where the name is the functor name);
-a-a- The syntax <var>{<key>:<any>,...} for attributed vars.

LoL, I guess he has never heard of unification.

You just mangle quotes and go out on an insane and
abusive, even personally abusive, tangent: as usual.

Welcome back to my kill-file, under the rubric
stupidity is a moral defect.

*Plonk*

-Julio

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Here my citation source:

https://swi-prolog.discourse.group/t/dicts-attribute-variables-and-cyclic-terms/9324

a) Turn bottom up PIPs into top-down ISO-2:

"Some discussions are going on in the PIP
working group related to synchronize (as a
lightweight standardize) some aspects
between Prolog systems."
- Jan W.

b) Clueless about SWI Var dicts Unification:

- The syntax <atom>{<key>:<any>,...} for rCLstructsrCY
(i.e. where the name is the functor name);
- The syntax <var>{<key>:<any>,...} for attributed vars.
- Julio Di Egidio

Bye

Mild Shock schrieb:

Hi,

I big advantage of PoC derived only PIPs is a
firm scope. Put PoC first, derive PIPs bottom up,
and not the other way around use PIPs to spark

PoCs top down. A PoC would surely have a strong
boundary scope. On the other hand these PIPs now
have very weak fuzzy scopes.

They should put Boris the Loris into the
steering board, he was very good when
it came to community, and fuzzy versus

non-fuzzy. PoC based PIPs would probably
have clean descriptions, and not this horror
of Fuzzyness, where PIPs don't know their own Scope!!!

APPENDIX: META-DISCUSSION FOR THIS PIP
What should be covered in this PIP? https://prolog-lang.org/ImplementersForum/0102-dicts.html

TBD: relate with current_struct/1 ECLiPSe?
TBD: Discuss it
TBD: useful for portray, translation to dynamic dicts (Jan) https://prolog-lang.org/ImplementersForum/0104-argnames.html

Such discussion would be find in the GitHub
of a PoC, in case the PoC was developed
with GitHub. Nowadays the GitHub could even

contain longwinding discussions, since GitHub
offers discussions, its even not necessary
to put discussions into issue tickets.

Bye

Mild Shock schrieb:

Hi,

The PoC (Proof of Concept) aspect of a PIP
gets totally ignored. A PIP should be backed
by a small number of systems implementing

the proposal. This has implications on what
topic can be chosen and what staff can work
on a PIP. Ask Boris the Loris for the semiotics

of a PoC. Now PIPs have been perverted into
a forum to siphon Money into the Nowhere:

- Some discussions are going on in the PIP
-a-a working group related to synchronize (as a
-a-a lightweight standardize) some aspects
-a-a between Prolog systems.

So PIP has become ISO-2. Its not anymore
a PIP, which would modularly maybe conflicting,
collect proposals. One could very easily

jigsaw different dict efforts into separate
PIPs, when then work inheritly different.
Instead the goal is now "lightweight"

standardizing. It shows in this mess:

Dictionaries in Prolog (dynamic)
https://prolog-lang.org/ImplementersForum/0102-dicts.html

Terms with named arguments (static dicts)
https://prolog-lang.org/ImplementersForum/0104-argnames.html

Not a proposal at all. Just a big big mess.
Theretically when we assume that a PIP has
already PoCs, namely at least 2 Prolog systems

that implement something.


Bye

Julio Di Egidio schrieb:

On 27/09/2025 20:10, Mild Shock wrote:

Lets not forget that SWI-Prolog is now doomed
to have professional moron Julio Di Egidio
on board. Lets see what he says about dicts:

-a-a- The syntax <atom>{<key>:<any>,...} for rCLstructsrCY
-a-a-a-a (i.e. where the name is the functor name);
-a-a- The syntax <var>{<key>:<any>,...} for attributed vars.

LoL, I guess he has never heard of unification.

You just mangle quotes and go out on an insane and
abusive, even personally abusive, tangent: as usual.

Welcome back to my kill-file, under the rubric
stupidity is a moral defect.

*Plonk*

-Julio

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

So lets recap the history again:

How SWI-Prolog went down hills. Its
very easy to see. It lost the following
hotshots over time:

- Paulo Moura (Logtalk)
- Markus Triska (CLP(Z))
- Ulrich Neumerkel (ISO)
- Who else?

With the loss of Ulrich Neumerkel (ISO), it
also liberated itself from ISO. The historic
divided happend in SWI7 and was documented here:

https://www.complang.tuwien.ac.at/ulrich/iso-prolog/SWI7_and_ISO

Might have been the same time when SWI-Prolog dicts
were heralded as a community invention.
Irony how they ignored existing attribute

variable syntax already back then. But now
since the horizon has strong new players, the
world has become more threatening with Scryer Prolog.

PIPs and the label "Prolog" are abused, and
there is a revival of the standardization idea,
now rebrandished as "light". Before it was only one

system has it all, all extensions, and its
SWI-Prolog, so everything is fine. SWI-Prolog
was the vessel for consolidation of extensions.

Now the aims have dramatically changed, its
about to snip off a piece of the Prolog world.
And bring other Prolog systems on board, because

there are new amazing competitor vessels
cruising the Prolog ocean.

Bye

Mild Shock schrieb:

Hi,

Here my citation source:

https://swi-prolog.discourse.group/t/dicts-attribute-variables-and-cyclic-terms/9324

a) Turn bottom up PIPs into top-down ISO-2:

"Some discussions are going on in the PIP
working group related to synchronize (as a
lightweight standardize) some aspects
between Prolog systems."
- Jan W.

b) Clueless about SWI Var dicts Unification:

-a- The syntax <atom>{<key>:<any>,...} for rCLstructsrCY
-a-a-a (i.e. where the name is the functor name);
-a- The syntax <var>{<key>:<any>,...} for attributed vars.
- Julio Di Egidio

Bye

Mild Shock schrieb:

Hi,

I big advantage of PoC derived only PIPs is a
firm scope. Put PoC first, derive PIPs bottom up,
and not the other way around use PIPs to spark

PoCs top down. A PoC would surely have a strong
boundary scope. On the other hand these PIPs now
have very weak fuzzy scopes.

They should put Boris the Loris into the
steering board, he was very good when
it came to community, and fuzzy versus

non-fuzzy. PoC based PIPs would probably
have clean descriptions, and not this horror
of Fuzzyness, where PIPs don't know their own Scope!!!

APPENDIX: META-DISCUSSION FOR THIS PIP
What should be covered in this PIP?
https://prolog-lang.org/ImplementersForum/0102-dicts.html

TBD: relate with current_struct/1 ECLiPSe?
TBD: Discuss it
TBD: useful for portray, translation to dynamic dicts (Jan)
https://prolog-lang.org/ImplementersForum/0104-argnames.html

Such discussion would be find in the GitHub
of a PoC, in case the PoC was developed
with GitHub. Nowadays the GitHub could even

contain longwinding discussions, since GitHub
offers discussions, its even not necessary
to put discussions into issue tickets.

Bye

Mild Shock schrieb:

Hi,

The PoC (Proof of Concept) aspect of a PIP
gets totally ignored. A PIP should be backed
by a small number of systems implementing

the proposal. This has implications on what
topic can be chosen and what staff can work
on a PIP. Ask Boris the Loris for the semiotics

of a PoC. Now PIPs have been perverted into
a forum to siphon Money into the Nowhere:

- Some discussions are going on in the PIP
-a-a working group related to synchronize (as a
-a-a lightweight standardize) some aspects
-a-a between Prolog systems.

So PIP has become ISO-2. Its not anymore
a PIP, which would modularly maybe conflicting,
collect proposals. One could very easily

jigsaw different dict efforts into separate
PIPs, when then work inheritly different.
Instead the goal is now "lightweight"

standardizing. It shows in this mess:

Dictionaries in Prolog (dynamic)
https://prolog-lang.org/ImplementersForum/0102-dicts.html

Terms with named arguments (static dicts)
https://prolog-lang.org/ImplementersForum/0104-argnames.html

Not a proposal at all. Just a big big mess.
Theretically when we assume that a PIP has
already PoCs, namely at least 2 Prolog systems

that implement something.


Bye

Julio Di Egidio schrieb:

On 27/09/2025 20:10, Mild Shock wrote:

Lets not forget that SWI-Prolog is now doomed
to have professional moron Julio Di Egidio
on board. Lets see what he says about dicts:

-a-a- The syntax <atom>{<key>:<any>,...} for rCLstructsrCY
-a-a-a-a (i.e. where the name is the functor name);
-a-a- The syntax <var>{<key>:<any>,...} for attributed vars.

LoL, I guess he has never heard of unification.

You just mangle quotes and go out on an insane and
abusive, even personally abusive, tangent: as usual.

Welcome back to my kill-file, under the rubric
stupidity is a moral defect.

*Plonk*

-Julio

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

You can still make a tag variable an
attributed variable in SWI-Prolog. This
here works in SWI-Prolog:

?- X = foo{bar:123,baz:abc},
freeze(Tag, Tag = foo),
Y = Tag{bar:Value1,baz:Value2}, X = Y.
X = Y, Y = foo{bar:123, baz:abc},
Tag = foo,
Value1 = 123,
Value2 = abc.

?- X = foo{bar:123,baz:abc},
freeze(Tag, Tag = jack),
Y = Tag{bar:Value1,baz:Value2}, X = Y.
false.

But if the tag variable is an attributed
variable, the write result can possibly
not be read back:

?- freeze(X, X = foo), Y = X{bar:123,baz:abc},
write_term(Y, [attributes(dots)]).
_9352{...}{bar:123,baz:abc}
Y = X{bar:123, baz:abc},
freeze(X, X=foo).

The syntax of cascaded dicts, is not supported,
the Tag can only be atomic or variable, but
not structured itself at the moment:

?- X = foo{bar:123}{baz:abc}.
ERROR: Syntax error: Operator expected
ERROR: X = foo{bar:123
ERROR: ** here **
ERROR: }{baz:abc} .

The old and existing proposals that have dict
syntax only for attributed variable state, typically
avoid a cascading syntax.

Bye
--- Synchronet 3.21a-Linux NewsLink 1.2