Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.szaf.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: Mild Shock <janburse@fastmail.fm>
Newsgroups: comp.lang.prolog
Subject: Antique Programming Style versus Modern Programming Style
 [SWI-Prolog] (Was: Workers never had the blessing of Paul Tarau [Prolog
 missed Web 2.0])
Date: Wed, 2 Jul 2025 15:54:22 +0200
Message-ID: <1043dmd$1jkcq$1@solani.org>
References: <vrkadh$7arh$1@solani.org> <1042nbf$1kdle$1@solani.org>
 <1042ngl$1kdle$2@solani.org> <1042oa1$1ke7t$1@solani.org>
 <1042pba$1kf2i$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 2 Jul 2025 13:54:21 -0000 (UTC)
Injection-Info: solani.org;
	logging-data="1692058"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101
 Firefox/128.0 SeaMonkey/2.53.21
Cancel-Lock: sha1:fjc76vAOuQsHUIMXR31/tcN0WiE=
In-Reply-To: <1042pba$1kf2i$1@solani.org>
X-User-ID: eJwFwQkBwDAIA0BLvIHJoaH1L2F36VCwAonIl+/cYIiZCOq4XeLV1A6xkZ9csoXMXpV05tyuLVH1NmDf/FaBFYE=

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