1e+191e19
1e1910000000000000000000
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.
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:
1e+191e19
- JavaScript:
1e1910000000000000000000
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.
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:
1e+191e19
- JavaScript:
1e1910000000000000000000
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.
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:
1e+191e19
- JavaScript:
1e1910000000000000000000
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.
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:
1e+191e19
- JavaScript:
1e1910000000000000000000
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.
The required changes could be fairly limited.
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…
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…
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…
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…
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…
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 149:55:54 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
437 files (114M bytes) |
| Messages: | 2,410,966 |