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


Groups > comp.lang.prolog > #14152

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

From Mild Shock <janburse@fastmail.fm>
Newsgroups comp.lang.prolog
Subject Re: Is a PIP for Syntax extensions necessary? (Was; post-N246 Read- and Write-Option variable_names/1)
Date 2024-08-11 00:25 +0200
Message-ID <v98pcg$12bjs$1@solani.org> (permalink)
References (1 earlier) <v98b1p$123qt$1@solani.org> <v98bpp$124d0$1@solani.org> <v98o1s$12aq2$1@solani.org> <v98o6o$12aq2$2@solani.org> <v98ort$12bb4$1@solani.org>

Show all headers | View raw


 > 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?
> 

Back to comp.lang.prolog | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web