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

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

Noacore is a Prolog profile that explores various relaxations

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

Contents

  Noacore is a Prolog profile that explores various relaxations Mild Shock <janburse@fastmail.fm> - 2025-03-21 19:16 +0100
    What about allowing numbers 1e19, etc.. (Re: Novacore is a Prolog profile that explores various relaxations) Mild Shock <janburse@fastmail.fm> - 2025-03-21 19:21 +0100
      Re: What about allowing numbers 1e19, etc.. (Re: Novacore is a Prolog profile that explores various relaxations) Mild Shock <janburse@fastmail.fm> - 2025-03-21 19:29 +0100
      prolog_file_name/2 was a big mistake [Novacore] Mild Shock <janburse@fastmail.fm> - 2025-05-25 09:22 +0200
        The recent extension/1 addition in Dogelog Player (Was: prolog_file_name/2 was a big mistake [Novacore]) Mild Shock <janburse@fastmail.fm> - 2025-05-25 09:33 +0200
          Corr.: Typo (Was: The recent extension/1 addition in Dogelog Player) Mild Shock <janburse@fastmail.fm> - 2025-05-25 09:39 +0200
    How difficult is a Knowledbase notion? (Was: Novacore is a Prolog profile that explores various relaxations) Mild Shock <janburse@fastmail.fm> - 2025-07-02 09:33 +0200
      C++ programming or a PhD in Macro defs (Was: How difficult is a Knowledbase notion?) Mild Shock <janburse@fastmail.fm> - 2025-07-02 09:35 +0200
        Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0] (Was: C++ programming or a PhD in Macro defs) Mild Shock <janburse@fastmail.fm> - 2025-07-02 09:49 +0200
          General Magic didn't predict the Future (Was: Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0]) Mild Shock <janburse@fastmail.fm> - 2025-07-02 10:07 +0200
            Antique Programming Style versus Modern Programming Style [SWI-Prolog] (Was: Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0]) Mild Shock <janburse@fastmail.fm> - 2025-07-02 15:54 +0200
              Grand mothers kitchen is nevertheless the best, who knows? (Was: Antique Programming Style versus Modern Programming Style [SWI-Prolog]) Mild Shock <janburse@fastmail.fm> - 2025-07-02 16:06 +0200

#14482 — Noacore is a Prolog profile that explores various relaxations

Interestingly a flag strict_iso could solve a few
vexing problems. For example the ISO core standard
did only mention floor/1 with signature F → I.

So in GNU Prolog I can do:

/* GNU Prolog 1.5.0 */

?- current_prolog_flag(strict_iso, X).
X = on
yes

?- X is floor(1).
uncaught exception: error(type_error(float,1),(is)/2)

?- set_prolog_flag(strict_iso, off).
yes

?- X is floor(1).
X = 1
yes

A few Prolog systems don’t share the above behavior,
like SWI-Prolog for example doesn’t throw the type error.
Also SWI-Prolog has nowhere a flag strict_iso.

Currently I have changed my Prolog system to tell me:

/* Dogelog Player 1.3.1 */

?- current_prolog_flag(strict_iso, X).
X = off.

[toc] | [next] | [standalone]

#14483 — What about allowing numbers 1e19, etc.. (Re: Novacore is a Prolog profile that explores various relaxations)

Hi,

Somehow I have the feeling it doesn't make
sense to only recognize floating point numbers
as number literals that have a period in it.

Most programming languages I have encountered
also recognize floating point numbers when
they have an exponent e or E in it:

- Python:
 >>> 1e19
1e+19

- JavaScript:
 > 1e19
10000000000000000000

JavaScript is a little special. Since it has a
integer subset inside there floating point numbers.
Now I find that SWI-Prolog also allows 1e19:

/* SWI-Prolog 9.3.20 */
?- X = 1e19.
X = 1.0e+19.

I think this is a good idea. Since there is no
confusion. Most Prolog systems I checked never
alias an operator e with a number:

/* SWI-Prolog 9.3.20 */
?- op(500,yfx,e).
true.

?- X = 1 e 2.
X = 1 e 2.

Bye

Mild Shock schrieb:
> Interestingly a flag strict_iso could solve a few
> vexing problems. For example the ISO core standard
> did only mention floor/1 with signature F → I.
> 
> So in GNU Prolog I can do:
> 
> /* GNU Prolog 1.5.0 */
> 
> ?- current_prolog_flag(strict_iso, X).
> X = on
> yes
> 
> ?- X is floor(1).
> uncaught exception: error(type_error(float,1),(is)/2)
> 
> ?- set_prolog_flag(strict_iso, off).
> yes
> 
> ?- X is floor(1).
> X = 1
> yes
> 
> A few Prolog systems don’t share the above behavior,
> like SWI-Prolog for example doesn’t throw the type error.
> Also SWI-Prolog has nowhere a flag strict_iso.
> 
> Currently I have changed my Prolog system to tell me:
> 
> /* Dogelog Player 1.3.1 */
> 
> ?- current_prolog_flag(strict_iso, X).
> X = off.

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

#14484 — Re: What about allowing numbers 1e19, etc.. (Re: Novacore is a Prolog profile that explores various relaxations)

Hi,

Interestingly unknowningly, to facilitate JSON
parsing, I had already partially introduced such
numbers. Namely I have already:

/* Dogelog Player 1.3.0 */
?- number_codes(X, "1e19").
X = 1.0e19.

SWI-Prolog consequently does the same:

/* SWI-Prolog 9.3.20 */
?- number_codes(X, "1e19").
X = 1.0e+19.

So all that remains is change the tokenizer a little
bit to allow 1e19. And then we can be lazy and
write 1e19, which is the winner in length, i.e. the

shortes variant among these variants:

- 10.0^19
- 10**19  /* except for SWI-Prolog 9.3.20 */
- 1.0e19
- 1e19

Bye

Mild Shock schrieb:
> Hi,
> 
> Somehow I have the feeling it doesn't make
> sense to only recognize floating point numbers
> as number literals that have a period in it.
> 
> Most programming languages I have encountered
> also recognize floating point numbers when
> they have an exponent e or E in it:
> 
> - Python:
>  >>> 1e19
> 1e+19
> 
> - JavaScript:
>  > 1e19
> 10000000000000000000
> 
> JavaScript is a little special. Since it has a
> integer subset inside there floating point numbers.
> Now I find that SWI-Prolog also allows 1e19:
> 
> /* SWI-Prolog 9.3.20 */
> ?- X = 1e19.
> X = 1.0e+19.
> 
> I think this is a good idea. Since there is no
> confusion. Most Prolog systems I checked never
> alias an operator e with a number:
> 
> /* SWI-Prolog 9.3.20 */
> ?- op(500,yfx,e).
> true.
> 
> ?- X = 1 e 2.
> X = 1 e 2.
> 
> Bye
> 
> Mild Shock schrieb:
>> Interestingly a flag strict_iso could solve a few
>> vexing problems. For example the ISO core standard
>> did only mention floor/1 with signature F → I.
>>
>> So in GNU Prolog I can do:
>>
>> /* GNU Prolog 1.5.0 */
>>
>> ?- current_prolog_flag(strict_iso, X).
>> X = on
>> yes
>>
>> ?- X is floor(1).
>> uncaught exception: error(type_error(float,1),(is)/2)
>>
>> ?- set_prolog_flag(strict_iso, off).
>> yes
>>
>> ?- X is floor(1).
>> X = 1
>> yes
>>
>> A few Prolog systems don’t share the above behavior,
>> like SWI-Prolog for example doesn’t throw the type error.
>> Also SWI-Prolog has nowhere a flag strict_iso.
>>
>> Currently I have changed my Prolog system to tell me:
>>
>> /* Dogelog Player 1.3.1 */
>>
>> ?- current_prolog_flag(strict_iso, X).
>> X = off.
> 

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

#14515 — prolog_file_name/2 was a big mistake [Novacore]

Hi,

The GNU Prolog specification of prolog_file_name/2
was a big mistake. It reads as follows:

prolog_file_name(File1, File2) unifies File2 with the
Prolog file name associated with File1. More precisely
File2 is computed as follows:

- if File1 has a suffix or if it is user then File2
   is unified with File1.
- else if the file whose name is File1 + ’.pl’ exists
   then File2 is    unified with this name.
- else if the file whose name is File1 + ’.pro’ exists
   then File2 is unified with this name.
- else if the file whose name is File1 + ’.prolog’ exists
   then File2 is unified with this name.
- else File2 is unified with the name File1 + ’.pl’.

This predicate uses absolute_file_name/2 to check the existence of a 
file (section 8.26.1).

http://www.gprolog.org/manual/html_node/gprolog050.html#hevea_default836

It was adopted by SWI-Prolog and made parameterizable through
absolute_file_name/3:

https://www.swi-prolog.org/pldoc/doc_for?object=absolute_file_name/3

The big mistake is the existence check. In a web context
it requires a server rountrip or something. And since there are
3 existence checks, its 3 server rountrips possibly HEAD requests.

Formerly Jekejeke Prolog suffered from this problem. Now
with Dogelog Player and as part of Novacore we wanted to
do something else. What is the solution?

Bye

Mild Shock schrieb:
> Hi,
> 
> Somehow I have the feeling it doesn't make
> sense to only recognize floating point numbers
> as number literals that have a period in it.
> 
> Most programming languages I have encountered
> also recognize floating point numbers when
> they have an exponent e or E in it:
> 
> - Python:
>  >>> 1e19
> 1e+19
> 
> - JavaScript:
>  > 1e19
> 10000000000000000000
> 
> JavaScript is a little special. Since it has a
> integer subset inside there floating point numbers.
> Now I find that SWI-Prolog also allows 1e19:
> 
> /* SWI-Prolog 9.3.20 */
> ?- X = 1e19.
> X = 1.0e+19.
> 
> I think this is a good idea. Since there is no
> confusion. Most Prolog systems I checked never
> alias an operator e with a number:
> 
> /* SWI-Prolog 9.3.20 */
> ?- op(500,yfx,e).
> true.
> 
> ?- X = 1 e 2.
> X = 1 e 2.
> 
> Bye
> 
> Mild Shock schrieb:
>> Interestingly a flag strict_iso could solve a few
>> vexing problems. For example the ISO core standard
>> did only mention floor/1 with signature F → I.
>>
>> So in GNU Prolog I can do:
>>
>> /* GNU Prolog 1.5.0 */
>>
>> ?- current_prolog_flag(strict_iso, X).
>> X = on
>> yes
>>
>> ?- X is floor(1).
>> uncaught exception: error(type_error(float,1),(is)/2)
>>
>> ?- set_prolog_flag(strict_iso, off).
>> yes
>>
>> ?- X is floor(1).
>> X = 1
>> yes
>>
>> A few Prolog systems don’t share the above behavior,
>> like SWI-Prolog for example doesn’t throw the type error.
>> Also SWI-Prolog has nowhere a flag strict_iso.
>>
>> Currently I have changed my Prolog system to tell me:
>>
>> /* Dogelog Player 1.3.1 */
>>
>> ?- current_prolog_flag(strict_iso, X).
>> X = off.
> 

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

#14516 — The recent extension/1 addition in Dogelog Player (Was: prolog_file_name/2 was a big mistake [Novacore])

Hi,

The solution for Novacore is as follows:

- absolute_file_name/[2,3] does NOT check existence,
   neither through failure nor through an error

- ONLY file_property/2 does check for existence,
   also available in GNU Prolog:
http://www.gprolog.org/manual/gprolog.html#file-property%2F2

- There is a tamer extension/1 option in absolute_file_name/3,
   which checks the file base name, and does add the given
   extension, if it does not yet have an extension.

   Here is a test case, since existence is tested, it also
   works with a server www.foo.com, which might not be reachable,
   and because it looks for the file base name, the server name

   which has a dot, doesn't confuse absolute_file_name/3 to assume
   that there is already an extension, and bar is correctly
   extended to bar.p:

    absolute_file_name('http://www.foo.com/bar', X, [extension('.p')]),
    X == 'http://www.foo.com/bar.p'.

- In Dogelog Player include/1, ensure_loaded/1, etc.. use
   extension('.p'), other Prolog systems might use extension('.pro')
   or extension('.pl'), this is just a top-level convenience,
   and allows more convention:

?- [bar]

- For portable code, the recommendation is to include the extension.
   This was enforced in Dogelog Player up to release 1.3.2, since
   it didn't have the extension/1 option. From release 1.3.3 this
   remains a best practice, but is not anymore enforced.

:- ensure_loaded('bar.p').

Bye

Mild Shock schrieb:
> Hi,
> 
> The GNU Prolog specification of prolog_file_name/2
> was a big mistake. It reads as follows:
> 
> prolog_file_name(File1, File2) unifies File2 with the
> Prolog file name associated with File1. More precisely
> File2 is computed as follows:
> 
> - if File1 has a suffix or if it is user then File2
>    is unified with File1.
> - else if the file whose name is File1 + ’.pl’ exists
>    then File2 is    unified with this name.
> - else if the file whose name is File1 + ’.pro’ exists
>    then File2 is unified with this name.
> - else if the file whose name is File1 + ’.prolog’ exists
>    then File2 is unified with this name.
> - else File2 is unified with the name File1 + ’.pl’.
> 
> This predicate uses absolute_file_name/2 to check the existence of a 
> file (section 8.26.1).
> 
> http://www.gprolog.org/manual/html_node/gprolog050.html#hevea_default836
> 
> It was adopted by SWI-Prolog and made parameterizable through
> absolute_file_name/3:
> 
> https://www.swi-prolog.org/pldoc/doc_for?object=absolute_file_name/3
> 
> The big mistake is the existence check. In a web context
> it requires a server rountrip or something. And since there are
> 3 existence checks, its 3 server rountrips possibly HEAD requests.
> 
> Formerly Jekejeke Prolog suffered from this problem. Now
> with Dogelog Player and as part of Novacore we wanted to
> do something else. What is the solution?
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Somehow I have the feeling it doesn't make
>> sense to only recognize floating point numbers
>> as number literals that have a period in it.
>>
>> Most programming languages I have encountered
>> also recognize floating point numbers when
>> they have an exponent e or E in it:
>>
>> - Python:
>>  >>> 1e19
>> 1e+19
>>
>> - JavaScript:
>>  > 1e19
>> 10000000000000000000
>>
>> JavaScript is a little special. Since it has a
>> integer subset inside there floating point numbers.
>> Now I find that SWI-Prolog also allows 1e19:
>>
>> /* SWI-Prolog 9.3.20 */
>> ?- X = 1e19.
>> X = 1.0e+19.
>>
>> I think this is a good idea. Since there is no
>> confusion. Most Prolog systems I checked never
>> alias an operator e with a number:
>>
>> /* SWI-Prolog 9.3.20 */
>> ?- op(500,yfx,e).
>> true.
>>
>> ?- X = 1 e 2.
>> X = 1 e 2.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Interestingly a flag strict_iso could solve a few
>>> vexing problems. For example the ISO core standard
>>> did only mention floor/1 with signature F → I.
>>>
>>> So in GNU Prolog I can do:
>>>
>>> /* GNU Prolog 1.5.0 */
>>>
>>> ?- current_prolog_flag(strict_iso, X).
>>> X = on
>>> yes
>>>
>>> ?- X is floor(1).
>>> uncaught exception: error(type_error(float,1),(is)/2)
>>>
>>> ?- set_prolog_flag(strict_iso, off).
>>> yes
>>>
>>> ?- X is floor(1).
>>> X = 1
>>> yes
>>>
>>> A few Prolog systems don’t share the above behavior,
>>> like SWI-Prolog for example doesn’t throw the type error.
>>> Also SWI-Prolog has nowhere a flag strict_iso.
>>>
>>> Currently I have changed my Prolog system to tell me:
>>>
>>> /* Dogelog Player 1.3.1 */
>>>
>>> ?- current_prolog_flag(strict_iso, X).
>>> X = off.
>>
> 

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

#14517 — Corr.: Typo (Was: The recent extension/1 addition in Dogelog Player)

Corr.: Typo

This here:

Here is a test case, since existence is tested, it also

Should read:

Here is a test case, since existence is NOT tested, it also

Mild Shock schrieb:
> Hi,
> 
> The solution for Novacore is as follows:
> 
> - absolute_file_name/[2,3] does NOT check existence,
>    neither through failure nor through an error
> 
> - ONLY file_property/2 does check for existence,
>    also available in GNU Prolog:
> http://www.gprolog.org/manual/gprolog.html#file-property%2F2
> 
> - There is a tamer extension/1 option in absolute_file_name/3,
>    which checks the file base name, and does add the given
>    extension, if it does not yet have an extension.
> 
>    Here is a test case, since existence is tested, it also
>    works with a server www.foo.com, which might not be reachable,
>    and because it looks for the file base name, the server name
> 
>    which has a dot, doesn't confuse absolute_file_name/3 to assume
>    that there is already an extension, and bar is correctly
>    extended to bar.p:
> 
>     absolute_file_name('http://www.foo.com/bar', X, [extension('.p')]),
>     X == 'http://www.foo.com/bar.p'.
> 
> - In Dogelog Player include/1, ensure_loaded/1, etc.. use
>    extension('.p'), other Prolog systems might use extension('.pro')
>    or extension('.pl'), this is just a top-level convenience,
>    and allows more convention:
> 
> ?- [bar]
> 
> - For portable code, the recommendation is to include the extension.
>    This was enforced in Dogelog Player up to release 1.3.2, since
>    it didn't have the extension/1 option. From release 1.3.3 this
>    remains a best practice, but is not anymore enforced.
> 
> :- ensure_loaded('bar.p').
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> The GNU Prolog specification of prolog_file_name/2
>> was a big mistake. It reads as follows:
>>
>> prolog_file_name(File1, File2) unifies File2 with the
>> Prolog file name associated with File1. More precisely
>> File2 is computed as follows:
>>
>> - if File1 has a suffix or if it is user then File2
>>    is unified with File1.
>> - else if the file whose name is File1 + ’.pl’ exists
>>    then File2 is    unified with this name.
>> - else if the file whose name is File1 + ’.pro’ exists
>>    then File2 is unified with this name.
>> - else if the file whose name is File1 + ’.prolog’ exists
>>    then File2 is unified with this name.
>> - else File2 is unified with the name File1 + ’.pl’.
>>
>> This predicate uses absolute_file_name/2 to check the existence of a 
>> file (section 8.26.1).
>>
>> http://www.gprolog.org/manual/html_node/gprolog050.html#hevea_default836
>>
>> It was adopted by SWI-Prolog and made parameterizable through
>> absolute_file_name/3:
>>
>> https://www.swi-prolog.org/pldoc/doc_for?object=absolute_file_name/3
>>
>> The big mistake is the existence check. In a web context
>> it requires a server rountrip or something. And since there are
>> 3 existence checks, its 3 server rountrips possibly HEAD requests.
>>
>> Formerly Jekejeke Prolog suffered from this problem. Now
>> with Dogelog Player and as part of Novacore we wanted to
>> do something else. What is the solution?
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Somehow I have the feeling it doesn't make
>>> sense to only recognize floating point numbers
>>> as number literals that have a period in it.
>>>
>>> Most programming languages I have encountered
>>> also recognize floating point numbers when
>>> they have an exponent e or E in it:
>>>
>>> - Python:
>>>  >>> 1e19
>>> 1e+19
>>>
>>> - JavaScript:
>>>  > 1e19
>>> 10000000000000000000
>>>
>>> JavaScript is a little special. Since it has a
>>> integer subset inside there floating point numbers.
>>> Now I find that SWI-Prolog also allows 1e19:
>>>
>>> /* SWI-Prolog 9.3.20 */
>>> ?- X = 1e19.
>>> X = 1.0e+19.
>>>
>>> I think this is a good idea. Since there is no
>>> confusion. Most Prolog systems I checked never
>>> alias an operator e with a number:
>>>
>>> /* SWI-Prolog 9.3.20 */
>>> ?- op(500,yfx,e).
>>> true.
>>>
>>> ?- X = 1 e 2.
>>> X = 1 e 2.
>>>
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>> Interestingly a flag strict_iso could solve a few
>>>> vexing problems. For example the ISO core standard
>>>> did only mention floor/1 with signature F → I.
>>>>
>>>> So in GNU Prolog I can do:
>>>>
>>>> /* GNU Prolog 1.5.0 */
>>>>
>>>> ?- current_prolog_flag(strict_iso, X).
>>>> X = on
>>>> yes
>>>>
>>>> ?- X is floor(1).
>>>> uncaught exception: error(type_error(float,1),(is)/2)
>>>>
>>>> ?- set_prolog_flag(strict_iso, off).
>>>> yes
>>>>
>>>> ?- X is floor(1).
>>>> X = 1
>>>> yes
>>>>
>>>> A few Prolog systems don’t share the above behavior,
>>>> like SWI-Prolog for example doesn’t throw the type error.
>>>> Also SWI-Prolog has nowhere a flag strict_iso.
>>>>
>>>> Currently I have changed my Prolog system to tell me:
>>>>
>>>> /* Dogelog Player 1.3.1 */
>>>>
>>>> ?- current_prolog_flag(strict_iso, X).
>>>> X = off.
>>>
>>
> 

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

#14612 — How difficult is a Knowledbase notion? (Was: Novacore is a Prolog profile that explores various relaxations)

 > The required changes could be fairly limited.

I don’t know. You never know before you did it.
With the current design you might end up in a
Münchhausen scenario, trying to defy gravity by
pulling your own hair. It seems there is a global switch

which engine is active? I don’t understand, isn’t
SWI-Prolog able to run truely concurrently on a
multi-core machine. Because such things, wouldn’t
work for threads that distribute themselves over cores.

I saw an L_THREAD lock somewhere?

#define GET_LD	  PL_local_data_t *__PL_ld = GLOBAL_LD;

In the “worker” scenario, a “worker” can typically grab
a CPU core all for himself, and for its knowledge and
for all the engines that work over this knowlegde base.
Thats the beauty of JavaScript

isolation through “workers”, and it is also used in
the Ciao Playground. Its very multi core friendly, a
“worker” can also have its own garbage collection etc…

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

#14613 — C++ programming or a PhD in Macro defs (Was: How difficult is a Knowledbase notion?)

If SWI-Prolog would be rewritten in C++ maybe a GLOBAL_LD
wouldn’t be needed at all. You could make Knowledgebase
and Engine classes, the C++ compiler would optimize for

you passing around GD or LD in the form of a “this”, and
a method inside an Engine, could access a Knowledge base,
by “this->KB” or simply “KB”. C++ would be even less
annoying than Java, since you can do deferred mixin:

class Person {
    [...]
}

And later:

void Person::Print() {
    [...]
}

Because I don’t have deferred mixin in Java, my own
modularization looks extremly messy, passing around a
parameter explicitly, hoping that the usual register
file optimization of a Java compiler eliminates

most parameter passing. But my C++ knowledge is very
limited, so I don’t know whether a PhD in Macro defs
was the better solution. Was there never a C++

implemenation of SWI-Prolog ?

Mild Shock schrieb:
> 
>  > The required changes could be fairly limited.
> 
> I don’t know. You never know before you did it.
> With the current design you might end up in a
> Münchhausen scenario, trying to defy gravity by
> pulling your own hair. It seems there is a global switch
> 
> which engine is active? I don’t understand, isn’t
> SWI-Prolog able to run truely concurrently on a
> multi-core machine. Because such things, wouldn’t
> work for threads that distribute themselves over cores.
> 
> I saw an L_THREAD lock somewhere?
> 
> #define GET_LD      PL_local_data_t *__PL_ld = GLOBAL_LD;
> 
> In the “worker” scenario, a “worker” can typically grab
> a CPU core all for himself, and for its knowledge and
> for all the engines that work over this knowlegde base.
> Thats the beauty of JavaScript
> 
> isolation through “workers”, and it is also used in
> the Ciao Playground. Its very multi core friendly, a
> “worker” can also have its own garbage collection etc…
> 
> 
> 
> 

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

#14614 — Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0] (Was: C++ programming or a PhD in Macro defs)

Another solution would be to dismiss the whole Java
ClassLoader thing as humbug, and not strive for a
Knowlegebase abstraction, and create workers via some
operating system fork().

This might perfectly well work as well. It only
breaks down if you want to embed and integrate
your “workers”, into systems that have something like
this Java ClassLoader notion.

Either way, “workers” provide a nice new notion
besides engines, which was never covered by Papers
of Paul Tarau and the like, and might not have
existed in older Prolog systems. Because

old papers had a different ontology: Places,
Sandbox, etc.. workers were simply not on the radar.
The data isolation allows for non-cooperative
parallelism among workers, despite the notion of an

engine is rather cooperative. Workers got momentum
with Web 2.0 and early process isolation of browser
tabs in 2008 when Chrome debuted. Just after that
in 2010 they were introduced as part of HTML5 for

thread isolation inside a browser tab.

See for yourself:

Jinni: Intelligent Mobile Agent Programming
at the Intersection of Java and Prolog
https://www.researchgate.net/profile/Paul-Tarau/publication/2762429

Mild Shock schrieb:
> If SWI-Prolog would be rewritten in C++ maybe a GLOBAL_LD
> wouldn’t be needed at all. You could make Knowledgebase
> and Engine classes, the C++ compiler would optimize for
> 
> you passing around GD or LD in the form of a “this”, and
> a method inside an Engine, could access a Knowledge base,
> by “this->KB” or simply “KB”. C++ would be even less
> annoying than Java, since you can do deferred mixin:
> 
> class Person {
>     [...]
> }
> 
> And later:
> 
> void Person::Print() {
>     [...]
> }
> 
> Because I don’t have deferred mixin in Java, my own
> modularization looks extremly messy, passing around a
> parameter explicitly, hoping that the usual register
> file optimization of a Java compiler eliminates
> 
> most parameter passing. But my C++ knowledge is very
> limited, so I don’t know whether a PhD in Macro defs
> was the better solution. Was there never a C++
> 
> implemenation of SWI-Prolog ?
> 
> Mild Shock schrieb:
>>
>>  > The required changes could be fairly limited.
>>
>> I don’t know. You never know before you did it.
>> With the current design you might end up in a
>> Münchhausen scenario, trying to defy gravity by
>> pulling your own hair. It seems there is a global switch
>>
>> which engine is active? I don’t understand, isn’t
>> SWI-Prolog able to run truely concurrently on a
>> multi-core machine. Because such things, wouldn’t
>> work for threads that distribute themselves over cores.
>>
>> I saw an L_THREAD lock somewhere?
>>
>> #define GET_LD      PL_local_data_t *__PL_ld = GLOBAL_LD;
>>
>> In the “worker” scenario, a “worker” can typically grab
>> a CPU core all for himself, and for its knowledge and
>> for all the engines that work over this knowlegde base.
>> Thats the beauty of JavaScript
>>
>> isolation through “workers”, and it is also used in
>> the Ciao Playground. Its very multi core friendly, a
>> “worker” can also have its own garbage collection etc…
>>
>>
>>
>>
> 

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

#14615 — General Magic didn't predict the Future (Was: Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0])

Hi,

They had a bunny-shaped topiary in front
of their offices, must have been swimming
in money, General Magic didn't predict the Future:

https://www.youtube.com/watch?v=N4lqz2OofL0

Now, things don't look exactly how they evisioned.

Bye

Mild Shock schrieb:
> 
> Another solution would be to dismiss the whole Java
> ClassLoader thing as humbug, and not strive for a
> Knowlegebase abstraction, and create workers via some
> operating system fork().
> 
> This might perfectly well work as well. It only
> breaks down if you want to embed and integrate
> your “workers”, into systems that have something like
> this Java ClassLoader notion.
> 
> Either way, “workers” provide a nice new notion
> besides engines, which was never covered by Papers
> of Paul Tarau and the like, and might not have
> existed in older Prolog systems. Because
> 
> old papers had a different ontology: Places,
> Sandbox, etc.. workers were simply not on the radar.
> The data isolation allows for non-cooperative
> parallelism among workers, despite the notion of an
> 
> engine is rather cooperative. Workers got momentum
> with Web 2.0 and early process isolation of browser
> tabs in 2008 when Chrome debuted. Just after that
> in 2010 they were introduced as part of HTML5 for
> 
> thread isolation inside a browser tab.
> 
> See for yourself:
> 
> Jinni: Intelligent Mobile Agent Programming
> at the Intersection of Java and Prolog
> https://www.researchgate.net/profile/Paul-Tarau/publication/2762429
> 
> Mild Shock schrieb:
>> If SWI-Prolog would be rewritten in C++ maybe a GLOBAL_LD
>> wouldn’t be needed at all. You could make Knowledgebase
>> and Engine classes, the C++ compiler would optimize for
>>
>> you passing around GD or LD in the form of a “this”, and
>> a method inside an Engine, could access a Knowledge base,
>> by “this->KB” or simply “KB”. C++ would be even less
>> annoying than Java, since you can do deferred mixin:
>>
>> class Person {
>>     [...]
>> }
>>
>> And later:
>>
>> void Person::Print() {
>>     [...]
>> }
>>
>> Because I don’t have deferred mixin in Java, my own
>> modularization looks extremly messy, passing around a
>> parameter explicitly, hoping that the usual register
>> file optimization of a Java compiler eliminates
>>
>> most parameter passing. But my C++ knowledge is very
>> limited, so I don’t know whether a PhD in Macro defs
>> was the better solution. Was there never a C++
>>
>> implemenation of SWI-Prolog ?
>>
>> Mild Shock schrieb:
>>>
>>>  > The required changes could be fairly limited.
>>>
>>> I don’t know. You never know before you did it.
>>> With the current design you might end up in a
>>> Münchhausen scenario, trying to defy gravity by
>>> pulling your own hair. It seems there is a global switch
>>>
>>> which engine is active? I don’t understand, isn’t
>>> SWI-Prolog able to run truely concurrently on a
>>> multi-core machine. Because such things, wouldn’t
>>> work for threads that distribute themselves over cores.
>>>
>>> I saw an L_THREAD lock somewhere?
>>>
>>> #define GET_LD      PL_local_data_t *__PL_ld = GLOBAL_LD;
>>>
>>> In the “worker” scenario, a “worker” can typically grab
>>> a CPU core all for himself, and for its knowledge and
>>> for all the engines that work over this knowlegde base.
>>> Thats the beauty of JavaScript
>>>
>>> isolation through “workers”, and it is also used in
>>> the Ciao Playground. Its very multi core friendly, a
>>> “worker” can also have its own garbage collection etc…
>>>
>>>
>>>
>>>
>>
> 

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

#14616 — Antique Programming Style versus Modern Programming Style [SWI-Prolog] (Was: Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0])

Hi,

I just double checked OpenJDK, it has a few macros
for ptrace meta data, but otherwise I don’t find so
many macros. The problem is SWI-Prolog has a very
antique programming style. It has an over use of macros.

Macros have a lot of drawbacks. Although you can do:

#define SQUARE(x) ((x) * (x))

/* makes this not behave as expected */
int z = SQUARE(x++); // expands to (x++ * x++) —
                      // side effects happen twice! ❌

In most modern C and C++ compilers you can do,
i.e. use the “inline” keyword:

inline int square(int x) {
   return x * x;
}

/* lets this behave as expected */
int z = square(x++); // x++ evaluated once ✔

This avoids all the classic macro pitfalls. So I wouldn’t
touch Knowledge bases, as long as there is a macro hell.
After getting rid of macros, yes, things are fairly

straight forward.

Bye

Mild Shock schrieb:
> Hi,
> 
> They had a bunny-shaped topiary in front
> of their offices, must have been swimming
> in money, General Magic didn't predict the Future:
> 
> https://www.youtube.com/watch?v=N4lqz2OofL0
> 
> Now, things don't look exactly how they evisioned.
> 
> Bye
> 
> Mild Shock schrieb:
>>
>> Another solution would be to dismiss the whole Java
>> ClassLoader thing as humbug, and not strive for a
>> Knowlegebase abstraction, and create workers via some
>> operating system fork().
>>
>> This might perfectly well work as well. It only
>> breaks down if you want to embed and integrate
>> your “workers”, into systems that have something like
>> this Java ClassLoader notion.
>>
>> Either way, “workers” provide a nice new notion
>> besides engines, which was never covered by Papers
>> of Paul Tarau and the like, and might not have
>> existed in older Prolog systems. Because
>>
>> old papers had a different ontology: Places,
>> Sandbox, etc.. workers were simply not on the radar.
>> The data isolation allows for non-cooperative
>> parallelism among workers, despite the notion of an
>>
>> engine is rather cooperative. Workers got momentum
>> with Web 2.0 and early process isolation of browser
>> tabs in 2008 when Chrome debuted. Just after that
>> in 2010 they were introduced as part of HTML5 for
>>
>> thread isolation inside a browser tab.
>>
>> See for yourself:
>>
>> Jinni: Intelligent Mobile Agent Programming
>> at the Intersection of Java and Prolog
>> https://www.researchgate.net/profile/Paul-Tarau/publication/2762429
>>
>> Mild Shock schrieb:
>>> If SWI-Prolog would be rewritten in C++ maybe a GLOBAL_LD
>>> wouldn’t be needed at all. You could make Knowledgebase
>>> and Engine classes, the C++ compiler would optimize for
>>>
>>> you passing around GD or LD in the form of a “this”, and
>>> a method inside an Engine, could access a Knowledge base,
>>> by “this->KB” or simply “KB”. C++ would be even less
>>> annoying than Java, since you can do deferred mixin:
>>>
>>> class Person {
>>>     [...]
>>> }
>>>
>>> And later:
>>>
>>> void Person::Print() {
>>>     [...]
>>> }
>>>
>>> Because I don’t have deferred mixin in Java, my own
>>> modularization looks extremly messy, passing around a
>>> parameter explicitly, hoping that the usual register
>>> file optimization of a Java compiler eliminates
>>>
>>> most parameter passing. But my C++ knowledge is very
>>> limited, so I don’t know whether a PhD in Macro defs
>>> was the better solution. Was there never a C++
>>>
>>> implemenation of SWI-Prolog ?
>>>
>>> Mild Shock schrieb:
>>>>
>>>>  > The required changes could be fairly limited.
>>>>
>>>> I don’t know. You never know before you did it.
>>>> With the current design you might end up in a
>>>> Münchhausen scenario, trying to defy gravity by
>>>> pulling your own hair. It seems there is a global switch
>>>>
>>>> which engine is active? I don’t understand, isn’t
>>>> SWI-Prolog able to run truely concurrently on a
>>>> multi-core machine. Because such things, wouldn’t
>>>> work for threads that distribute themselves over cores.
>>>>
>>>> I saw an L_THREAD lock somewhere?
>>>>
>>>> #define GET_LD      PL_local_data_t *__PL_ld = GLOBAL_LD;
>>>>
>>>> In the “worker” scenario, a “worker” can typically grab
>>>> a CPU core all for himself, and for its knowledge and
>>>> for all the engines that work over this knowlegde base.
>>>> Thats the beauty of JavaScript
>>>>
>>>> isolation through “workers”, and it is also used in
>>>> the Ciao Playground. Its very multi core friendly, a
>>>> “worker” can also have its own garbage collection etc…
>>>>
>>>>
>>>>
>>>>
>>>
>>
> 

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

#14617 — Grand mothers kitchen is nevertheless the best, who knows? (Was: Antique Programming Style versus Modern Programming Style [SWI-Prolog])

Disclaimer: Below was just a little rant, pushing
my modernization agenda, like elsewhere. But
this is just an opinion.

Maybe grand mothers kitchen is nevertheless
the best, who knows?

Mild Shock schrieb:
> Hi,
> 
> I just double checked OpenJDK, it has a few macros
> for ptrace meta data, but otherwise I don’t find so
> many macros. The problem is SWI-Prolog has a very
> antique programming style. It has an over use of macros.
> 
> Macros have a lot of drawbacks. Although you can do:
> 
> #define SQUARE(x) ((x) * (x))
> 
> /* makes this not behave as expected */
> int z = SQUARE(x++); // expands to (x++ * x++) —
>                       // side effects happen twice! ❌
> 
> In most modern C and C++ compilers you can do,
> i.e. use the “inline” keyword:
> 
> inline int square(int x) {
>    return x * x;
> }
> 
> /* lets this behave as expected */
> int z = square(x++); // x++ evaluated once ✔
> 
> This avoids all the classic macro pitfalls. So I wouldn’t
> touch Knowledge bases, as long as there is a macro hell.
> After getting rid of macros, yes, things are fairly
> 
> straight forward.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> They had a bunny-shaped topiary in front
>> of their offices, must have been swimming
>> in money, General Magic didn't predict the Future:
>>
>> https://www.youtube.com/watch?v=N4lqz2OofL0
>>
>> Now, things don't look exactly how they evisioned.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>>
>>> Another solution would be to dismiss the whole Java
>>> ClassLoader thing as humbug, and not strive for a
>>> Knowlegebase abstraction, and create workers via some
>>> operating system fork().
>>>
>>> This might perfectly well work as well. It only
>>> breaks down if you want to embed and integrate
>>> your “workers”, into systems that have something like
>>> this Java ClassLoader notion.
>>>
>>> Either way, “workers” provide a nice new notion
>>> besides engines, which was never covered by Papers
>>> of Paul Tarau and the like, and might not have
>>> existed in older Prolog systems. Because
>>>
>>> old papers had a different ontology: Places,
>>> Sandbox, etc.. workers were simply not on the radar.
>>> The data isolation allows for non-cooperative
>>> parallelism among workers, despite the notion of an
>>>
>>> engine is rather cooperative. Workers got momentum
>>> with Web 2.0 and early process isolation of browser
>>> tabs in 2008 when Chrome debuted. Just after that
>>> in 2010 they were introduced as part of HTML5 for
>>>
>>> thread isolation inside a browser tab.
>>>
>>> See for yourself:
>>>
>>> Jinni: Intelligent Mobile Agent Programming
>>> at the Intersection of Java and Prolog
>>> https://www.researchgate.net/profile/Paul-Tarau/publication/2762429
>>>
>>> Mild Shock schrieb:
>>>> If SWI-Prolog would be rewritten in C++ maybe a GLOBAL_LD
>>>> wouldn’t be needed at all. You could make Knowledgebase
>>>> and Engine classes, the C++ compiler would optimize for
>>>>
>>>> you passing around GD or LD in the form of a “this”, and
>>>> a method inside an Engine, could access a Knowledge base,
>>>> by “this->KB” or simply “KB”. C++ would be even less
>>>> annoying than Java, since you can do deferred mixin:
>>>>
>>>> class Person {
>>>>     [...]
>>>> }
>>>>
>>>> And later:
>>>>
>>>> void Person::Print() {
>>>>     [...]
>>>> }
>>>>
>>>> Because I don’t have deferred mixin in Java, my own
>>>> modularization looks extremly messy, passing around a
>>>> parameter explicitly, hoping that the usual register
>>>> file optimization of a Java compiler eliminates
>>>>
>>>> most parameter passing. But my C++ knowledge is very
>>>> limited, so I don’t know whether a PhD in Macro defs
>>>> was the better solution. Was there never a C++
>>>>
>>>> implemenation of SWI-Prolog ?
>>>>
>>>> Mild Shock schrieb:
>>>>>
>>>>>  > The required changes could be fairly limited.
>>>>>
>>>>> I don’t know. You never know before you did it.
>>>>> With the current design you might end up in a
>>>>> Münchhausen scenario, trying to defy gravity by
>>>>> pulling your own hair. It seems there is a global switch
>>>>>
>>>>> which engine is active? I don’t understand, isn’t
>>>>> SWI-Prolog able to run truely concurrently on a
>>>>> multi-core machine. Because such things, wouldn’t
>>>>> work for threads that distribute themselves over cores.
>>>>>
>>>>> I saw an L_THREAD lock somewhere?
>>>>>
>>>>> #define GET_LD      PL_local_data_t *__PL_ld = GLOBAL_LD;
>>>>>
>>>>> In the “worker” scenario, a “worker” can typically grab
>>>>> a CPU core all for himself, and for its knowledge and
>>>>> for all the engines that work over this knowlegde base.
>>>>> Thats the beauty of JavaScript
>>>>>
>>>>> isolation through “workers”, and it is also used in
>>>>> the Ciao Playground. Its very multi core friendly, a
>>>>> “worker” can also have its own garbage collection etc…
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> 

[toc] | [prev] | [standalone]

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

csiph-web