ANN: Dogelog Runtime, Prolog to the Moon (2021)

[Mostowski Collapse]

Now I am expecting somebody telling me I should not
program Java style in Python. So I wonder what would have
happened if I would tell you I am FORTRAN programmer.

Then somebody would tell me I should not program 
FORTRAN style in Python. Hopefully this makes it evident
that this argumentation is moot.

Better would be more facts on the table based on
the existing code of Dogelog runtime. The future Dogelog
runtime code will possibly use ast.parse() and compile().

Thats why I am conducting this experiment which has only
been half way completed. The experiment is conducted 
because Python belongs to the champ of dynamic languages:

Dynamic programming language
https://en.wikipedia.org/wiki/Dynamic_programming_language

The experiment will be completed when the ast.parse()
and compile() thingy was explored as well. As it happens I
am conducting the experiment in parallel for JavaScript and

Python, both being dynamic programming languages.

Mostowski Collapse schrieb am Montag, 20. September 2021 um 14:43:01 UTC+2:
> Also I am not a C programmer. The last time I was programming C 
> was 30 years ago. I am mostly a Java programmer the recent years. 
> Dogelog Runtime adopts a lot of implementation details from 
> 
> Jekejeke Prolog which is a Prolog written in Java. The difference 
> betweeen the two is that Jekejeke Prolog has another Prolog term 
> model where Prolog terms are passed around as molecs, which 
> 
> are pairs of skeleton and display. On the other in Dogelog Runtime 
> uses a simpler representation, Prolog terms are passed around 
> as only one object. Programming language wise the difference 
> 
> between using Java and JavaScript or Python, is that Java has 
> types. So variables need a type declaration. Otherwise Java is 
> very similar to JavaScript or Python, it also provides a runtime with 
> 
> a garbage collection. The idea I would use C-style is a little absurd. It 
> would also require that a free() objects manually. But sweep_trail() has 
> nothing to do with freeing objects manually, its the anti-thesis to 
> 
> freeing objects manually, its a Prolog garbage collector after all!
> Mostowski Collapse schrieb am Montag, 20. September 2021 um 14:36:01 UTC+2: 
> > The sweep_trail() is not an issue. There must be a bottleneck 
> > somewhere else in Python. The sweep_trail() respectively the 
> > paremt call gc() only takes a very small fraction of the runtime: 
> > 
> > Check the "gc" timing, the bottleneck is somewhere else? 
> > Mostowski Collapse schrieb am Freitag, 17. September 2021 um 10:58:57 UTC+2: 
> > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
> > > % Standard Python Version, Warm Run 
> > > % ?- time(fibo(23,X)). 
> > > % % Wall 3865 ms, gc 94 ms, 71991 lips 
> > > % X = 46368. 
> > > 
> > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
> > > % GraalVM Python Version, Warm Warm Run 
> > > % ?- time(fibo(23,X)). 
> > > % % Wall 695 ms, gc 14 ms, 400356 lips 
> > > % X = 46368. 
> > Also my code is not C-style. If I would use C-style code, I would 
> > use address calculations and the adress operator &. But you 
> > don't find and according C-style in the Python or JavaScript code. 
> > 
> > Also there is no substitute for such coding style in the for 
> > of value holders or some such. Its all plain Python respectively 
> > JavaScript not at all inspired by the C programming language. 
> > 
> > The single linked list is not some indicative of C programming 
> > language style. With C programming language sytle one would 
> > do other tricks, you cannot read off from my Python or JavaScript 
> > 
> > code, since I cannot apply them to Python or JavaScript. Among 
> > the other C programming language tricks not available in Python 
> > or JavaScript would for example be inlining the args in Compound 
> > 
> > and so on. But I am not sure whether this is the bottleneck. 
> > Chris Angelico schrieb am Montag, 20. September 2021 um 14:25:12 UTC+2: 
> > > On Mon, Sep 20, 2021 at 9:50 PM Peter J. Holzer <hjp-p... at hjp.at> wrote: 
> > > > > Let Python be Python, don't try to build your own language on top of 
> > > > > it. 
> > > > 
> > > > Well, he's writing a Prolog interpreter, so building his own language on 
> > > > top of Python is sort of the point. I think a better way to put it is 
> > > > "Don't try to write Python as if it was C". 
> > > Fair point. Or combining them both: Writing a language interpreter in 
> > > Python as if you were writing it in C, and then complaining that it is 
> > > slow, is only going to elicit "well uhh yes?" responses. 
> > > 
> > > Languages like NetRexx (and, I think, Jython, although I can't find 
> > > any definitive and current answers) are slightly different from their 
> > > "parent" languages, because they make good use of their implementation 
> > > languages' features. This Prolog interpreter might not even need to be 
> > > different in functionality, but its implementation would be different, 
> > > and it could take advantage of the underlying garbage collection. 
> > > 
> > > ChrisA