It is likely that people would understand better if spoken to properly so I have been listening and hopefully gaining a picture that I can share, and be corrected helpfully when wrong.
My personal guess is that the project at hand is to do something very vaguely like what was done to the CURSES functionality ages ago in prehistory where lots of different terminals (and terminal emulators) used an assortment of control and escape sequences to make a text-based terminal do things like delete to the end of a line. The idea was to extract out all kinds of functionality used by pretty much all the terminals and save the info for say the hp2621 terminal either in a file with that name, or as entries in a file specifying many terminals or even in your environment. Then you made sure you had some variable like TERM set to hp2621 or whatever. If later you logged in on another kind of terminal, it would adjust dynamically for that without changing your program. When a program like vi(m) or emacs ran, it used the curses library which would dynamically reconfigure based on the terminal used and try to figure out the cheapest way (in terms of characters and I/O usually) to send extra escape sequences to update your screen as changes were made. Sometimes it would clear the screen and re-enter the new stuff and sometimes delete three lines then put in the replacement and so on. End of example. There are other examples like a format for documents that might take one of many ones like Word and make a common storage format that can easily be printed on any device that supports the features. The important aspect for me, is abstraction. My impression is the proposed project would abstract out the details of what any language can do and then examine one language after another (such as Ada or Python) and create some kind of description that can be stored, such as in a file. I have no idea what that might look like. I assume it would include what keywords there are or what variable names might look like or if some construct has an ending like "FI" or "endif" or "}" and it is only once this is completed, that the next phase can be used. It sounds like they would have what he considers a universal compiler that determines what language (perhaps even version) a file or group of files are using and then loads in info that metamorphizes it into an effective compiler for that language. It may not be that simple and I have no idea how it does that or how it outputs the result but it sounds like they have yet another language we might loosely compare to the byte stream used by JAVA and SCALA and some others that is half-digested and can be run by the JVM, or the Python version of something along those lines. In any case, I get the impression that this output will then look about the same no matter what language it came from. It will not require specific run-time environments but one overarching runtime that can run anything, again, using whatever abstraction or rules they come up with. And, in some cases, you may choose to go a step further and take this portable file format and compile it further down to an executable that runs on a specific machine and so on. I shudder at how well it will output error messages! Assuming this is feasible and well done, it might open quite a few doors in terms of designing both mini-languages and variants on existing ones and brand new ones with new ideas. You would have to find a way to describe your language as described above and as long as it is consistent in some ways, no need to ever build your own interpreter or compiler. It might be a bit like designing a new terminal (or just emulator) that has features you want. Mind you, some of the new features might require changes in the "Neo" something/data before it can be handled, but once added, any other language, within reason, might be able to add a similar feature and it should work. I hope I got this at least partially right and it is more informative that repeatedly telling people things like "Nope" as if this is a quiz and not an informative discussion. -----Original Message----- From: Python-list <python-list-bounces+avigross=verizon....@python.org> On Behalf Of Mr Flibble Sent: Saturday, February 13, 2021 7:07 PM To: python-list@python.org Subject: 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 -- https://mail.python.org/mailman/listinfo/python-list
