Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.prolog > #14115 > unrolled thread

DCG restrictions on the left-hand side [Novacore]

Back to article view | Back to comp.lang.prolog

Contents

  DCG restrictions on the left-hand side [Novacore] Mild Shock <janburse@fastmail.fm> - 2024-07-30 20:39 +0200
    Re: DCG restrictions on the left-hand side [Novacore] Mild Shock <janburse@fastmail.fm> - 2024-07-30 20:43 +0200
      Re: DCG restrictions on the left-hand side [Novacore] Mild Shock <janburse@fastmail.fm> - 2024-07-30 20:45 +0200
        Re: DCG restrictions on the left-hand side [Novacore] Mild Shock <janburse@fastmail.fm> - 2024-07-31 07:55 +0200
          Re: DCG restrictions on the left-hand side [Novacore] Mild Shock <janburse@fastmail.fm> - 2024-07-31 08:07 +0200
    post-N246 Read- and Write-Option variable_names/1 (Was: DCG restrictions on the left-hand side [Novacore]) Mild Shock <janburse@fastmail.fm> - 2024-08-10 20:20 +0200
      Re: post-N246 Read- and Write-Option variable_names/1 (Was: DCG restrictions on the left-hand side [Novacore]) Mild Shock <janburse@fastmail.fm> - 2024-08-10 20:33 +0200
        Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1) Mild Shock <janburse@fastmail.fm> - 2024-08-11 00:02 +0200
          Re: Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1) Mild Shock <janburse@fastmail.fm> - 2024-08-11 00:05 +0200
            Re: Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1) Mild Shock <janburse@fastmail.fm> - 2024-08-11 00:16 +0200
              Re: Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1) Mild Shock <janburse@fastmail.fm> - 2024-08-11 00:25 +0200
                Re: Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1) Mild Shock <janburse@fastmail.fm> - 2024-08-11 14:46 +0200
    A PIP classification scheme is needed (Was: DCG restrictions on the left-hand side [Novacore]) Mild Shock <janburse@fastmail.fm> - 2024-08-13 11:18 +0200
      Re: A PIP classification scheme is needed (Was: DCG restrictions on the left-hand side [Novacore]) Mild Shock <janburse@fastmail.fm> - 2024-08-13 11:23 +0200
        Re: A PIP classification scheme is needed (Was: DCG restrictions on the left-hand side [Novacore]) Mild Shock <janburse@fastmail.fm> - 2024-08-13 13:08 +0200

#14115 — DCG restrictions on the left-hand side [Novacore]

Guess how many newer Prolog systems allow this here:

?- [user].
p;q --> r.
    true.

On the other hand SWI-Prolog disallows it:

?- [user].
p;q --> r.

ERROR: user://1:29:
ERROR:    No permission to define dcg_nonterminal `p;q'

[toc] | [next] | [standalone]

#14116

In Novacore we are lucky, its a side effect of
phrase translating the head and a multi-file check:

?- [user].
p;q --> r.
Fehler: Kann Prädikat ;/2 nicht umdefinieren, nicht als Mehrdateien 
markiert.

But might work out differently if a DCG is expanded
and asserted. Ok, its actually not so bad:

?- expand_term((p;q --> r), X), assertz(X).
Fehler: Kann Prädikat ;/2 nicht aktualisieren.
	user auf 1


Mild Shock schrieb:
> Guess how many newer Prolog systems allow this here:
> 
> ?- [user].
> p;q --> r.
>     true.
> 
> On the other hand SWI-Prolog disallows it:
> 
> ?- [user].
> p;q --> r.
> 
> ERROR: user://1:29:
> ERROR:    No permission to define dcg_nonterminal `p;q'

[toc] | [prev] | [next] | [standalone]

#14117

This was discussed here:

Definite Clause Grammars Harmonization Proposal
Last edit jschimpf? October 20, 2016, at 12:42 AM
https://eclipseclp.org/wiki/Prolog/DCG

Not sure why Scryer Prolog doesn't implement it.

Mild Shock schrieb:
> 
> In Novacore we are lucky, its a side effect of
> phrase translating the head and a multi-file check:
> 
> ?- [user].
> p;q --> r.
> Fehler: Kann Prädikat ;/2 nicht umdefinieren, nicht als Mehrdateien 
> markiert.
> 
> But might work out differently if a DCG is expanded
> and asserted. Ok, its actually not so bad:
> 
> ?- expand_term((p;q --> r), X), assertz(X).
> Fehler: Kann Prädikat ;/2 nicht aktualisieren.
>      user auf 1
> 
> 
> Mild Shock schrieb:
>> Guess how many newer Prolog systems allow this here:
>>
>> ?- [user].
>> p;q --> r.
>>     true.
>>
>> On the other hand SWI-Prolog disallows it:
>>
>> ?- [user].
>> p;q --> r.
>>
>> ERROR: user://1:29:
>> ERROR:    No permission to define dcg_nonterminal `p;q'
> 

[toc] | [prev] | [next] | [standalone]

#14118

Although SWI-Prolog implements a lot of checks.
It still allows this one:

?- a-->b.
ERROR: Unknown procedure: (-->)/2

?- assertz((a-->b)).
true.

?- a-->b.
true.

Scryer Prolog managed to prevent this, in that
the assertz/1 throws an error.

Think will finally adopt this behaviour to
prevent the end-user from accidentially

fiddling with (-->)/2.

Mild Shock schrieb:
> 
> This was discussed here:
> 
> Definite Clause Grammars Harmonization Proposal
> Last edit jschimpf? October 20, 2016, at 12:42 AM
> https://eclipseclp.org/wiki/Prolog/DCG
> 
> Not sure why Scryer Prolog doesn't implement it.
> 
> Mild Shock schrieb:
>>
>> In Novacore we are lucky, its a side effect of
>> phrase translating the head and a multi-file check:
>>
>> ?- [user].
>> p;q --> r.
>> Fehler: Kann Prädikat ;/2 nicht umdefinieren, nicht als Mehrdateien 
>> markiert.
>>
>> But might work out differently if a DCG is expanded
>> and asserted. Ok, its actually not so bad:
>>
>> ?- expand_term((p;q --> r), X), assertz(X).
>> Fehler: Kann Prädikat ;/2 nicht aktualisieren.
>>      user auf 1
>>
>>
>> Mild Shock schrieb:
>>> Guess how many newer Prolog systems allow this here:
>>>
>>> ?- [user].
>>> p;q --> r.
>>>     true.
>>>
>>> On the other hand SWI-Prolog disallows it:
>>>
>>> ?- [user].
>>> p;q --> r.
>>>
>>> ERROR: user://1:29:
>>> ERROR:    No permission to define dcg_nonterminal `p;q'
>>
> 

[toc] | [prev] | [next] | [standalone]

#14119

I think its worth adopting this behaviour:

/* Scryer Prolog */
?- a-->b.
    error(existence_error(procedure,(-->)/2),(-->)/2).
?- assertz((a-->b)).
    error(permission_error(modify,static_procedure,(-->)/2),assertz/1).
?- a-->b.
    error(existence_error(procedure,(-->)/2),(-->)/2).

Mild Shock schrieb:
> Although SWI-Prolog implements a lot of checks.
> It still allows this one:
> 
> ?- a-->b.
> ERROR: Unknown procedure: (-->)/2
> 
> ?- assertz((a-->b)).
> true.
> 
> ?- a-->b.
> true.
> 
> Scryer Prolog managed to prevent this, in that
> the assertz/1 throws an error.
> 
> Think will finally adopt this behaviour to
> prevent the end-user from accidentially
> 
> fiddling with (-->)/2.
> 
> Mild Shock schrieb:
>>
>> This was discussed here:
>>
>> Definite Clause Grammars Harmonization Proposal
>> Last edit jschimpf? October 20, 2016, at 12:42 AM
>> https://eclipseclp.org/wiki/Prolog/DCG
>>
>> Not sure why Scryer Prolog doesn't implement it.
>>
>> Mild Shock schrieb:
>>>
>>> In Novacore we are lucky, its a side effect of
>>> phrase translating the head and a multi-file check:
>>>
>>> ?- [user].
>>> p;q --> r.
>>> Fehler: Kann Prädikat ;/2 nicht umdefinieren, nicht als Mehrdateien 
>>> markiert.
>>>
>>> But might work out differently if a DCG is expanded
>>> and asserted. Ok, its actually not so bad:
>>>
>>> ?- expand_term((p;q --> r), X), assertz(X).
>>> Fehler: Kann Prädikat ;/2 nicht aktualisieren.
>>>      user auf 1
>>>
>>>
>>> Mild Shock schrieb:
>>>> Guess how many newer Prolog systems allow this here:
>>>>
>>>> ?- [user].
>>>> p;q --> r.
>>>>     true.
>>>>
>>>> On the other hand SWI-Prolog disallows it:
>>>>
>>>> ?- [user].
>>>> p;q --> r.
>>>>
>>>> ERROR: user://1:29:
>>>> ERROR:    No permission to define dcg_nonterminal `p;q'
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14147 — post-N246 Read- and Write-Option variable_names/1 (Was: DCG restrictions on the left-hand side [Novacore])

UWN is testing Prolog systems that don't exist anymore:

Jekejeke 1.5.0
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/variable_names#73

a) There is no more publicitly available Jekejeke
    Prolog anymore, I think I wrote UWN already in the
    past about that.

b) There is only Dogelog Player, which has a 100%
    Prolog written read/write predicates including
    the variable_name/1 option. Source code is here,
    you also find GIT access etc to the Prolog system:

Quelltexte und Archive des Dogelog Spieler.
https://www.xlog.ch/izytab/doclet/docs/07_spec/02_dogelog.html

c) There is an internal version of Jekejeke Prolog,
    which is way after 1.5.0, with version 1.7.0, but
    it also uses the Dogelog Payer 100% Prolog
    written read/write, so no need to test.


Mild Shock schrieb:
> Guess how many newer Prolog systems allow this here:
> 
> ?- [user].
> p;q --> r.
>     true.
> 
> On the other hand SWI-Prolog disallows it:
> 
> ?- [user].
> p;q --> r.
> 
> ERROR: user://1:29:
> ERROR:    No permission to define dcg_nonterminal `p;q'

[toc] | [prev] | [next] | [standalone]

#14148 — Re: post-N246 Read- and Write-Option variable_names/1 (Was: DCG restrictions on the left-hand side [Novacore])

Hi,

I recently introduce '$VAR'/1 detection in
writing again. I have now a 100% Prolog written
'$VAR'/1 capable output routine.

Somehow I found '$VAR'/1 usueful again, especially
in connection with numbersvars/3 which is in
library(compat) the two make a nice pair

of Swiss army knife for printing. What the
routines don't do, they for example don't check
variable_names/1 option for a cyclic list, so

I currently get:

/* Dogelog Player */
?- VN = ['U'=X,'V'=Y | VN], write_term(f(X,g(Y,X),Y), 
[variable_names(VN)]), nl.
%%% hangs or I wasn't wainting long enough

But then SWI-Prolog does something strange,
but the error message is funny:

?- VN = ['U'=X,'V'=Y | VN], write_term(f(X,g(Y,X),Y), 
[variable_names(VN)]), nl.
ERROR: Type error: `list' expected, found `'V'=V' (a compound)

Does the error message use the variable_names/1
association list that is in prepaperation somehow,
as a unintended side effect? Or what explains that

it shows 'V'=V' and not 'V'=Y'? And why does it
complain about compound? And not say something about cyclic?
This here works correctly:

?- VN = ['U'=X,'V'=Y], write_term(f(X,g(Y,X),Y),
    [variable_names(VN)]), nl.
f(U,g(V,U),V)

Mild Shock schrieb:
> 
> UWN is testing Prolog systems that don't exist anymore:
> 
> Jekejeke 1.5.0
> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/variable_names#73
> 
> a) There is no more publicitly available Jekejeke
>     Prolog anymore, I think I wrote UWN already in the
>     past about that.
> 
> b) There is only Dogelog Player, which has a 100%
>     Prolog written read/write predicates including
>     the variable_name/1 option. Source code is here,
>     you also find GIT access etc to the Prolog system:
> 
> Quelltexte und Archive des Dogelog Spieler.
> https://www.xlog.ch/izytab/doclet/docs/07_spec/02_dogelog.html
> 
> c) There is an internal version of Jekejeke Prolog,
>     which is way after 1.5.0, with version 1.7.0, but
>     it also uses the Dogelog Payer 100% Prolog
>     written read/write, so no need to test.
> 
> 
> Mild Shock schrieb:
>> Guess how many newer Prolog systems allow this here:
>>
>> ?- [user].
>> p;q --> r.
>>     true.
>>
>> On the other hand SWI-Prolog disallows it:
>>
>> ?- [user].
>> p;q --> r.
>>
>> ERROR: user://1:29:
>> ERROR:    No permission to define dcg_nonterminal `p;q'
> 

[toc] | [prev] | [next] | [standalone]

#14149 — Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1)

I have a question, does SWI-Prolog not anymore use
their dict syntax in the Janus interface:

 > import janus_swi as janus
 > janus.query_once("Y is X+1", {"X":1})
{'Y': 2, 'truth': True}

I don’t see _{...} anymore. When and how did this
happen? I was just thinking whether a Syntax
extension PIP is necessary. Such a PIP isn’t listed:

https://prolog-lang.org/ImplementersForum/PIPs.html

Is SWI-Prolog safe, against parsing problems,
when it still has block operators in the
background? Like can one mix and match

code that uses Janus interface with the
“new” dicts with other code that uses the
SWI-Prolog dicts based on _{...}

which we might now term the “old” dicts.
How do you access and manipulate the
“new” dicts, do the “old” operations work?

Mild Shock schrieb:
> Hi,
> 
> I recently introduce '$VAR'/1 detection in
> writing again. I have now a 100% Prolog written
> '$VAR'/1 capable output routine.
> 
> Somehow I found '$VAR'/1 usueful again, especially
> in connection with numbersvars/3 which is in
> library(compat) the two make a nice pair
> 
> of Swiss army knife for printing. What the
> routines don't do, they for example don't check
> variable_names/1 option for a cyclic list, so
> 
> I currently get:
> 
> /* Dogelog Player */
> ?- VN = ['U'=X,'V'=Y | VN], write_term(f(X,g(Y,X),Y), 
> [variable_names(VN)]), nl.
> %%% hangs or I wasn't wainting long enough
> 
> But then SWI-Prolog does something strange,
> but the error message is funny:
> 
> ?- VN = ['U'=X,'V'=Y | VN], write_term(f(X,g(Y,X),Y), 
> [variable_names(VN)]), nl.
> ERROR: Type error: `list' expected, found `'V'=V' (a compound)
> 
> Does the error message use the variable_names/1
> association list that is in prepaperation somehow,
> as a unintended side effect? Or what explains that
> 
> it shows 'V'=V' and not 'V'=Y'? And why does it
> complain about compound? And not say something about cyclic?
> This here works correctly:
> 
> ?- VN = ['U'=X,'V'=Y], write_term(f(X,g(Y,X),Y),
>     [variable_names(VN)]), nl.
> f(U,g(V,U),V)
> 
> Mild Shock schrieb:
>>
>> UWN is testing Prolog systems that don't exist anymore:
>>
>> Jekejeke 1.5.0
>> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/variable_names#73
>>
>> a) There is no more publicitly available Jekejeke
>>     Prolog anymore, I think I wrote UWN already in the
>>     past about that.
>>
>> b) There is only Dogelog Player, which has a 100%
>>     Prolog written read/write predicates including
>>     the variable_name/1 option. Source code is here,
>>     you also find GIT access etc to the Prolog system:
>>
>> Quelltexte und Archive des Dogelog Spieler.
>> https://www.xlog.ch/izytab/doclet/docs/07_spec/02_dogelog.html
>>
>> c) There is an internal version of Jekejeke Prolog,
>>     which is way after 1.5.0, with version 1.7.0, but
>>     it also uses the Dogelog Payer 100% Prolog
>>     written read/write, so no need to test.
>>
>>
>> Mild Shock schrieb:
>>> Guess how many newer Prolog systems allow this here:
>>>
>>> ?- [user].
>>> p;q --> r.
>>>     true.
>>>
>>> On the other hand SWI-Prolog disallows it:
>>>
>>> ?- [user].
>>> p;q --> r.
>>>
>>> ERROR: user://1:29:
>>> ERROR:    No permission to define dcg_nonterminal `p;q'
>>
> 

[toc] | [prev] | [next] | [standalone]

#14150 — Re: Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1)

Anything that touches or depends on syntax
is a complete can of worms. The ISO commitee
was not able to find an initial *english natural

language specification wording* for character
look-ahead, so that we find now character
look-ahead in Prolog compounds practially

implemented by all Prolog systems, but character
look-ahead interpretation may differ for
negative numbers, like here:

/* SWI-Prolog */
?- X = - 1^2, write_canonical(X), nl.
-(^(1,2))

/* Scryer Prolog */
?- X = - 1^2, write_canonical(X), nl.
^(-1,2)

But in the case of Scryer Prolog it doesn't
matter, since Scryer Prolog is anyway dead.

Mild Shock schrieb:
> I have a question, does SWI-Prolog not anymore use
> their dict syntax in the Janus interface:
> 
>  > import janus_swi as janus
>  > janus.query_once("Y is X+1", {"X":1})
> {'Y': 2, 'truth': True}
> 
> I don’t see _{...} anymore. When and how did this
> happen? I was just thinking whether a Syntax
> extension PIP is necessary. Such a PIP isn’t listed:
> 
> https://prolog-lang.org/ImplementersForum/PIPs.html
> 
> Is SWI-Prolog safe, against parsing problems,
> when it still has block operators in the
> background? Like can one mix and match
> 
> code that uses Janus interface with the
> “new” dicts with other code that uses the
> SWI-Prolog dicts based on _{...}
> 
> which we might now term the “old” dicts.
> How do you access and manipulate the
> “new” dicts, do the “old” operations work?

[toc] | [prev] | [next] | [standalone]

#14151 — Re: Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1)

So we have two victims in 2024, two
things died in 2024, are pepsi now:

- Scryer Prolog

- SWI-Prolog Dicts

LoL

Mild Shock schrieb:
> Anything that touches or depends on syntax
> is a complete can of worms. The ISO commitee
> was not able to find an initial *english natural
> 
> language specification wording* for character
> look-ahead, so that we find now character
> look-ahead in Prolog compounds practially
> 
> implemented by all Prolog systems, but character
> look-ahead interpretation may differ for
> negative numbers, like here:
> 
> /* SWI-Prolog */
> ?- X = - 1^2, write_canonical(X), nl.
> -(^(1,2))
> 
> /* Scryer Prolog */
> ?- X = - 1^2, write_canonical(X), nl.
> ^(-1,2)
> 
> But in the case of Scryer Prolog it doesn't
> matter, since Scryer Prolog is anyway dead.
> 
> Mild Shock schrieb:
>> I have a question, does SWI-Prolog not anymore use
>> their dict syntax in the Janus interface:
>>
>>  > import janus_swi as janus
>>  > janus.query_once("Y is X+1", {"X":1})
>> {'Y': 2, 'truth': True}
>>
>> I don’t see _{...} anymore. When and how did this
>> happen? I was just thinking whether a Syntax
>> extension PIP is necessary. Such a PIP isn’t listed:
>>
>> https://prolog-lang.org/ImplementersForum/PIPs.html
>>
>> Is SWI-Prolog safe, against parsing problems,
>> when it still has block operators in the
>> background? Like can one mix and match
>>
>> code that uses Janus interface with the
>> “new” dicts with other code that uses the
>> SWI-Prolog dicts based on _{...}
>>
>> which we might now term the “old” dicts.
>> How do you access and manipulate the
>> “new” dicts, do the “old” operations work?

[toc] | [prev] | [next] | [standalone]

#14152 — Re: Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1)

 > import janus_swi as janus
 > janus.query_once("Y is X+1", {"X":1})
{'Y': 2, 'truth': True}

Ok, my bad the above is Python code and
not Prolog code, right? But how does XSB do it?

Ok the docu say:

Compatibility to the XSB Janus implementation
For this reason we support creating a Python
dict both from a SWI-Prolog dict and from the
Prolog term py({k1:v1, k2:v2, ...}) .
https://www.swi-prolog.org/pldoc/man?section=janus-vs-xsb

Does this affirm or reject the need for syntax
extension PIP? Why not just use “new” dicts on
both sides? Forget about the py tag, its anyway
always py. Does XSB “new” dict wrapped

in py compound have access and modification
operations? Wouldn’t it be enough to provide
operations without the py compound wrapping.


Mild Shock schrieb:
> So we have two victims in 2024, two
> things died in 2024, are pepsi now:
> 
> - Scryer Prolog
> 
> - SWI-Prolog Dicts
> 
> LoL
> 
> Mild Shock schrieb:
>> Anything that touches or depends on syntax
>> is a complete can of worms. The ISO commitee
>> was not able to find an initial *english natural
>>
>> language specification wording* for character
>> look-ahead, so that we find now character
>> look-ahead in Prolog compounds practially
>>
>> implemented by all Prolog systems, but character
>> look-ahead interpretation may differ for
>> negative numbers, like here:
>>
>> /* SWI-Prolog */
>> ?- X = - 1^2, write_canonical(X), nl.
>> -(^(1,2))
>>
>> /* Scryer Prolog */
>> ?- X = - 1^2, write_canonical(X), nl.
>> ^(-1,2)
>>
>> But in the case of Scryer Prolog it doesn't
>> matter, since Scryer Prolog is anyway dead.
>>
>> Mild Shock schrieb:
>>> I have a question, does SWI-Prolog not anymore use
>>> their dict syntax in the Janus interface:
>>>
>>>  > import janus_swi as janus
>>>  > janus.query_once("Y is X+1", {"X":1})
>>> {'Y': 2, 'truth': True}
>>>
>>> I don’t see _{...} anymore. When and how did this
>>> happen? I was just thinking whether a Syntax
>>> extension PIP is necessary. Such a PIP isn’t listed:
>>>
>>> https://prolog-lang.org/ImplementersForum/PIPs.html
>>>
>>> Is SWI-Prolog safe, against parsing problems,
>>> when it still has block operators in the
>>> background? Like can one mix and match
>>>
>>> code that uses Janus interface with the
>>> “new” dicts with other code that uses the
>>> SWI-Prolog dicts based on _{...}
>>>
>>> which we might now term the “old” dicts.
>>> How do you access and manipulate the
>>> “new” dicts, do the “old” operations work?
> 

[toc] | [prev] | [next] | [standalone]

#14157 — Re: Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1)

Ok, when I listed these two tomb stones,
this wasn't because I was jealous that
SWI-Prolog has dicts and dicts syntax,

its more the KISS principle, and the idea
that Prolog processors should pursue
non-functional optimizations without

new functional requirements. It might
appear as a strange idea, but it has many
advantages like not affecting the end-user

functionally in any way and not affecting
portability in any way. In as far my
tomb stones wish list is that long:

- SWI-Prolog dicts

- String type [not only SWI-Prolog]

The string type idea made it also into
a few newer Prolog system, but wouldn't it
be nice if strings where just transparent,

and implementation detail the Prolog processor
chooses, and not anything the end-user has
to worry about?

Mild Shock schrieb:
>> So we have two victims in 2024, two
>> things died in 2024, are pepsi now:
>>
>> - Scryer Prolog
>>
>> - SWI-Prolog Dicts
>>
>> LoL

[toc] | [prev] | [next] | [standalone]

#14160 — A PIP classification scheme is needed (Was: DCG restrictions on the left-hand side [Novacore])

.
Hi,

SARS-CoV-2 variant are classified as variant under
monitoring (VUM), variant of interest (VOI)
and variant of concern (VOC).

How would we classify PIPs. Here is a list:

- PIP 701: Tasks
Stackfull and stackless cooperative cooroutines.

- PIP 702: Events
An event loop to “asyncify” file system access, network
access, queues, terminals, windowing systems, etc…

- PIP 801: Threads
Split off from Paulo Maura’s multi-threading document.

- PIP 801: Mutex
Split off from Paulo Maura’s multi-threading document.

- PIP 802: Message queues for multi-threading
Split off from Paulo Maura’s multi-threading document.

- PIP 803: Simpler queues not for multi-threading (@marco’s ?)
Other sources here.

- PIP 901: Embrace strings
String literal, unify, (==)/2 and (@<)/2

- PIP 902: Fully embrace strings
String is/2, (=:=)/2 and (<)/2

- PIP 903: Partial strings
Compact and shared char lists.

Bye

Mild Shock schrieb:
> Guess how many newer Prolog systems allow this here:
> 
> ?- [user].
> p;q --> r.
>     true.
> 
> On the other hand SWI-Prolog disallows it:
> 
> ?- [user].
> p;q --> r.
> 
> ERROR: user://1:29:
> ERROR:    No permission to define dcg_nonterminal `p;q'

[toc] | [prev] | [next] | [standalone]

#14161 — Re: A PIP classification scheme is needed (Was: DCG restrictions on the left-hand side [Novacore])

The PIP 903: Partial strings wasn't
so successful yet. Although pursued by
two Prolog systems, Scryer Prolog

and Trealla Prolog, the results are
not a banger performance wise. Could
have to do with some DCG pipe dreams:

/* Scryer Prolog 0.9.4-135 */
?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)).
    % CPU time: 0.283s, 2_506_022 inferences
    true.

/* Trealla Prolog 2.55.19 */
?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)).
% Time elapsed 0.235s, 2568003 Inferences, 10.937 MLips
    true.

/* Dogelog Player for Java 1.2.1 */
?- time((between(1,1000,_), data(X), json_atom(Y,X), fail; true)).
% Zeit 40 ms, GC 0 ms, Lips 12502725, Uhr 13.08.2024 08:43
true.

/* SWI-Prolog 9.3.8 */
?- time((between(1,1000,_), data(X), atom_json_term(X,Y,[]), fail; true)).
% 44,998 inferences, 0.016 CPU in 0.006 seconds (281% CPU, 2879872 Lips)
true.

Bye

Mild Shock schrieb:
> .
> Hi,
> 
> SARS-CoV-2 variant are classified as variant under
> monitoring (VUM), variant of interest (VOI)
> and variant of concern (VOC).
> 
> How would we classify PIPs. Here is a list:
> 
> - PIP 701: Tasks
> Stackfull and stackless cooperative cooroutines.
> 
> - PIP 702: Events
> An event loop to “asyncify” file system access, network
> access, queues, terminals, windowing systems, etc…
> 
> - PIP 801: Threads
> Split off from Paulo Maura’s multi-threading document.
> 
> - PIP 801: Mutex
> Split off from Paulo Maura’s multi-threading document.
> 
> - PIP 802: Message queues for multi-threading
> Split off from Paulo Maura’s multi-threading document.
> 
> - PIP 803: Simpler queues not for multi-threading (@marco’s ?)
> Other sources here.
> 
> - PIP 901: Embrace strings
> String literal, unify, (==)/2 and (@<)/2
> 
> - PIP 902: Fully embrace strings
> String is/2, (=:=)/2 and (<)/2
> 
> - PIP 903: Partial strings
> Compact and shared char lists.
> 
> Bye
> 
> Mild Shock schrieb:
>> Guess how many newer Prolog systems allow this here:
>>
>> ?- [user].
>> p;q --> r.
>>     true.
>>
>> On the other hand SWI-Prolog disallows it:
>>
>> ?- [user].
>> p;q --> r.
>>
>> ERROR: user://1:29:
>> ERROR:    No permission to define dcg_nonterminal `p;q'
> 

[toc] | [prev] | [next] | [standalone]

#14162 — Re: A PIP classification scheme is needed (Was: DCG restrictions on the left-hand side [Novacore])

More hot topics flowing in:

- PIP 904: Partial strings and memory mapping
   Compact and shared char lists but memory mapped files.

- PIP 601: DCG
   Defiinite clause grammars

- PIP 602: PIO
   Clever DCGs over files using other than memory mapping.

Mild Shock schrieb:
> The PIP 903: Partial strings wasn't
> so successful yet. Although pursued by
> two Prolog systems, Scryer Prolog
> 
> and Trealla Prolog, the results are
> not a banger performance wise. Could
> have to do with some DCG pipe dreams:
> 
> /* Scryer Prolog 0.9.4-135 */
> ?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)).
>     % CPU time: 0.283s, 2_506_022 inferences
>     true.
> 
> /* Trealla Prolog 2.55.19 */
> ?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)).
> % Time elapsed 0.235s, 2568003 Inferences, 10.937 MLips
>     true.
> 
> /* Dogelog Player for Java 1.2.1 */
> ?- time((between(1,1000,_), data(X), json_atom(Y,X), fail; true)).
> % Zeit 40 ms, GC 0 ms, Lips 12502725, Uhr 13.08.2024 08:43
> true.
> 
> /* SWI-Prolog 9.3.8 */
> ?- time((between(1,1000,_), data(X), atom_json_term(X,Y,[]), fail; true)).
> % 44,998 inferences, 0.016 CPU in 0.006 seconds (281% CPU, 2879872 Lips)
> true.
> 
> Bye
> 
> Mild Shock schrieb:
>> .
>> Hi,
>>
>> SARS-CoV-2 variant are classified as variant under
>> monitoring (VUM), variant of interest (VOI)
>> and variant of concern (VOC).
>>
>> How would we classify PIPs. Here is a list:
>>
>> - PIP 701: Tasks
>> Stackfull and stackless cooperative cooroutines.
>>
>> - PIP 702: Events
>> An event loop to “asyncify” file system access, network
>> access, queues, terminals, windowing systems, etc…
>>
>> - PIP 801: Threads
>> Split off from Paulo Maura’s multi-threading document.
>>
>> - PIP 801: Mutex
>> Split off from Paulo Maura’s multi-threading document.
>>
>> - PIP 802: Message queues for multi-threading
>> Split off from Paulo Maura’s multi-threading document.
>>
>> - PIP 803: Simpler queues not for multi-threading (@marco’s ?)
>> Other sources here.
>>
>> - PIP 901: Embrace strings
>> String literal, unify, (==)/2 and (@<)/2
>>
>> - PIP 902: Fully embrace strings
>> String is/2, (=:=)/2 and (<)/2
>>
>> - PIP 903: Partial strings
>> Compact and shared char lists.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Guess how many newer Prolog systems allow this here:
>>>
>>> ?- [user].
>>> p;q --> r.
>>>     true.
>>>
>>> On the other hand SWI-Prolog disallows it:
>>>
>>> ?- [user].
>>> p;q --> r.
>>>
>>> ERROR: user://1:29:
>>> ERROR:    No permission to define dcg_nonterminal `p;q'
>>
> 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.prolog

csiph-web