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

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

A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024]

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

Contents

  A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024] Mild Shock <janburse@fastmail.fm> - 2024-05-27 19:58 +0200
    Re: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024] Mild Shock <janburse@fastmail.fm> - 2024-05-27 20:01 +0200
    Scryer Prolog is dead now? (Was: A harsh wind is blowing into the face of Prolog now…) Mild Shock <janburse@fastmail.fm> - 2024-07-20 11:35 +0200
      What about the Holy Grail? (Was: Scryer Prolog is dead now?) Mild Shock <janburse@fastmail.fm> - 2024-07-21 17:29 +0200
        Is Rust the culprit? (Was: What about the Holy Grail?) Mild Shock <janburse@fastmail.fm> - 2024-07-22 22:16 +0200
          Re: Is Rust the culprit? (Was: What about the Holy Grail?) Mild Shock <janburse@fastmail.fm> - 2024-07-22 22:26 +0200
            Re: Is Rust the culprit? (Was: What about the Holy Grail?) Mild Shock <janburse@fastmail.fm> - 2024-07-22 22:38 +0200
          Night Train to Lisbon (Re: Is Rust the culprit?) Mild Shock <janburse@fastmail.fm> - 2024-10-18 01:35 +0200
            Prolog System running on JS/Bun ? (Was: Night Train to Lisbon) Mild Shock <janburse@fastmail.fm> - 2024-11-20 14:20 +0100
          Highly bred Hackers: Wallowing in enlightenment (Was: Is Rust the culprit?) Mild Shock <janburse@fastmail.fm> - 2024-10-26 17:43 +0200
            Good Bye Stack-Overflow (Was: Highly bred Hackers: Wallowing in enlightenment) Mild Shock <janburse@fastmail.fm> - 2024-11-15 03:16 +0100
              Re: Good Bye Stack-Overflow (Was: Highly bred Hackers: Wallowing in enlightenment) Mild Shock <janburse@fastmail.fm> - 2024-11-15 03:24 +0100
                Re: Good Bye Stack-Overflow (Was: Highly bred Hackers: Wallowing in enlightenment) Mild Shock <janburse@fastmail.fm> - 2024-11-15 03:28 +0100
                  Re: Good Bye Stack-Overflow (Was: Highly bred Hackers: Wallowing in enlightenment) Mild Shock <janburse@fastmail.fm> - 2024-11-15 03:54 +0100
              they shoot themselves into the foot (Re: Good Bye Stack-Overflow) Mild Shock <janburse@fastmail.fm> - 2024-11-15 16:47 +0100
                Re: they shoot themselves into the foot (Re: Good Bye Stack-Overflow) Mild Shock <janburse@fastmail.fm> - 2024-11-15 17:00 +0100
                  Re: they shoot themselves into the foot (Re: Good Bye Stack-Overflow) Mild Shock <janburse@fastmail.fm> - 2024-11-15 17:11 +0100
                    Re: they shoot themselves into the foot (Re: Good Bye Stack-Overflow) Mild Shock <janburse@fastmail.fm> - 2024-11-15 18:00 +0100
    Can we trust the Scryer Prolog Gurus? (Was: A harsh wind is blowing into the face of Prolog now… ) Mild Shock <janburse@fastmail.fm> - 2024-07-23 00:27 +0200
      Re: Can we trust the Scryer Prolog Gurus? (Was: A harsh wind is blowing into the face of Prolog now… ) Mild Shock <janburse@fastmail.fm> - 2024-07-23 00:30 +0200
        Re: Can we trust the Scryer Prolog Gurus? (Was: A harsh wind is blowing into the face of Prolog now… ) Mild Shock <janburse@fastmail.fm> - 2024-07-23 00:42 +0200
    The longest pregnancy in the history of Prolog ~~> DCGs (Was: A harsh wind is blowing into the face of Prolog now…) Mild Shock <janburse@fastmail.fm> - 2024-07-23 09:51 +0200
      Re: The longest pregnancy in the history of Prolog ~~> DCGs (Was: A harsh wind is blowing into the face of Prolog now…) Mild Shock <janburse@fastmail.fm> - 2024-07-23 09:52 +0200
        Re: The longest pregnancy in the history of Prolog ~~> DCGs (Was: A harsh wind is blowing into the face of Prolog now…) Mild Shock <janburse@fastmail.fm> - 2024-07-23 10:18 +0200
          Re: The longest pregnancy in the history of Prolog ~~> DCGs (Was: A harsh wind is blowing into the face of Prolog now…) Mild Shock <janburse@fastmail.fm> - 2024-07-23 10:20 +0200
            Re: The longest pregnancy in the history of Prolog ~~> DCGs (Was: A harsh wind is blowing into the face of Prolog now…) Mild Shock <janburse@fastmail.fm> - 2024-07-23 16:38 +0200
    Is Scryer Prolog the Air Guitar of Prolog? (Was: A harsh wind is blowing into the face of Prolog now…) Mild Shock <janburse@fastmail.fm> - 2024-07-23 21:56 +0200
      Re: Is Scryer Prolog the Air Guitar of Prolog? (Was: A harsh wind is blowing into the face of Prolog now…) Mild Shock <janburse@fastmail.fm> - 2024-07-23 23:49 +0200
        Re: Is Scryer Prolog the Air Guitar of Prolog? (Was: A harsh wind is blowing into the face of Prolog now…) Mild Shock <janburse@fastmail.fm> - 2024-07-24 22:21 +0200
    Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024]) Mild Shock <janburse@fastmail.fm> - 2024-07-26 15:38 +0200
      Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024]) Mild Shock <janburse@fastmail.fm> - 2024-07-26 15:41 +0200
        Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024]) Mild Shock <janburse@fastmail.fm> - 2024-07-27 11:27 +0200
          Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024]) Mild Shock <janburse@fastmail.fm> - 2024-07-27 11:36 +0200
            Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024]) Mild Shock <janburse@fastmail.fm> - 2024-07-27 11:52 +0200
              Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024]) Mild Shock <janburse@fastmail.fm> - 2024-07-27 11:56 +0200
                Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024]) Mild Shock <janburse@fastmail.fm> - 2024-07-27 12:04 +0200
                  Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024]) Mild Shock <janburse@fastmail.fm> - 2024-07-27 12:09 +0200
                    Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024]) Mild Shock <janburse@fastmail.fm> - 2024-07-27 12:54 +0200

Page 2 of 2 — ← Prev page 1 [2]

#14080 — Re: Can we trust the Scryer Prolog Gurus? (Was: A harsh wind is blowing into the face of Prolog now… )

Well I am mistaken, Prolog 0 must have had some
concept of error. For example I find:

3. OPERATION SUR LES NOMBRES
=============================
LES PREDICATS SONT EVALUES A ERROR

And this is also used in a code_type variant, i.e.
CHIFFRE and LETTRE, follow the instantiation error
idea. But we have this also in Prolog systems today:

/* SWI-Prolog */
?- code_type(0'a, X).
X = alnum .

?- code_type(X, X).
ERROR: Arguments are not sufficiently instantiated

It is not the case that modern Prolog systems always
silently fail. They silently fail in atom/1, integer/1, etc..
which makes sense, especially from a WAM implementation

viewpoint, since WAM has usually type tag branching or
switching instructions. So these atom/1, integer/1, etc.. can
be implemented quite efficiently and one should view them

as belonging to the same category as var/1, (==)/2, etc..
i.e. meta predicates that deal syntactically with Prolog terms.
Some Prolog system can even perform indexing on these guards.

Mild Shock schrieb:
> That the DEC 10 Prolog 1975 is close to Prolog 0,
> can be verified by reading the Prolog 0 manual:
> 
> MANUEL DE REFE RE NeE ET D'UTILISATION - PROLOG
> ROUSSEL Ph. (1975)
> http://alain.colmerauer.free.fr/alcol/ArchivesPublications/ManuelProlog/Pr.pdf 
> 
> 
> So at that same year there was already an
> English rip-off. If I read the french, I also
> don't find some atom/1, integer/1 equivalent
> 
> that would throw an instantiation error. Problem
> is again, what would have been an exception in Prolog 0?
> 
> Mild Shock schrieb:
>> For example one Guru claimed?
>>
>>  > Prolog were invented today, I think there would
>>  > be at least two significant differences:
>>  >
>>  > First, the type-testing predicates like atom/1,
>>  > integer/1 and compound/1 would (and should) throw
>>  > instantiation errors if their arguments are not
>>  > sufficiently instantiated.
>>  >
>>  > This is also what the original versions of Prolog
>>  > did. However, DEC 10 Prolog chose to replace instantiation
>>  > errors by silent failures, and this has been
>>  > perpetuated in the Edinburgh tradition for type tests
>>  > including the ISO standard.
>> https://www.quora.com/If-prolog-were-being-invented-today-with-no-concern-for-backward-compatibility-or-the-existing-standardization-how-would-it-differ-from-standard-prolog 
>>
>>
>> I cannot verify any of the above nonsense.
>>
>> First of all the term "DEC-10 Prolog" is ambigious:
>>
>> DEC 10 Prolog 1975
>> https://www.softwarepreservation.org/projects/prolog/prolog/edinburgh/doc/Warren-Epilog_400_400-1975.pdf 
>>
>>
>> DEC 10 Prolog 1982
>> https://userweb.fct.unl.pt/~lmp/publications/online-papers/DECsystem-10%20PROLOG%20USER%27S%20MANUAL.pdf 
>>
>>
>> The DEC 10 Prolog 1975 looks very close to Prolog 0
>> with its french predicate names. There is not a simgle
>> atom/1, integer/1 equivalent that would throw an
>>
>> instantiation error. Actually Prolog 0 didn't even
>> have some sort of exceptions, right?
>>
>> Mild Shock schrieb:
>>> Especially since good old FORTRAN has
>>> made a new appearance:
>>>
>>> TIOBE Index for May 2024
>>> I have received a lot of questions why Fortran entered the top 10
>>> again after more than 20 years. The TIOBE index just publishes
>>> what has been measured.
>>> https://www.tiobe.com/tiobe-index/
>>>
>>> Why Fortran is back in TIOBE’s top 10
>>> First, Fortran is especially good at numerical analysis and
>>> computational mathematics. Numerical and mathematical
>>> computing is growing because interest in artificial intelligence
>>> is growing, Jansen told TechRepublic in an email.
>>> https://www.techrepublic.com/article/tiobe-index-may-2024/
>>
> 

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

#14081 — The longest pregnancy in the history of Prolog ~~> DCGs (Was: A harsh wind is blowing into the face of Prolog now…)

Woa! They are still fiddling with DCG:

Modified: Samstag, 6. Juli 2024, 07:53:05
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/phrase

For Dogelog Player and its Novacore, I have
invented shallow DCG transform. Shallow expansion is a
variant of the usually deep expansion, in that

we don't define a multi-file predicate:

term_expansion(<from>, <to>).

Which uses a result from goal expansion, i.e.
there is both term and goal expansion in deep expansion,
SWI-Prolog has even function expansion a third type of

expansion, but in shallow expansion we have only:

term_conversion(<from>, <to>).

In particular for performance and didactical
reasons Novacore from Dogelog Player has nothing
higher-order. So phrase/2 is missing. Not needed.

But I don't have test cases yet for this shallow
expansion. Maybe I could adapt a few from formerly
Jekejeke Prolog, trim them down to the scope of

shallow expansion.

Mild Shock schrieb:
> Especially since good old FORTRAN has
> made a new appearance:
> 
> TIOBE Index for May 2024
> I have received a lot of questions why Fortran entered the top 10
> again after more than 20 years. The TIOBE index just publishes
> what has been measured.
> https://www.tiobe.com/tiobe-index/
> 
> Why Fortran is back in TIOBE’s top 10
> First, Fortran is especially good at numerical analysis and
> computational mathematics. Numerical and mathematical
> computing is growing because interest in artificial intelligence
> is growing, Jansen told TechRepublic in an email.
> https://www.techrepublic.com/article/tiobe-index-may-2024/

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

#14082 — Re: The longest pregnancy in the history of Prolog ~~> DCGs (Was: A harsh wind is blowing into the face of Prolog now…)

P.S.: Only providing shallow expansion is no a loss.
You can use it to bootstrap deep expansion, I do
that in a stashed version of formerly Jekejeke Prolog,

as a proof of concept. So basically you can bootsrap
ISO-Core from Novacore in many cases. Also if DCG with
deep expansion would enter ISO-Core.

Novecore is just the smaller core than ISO-core.
Novacore is Prolog reduced to the max.

Mild Shock schrieb:
> Woa! They are still fiddling with DCG:
> 
> Modified: Samstag, 6. Juli 2024, 07:53:05
> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/phrase
> 
> For Dogelog Player and its Novacore, I have
> invented shallow DCG transform. Shallow expansion is a
> variant of the usually deep expansion, in that
> 
> we don't define a multi-file predicate:
> 
> term_expansion(<from>, <to>).
> 
> Which uses a result from goal expansion, i.e.
> there is both term and goal expansion in deep expansion,
> SWI-Prolog has even function expansion a third type of
> 
> expansion, but in shallow expansion we have only:
> 
> term_conversion(<from>, <to>).
> 
> In particular for performance and didactical
> reasons Novacore from Dogelog Player has nothing
> higher-order. So phrase/2 is missing. Not needed.
> 
> But I don't have test cases yet for this shallow
> expansion. Maybe I could adapt a few from formerly
> Jekejeke Prolog, trim them down to the scope of
> 
> shallow expansion.
> 
> Mild Shock schrieb:
>> Especially since good old FORTRAN has
>> made a new appearance:
>>
>> TIOBE Index for May 2024
>> I have received a lot of questions why Fortran entered the top 10
>> again after more than 20 years. The TIOBE index just publishes
>> what has been measured.
>> https://www.tiobe.com/tiobe-index/
>>
>> Why Fortran is back in TIOBE’s top 10
>> First, Fortran is especially good at numerical analysis and
>> computational mathematics. Numerical and mathematical
>> computing is growing because interest in artificial intelligence
>> is growing, Jansen told TechRepublic in an email.
>> https://www.techrepublic.com/article/tiobe-index-may-2024/
> 

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

#14083 — Re: The longest pregnancy in the history of Prolog ~~> DCGs (Was: A harsh wind is blowing into the face of Prolog now…)

Scryer Prolog is not the only dead Prolog around.
Like 12 months ago or so, I mentioned in passing
to @joseph-vidal-rosset , because he used Tau Prolog

on his web site, that Tau Prolog will be dead as soon
as the authors get their academic merits. And I guess
this is indeed the case, their GitHub is inactive

for at least 12 months now. But then some people still
include it in their testing, maybe this is a sign of a little
desperation, of finding Prolog system interested

in ISO nonsense?

Modified: Samstag, 6. Juli 2024, 07:53:05
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/phrase

The main problem with ISO Prolog is, that it is not
enough reduced to the max.


Mild Shock schrieb:
> 
> P.S.: Only providing shallow expansion is no a loss.
> You can use it to bootstrap deep expansion, I do
> that in a stashed version of formerly Jekejeke Prolog,
> 
> as a proof of concept. So basically you can bootsrap
> ISO-Core from Novacore in many cases. Also if DCG with
> deep expansion would enter ISO-Core.
> 
> Novecore is just the smaller core than ISO-core.
> Novacore is Prolog reduced to the max.
> 
> Mild Shock schrieb:
>> Woa! They are still fiddling with DCG:
>>
>> Modified: Samstag, 6. Juli 2024, 07:53:05
>> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/phrase
>>
>> For Dogelog Player and its Novacore, I have
>> invented shallow DCG transform. Shallow expansion is a
>> variant of the usually deep expansion, in that
>>
>> we don't define a multi-file predicate:
>>
>> term_expansion(<from>, <to>).
>>
>> Which uses a result from goal expansion, i.e.
>> there is both term and goal expansion in deep expansion,
>> SWI-Prolog has even function expansion a third type of
>>
>> expansion, but in shallow expansion we have only:
>>
>> term_conversion(<from>, <to>).
>>
>> In particular for performance and didactical
>> reasons Novacore from Dogelog Player has nothing
>> higher-order. So phrase/2 is missing. Not needed.
>>
>> But I don't have test cases yet for this shallow
>> expansion. Maybe I could adapt a few from formerly
>> Jekejeke Prolog, trim them down to the scope of
>>
>> shallow expansion.
>>
>> Mild Shock schrieb:
>>> Especially since good old FORTRAN has
>>> made a new appearance:
>>>
>>> TIOBE Index for May 2024
>>> I have received a lot of questions why Fortran entered the top 10
>>> again after more than 20 years. The TIOBE index just publishes
>>> what has been measured.
>>> https://www.tiobe.com/tiobe-index/
>>>
>>> Why Fortran is back in TIOBE’s top 10
>>> First, Fortran is especially good at numerical analysis and
>>> computational mathematics. Numerical and mathematical
>>> computing is growing because interest in artificial intelligence
>>> is growing, Jansen told TechRepublic in an email.
>>> https://www.techrepublic.com/article/tiobe-index-may-2024/
>>
> 

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

#14084 — Re: The longest pregnancy in the history of Prolog ~~> DCGs (Was: A harsh wind is blowing into the face of Prolog now…)

Another issue is that ISO Prolog doesn’t
have a reference implementation 100% written
in Prolog itself. Like for example the term
reading and writing. Now we have the situation

that no Prolog system can do these TPTP modal
logic operators and TPTP first order logic
quantifers at the same time:

/* Segerberg Models */
:- op( 600, fy, !).     % universal quantifier:  ![X]:
:- op( 600, fy, ?).     % existential quantifier:  ?[X]:
:- op( 600, fy, []).    % necessity
:- op( 600, fy, <>).    % possibility

But the above works in Dogelog Player. It doesn’t
work in SWI-Prolog, neither in Trealla Prolog,
neither in Scryer Prolog. Some Prolog systems have

problems with !, other Prolog systems have problems
with []. The parsing is admittedly a little tricky but
after some thinking it turns out relatively straight

forward doable.

Mild Shock schrieb:
> 
> Scryer Prolog is not the only dead Prolog around.
> Like 12 months ago or so, I mentioned in passing
> to @joseph-vidal-rosset , because he used Tau Prolog
> 
> on his web site, that Tau Prolog will be dead as soon
> as the authors get their academic merits. And I guess
> this is indeed the case, their GitHub is inactive
> 
> for at least 12 months now. But then some people still
> include it in their testing, maybe this is a sign of a little
> desperation, of finding Prolog system interested
> 
> in ISO nonsense?
> 
> Modified: Samstag, 6. Juli 2024, 07:53:05
> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/phrase
> 
> The main problem with ISO Prolog is, that it is not
> enough reduced to the max.

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

#14085 — Re: The longest pregnancy in the history of Prolog ~~> DCGs (Was: A harsh wind is blowing into the face of Prolog now…)

Amazing Ciao Prolog can do it correctly.

Even if the mode “fy” is correctly honored, it
might nevertheless be a challenge. Since for
example this here works also, note

the space inside the empty list atom:

/* Ciao Prolog 1.23.0 */
?- op( 100, fy, []).
yes

?- X = [ ] p.
X = []p ?

https://ciao-lang.org/playground/

Took me a while to figure out how to do it.
But its rather straight forward to do. You
find it in the source code of Novacore.


Mild Shock schrieb:
> Another issue is that ISO Prolog doesn’t
> have a reference implementation 100% written
> in Prolog itself. Like for example the term
> reading and writing. Now we have the situation
> 
> that no Prolog system can do these TPTP modal
> logic operators and TPTP first order logic
> quantifers at the same time:
> 
> /* Segerberg Models */
> :- op( 600, fy, !).     % universal quantifier:  ![X]:
> :- op( 600, fy, ?).     % existential quantifier:  ?[X]:
> :- op( 600, fy, []).    % necessity
> :- op( 600, fy, <>).    % possibility
> 
> But the above works in Dogelog Player. It doesn’t
> work in SWI-Prolog, neither in Trealla Prolog,
> neither in Scryer Prolog. Some Prolog systems have
> 
> problems with !, other Prolog systems have problems
> with []. The parsing is admittedly a little tricky but
> after some thinking it turns out relatively straight
> 
> forward doable.
> 
> Mild Shock schrieb:
>>
>> Scryer Prolog is not the only dead Prolog around.
>> Like 12 months ago or so, I mentioned in passing
>> to @joseph-vidal-rosset , because he used Tau Prolog
>>
>> on his web site, that Tau Prolog will be dead as soon
>> as the authors get their academic merits. And I guess
>> this is indeed the case, their GitHub is inactive
>>
>> for at least 12 months now. But then some people still
>> include it in their testing, maybe this is a sign of a little
>> desperation, of finding Prolog system interested
>>
>> in ISO nonsense?
>>
>> Modified: Samstag, 6. Juli 2024, 07:53:05
>> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/phrase
>>
>> The main problem with ISO Prolog is, that it is not
>> enough reduced to the max.

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

#14086 — Is Scryer Prolog the Air Guitar of Prolog? (Was: A harsh wind is blowing into the face of Prolog now…)

Happy Birthday Alan Key, he must be 84 years old now.
I am big fan of his dynabook and this is also gold:

Alan Kay on Computer Science Degree
https://www.youtube.com/watch?v=Lb-cKVxmVGk

Mild Shock schrieb:
> Especially since good old FORTRAN has
> made a new appearance:
> 
> TIOBE Index for May 2024
> I have received a lot of questions why Fortran entered the top 10
> again after more than 20 years. The TIOBE index just publishes
> what has been measured.
> https://www.tiobe.com/tiobe-index/
> 
> Why Fortran is back in TIOBE’s top 10
> First, Fortran is especially good at numerical analysis and
> computational mathematics. Numerical and mathematical
> computing is growing because interest in artificial intelligence
> is growing, Jansen told TechRepublic in an email.
> https://www.techrepublic.com/article/tiobe-index-may-2024/

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

#14088 — Re: Is Scryer Prolog the Air Guitar of Prolog? (Was: A harsh wind is blowing into the face of Prolog now…)

Mostlikely Scryer Prolog was so bold with its
statements about its own future, like here:

Scryer Prolog aims to become to
ISO Prolog what GHC is to Haskell
https://github.com/mthom/scryer-prolog

Because according to Alan Key in this interview
this is the easier thing to do, than to judge
the present or the past.

Joe Armstrong interviews Alan Kay
https://www.youtube.com/watch?v=fhOHn9TClXY

Mild Shock schrieb:
> 
> Happy Birthday Alan Key, he must be 84 years old now.
> I am big fan of his dynabook and this is also gold:
> 
> Alan Kay on Computer Science Degree
> https://www.youtube.com/watch?v=Lb-cKVxmVGk
> 
> Mild Shock schrieb:
>> Especially since good old FORTRAN has
>> made a new appearance:
>>
>> TIOBE Index for May 2024
>> I have received a lot of questions why Fortran entered the top 10
>> again after more than 20 years. The TIOBE index just publishes
>> what has been measured.
>> https://www.tiobe.com/tiobe-index/
>>
>> Why Fortran is back in TIOBE’s top 10
>> First, Fortran is especially good at numerical analysis and
>> computational mathematics. Numerical and mathematical
>> computing is growing because interest in artificial intelligence
>> is growing, Jansen told TechRepublic in an email.
>> https://www.techrepublic.com/article/tiobe-index-may-2024/
> 

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

#14089 — Re: Is Scryer Prolog the Air Guitar of Prolog? (Was: A harsh wind is blowing into the face of Prolog now…)

Scryer Prolog's mentality can be seen here:

?- op(600, fy, []).
    error(permission_error(create,operator,[]),op/3).

What they cannot solve, they simply forbid.

This mentality was already seen when UWN started
fiddling with '|' operator definition, and made
some hilarious changes to ISO core standard,

and some hilarious claims for DCG. In Novacore '|'
is simply nowhere used and undefined, but can be
defined. For DCG the usual (;)/2 is used for disjunction,

no need to use '|' in DCG. Now we have the situation
that Ciao Prolog can easily do this:

/* Segerberg Models */
:- op( 600, fy, !).     % universal quantifier:  ![X]:
:- op( 600, fy, ?).     % existential quantifier:  ?[X]:
:- op( 600, fy, []).    % necessity
:- op( 600, fy, <>).    % possibility

?- X = ! [Y]:p(Y).
X = ![Y]:p(Y) ?

?- X = [] p.
X = []p ?

But Scryer Prolog can do neither of it. Scryer
Prolog stumbles on op( 600, fy, !), it will
suddently not anymore accept clauses such as:

p :- q, !, r.

Which is easy to fix with a small parsing heuristic,
doesn't need non-deterministic parsing or some such.

Mild Shock schrieb:
> Mostlikely Scryer Prolog was so bold with its
> statements about its own future, like here:
> 
> Scryer Prolog aims to become to
> ISO Prolog what GHC is to Haskell
> https://github.com/mthom/scryer-prolog
> 
> Because according to Alan Key in this interview
> this is the easier thing to do, than to judge
> the present or the past.
> 
> Joe Armstrong interviews Alan Kay
> https://www.youtube.com/watch?v=fhOHn9TClXY
> 
> Mild Shock schrieb:
>>
>> Happy Birthday Alan Key, he must be 84 years old now.
>> I am big fan of his dynabook and this is also gold:
>>
>> Alan Kay on Computer Science Degree
>> https://www.youtube.com/watch?v=Lb-cKVxmVGk
>>
>> Mild Shock schrieb:
>>> Especially since good old FORTRAN has
>>> made a new appearance:
>>>
>>> TIOBE Index for May 2024
>>> I have received a lot of questions why Fortran entered the top 10
>>> again after more than 20 years. The TIOBE index just publishes
>>> what has been measured.
>>> https://www.tiobe.com/tiobe-index/
>>>
>>> Why Fortran is back in TIOBE’s top 10
>>> First, Fortran is especially good at numerical analysis and
>>> computational mathematics. Numerical and mathematical
>>> computing is growing because interest in artificial intelligence
>>> is growing, Jansen told TechRepublic in an email.
>>> https://www.techrepublic.com/article/tiobe-index-may-2024/
>>
> 

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

#14092 — Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024])

Hi,

Did Lifeware Kill Scryer Prolog CLP(Z) ?

Sounds interesting:

Pack modeling a SWI-Prolog pack for mathematical
modellng with constraints on subscripted variables,
developed by François Fages. François Fages. A
Constraint-based Mathematical Modeling Library in
Prolog with Answer Constraint Semantics.
https://lifeware.inria.fr/wiki/Main/Software

In 17th International Symposium on Functional and
Logic Programming, FLOPS 2024, volume 14659 of LNCS.
Springer-Verlag, 2024. [ preprint ]
https://arxiv.org/abs/2402.17286

Does it perform?

Bye

Mild Shock schrieb:
> Especially since good old FORTRAN has
> made a new appearance:
> 
> TIOBE Index for May 2024
> I have received a lot of questions why Fortran entered the top 10
> again after more than 20 years. The TIOBE index just publishes
> what has been measured.
> https://www.tiobe.com/tiobe-index/
> 
> Why Fortran is back in TIOBE’s top 10
> First, Fortran is especially good at numerical analysis and
> computational mathematics. Numerical and mathematical
> computing is growing because interest in artificial intelligence
> is growing, Jansen told TechRepublic in an email.
> https://www.techrepublic.com/article/tiobe-index-may-2024/

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

#14093 — Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024])

Hi,

What killed Scryer Prolog exactly? Except
maybe this mess of >270 issues?

https://github.com/mthom/scryer-prolog/issues

There are open issues back to 2019.
Its quite an amazing showcase.

Bye

Mild Shock schrieb:
> Hi,
> 
> Did Lifeware Kill Scryer Prolog CLP(Z) ?
> 
> Sounds interesting:
> 
> Pack modeling a SWI-Prolog pack for mathematical
> modellng with constraints on subscripted variables,
> developed by François Fages. François Fages. A
> Constraint-based Mathematical Modeling Library in
> Prolog with Answer Constraint Semantics.
> https://lifeware.inria.fr/wiki/Main/Software
> 
> In 17th International Symposium on Functional and
> Logic Programming, FLOPS 2024, volume 14659 of LNCS.
> Springer-Verlag, 2024. [ preprint ]
> https://arxiv.org/abs/2402.17286
> 
> Does it perform?
> 
> Bye
> 
> Mild Shock schrieb:
>> Especially since good old FORTRAN has
>> made a new appearance:
>>
>> TIOBE Index for May 2024
>> I have received a lot of questions why Fortran entered the top 10
>> again after more than 20 years. The TIOBE index just publishes
>> what has been measured.
>> https://www.tiobe.com/tiobe-index/
>>
>> Why Fortran is back in TIOBE’s top 10
>> First, Fortran is especially good at numerical analysis and
>> computational mathematics. Numerical and mathematical
>> computing is growing because interest in artificial intelligence
>> is growing, Jansen told TechRepublic in an email.
>> https://www.techrepublic.com/article/tiobe-index-may-2024/
> 

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

#14096 — Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024])

Hi,

Question is what happened to academic artificial
intelligence. The golden years are over where
longer projects over 10 years or so produced

tangible results. Industry with Facebook, OpenAI
has taken over. And there is a residual research
which is basically a camp for geriatric

unemployeds cauched in fancy role names:

Example:

DIVERSITY AND INCLUSION CHAIRS
WORKFLOW MANAGERS
https://www.ecai2024.eu/

Automatizing the watering can, is probably the
next step:

Improving the Buurtbudget:
Can Mathematics and Computer Science?
https://www.youtube.com/watch?v=iSX90xJjSAw

Why not make it a blind lottery. You just get
money, but you don't have to return something
in exchange.

Just like Scryer Prolog, which spent 3 years
of programming, for nothing.

Bye

Mild Shock schrieb:
> Hi,
> 
> What killed Scryer Prolog exactly? Except
> maybe this mess of >270 issues?
> 
> https://github.com/mthom/scryer-prolog/issues
> 
> There are open issues back to 2019.
> Its quite an amazing showcase.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Did Lifeware Kill Scryer Prolog CLP(Z) ?
>>
>> Sounds interesting:
>>
>> Pack modeling a SWI-Prolog pack for mathematical
>> modellng with constraints on subscripted variables,
>> developed by François Fages. François Fages. A
>> Constraint-based Mathematical Modeling Library in
>> Prolog with Answer Constraint Semantics.
>> https://lifeware.inria.fr/wiki/Main/Software
>>
>> In 17th International Symposium on Functional and
>> Logic Programming, FLOPS 2024, volume 14659 of LNCS.
>> Springer-Verlag, 2024. [ preprint ]
>> https://arxiv.org/abs/2402.17286
>>
>> Does it perform?
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Especially since good old FORTRAN has
>>> made a new appearance:
>>>
>>> TIOBE Index for May 2024
>>> I have received a lot of questions why Fortran entered the top 10
>>> again after more than 20 years. The TIOBE index just publishes
>>> what has been measured.
>>> https://www.tiobe.com/tiobe-index/
>>>
>>> Why Fortran is back in TIOBE’s top 10
>>> First, Fortran is especially good at numerical analysis and
>>> computational mathematics. Numerical and mathematical
>>> computing is growing because interest in artificial intelligence
>>> is growing, Jansen told TechRepublic in an email.
>>> https://www.techrepublic.com/article/tiobe-index-may-2024/
>>
> 

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

#14097 — Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024])

Hi,

I do not exclude a turn-around possibility
for Scryer Prolog. But with errors like this,
that are at the core of some ideas behind

Scryer Prolog, like the glorious char based
double quoted lists, which have special data
structure support:

?- [X,Y] = [e,foo], Z is X.
    X = e, Y = foo, Z = 2.718281828459045.

?- [X,Y] = [e,f], Z is X.
    error(type_error(evaluable,e),(is)/2).

But I doubt that any such list/array ideas,
especially when they try to share subarrays
are even a good idea. Trealla Prolog tries

something similar. But initial Java had for
example a sharing substring() method. But they
abandoned that over the time. So their

strings are not sharing anymore, and code that
relied on sharing got broken. You can have
sharing through other interfaces, but Strings

are not anymore sharing. Any idea why?

Bye

Mild Shock schrieb:
> Hi,
> 
> Question is what happened to academic artificial
> intelligence. The golden years are over where
> longer projects over 10 years or so produced
> 
> tangible results. Industry with Facebook, OpenAI
> has taken over. And there is a residual research
> which is basically a camp for geriatric
> 
> unemployeds cauched in fancy role names:
> 
> Example:
> 
> DIVERSITY AND INCLUSION CHAIRS
> WORKFLOW MANAGERS
> https://www.ecai2024.eu/
> 
> Automatizing the watering can, is probably the
> next step:
> 
> Improving the Buurtbudget:
> Can Mathematics and Computer Science?
> https://www.youtube.com/watch?v=iSX90xJjSAw
> 
> Why not make it a blind lottery. You just get
> money, but you don't have to return something
> in exchange.
> 
> Just like Scryer Prolog, which spent 3 years
> of programming, for nothing.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> What killed Scryer Prolog exactly? Except
>> maybe this mess of >270 issues?
>>
>> https://github.com/mthom/scryer-prolog/issues
>>
>> There are open issues back to 2019.
>> Its quite an amazing showcase.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Did Lifeware Kill Scryer Prolog CLP(Z) ?
>>>
>>> Sounds interesting:
>>>
>>> Pack modeling a SWI-Prolog pack for mathematical
>>> modellng with constraints on subscripted variables,
>>> developed by François Fages. François Fages. A
>>> Constraint-based Mathematical Modeling Library in
>>> Prolog with Answer Constraint Semantics.
>>> https://lifeware.inria.fr/wiki/Main/Software
>>>
>>> In 17th International Symposium on Functional and
>>> Logic Programming, FLOPS 2024, volume 14659 of LNCS.
>>> Springer-Verlag, 2024. [ preprint ]
>>> https://arxiv.org/abs/2402.17286
>>>
>>> Does it perform?
>>>
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>> Especially since good old FORTRAN has
>>>> made a new appearance:
>>>>
>>>> TIOBE Index for May 2024
>>>> I have received a lot of questions why Fortran entered the top 10
>>>> again after more than 20 years. The TIOBE index just publishes
>>>> what has been measured.
>>>> https://www.tiobe.com/tiobe-index/
>>>>
>>>> Why Fortran is back in TIOBE’s top 10
>>>> First, Fortran is especially good at numerical analysis and
>>>> computational mathematics. Numerical and mathematical
>>>> computing is growing because interest in artificial intelligence
>>>> is growing, Jansen told TechRepublic in an email.
>>>> https://www.techrepublic.com/article/tiobe-index-may-2024/
>>>
>>
> 

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

#14098 — Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024])

Hi,

Java had a grace period where it still supported
sharing through a command line option, but later
it was ditched completely:

Restriction: This system property is supported only on Java™ 8. String 
sharing cannot be enabled on Java 11 and later.

Start of content that applies only to Java 8 (LTS) Setting this property 
to true avoids sharing a String object when substring() is used to 
subset a String beginning from offset zero. Avoiding sharing is 
compatible with the Oracle HotSpot VM.
https://www.ibm.com/docs/en/sdk-java-technology/8?topic=options-djavalangstringsubstringnocopy

Unfortunately I don't find a document detailing
the decision. Like some JEP or so. Still searching.
With substring sharing it was very easy to provoke

an out of memory error. You could allocate large
strings. Share a UTF-16 character, i.e. substring of
length 1, in the middle of the string, and the string

was not garbage collected anymore. I do not exclude
that under the hood sharing could be used. But it
possibly needs to some compilation technique including

some dedicated analysis that determines that the parent
string stays reachable, so that the child sharing doesn't
make the parent string solely reachable, since

since the parent string is already reachable.

Bye

Mild Shock schrieb:
> Hi,
> 
> I do not exclude a turn-around possibility
> for Scryer Prolog. But with errors like this,
> that are at the core of some ideas behind
> 
> Scryer Prolog, like the glorious char based
> double quoted lists, which have special data
> structure support:
> 
> ?- [X,Y] = [e,foo], Z is X.
>     X = e, Y = foo, Z = 2.718281828459045.
> 
> ?- [X,Y] = [e,f], Z is X.
>     error(type_error(evaluable,e),(is)/2).
> 
> But I doubt that any such list/array ideas,
> especially when they try to share subarrays
> are even a good idea. Trealla Prolog tries
> 
> something similar. But initial Java had for
> example a sharing substring() method. But they
> abandoned that over the time. So their
> 
> strings are not sharing anymore, and code that
> relied on sharing got broken. You can have
> sharing through other interfaces, but Strings
> 
> are not anymore sharing. Any idea why?
> 
> Bye

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

#14099 — Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024])

Hi,

But such a criteria is not satisfied in parsing,
especially if you use the more advanced last call
optimization and not only tail recursion optimization.

As soon as parsing is deterministic, you can
leave behind the string part that you already parsed.
So you would need a special sharing that is kind of

a weak sharing that can free some head part. There is
no such problem of freeing the head part, if you use
proper cons cell based lists for parsing.

But naive substring sharing doesn't work for Prolog.
It will unnecessarely lock the whole string always.
Whereas a cell based parser can drop

already parsed parts.

Bye

Mild Shock schrieb:
> Hi,
> 
> Java had a grace period where it still supported
> sharing through a command line option, but later
> it was ditched completely:
> 
> Restriction: This system property is supported only on Java™ 8. String 
> sharing cannot be enabled on Java 11 and later.
> 
> Start of content that applies only to Java 8 (LTS) Setting this property 
> to true avoids sharing a String object when substring() is used to 
> subset a String beginning from offset zero. Avoiding sharing is 
> compatible with the Oracle HotSpot VM.
> https://www.ibm.com/docs/en/sdk-java-technology/8?topic=options-djavalangstringsubstringnocopy 
> 
> 
> Unfortunately I don't find a document detailing
> the decision. Like some JEP or so. Still searching.
> With substring sharing it was very easy to provoke
> 
> an out of memory error. You could allocate large
> strings. Share a UTF-16 character, i.e. substring of
> length 1, in the middle of the string, and the string
> 
> was not garbage collected anymore. I do not exclude
> that under the hood sharing could be used. But it
> possibly needs to some compilation technique including
> 
> some dedicated analysis that determines that the parent
> string stays reachable, so that the child sharing doesn't
> make the parent string solely reachable, since
> 
> since the parent string is already reachable.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> I do not exclude a turn-around possibility
>> for Scryer Prolog. But with errors like this,
>> that are at the core of some ideas behind
>>
>> Scryer Prolog, like the glorious char based
>> double quoted lists, which have special data
>> structure support:
>>
>> ?- [X,Y] = [e,foo], Z is X.
>>     X = e, Y = foo, Z = 2.718281828459045.
>>
>> ?- [X,Y] = [e,f], Z is X.
>>     error(type_error(evaluable,e),(is)/2).
>>
>> But I doubt that any such list/array ideas,
>> especially when they try to share subarrays
>> are even a good idea. Trealla Prolog tries
>>
>> something similar. But initial Java had for
>> example a sharing substring() method. But they
>> abandoned that over the time. So their
>>
>> strings are not sharing anymore, and code that
>> relied on sharing got broken. You can have
>> sharing through other interfaces, but Strings
>>
>> are not anymore sharing. Any idea why?
>>
>> Bye

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

#14100 — Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024])

Hi,

Whats then more disturbing, if you try picking subparts
of the parsing string, and integrate them in the
parse tree, i.e. your AST.

You then definitively lock the whole parsing source. But
the parsing source might be a couple of predicate
definitions, with constant arguments as found in Datalog:

foo(bar, baz) :- ....
...

The old school non sharing approach would be to have
an atom table and you have then deduplicated foo, bar,
baz, etc... in one place and the source doesn't get

locked. There is a also a new school, which I started
with Jekejeke Prolog and continued with Dogelog Player.
You don't share and you don't atom table.

If you don't use atom table, you might have copies
in your code of foo, bar, baz etc.. But this is only
a small factor, the used memory is still lower than

locking the whole source. And some Java versions have
string deduplication garbage collection under the hood now.
I am not sure what Python and JavaScript do.

But so far I think the small factor of extra memory
usage is not an issue.

Bye

Mild Shock schrieb:
> Hi,
> 
> But such a criteria is not satisfied in parsing,
> especially if you use the more advanced last call
> optimization and not only tail recursion optimization.
> 
> As soon as parsing is deterministic, you can
> leave behind the string part that you already parsed.
> So you would need a special sharing that is kind of
> 
> a weak sharing that can free some head part. There is
> no such problem of freeing the head part, if you use
> proper cons cell based lists for parsing.
> 
> But naive substring sharing doesn't work for Prolog.
> It will unnecessarely lock the whole string always.
> Whereas a cell based parser can drop
> 
> already parsed parts.
> 
> Bye

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

#14101 — Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024])

Hi,

The factor is smaller if the source has anyway a
diversity of strings. If the source has a lot of
redundant strings the factor is higher. You

can explore Prolog compilation techniques that further
deduplicate, but these compilation technqiques are
best appplied by a more broader view, i.e. sharing

numbers and compounds as well. Only looking at strings
is possibly not worth the effort. But if you
cross compile you don't have to do anything anyway.

If I cross compile Dogelog Player to Java, the
Jave byte code class format has a constant pools, so
the Java compiler does the deduplication of strings for you.

A cross compiled Datalog with a lot of foo, bar, baz, ..-

foo(bar, baz) :- ....
...

Will have a compilation output that uses a constant pool,
and the strings in itself foo, bar, baz, etc.. will
be shared. So the factor is again very low for

cross compiled artefacts. Not sure what Python and JavaScript
do, they might do a constant pooling as well. The constant
pooling is very known for Java byte code class format the

output of Java compilers, it was already there in the beginning.

Bye

Mild Shock schrieb:
> Hi,
> 
> Whats then more disturbing, if you try picking subparts
> of the parsing string, and integrate them in the
> parse tree, i.e. your AST.
> 
> You then definitively lock the whole parsing source. But
> the parsing source might be a couple of predicate
> definitions, with constant arguments as found in Datalog:
> 
> foo(bar, baz) :- ....
> ...
> 
> The old school non sharing approach would be to have
> an atom table and you have then deduplicated foo, bar,
> baz, etc... in one place and the source doesn't get
> 
> locked. There is a also a new school, which I started
> with Jekejeke Prolog and continued with Dogelog Player.
> You don't share and you don't atom table.
> 
> If you don't use atom table, you might have copies
> in your code of foo, bar, baz etc.. But this is only
> a small factor, the used memory is still lower than
> 
> locking the whole source. And some Java versions have
> string deduplication garbage collection under the hood now.
> I am not sure what Python and JavaScript do.
> 
> But so far I think the small factor of extra memory
> usage is not an issue.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> But such a criteria is not satisfied in parsing,
>> especially if you use the more advanced last call
>> optimization and not only tail recursion optimization.
>>
>> As soon as parsing is deterministic, you can
>> leave behind the string part that you already parsed.
>> So you would need a special sharing that is kind of
>>
>> a weak sharing that can free some head part. There is
>> no such problem of freeing the head part, if you use
>> proper cons cell based lists for parsing.
>>
>> But naive substring sharing doesn't work for Prolog.
>> It will unnecessarely lock the whole string always.
>> Whereas a cell based parser can drop
>>
>> already parsed parts.
>>
>> Bye

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

#14102 — Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024])

Hi,

Or to put it differently:

substring sharing could turn a
library(pio) into a memory nightmare.

Bye

Mild Shock schrieb:
> Hi,
> 
> The factor is smaller if the source has anyway a
> diversity of strings. If the source has a lot of
> redundant strings the factor is higher. You
> 
> can explore Prolog compilation techniques that further
> deduplicate, but these compilation technqiques are
> best appplied by a more broader view, i.e. sharing
> 
> numbers and compounds as well. Only looking at strings
> is possibly not worth the effort. But if you
> cross compile you don't have to do anything anyway.
> 
> If I cross compile Dogelog Player to Java, the
> Jave byte code class format has a constant pools, so
> the Java compiler does the deduplication of strings for you.
> 
> A cross compiled Datalog with a lot of foo, bar, baz, ..-
> 
> foo(bar, baz) :- ....
> ...
> 
> Will have a compilation output that uses a constant pool,
> and the strings in itself foo, bar, baz, etc.. will
> be shared. So the factor is again very low for
> 
> cross compiled artefacts. Not sure what Python and JavaScript
> do, they might do a constant pooling as well. The constant
> pooling is very known for Java byte code class format the
> 
> output of Java compilers, it was already there in the beginning.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Whats then more disturbing, if you try picking subparts
>> of the parsing string, and integrate them in the
>> parse tree, i.e. your AST.
>>
>> You then definitively lock the whole parsing source. But
>> the parsing source might be a couple of predicate
>> definitions, with constant arguments as found in Datalog:
>>
>> foo(bar, baz) :- ....
>> ...
>>
>> The old school non sharing approach would be to have
>> an atom table and you have then deduplicated foo, bar,
>> baz, etc... in one place and the source doesn't get
>>
>> locked. There is a also a new school, which I started
>> with Jekejeke Prolog and continued with Dogelog Player.
>> You don't share and you don't atom table.
>>
>> If you don't use atom table, you might have copies
>> in your code of foo, bar, baz etc.. But this is only
>> a small factor, the used memory is still lower than
>>
>> locking the whole source. And some Java versions have
>> string deduplication garbage collection under the hood now.
>> I am not sure what Python and JavaScript do.
>>
>> But so far I think the small factor of extra memory
>> usage is not an issue.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> But such a criteria is not satisfied in parsing,
>>> especially if you use the more advanced last call
>>> optimization and not only tail recursion optimization.
>>>
>>> As soon as parsing is deterministic, you can
>>> leave behind the string part that you already parsed.
>>> So you would need a special sharing that is kind of
>>>
>>> a weak sharing that can free some head part. There is
>>> no such problem of freeing the head part, if you use
>>> proper cons cell based lists for parsing.
>>>
>>> But naive substring sharing doesn't work for Prolog.
>>> It will unnecessarely lock the whole string always.
>>> Whereas a cell based parser can drop
>>>
>>> already parsed parts.
>>>
>>> Bye
> 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web