Re: neoPython : Fastest Python Implementation: Coming Soon
On 05/05/2021 17:36, Igor Korot wrote:
Hi,
On Wed, May 5, 2021 at 11:27 AM Mr Flibble <
flib...@i42.invalidwibblegrok.co.uk> wrote:
On 05/05/2021 17:02, Chris Angelico wrote:
On Thu, May 6, 2021 at 2:01 AM Mr Flibble
wrote:
neoPython : Fastest Python Implementation: Coming Soon
Message ends.
/Flibble
My breath: not being held.
Message ends.
Why? The currently extant Python implementations are so inefficient they
contribute to climate change; CPython is particularly egregious. Making a
faster
implementation isn't in the least bit a stretch.
Message ends.
Why do you use {C}Python in the first place if its so inefficient?
Why not use C or even Assembly?
And "coming soon" - is a little weird.
Why not say "coming 10 May 2021 at 23:59:59"?
/Message ends.
Thank you.
But I don't use Python, I use C++ (probably the best programming language in the
world).
/Flibble
--
--
https://mail.python.org/mailman/listinfo/python-list
Re: neoPython : Fastest Python Implementation: Coming Soon
On 05/05/2021 17:33, Mark Lawrence wrote: On Wednesday, May 5, 2021 at 4:57:13 PM UTC+1, Mr Flibble wrote: neoPython : Fastest Python Implementation: Coming Soon Message ends. /Flibble -- Dedicated to you and all like you https://www.youtube.com/watch?v=X15PsqN0DHc ORLY? If anyone is thick around here it is the typical Python user such as yourself. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: neoPython : Fastest Python Implementation: Coming Soon
On 05/05/2021 17:02, Chris Angelico wrote: On Thu, May 6, 2021 at 2:01 AM Mr Flibble wrote: neoPython : Fastest Python Implementation: Coming Soon Message ends. /Flibble My breath: not being held. Message ends. Why? The currently extant Python implementations are so inefficient they contribute to climate change; CPython is particularly egregious. Making a faster implementation isn't in the least bit a stretch. Message ends. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: neoPython : Fastest Python Implementation: Coming Soon
On 05/05/2021 17:02, Chris Angelico wrote: On Thu, May 6, 2021 at 2:01 AM Mr Flibble wrote: neoPython : Fastest Python Implementation: Coming Soon Message ends. /Flibble My breath: not being held. Message ends. Why? The currently extant Python implementations contribute to climate change as they are so inefficient; CPython is so egregious it is best called a bag of shite. Making a faster implementation isn't in the least bit a stretch. Message ends. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
neoPython : Fastest Python Implementation: Coming Soon
neoPython : Fastest Python Implementation: Coming Soon Message ends. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 14/02/2021 23:00, Christian Gollwitzer wrote: Am 14.02.21 um 11:12 schrieb Paul Rubin: Christian Gollwitzer writes: He wants that neoGFX is scriptable in Python, but instead of linking with CPython, he will write his own Python implementation instead, because CPython is slow/not clean/ whatever. He doesn't seem to understand that this is an enormous task on its own, because the interesting part of a scripting language is the standard library with many decade-years of work. I wonder how big an issue the stdlib really is. Lots of it is written in Python and can port to another interpreter. Lots more is CPython C API bindings to external C libraries (e.g. OpenSSL) so porting those would be a matter of rebinding those libraries to libffi in the cases where that hasn't been done already. I'm not saying that it is unfeasible or very difficult. I'm saying that it is a lot of work, and for a single developer who has this as a side project / support for his graphics engine and who wants to beat existing implementations wrt. speed, I'm saying it is going to take a lot of time. It'definitely impossible by "defining a few JSON schema files", as Leigh claims with his "universal compiler". There definitely IS a lot of stuff in a baseline CPython interpreter - a (seemingly) simple thing like "print" will have an implementation of 1000 lines in C with all the formatting library, file I/O etc. Arbitrary precision integers - another library, networking - yet another and so on. There will only be one schema file and it is will be a relatively small task which certainly isn't "impossible": I should have a working implementation by the summer. As far as arbitrary precision integers are concerned I am well on the way to completing the "neonumeral" library (which also has arbitrary precision floats). As far as the standard library is concerned: that is already in Python so I should be able to support it with little effort; the only thing requiring more work would be the built-ins. CPython really is pretty slow, maybe because it uses so much boxed data, derps around with refcounts all the time, suffers memory fragmentation from not having a relocating GC, etc. And that is before we even mention the GIL. I don't argue with that. CPython is slow. But I'm arguing that you can't make it faster by multiple orders of magnitude unless you change the language. For numerical code, straight-forward C is usually 100x to 1000x faster than Python, and you can reach the same performance by giving up dynamic typing - Cython demonstrates this quite convincingly. If you don't want static typing (with types close to the machine like fixed-width integers) than you'll have to resort to a LOT of black magic to even come close (PyPy, modern JS engines, ) I believe PyPy is only 4x faster than CPython on average and comes nowhere near close to JS JIT engines performance-wise. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Change first occurrence of character x in a string - how?
On 14/02/2021 21:14, Chris Green wrote: What's the easiest way to change the first occurrence of a specified character in a string? By using a grown up (i.e. non-toy) programming language. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Sketch
On 14/02/2021 09:10, Michał Jaworski wrote: Wow, that thread is entertaining. It seems that neos is one of it’s kind. What I hope is that it will support TempleOS. Going back going back to your original question Mr. Fibble. If ISO standard is what you really need to finish your project you can always take up this challenge and standardize the language yourself. From what I’ve learned already you have enough skills, experience and perseverance to complete such endeavor single-handedly. Ah yes, the good old TempleOS equivalence ploy: typically used by backseat programmers and/or trolls to dismiss projects or project authors they deem to have no value based on subjective hyperbole rather than valid criticism based on objective fact. Usually they lack the skill to embark on such a project themselves so their invective tends to stem from feelings of inadequacy. Make yourself a cup of tea, dear. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Sketch
On 14/02/2021 09:10, Michał Jaworski wrote: Wow, that thread is entertaining. It seems that neos is one of it’s kind. What I hope is that it will support TempleOS. Going back going back to your original question Mr. Fibble. If ISO standard is what you really need to finish your project you can always take up this challenge and standardize the language yourself. From what I’ve learned already you have enough skills, experience and perseverance to complete such endeavor single-handedly. If I standardized the language myself I couldn't call it "Python" as fixing Python requires changing it such as to make it unrecognisable as Python. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Sketch
On 14/02/2021 05:04, Mark Lawrence wrote: On Sunday, February 14, 2021 at 5:01:46 AM UTC, Mr Flibble wrote: CPython *is* the dead parrot. It's time for Python to evolve out of the primordial soup. /Flibble -- Says the bloke(?) who doesn't use mailing lists but does get here https://mail.python.org/pipermail/python-list/2021-February/900797.html I am using Usenet, dear. Apparently posts to comp.lang.python are copied to the mailing list which you worship like a god. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Sketch
CPython *is* the dead parrot. It's time for Python to evolve out of the primordial soup. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 14/02/2021 03:26, Grant Edwards wrote: On 2021-02-14, Ned Batchelder wrote: On Saturday, February 13, 2021 at 7:19:58 PM UTC-5, Chris Angelico wrote: At the absolute least, show that you have something that can run Python code. The OP has been making these claims on IRC for a (at least two years). He has never cared to substantiate them, or even participate in a civil and detailed discussion. He is either 1) smarter than all of us, or 2) woefully under-informed, or 3) trolling. He posts using the name of a hand-puppet. I think that provides a bit of a clue as to which of the 3 is most likely. And it's not even a _real_ hand-puppet: it's a computer-generated hologram of a hand hand-puppet. lulz. If I am a troll then Elon Musk is also a troll. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 14/02/2021 00:52, Alan Gauld wrote: On 14/02/2021 00:07, Mr Flibble wrote: On 13/02/2021 18:11, Alan Gauld wrote: You are going to create a Python compiler that will take existing Python code and output a byte code file. No neos is not a Python compiler: it is a *universal* compiler that can compile any programming language describable by a schema file Yes, I understand that, but from the perspective of this list what you are doing is providing a tool (a combination of neos and a schema) that will take in Python source code and spit out neos byte code. So, to all intents and purposes it is a Python compiler (albeit capable of more when needed). If that's correct, then how do you propose to deal with regular Python byte code? And what would the Python disassembler produce - Python assembler instructions or neos? The neos Python implementation will not be dealing with Python byte code in any form whatsoever. Ok but what do you do with the disassembler module? Will it read neos byte code instead of the Python codes? Also what about tools that work at the byte code level, I assume they will not work with neos either? That might include the profiler and debugger for example? neos will include a language agnostic disassembler and debugger. Also what would happen with the interactive prompt (>>>) I'm assuming you'd expect users to continue using the CPython interpreter and only compile the source after it was working there? Like turning on the optimiser in a traditional compiled language like C. neos will include support for interactive sessions; no reason to use CPython at all. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 14/02/2021 02:54, Mark Lawrence wrote: On Sunday, February 14, 2021 at 2:18:03 AM UTC, Mr Flibble wrote: On 14/02/2021 00:51, Ned Batchelder wrote: The OP has been making these claims on IRC for a while (at least two years). He has never cared to substantiate them, or even participate in a civil and detailed discussion. He is either 1) smarter than all of us, or 2) woefully under-informed, or 3) trolling. Our best course is to ignore him until he has code we can try. I am sure you are most annoyed that you can't ban me from Usenet, dear, like you banned me from IRC. You need to grow the fuck up. I take it that you didn't write "How to win friends and influence people"? I don't suppose that the moderators will actually wake up and remove you from the mailing lists asap. I see you are just as prickly as Ned, Mark. May I suggest that you too grow a pair? I am not on the mailing list BTW; e-mail lists are an outmoded concept much like CPython. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 14/02/2021 03:35, Paul Rubin wrote: Mr Flibble writes: I am creating neos as I need a performant scripting engine for my other major project "neoGFX" and I want to be able to support multiple popular scripting languages including Python. Is something wrong with Guile for that purpose? If yes, maybe you are setting yourself up for the exact same obstacles ;-). NIH. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 14/02/2021 00:51, Ned Batchelder wrote: On Saturday, February 13, 2021 at 7:19:58 PM UTC-5, Chris Angelico wrote: On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble wrote: On 13/02/2021 23:30, Igor Korot wrote: Hi, But most importantly - what is the reason for this ? I mean - what problems the actual python compiler produce? Thank you. I am creating neos as I need a performant scripting engine for my other major project "neoGFX" and I want to be able to support multiple popular scripting languages including Python. Until you have actually produced a (mostly) compatible Python implementation, can you please stop making these repeated and baseless jabs at CPython's performance? You keep stating or hinting that CPython is somehow unnecessarily slow, but unless you have some code to back your claims, this is nothing but mudslinging. CPython is not as slow as you might think. And PyPy is highly efficient at what it does well. Show us that you can do better than these before you call them slow. At the absolute least, show that you have something that can run Python code. ChrisA The OP has been making these claims on IRC for a while (at least two years). He has never cared to substantiate them, or even participate in a civil and detailed discussion. He is either 1) smarter than all of us, or 2) woefully under-informed, or 3) trolling. Our best course is to ignore him until he has code we can try. I am sure you are most annoyed that you can't ban me from Usenet, dear, like you banned me from IRC. You need to grow the fuck up. Your use of the words "all of us" is disingenuous, try "me" instead. "All of us" includes people as smart as me but can't be arsed fixing the Python space because they can just about live with the status quo. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 14/02/2021 00:19, Chris Angelico wrote: On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble wrote: On 13/02/2021 23:30, Igor Korot wrote: Hi, But most importantly - what is the reason for this ? I mean - what problems the actual python compiler produce? Thank you. I am creating neos as I need a performant scripting engine for my other major project "neoGFX" and I want to be able to support multiple popular scripting languages including Python. Until you have actually produced a (mostly) compatible Python implementation, can you please stop making these repeated and baseless jabs at CPython's performance? You keep stating or hinting that CPython is somehow unnecessarily slow, but unless you have some code to back your claims, this is nothing but mudslinging. CPython is not as slow as you might think. And PyPy is highly efficient at what it does well. Show us that you can do better than these before you call them slow. At the absolute least, show that you have something that can run Python code. It isn't just me that is saying CPython is egregiously slow: it is at the bottom of the list as far as performance is concerned. Python is undoubtedly the biggest contributor to climate change of all the programming languages in mainstream use today. See: https://thenewstack.io/which-programming-languages-use-the-least-electricity/ /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 13/02/2021 23:30, Igor Korot wrote: Hi, But most importantly - what is the reason for this ? I mean - what problems the actual python compiler produce? Thank you. I am creating neos as I need a performant scripting engine for my other major project "neoGFX" and I want to be able to support multiple popular scripting languages including Python. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 13/02/2021 18:11, Alan Gauld wrote: On 13/02/2021 16:09, Mr Flibble wrote: On 13/02/2021 00:01, Alan Gauld wrote: I'm assuming it's a new executable interpreter that can run any valid python code. Is that correct? It is a universal *compiler* so it compiles the python code to byte code and then optionally to machine code via a JIT which is then executed. OK, sorry for being dense, but just to be absolutely clear. You are going to create a Python compiler that will take existing Python code and output a byte code file. (I assume the byte code is not standard Python byte code?) And I assume the execution environment for the bytecode is part of your neos system? No neos is not a Python compiler: it is a *universal* compiler that can compile any programming language describable by a schema file and any language-specific semantic concepts. The byte code will be proprietary, yes, and will be executed by neos and/or JITed. If that's correct, then how do you propose to deal with regular Python byte code? And what would the Python disassembler produce - Python assembler instructions or neos? The neos Python implementation will not be dealing with Python byte code in any form whatsoever. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 13/02/2021 00:01, Alan Gauld wrote: On 12/02/2021 21:46, Mr Flibble wrote: The neos Python implementation will consist of a schema file which describes the language plus any Python-specific semantic concepts So the schema file is some kind of formal grammar definition of the language? And you "compile" this directly into machine code? Is that the idea? So when you say you have a universal compiler for any language what you mean is that you can produce a compiler/interpreter for any language from a language definition/schema. Is that it? I'm still not sure I understand what exactly you are proposing to do. What the final output looks like? I'm assuming it's a new executable interpreter that can run any valid python code. Is that correct? It is a universal *compiler* so it compiles the python code to byte code and then optionally to machine code via a JIT which is then executed. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 12/02/2021 00:15, Alan Gauld wrote: On 11/02/2021 12:30, Mr Flibble wrote: I am starting work on creating a new Python implementation from scratch using "neos" my universal compiler that can compile any programming language. Can i clarify that? Are you saying that you are going to recompile the existing C code for pyhton using yoour universal compiler and the resulting binary file will be a new implementation of the interpreter that you expect to be faster? Nope. That's what it sounds like to me. In which case the question is not whether you can write a better interpreter than CPython but whether you can write a better compiler than GNU/MING/VC etc See previous answer. While a universal compiler is certainly an interesting and challenging project I'm not sure how much it tells us about existing Python implementations. The two things are unrelated; however it is well known that Python is slow. On the other hand, if you are planning on rewriting the existing interpreter in something other than C, what is that something? Nope. Sample neos session (parsing a fibonacci program, neoscript rather than Python in this case): I'm not sure what relevance this has unless you want to rewrite Python in neoscript? Or are you translating the C into neoscript and then compiling it? But in a later response you seem to say neoscript was not involved? Slightly confused... The neos Python implementation will consist of a schema file which describes the language plus any Python-specific semantic concepts that don't generalize to more than one language. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 12/02/2021 02:45, Terry Reedy wrote: On 2/11/2021 5:33 PM, Mr Flibble wrote: On 11/02/2021 22:25, Dan Stromberg wrote: On Thu, Feb 11, 2021 at 2:00 PM Mr Flibble wrote: On 11/02/2021 21:13, Dan Stromberg wrote: Does your project have a name yet? I'd like to follow it through google alerts or an announcement mailing list. "neos" - https://neos.dev/ https://github.com/i42output/neos Pypi already appears to have another project named neos: https://pypi.org/project/neos/ neos isn't a Python package so that isn't a problem. Since it obviously is a Python package, as in importable into a Python program, why do you deny it? You are mistaken: it isn't a Python package and it isn't importable into a Python program. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 23:05, Paul Rubin wrote: Mr Flibble writes: "neos" - https://neos.dev/ https://github.com/i42output/neos Good luck, let us know when it is done. What is there doesn't look like a credible start so far, but maybe you will surprise us. Have you actually written any code in the languages you say you are going to support? E.g. Ada, Haskell, Rust. I'd agree that Python is fairly simple compared to those. Not credible? On what do you base that analysis? /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 23:12, Greg Ewing wrote: On 12/02/21 11:33 am, Mr Flibble wrote: neos isn't a Python package so that isn't a problem. It might be a bit confusing if it ever becomes part of the wider Python ecosystem, though. Python is but one language that neos will implement. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 22:25, Dan Stromberg wrote: On Thu, Feb 11, 2021 at 2:00 PM Mr Flibble wrote: On 11/02/2021 21:13, Dan Stromberg wrote: Does your project have a name yet? I'd like to follow it through google alerts or an announcement mailing list. "neos" - https://neos.dev/ https://github.com/i42output/neos Pypi already appears to have another project named neos: https://pypi.org/project/neos/ neos isn't a Python package so that isn't a problem. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 21:13, Dan Stromberg wrote: Does your project have a name yet? I'd like to follow it through google alerts or an announcement mailing list. "neos" - https://neos.dev/ https://github.com/i42output/neos /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 18:24, Paul Bryan wrote: On Thu, 2021-02-11 at 17:56 +, Mr Flibble wrote: Actually it is a relatively small task due to the neos universal compiler's architectural design. If it was a large task I wouldn't be doing it. When do you estimate this task will be completed? I am not particularly interested in any of the existing implementations as they bear no relation to the design of my language agnostic universal compiler, runtime, VM and JIT; the only use they will have will be to disambiguate certain Python language constructs that I cannot disambiguate from documentation alone: this is a natural consequence of Python not being standardized; those steering the language need to grow a pair and get Python standardized preferably as an ISO Standard. I take it you don't hope to receive any support from those you're insulting by such a statement? Thanks for the sentiment but I am not relying on luck. By your conduct so far, I think you will also not be relying on the goodwill of this community. Personally I prefer telling it like it is (i.e. the truth) rather than walking on eggshells. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 18:06, Chris Angelico wrote: On Fri, Feb 12, 2021 at 5:01 AM Mr Flibble wrote: On 11/02/2021 16:31, Dan Stromberg wrote: On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble wrote: Hi! I am starting work on creating a new Python implementation from scratch using "neos" my universal compiler that can compile any programming language. I envision this implementation to be significantly faster than the currently extant Python implementations (which isn't a stretch given how poorly they perform). I'd like to encourage you to give this a go. It's a huge task, but it's needed. Actually it is a relatively small task due to the neos universal compiler's architectural design. If it was a large task I wouldn't be doing it. You may be interested in the approaches of Pypy, Cython, Shedskin and Nuitka. I am not particularly interested in any of the existing implementations as they bear no relation to the design of my language agnostic universal compiler, runtime, VM and JIT; the only use they will have will be to disambiguate certain Python language constructs that I cannot disambiguate from documentation alone: this is a natural consequence of Python not being standardized; those steering the language need to grow a pair and get Python standardized preferably as an ISO Standard. You keep insulting Python and the Python devs. Put up or shut up - show some actual code before you make too many boasts. Python DOES have a strong language specification. Its semantics are documented. If you find places where the documentation is lacking, point them out specifically, don't FUD your way through. For a language to transition from "toy" status it has to be formally standardized. It is unacceptable to define a language in terms of a particular implementation. A git repo of Source code and associated observable dynamic behaviour when that code is compiled and ran is a poor substitute for an official ISO Standard. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 18:03, Chris Angelico wrote: In any case, it's not Python if it can't handle arbitrarily large numbers. Python is an excellent language for mathematics. I am also creating Ada and Haskell implementations which have a similar requirement. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 16:31, Dan Stromberg wrote: On Thu, Feb 11, 2021 at 4:35 AM Mr Flibble wrote: Hi! I am starting work on creating a new Python implementation from scratch using "neos" my universal compiler that can compile any programming language. I envision this implementation to be significantly faster than the currently extant Python implementations (which isn't a stretch given how poorly they perform). I'd like to encourage you to give this a go. It's a huge task, but it's needed. Actually it is a relatively small task due to the neos universal compiler's architectural design. If it was a large task I wouldn't be doing it. You may be interested in the approaches of Pypy, Cython, Shedskin and Nuitka. I am not particularly interested in any of the existing implementations as they bear no relation to the design of my language agnostic universal compiler, runtime, VM and JIT; the only use they will have will be to disambiguate certain Python language constructs that I cannot disambiguate from documentation alone: this is a natural consequence of Python not being standardized; those steering the language need to grow a pair and get Python standardized preferably as an ISO Standard. Pypy is a Python written in RPython, where RPython is a restricted subset of Python 2. It can translate RPython to C, or JIT compile pretty full Python code - 2.x or 3.x. It has trouble with C extension modules, as the CPython API for extension modules is pretty leaky. CFFI appears to be the big hope of fixing this problem, but most C extension modules still use the CPython C extension Module API. RPython doesn't interest me. neos will be using libffi for FFI. Cython transpiles a Python-like language to C. It allows you to intermix Python datatypes and C datatypes; the more you use C datatypes, the faster the result is. It can be slower if you aren't careful with your type conversions, but it can be faster if used well. It has a really nice --annotate option that shows how close to C your program is, line by line. I don't agree with the concept of delivering C compilers to end users. The only compilers I think end users should be running are GPU shader compilers and byecode/JIT compilers such as neos. Shedskin transpiles an implicitly static subset of Python 2 to C++. It's a great tool, but sadly it is unlikely to make the jump from Python 2 to Python 3, and Python 3 is definitely the future of Python. Not interested in that (see previous answer replacing "C" with "C++"). Nuitka is a Python -> C/C++ transpiler. I know little about it, but it sounds kind of like what you're proposing. It's been focusing on compatibility first, followed by performance. Bears no relation to neos architecture. Good luck! Thanks for the sentiment but I am not relying on luck. /Flibble -- -- https://mail.python.org/mailman/listinfo/python-list
Re: New Python implementation
On 11/02/2021 15:13, Chris Angelico wrote:
On Thu, Feb 11, 2021 at 11:36 PM Mr Flibble
wrote:
Hi!
I am starting work on creating a new Python implementation from scratch using
"neos" my universal compiler that can compile any programming language.
Is it your intention to support all of Python's syntax and semantics,
Yes.
or is this an unrelated language with mandatory strict type tags and a
severely restricted set of data types? For instance, can your neos
compile this code?
No. The neos universal compiler itself is language agnostic: a pre-requisite
for the requirement to be able to compile any programming language.
def power():
return (2**3**4**2) % 10
from time import time
start = time()
print(power())
time = time() - start
print("Took %s seconds" % time)
On my system, I get this from CPython 3.10:
176561152
Took 0.1589798927307129 seconds
And this from PyPy:
176561152
Took 0.0233387947083 seconds
I envision this implementation to be significantly faster than the currently
extant Python implementations (which isn't a stretch given how poorly they
perform).
Riight, yep, all existing Python implementations are terribly
slow. Go ahead then; run the code above, show me a better time, and of
course compare to what a recent off-the-shelf CPython can do on the
same hardware. Then see how PyPy performs at the same job.
You are timing the arithmetic library rather than the interpreter.
Sample neos session (parsing a fibonacci program, neoscript rather than Python
in this case):
Is neoscript an intermediate language like RPython, used only to
implement the compiler, or are you actually transforming Python code
into neoscript?
neoscript is the neos reference language (i.e. not an intermediate language)
and will be unrelated to the Python implementation.
/Flibble
--
--
https://mail.python.org/mailman/listinfo/python-list
New Python implementation
Hi!
I am starting work on creating a new Python implementation from scratch using
"neos" my universal compiler that can compile any programming language. I
envision this implementation to be significantly faster than the currently extant Python
implementations (which isn't a stretch given how poorly they perform).
Sample neos session (parsing a fibonacci program, neoscript rather than Python
in this case):
neos 1.0.0.0 ED-209
] help
h(elp)
s(chema)Load language schema
l(oad) Load program
list List program
c(ompile)Compile program
r(un)Run program
![] Evaluate expression (enter interactive
mode if expression omitted)
: Input (as stdin)
q(uit) Quit neos
lc List loaded concept libraries
t(race) <0|1|2|3|4|5> [] Compiler trace
m(etrics)Display metrics for running programs
] lc
[neos.core] (file:///D:\code\neos\build\win32\vs2019\x64\Release\core.ncl)
[neos.boolean]
[neos.language]
[neos.logic]
[neos.math]
[neos.module]
[neos.object]
[neos.string]
[neos.math.universal]
(file:///D:\code\neos\build\win32\vs2019\x64\Release\core.math.universal.ncl)
] s neoscript
Loading schema 'neoscript'...
Language: Default neoGFX scripting language
Version: 1.0.0
Copyright (C) 2019 Leigh Johnston
neoscript] l examples/neoscript/fibonacci.neo
neoscript] list
File 'examples/neoscript/fibonacci.neo':
-- neoscript example: Fibonacci
using neos.string;
using neos.stream;
import fn to_string(x : i32) -> string;
import fn to_integer(s : string) -> i32;
import proc input(s : out string);
import proc print(s : in string);
-- functions are pure
def fn add(x, y : i32) -> i32
{
return x + y;
}
def fn fib(x : i32) -> i32
{
if (x < 2)
return 1;
else
return add(fib(x-1), fib(x-2));
}
-- procedures are impure
def proc main()
s : string;
{
print("Enter a positive "
"integer: ");
input(s);
print("Fibonacci(" + s + ") = " + to_string(fib(to_integer(s))) + "\n");
}
neoscript] t 1
neoscript] c
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
folding: string.utf8(g) <- string.utf8.character.alpha()
folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
folding: string.utf8(gn) <- string.utf8.character.alpha()
folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
folding: string.utf8(gni) <- string.utf8.character.alpha()
folded: string.utf8(gni) <- string.utf8.character.alpha() = string.utf8(gnir)
folding: string.utf8(gnir) <- string.utf8.character.alpha()
folded: string.utf8(gnir) <- string.utf8.character.alpha() = string.utf8(gnirt)
folding: string.utf8(gnirt) <- string.utf8.character.alpha()
folded: string.utf8(gnirt) <- string.utf8.character.alpha() =
string.utf8(gnirts)
folding: string.utf8(gnirts) <- string.utf8.character.period()
folded: string.utf8(gnirts) <- string.utf8.character.period() =
string.utf8(gnirts.)
folding: string.utf8(gnirts.) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.) <- string.utf8.character.alpha() =
string.utf8(gnirts.s)
folding: string.utf8(gnirts.s) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.s) <- string.utf8.character.alpha() =
string.utf8(gnirts.so)
folding: string.utf8(gnirts.so) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.so) <- string.utf8.character.alpha() =
string.utf8(gnirts.soe)
folding: string.utf8(gnirts.soe) <- string.utf8.character.alpha()
folded: string.utf8(gnirts.soe) <- string.utf8.character.alpha() =
string.utf8(gnirts.soen)
folding: source.package.name() <- string.utf8(gnirts.soen)
folded: source.package.name() <- string.utf8(gnirts.soen) =
source.package.name(neos.string)
folding: source.package.import() <- source.package.name(neos.string)
folded: source.package.import() <- source.package.name(neos.string) =
source.package.import(neos.string)
folding: source.package.import(neos.string) <-
source.package.import(neos.string)
folding: string.utf8() <- string.utf8.character.alpha()
folded: string.utf8() <- string.utf8.character.alpha() = string.utf8(g)
folding: string.utf8(g) <- string.utf8.character.alpha()
folded: string.utf8(g) <- string.utf8.character.alpha() = string.utf8(gn)
folding: string.utf8(gn) <- string.utf8.character.alpha()
folded: string.utf8(gn) <- string.utf8.character.alpha() = string.utf8(gni)
folding: string.utf8(gni) <- string.utf8.character.alpha()
folded: string.utf8(gni) <- string.utf8.character.alpha() = string.utf8(gnir)
folding: string.utf8(gnir) <- string.utf8.character.alpha()
folded: string.utf8(gnir) <- string.utf8.character.alpha() = string.utf8(gnirt)
folding: string.utf8(gnirt) <- string.utf8.character.alpha()
folded:
