Liste des Groupes | Revenir à l prolog |
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…
>
>
>
>
Les messages affichés proviennent d'usenet.