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/
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/
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
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/
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
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
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
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 491 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 146:56:40 |
| Calls: | 9,694 |
| Calls today: | 4 |
| Files: | 13,732 |
| Messages: | 6,178,670 |