Re: New Python implementation

[Alan Gauld via Python-list]

On 19/02/2021 18:14, Michael F. Stemper wrote:

>> and cons. LISP only had cons.

:-)

LOL


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New Python implementation

[Avi Gross via Python-list]

Benjamin,

I wonder if you understood my intended meaning not about the plusses and 
minuses of using a language like LISP but that it is fundamentally build on 
using the CONS concept to make lists in a poetic way but has no PROSE.

Not only does every language have what I meant by the usual meaning of pros and 
cons, but it depends on what other languages you are comparing it to, what kind 
of work you use the language for, is it for prototyping or final and efficient 
use, will someone else be extending or maintaining it, and which side of the 
bed you woke up on.

I used to be a fan of brevity as in whatever make me type less. But over time, 
many functions you call now have so many arguments, that I am now a fan of 
specifying the names of each argument as in function_name(arg1=value1, 
arg3=value3, ...) because it makes it much clearer what you want and prevents a 
certain class of errors. Nonetheless, I despise very long variable names, even 
when the editor allows for name completion. I thus like to place many commands 
on multiple lines to be read somewhat vertically and short lines. Others prefer 
the opposite. If a language hinders this style of multi-line, it is a plus or 
minus depending.

(cons "A" (cons "v" (cons "I" nil)))

-Original Message-
From: Python-list  On 
Behalf Of Benjamin Schollnick
Sent: Friday, February 19, 2021 1:31 PM
To: Michael F. Stemper 
Cc: python-list@python.org
Subject: Re: New Python implementation


>> that method was borrowed from or vice versa. Being a rich language 
>> has pro's and cons. LISP only had cons.

Now, Now.  That’s certainly not correct.  

LISP does have a few Pros.  Namely Job security.  You’ll have a hard time 
replacing a experienced and professional LISP programmer.

- Benjamin



--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Benjamin Schollnick]

>> that method was borrowed from or vice versa. Being a rich language has pro's
>> and cons. LISP only had cons.

Now, Now.  That’s certainly not correct.  

LISP does have a few Pros.  Namely Job security.  You’ll have a hard time 
replacing a experienced and professional LISP programmer.

- Benjamin



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Michael F. Stemper]

On 19/02/2021 10.49, Avi Gross wrote:


But for an individual programmer, it is great to use whichever method feels
best for you, and especially if you came to python from another language
that method was borrowed from or vice versa. Being a rich language has pro's
and cons. LISP only had cons.




--
Michael F. Stemper
If you take cranberries and stew them like applesauce they taste much
more like prunes than rhubarb does.
--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Grant Edwards]

On 2021-02-19, Avi Gross via Python-list  wrote:

> Some of us here go way back and have stories to tell of what we did even
> before Python existed. I won't rehash my history here now except to say I
> did use PASCAL in graduate school and my first job before switching to C
> which was less annoying to use.

ITYM Pascal. ;)

--
Grant

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Grant Edwards]

On 2021-02-19, Alan Gauld via Python-list  wrote:
> On 19/02/2021 03:51, Dennis Lee Bieber wrote:
>
>> They chose Pascal as being more modern, and something taught in
>> schools (yeah, like TurboPascal is going to be a good introduction
>> to writing software for real-time ground control of satellites).
>
> Funnily enough it was. Or at least for real-time telecomms control.
> We wrote all our real-time stuff on VAX and later PC using Pascal
> from the mid 80s through to early 1990s when we switched to C++.
> But TurboPascal was not much like Pascal, it had all the
> theoretical bits by-passed or removed.

Back in the 80's we wrote real-time embedded software for cellular
telephone radios in Pascal.  We even wrote the OS kernel in Pascal. It
worked great and was less error-prone than C.

--
Grant



-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New Python implementation

[Avi Gross via Python-list]

Some of us here go way back and have stories to tell of what we did even
before Python existed. I won't rehash my history here now except to say I
did use PASCAL in graduate school and my first job before switching to C
which was less annoying to use.

What I am interested in, in this forum, is how Python grew and specifically
what motivated adding new features. I see it as a bit more like a Camel
created when a committee got together and decided to create a horse and one
of them wanted it to also do well in a desert and so on.

For teaching purposes, it can be useful to have a minimalist design and a
way to catch lots of errors such as by strong typing. Some of that may also
be useful in the real world. But in re-teaching someone now in another
language, I keep running into the fact that when I use newer and more
powerful features they feel overwhelmed  as they vaguely remember the
built-in way and the new way uses a piping metaphor they are not familiar
with. I have had others who started with the new ways and don't even want to
know how an earlier version of the language did it.

In the real world, having to read, let alone maintain, code that others have
had a hand in shaping and reshaping can be hard work if each person did
things their own way. We have discussed the many ways you can format text in
python and if a program uses them all, here and there, ...

But for an individual programmer, it is great to use whichever method feels
best for you, and especially if you came to python from another language
that method was borrowed from or vice versa. Being a rich language has pro's
and cons. LISP only had cons.

-Original Message-
From: Python-list  On
Behalf Of Alan Gauld via Python-list
Sent: Friday, February 19, 2021 6:23 AM
To: python-list@python.org
Subject: Re: New Python implementation

On 19/02/2021 03:51, Dennis Lee Bieber wrote:

>   They chose Pascal as being more modern, and something taught in 
> schools (yeah, like TurboPascal is going to be a good introduction to 
> writing software for real-time ground control of satellites).

Funnily enough it was. Or at least for real-time telecomms control.
We wrote all our real-time stuff on VAX and later PC using Pascal from the
mid 80s through to early 1990s when we switched to C++.
But TurboPascal was not much like Pascal, it had all the theoretical bits
by-passed or removed.

I still use Pascal in the shape of Delphi for building windows GUI apps
today... But Delphi bears even less resemblance to Wirth's Pascal, in fact
its quite similar to Python in many ways.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Alan Gauld via Python-list]

On 19/02/2021 03:51, Dennis Lee Bieber wrote:

>   They chose Pascal as being more modern, and something taught in schools
> (yeah, like TurboPascal is going to be a good introduction to writing
> software for real-time ground control of satellites). 

Funnily enough it was. Or at least for real-time telecomms control.
We wrote all our real-time stuff on VAX and later PC using Pascal
from the mid 80s through to early 1990s when we switched to C++.
But TurboPascal was not much like Pascal, it had all the
theoretical bits by-passed or removed.

I still use Pascal in the shape of Delphi for building windows
GUI apps today... But Delphi bears even less resemblance to
Wirth's Pascal, in fact its quite similar to Python in many
ways.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New Python implementation

[Elliott Roper]

he goal is Computer USE literacy, I think python has more than enough if
> you include the modules that make hard things easy.
> 
> Just a thought. Admittedly it is hard these days to give a homework
> assignment when the student can find a trivial way to get the result and not
> do the hard work.
> 
> 
> -Original Message-
> From: Python-list  On
> Behalf Of Dennis Lee Bieber
> Sent: Thursday, February 18, 2021 12:45 AM
> To: python-list@python.org
> Subject: Re: New Python implementation
> 
> On Tue, 16 Feb 2021 11:03:33 +, Alan Gauld via Python-list
>  declaimed the following:
> 
>> On 16/02/2021 07:35, Christian Gollwitzer wrote:
>>>  Am 16.02.21 um 06:36 schrieb dn:
>>>>  Pascal's value as a teaching language was that it embodied many 
>>>>  aspects of structured programming, and like Python, consisted of a 
>>>>  limited range of items which could be learned very quickly
>>>  
>>>  ROFL. Maybe that was true for Python when it was first invented. 
>>>  Today it is not "a few simple things". Even just the core language,
>> 
>> Python v1 was a good teaching language. v2 complicated it a bit but it 
>> was still usable. v3 is no longer a good teaching language (unless 
>> maybe you are teaching CompSci at university.)
>> 
>> In fact in v3 things are so complex that I seriously considered 
>> dropping Python as the core language for my programming tutorial.
>> Until I started looking for an alternative, and there really isn't 
>> anything much better. At least not that can also be used for real 
>> projects once you've learned it.
> 
>   Depending upon the course intentions, I'd say Python is useful for
> teaching general programming and getting to usable real-world programs.
> 
>   For CompSci /theory/, OTOH, Python has too much built in, and would
> get in the way of having someone implement things like linked-lists, deques,
> hashed structures -- ie; the stuff that lies behind all those Python
> built-ins. Pascal, Modula-2 (or is it up to 3 now), or one of the other
> system programming languages: Edison from
> https://www.amazon.com/Programming-personal-computer-Brinch-Hansen/dp/013730
> 2673
>   Implement a hashed-head multiple-linked list using Kemeny
> level BASIC! (My algorithms instructor allowed the class to use any language
> on that he could read -- so FORTRAN, BASIC, Pascal, Sigma Meta-Symbol,
> COBOL... No Snobol, LISP, or APL -- for that final project: a phone book
> directory/look-up system). Interestingly, I've only seen a hashed-head
> multiple-linked list structure used in one real world application: The
> Commodore Amiga file system.


-- 
To de-mung my e-mail address:- fsnospam$elliott$$
PGP Fingerprint: 1A96 3CF7 637F 896B C810  E199 7E5C A9E4 8E59 E248


-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New Python implementation

[Avi Gross via Python-list]

Dennis made the interesting comment "... Python has too much built in ..."

I understand his point. At the same time, I wonder what most people using
computers today, or in the future, need. Given serious amounts of computer
power, what many people may want is higher-level ways to get things done
without worrying how they are done. Python, like many such languages, has a
very basic core that is augmented by what could be libraries, packages,
modules and so on but have been chosen to be built-in to one distribution or
another.

Some people and organizations use some things so commonly, they want python
to start up automatically loading say numpy and pandas and other such
things. They may not care if the programmer knows how to make a linked list
or binary tree data structure. Many such details are encapsulated within
objects built and tested already. 

I have seen subjects taught at various levels and python might qualify too.
I took a Physics course that required Calculus and used it to derive
formulas and other things. Others took one that sort of threw equations at
you without much explanation. I have even seen a course called Physics for
Poets. But at least the poets taking it  knew science existed and perhaps to
take it seriously when others who had studied it better shared their
results, even if they have no interest in the methods.

We routinely have people learn how to use Word Processors or Spreadsheets
with no clue on how to build such a thing or anything about the Object
models used within or even knowing there is such a thing. Do they need to
know how to use the embedded methods to extend things with Visual Basic or
Javascript? They like getting closer to a WYSIWYG interface that handles
most of their usual needs and perhaps farm out harder things to experts when
needed.

So what if you teach some aspects of python that are needed all over, like
how to make things conditional or in a loop, but not how to make every
possible data structure. What if you deliberately do not teach functional
aspects of the language at first or ever? For some people that is enough to
enable them to then use additional instructions on how to find prepared and
tested chunks to use, even if not always optimally or efficiently. For those
who really want to be programmers, that still may actually be enough if
their task is to work using the tools we have developed, not in making new
tools from scratch. Quite a bit of programming today consists of reading
manual pages and cobbling together chunks that together do the job.

But obviously I would choose the classes where I understood more. Many here
would. But where does it end? Do most of us know how compilers or
interpreters get built or do we just work on top of existing implementations
others make available? Can you build an operating system from Scratch or
make microchips to run them on?

If the goal is Computer USE literacy, I think python has more than enough if
you include the modules that make hard things easy.

Just a thought. Admittedly it is hard these days to give a homework
assignment when the student can find a trivial way to get the result and not
do the hard work.


-Original Message-
From: Python-list  On
Behalf Of Dennis Lee Bieber
Sent: Thursday, February 18, 2021 12:45 AM
To: python-list@python.org
Subject: Re: New Python implementation

On Tue, 16 Feb 2021 11:03:33 +, Alan Gauld via Python-list
 declaimed the following:

>On 16/02/2021 07:35, Christian Gollwitzer wrote:
>> Am 16.02.21 um 06:36 schrieb dn:
>>> Pascal's value as a teaching language was that it embodied many 
>>> aspects of structured programming, and like Python, consisted of a 
>>> limited range of items which could be learned very quickly
>> 
>> ROFL. Maybe that was true for Python when it was first invented. 
>> Today it is not "a few simple things". Even just the core language,
>
>Python v1 was a good teaching language. v2 complicated it a bit but it 
>was still usable. v3 is no longer a good teaching language (unless 
>maybe you are teaching CompSci at university.)
>
>In fact in v3 things are so complex that I seriously considered 
>dropping Python as the core language for my programming tutorial.
>Until I started looking for an alternative, and there really isn't 
>anything much better. At least not that can also be used for real 
>projects once you've learned it.

Depending upon the course intentions, I'd say Python is useful for
teaching general programming and getting to usable real-world programs.

For CompSci /theory/, OTOH, Python has too much built in, and would
get in the way of having someone implement things like linked-lists, deques,
hashed structures -- ie; the stuff that lies behind all those Python
built-ins. Pascal, Modula-2 (or is it up to 3 now), or one of the other
system programming languages: Edison from
https://www.amazon.com/Pr

Re: New Python implementation

[Alan Gauld via Python-list]

On 16/02/2021 21:22, Tarjei Bærland via Python-list wrote:

> To me, it depends on what you want out of including programming in
> mathematics education.

That's a really important subclass distinction.
If programming is seen as an adjunct to math then the aims
can be simplified considerably since you are only interested
in pure computation. Things like networking, interfacing
to peripherals and the like can be ignored.
Likewise you probably don't care about creating large projects wit
multiple files etc.

With those constraints there are probably better languages
than python. You mention Logo and I had fun with that back
in the 80s and early 90s. But ultimately it wasn't suitable
for the kind of real-world programming I needed.

That's why I chose python for my tutorial. Its not only
teachable at a basic level but it is actually usable on
larger, real-world type projects once you've learned it.
You never need to throw away your skills.

> If the aim is to quickly get the students to "be creative" with
> programming by themselves, my feeling is that Python is too unwieldy for
> a beginner.

Don't underestimate the interactive prompt. It gives instant
feedback and is moire usable for beginners than most Lisp-style
REPLs.

Logo works too of course. But almost anything you can do in
Logo you can do almost as easily in Python. Be it list
handling or turtle graphics.

> minutes. They get the feeling of designing their own computational
> procedure much quicker than in Python. (Yes, of course, the introductory
> excercises in Python are a bit more advanced than "add two numbers".)

But they don't need to be. My tutor starts off with precisely that...

> I am honestly not sure what quite what my feelings are regarding this,
> perhaps Python is the best of all possible options.

Its a good compromise. Its got faults (see my other post!) but
I haven't found anything clearly better.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Alan Gauld via Python-list]

On 16/02/2021 22:23, boB Stepp wrote:

>> And that's just one example, the language is now full of meta goodness
>> that makes it incomprehensible to beginners. 
> 
> Hmm.  I'm not sure I can agree, Alan.  My son took to Python 3 like a duck to
> water.  

That's interesting. I knew you were teaching him but not
how he got on. Good for him.

My comments stem from the feedback emails I get from my tutorial.
People get messages like "foo is not an iterable" or references
to range objects and such and it confuses them.

I never got those kinds of messages for the v.1 tutorial...

> Yes, there is a ton of meta-goodness in Python, but most of it can be ignored
> to be able to *just use it*.  

But the problem I see is that you can't ignore it because
it bubbles to the surface in error messages. And if you
don't know what it means you don't know that you can ignore it!
That's where a teacher/mentor comes in, they can say "Oh that's OK
just ignore it!" but if you are on your own you think
"Oh no! What do I do now?"

But as I say, I can't find anything better so I'll stick
with it for now.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Abdur-Rahmaan Janhangeer]

Greetings,

age: After university to retirement
level: school, A Level is high school, not university
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Igor Korot]

Hi,



On Tue, Feb 16, 2021, 8:15 PM Abdur-Rahmaan Janhangeer 
wrote:

> Greetings list,
>
> > Even if Python is my choice language for personal projects, I am not
> certain it
> is the right language to use in a classroom context.
>
> This sums the view of most teachers in my country. In here for A level
> at Cambridge for Computer Studies you can choose either Java, or VB or
> Python
>
> The teachers' logic seems to tell them that VB is the simplest of all and
> more fitted for students. Since we organise the local Python usergroup
> ,
> we have been encouraging the adoption of Python. This happens from
> experience when teachers think for students, they think student will think
> like that etc
>

How old are the teachers?
And is it for school or university?


Thank you.


> The way schools examinations are set up, learning  programming is a bore.
> Programming requires experimentation and projects. The students must be
> permitted to explore the wide deep sea that is Python. On one of my
> projects
> on Github, i have a toy language, someone from Slovakia (14 years old)
> built
> an IDE for it, what was needed was only guidance where he was stuck.
>
> The hurdle with Python if any is the setting up and getting the command
> 'python'
> to appear in the terminal, which is very easy to get up and running
> nowadays.
>
> When i was in high school, i did not take Computer Studies, but was
> learning programming
> on my own, including Python. The irony is that my friends who were learning
> Python
> got disgusted with it. Loops and functions turned out to be hard for them.
> That's because
> learning for the exam makes you learn the language close to theory. Some
> commandline
> stuffs and some numbers stuffs surely is not exiting. Mastery comes with
> projects, exciting ones.
> Then whatever the syllabus requires becomes easy. It's a means to an end
> rather than the end
> in itself.
>
> The teachers' reaction is a reaction to the design of the syllabus. The
> folks seem to think that let's
> water it down to a very theoretical approach, strike out practise, strike
> out the fun out of it and
> sure the students will find it easier. Since effort is disliked by humans,
> less effort in learning programming
> will make students happy.
>
> Then, if it was no Python at that time, it might be no Python for life.
> With that mindset ongoing,
> those students think they know Python, they studied it, but they missed the
> whole thing. Forest,
> trees and leaves. They know only the color of the sign board leading to the
> place.
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about  | blog
> 
> github 
> Mauritius
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Abdur-Rahmaan Janhangeer]

Greetings list,

> Even if Python is my choice language for personal projects, I am not
certain it
is the right language to use in a classroom context.

This sums the view of most teachers in my country. In here for A level
at Cambridge for Computer Studies you can choose either Java, or VB or
Python

The teachers' logic seems to tell them that VB is the simplest of all and
more fitted for students. Since we organise the local Python usergroup
,
we have been encouraging the adoption of Python. This happens from
experience when teachers think for students, they think student will think
like that etc

The way schools examinations are set up, learning  programming is a bore.
Programming requires experimentation and projects. The students must be
permitted to explore the wide deep sea that is Python. On one of my projects
on Github, i have a toy language, someone from Slovakia (14 years old)
built
an IDE for it, what was needed was only guidance where he was stuck.

The hurdle with Python if any is the setting up and getting the command
'python'
to appear in the terminal, which is very easy to get up and running
nowadays.

When i was in high school, i did not take Computer Studies, but was
learning programming
on my own, including Python. The irony is that my friends who were learning
Python
got disgusted with it. Loops and functions turned out to be hard for them.
That's because
learning for the exam makes you learn the language close to theory. Some
commandline
stuffs and some numbers stuffs surely is not exiting. Mastery comes with
projects, exciting ones.
Then whatever the syllabus requires becomes easy. It's a means to an end
rather than the end
in itself.

The teachers' reaction is a reaction to the design of the syllabus. The
folks seem to think that let's
water it down to a very theoretical approach, strike out practise, strike
out the fun out of it and
sure the students will find it easier. Since effort is disliked by humans,
less effort in learning programming
will make students happy.

Then, if it was no Python at that time, it might be no Python for life.
With that mindset ongoing,
those students think they know Python, they studied it, but they missed the
whole thing. Forest,
trees and leaves. They know only the color of the sign board leading to the
place.

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Peter J. Holzer]

On 2021-02-14 00:52:43 +, Alan Gauld via Python-list wrote:
> On 14/02/2021 00:07, Mr Flibble wrote:
> > 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?

What do PyPy, Jython, IronPython etc. do with the disassembler module?
My guess is that they simply don't implement it. It's tightly coupled to
the CPython implementation and useless on any other implementation. A
disassembler module for their respective bytecode or machine language
might be useful, but that wouldn't be compatible with CPython's
disassembler in input nor output.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Roel Schroeven]

Christian Gollwitzer schreef op 16/02/2021 om 8:25:

Am 15.02.21 um 21:37 schrieb Roel Schroeven:


So your claim is that your compiler is able to, or will be able to,
compile any language just by specifying a small schema file. Great!

Do you maybe have a proof-of-concept? A simple language with a simple
schema file to test the basic workings of your compiler,


Here is the git repo:

https://github.com/i42output/neos

under languages/ you'll find different schema files.


I saw that, and I saw the schema files. I had a look at the one for C, 
because I don't know the first thing about Ada, and it's not nearly 
enough to describe even the tiniest subset of C. And I saw the example 
session he posted here, where he supposedly compiles something, but 
doesn't even run it. It looked like that compilation did nothing but 
folding and folding and folding. And he didn't run it!


So it looks like that's the status of the project now: a compilation 
step that does /something/, but apparently doesn't result in anything 
runnable. And some work-in-progress (seemingly) schema files, but 
nothing concrete yet.


But I wanted to give Mr Flibble to benefit of the doubt, and asked more 
explicitly about the status of the project. Apparently I was too late, 
Mr Flibble was already banned, but I didn't know that yet.


I've thougt about downloading the whole thing and trying to build it. 
But I'd have to install Visual Studio 2019 first and probably some 
dependencies. It didn't seem worth the effort.



Regards,
Roel

--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[boB Stepp]

On 21/02/16 11:03AM, Alan Gauld wrote:


Python v1 was a good teaching language. v2 complicated it a bit
but it was still usable. v3 is no longer a good teaching language
(unless maybe you are teaching CompSci at university.)


[...]


And that's just one example, the language is now full of meta goodness
that makes it incomprehensible to beginners. In a teaching environment,
with a teacher present to answer questions, it's probably usable,
but for a self guided course it's increasingly inscrutable.


Hmm.  I'm not sure I can agree, Alan.  My son took to Python 3 like a duck to
water.  Occasionally he has had questions for me, but, for the most part, he
has been entirely on his own with no issues.  He now has several projects that
others are using, including a significant update to someone else's project he
was interested online to both update the Python and Qt.

Yes, there is a ton of meta-goodness in Python, but most of it can be ignored
to be able to *just use it*.  My wife is using Python 3 in a robotics class
she teaches and her high school students find it accessible.  AP computer
science second semester uses Python.  I really don't think it is much of a
problem for most people.  Of course on the Tutor list there often seems to be
some greatly puzzled people, but I think their issues stem from *never* having
tried to do anything even remotely technical other than clicking around in
the GUI programs they have become comfortable with.

--
Wishing you only the best,

boB Stepp
--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Dan Stromberg]

On Tue, Feb 16, 2021 at 1:23 PM Tarjei Bærland via Python-list <
python-list@python.org> wrote:

> Sure, Brainfuck is two steps too far, but Scheme or Logo I'd wager be
> excellent languages to get the students into computational
> thinking. Haskell might be a good choice as well, I do not have enough
> experience with it to say.
>
I am not a Haskell expert by any stretch.  But I did play with it a bit.

It's a fascinating language. But I think the language is hobbled by poor
error messages from the main compiler, GHC.  I've been told GHC has a
rather elegant implementation, but that came at the cost of the quality of
error messages.
https://www.reddit.com/r/haskell/comments/54l3ug/readable_error_messages_like_in_elm/

There was a project to produce a somewhat restricted Haskell implementation
with better error messages, but sadly that project is no longer maintained.
https://wiki.haskell.org/Hugs
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Tarjei Bærland via Python-list]

Christian Gollwitzer writes:

> I agree to all the rest of your post, but this:
>
> Am 16.02.21 um 09:57 schrieb Tarjei Bærland:
>> I am not sure I agree that a language like Scheme or Logo or Brainfuck, with
>> their small number of building blocks, would be harder to learn.
>
>
> is strange. I'm not sure, have you actually looked at Brainfuck? Maybe 
> there is also confusion what means "learning" a programming language. 
> For me, learning a language does not mean to remember the rules and 
> keywords, but to be able to write useful programs. Indeed, Brainfuck 
> with its 8 commands is easy to remember, but it comes at a very high 
> price: you can't do anything useful with it with reasonable effort. It 
> is unusable even for pure computer science stuff. It is easy to see that 
> BF is Turing complete, so please write a BF program to compute the 
> ackermann function. Should be easy, just three rules ;) I'd definitely 
> choose Python to do it here.
>
> In that sense, Scheme also appears to be the Brainfuck of functional 
> programming to me. It is not much more than the pure untyped lambda 
> calculus, and by definition this allows you to compute anything, just 
> like Brainfuck is a Turing machine. Actually it is impressive that you 
> can write actual useful code with such a minimalist language (infix 
> math? Pure bloat!). OTOH it feels like "assembly" compared to more 
> evolved functional languages like, e.g. Haskell.
>
>Christian

To me, it depends on what you want out of including programming in
mathematics education.

Sure, Brainfuck is two steps too far, but Scheme or Logo I'd wager be
excellent languages to get the students into computational
thinking. Haskell might be a good choice as well, I do not have enough
experience with it to say.

If the aim is to quickly get the students to "be creative" with
programming by themselves, my feeling is that Python is too unwieldy for
a beginner.

In a programming course I am teaching, one of the goals is for the
students to distinguish "high level" and "low level" languages. I've
used Brainfuck as an example of a programming language at a low level of
abstraction. That session is often the most engaging throughout the
year. The students are sitting writing their own code after a few
minutes. They get the feeling of designing their own computational
procedure much quicker than in Python. (Yes, of course, the introductory
excercises in Python are a bit more advanced than "add two numbers".)

I am honestly not sure what quite what my feelings are regarding this,
perhaps Python is the best of all possible options.

- Tarjei

Note, I am emphatically saying this in the context of a maths class.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Tarjei Bærland via Python-list]

David Lowry-Duda writes:

>> In Norway, where I try to teach mathematics to highschoolers, 
>> programming has recently entered the teaching of stem subjects.
>> 
>> Even if Python is my choice language for personal projects, I am not 
>> certain it is the right language to use in a classroom context.
>> ...
>> I am not sure I agree that a language like Scheme or Logo or 
>> Brainfuck, with their small number of building blocks, would be harder 
>> to learn.
>
> Does this mean that you also try to teach programming to highschoolers, 
> or is there a different (maybe dedicated) teacher to that? What language 
> do they use? And does it influence math education at all? (Coming from 
> someone who sometimes tries to teach undergraduates about math).
>
> - David Lowry-Duda

Yes, that also means that mathematics teachers are teaching programming
as well. For my part, it's a welcome change, and I've already been
teaching another programming course for a couple of years, but a lot of
teachers are having to start programming alongside their students.

I don't have any numbers for this, but I'd be surprised if less than 95%
of all teachers used Python for this. (I know of no exception.)

I think it's too soon to tell whether it affects the education. However,
I would have liked to better know the motivation for including
it. Python seems like one of several good choices if you want to
manipulate mathematical objects, perhaps mixing in som symbolic algebra
via Sympy, and other "high level concepts". However, if the aim is for
the students to quickly experience what it's like to design their own
simple algorithm without excessive guidance, Python might not then be the
optimal choice.

- Tarjei Bærland

PS: I can't remember in what context I visited it, but thanks for an
inspiring site.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Michael Torrie]

On 2/16/21 10:58 AM, Ben Bacarisse wrote:
> Attempts at a universal compiler stalled in the 1980s (though there may
> have been some new developments since I stopped looking) because
> expressing the semantics of different languages is so very hard.  In
> fact, much of the interest in pursuing the idea came from benefits that
> would be derived simply from having a language's semantics formally
> described.
> 
> I don't think there is anything to see here.  If the author had come up
> with some new ways to tackle any of the problems, he would be telling> people 
> about these, not saying "be patient" (and bad-mouthing CPython).

Indeed, in all seriousness if he is successful, I look forward to
reading his PhD dissertation, because it would be worthy of a PhD,
especially if he made some breakthroughs in metacompiler design.  His
comments don't give me hope, though.

Seems a bit paradoxical to me to, on the one hand, express a desire to
build a Python implementation, but on the other hand, mock Python as a
toy language.  Why bother with Python at all?

I wish him luck and maybe he'll eventually come back to the community
with something to show and impress with.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Christian Gollwitzer]

I agree to all the rest of your post, but this:

Am 16.02.21 um 09:57 schrieb Tarjei Bærland:

I am not sure I agree that a language like Scheme or Logo or Brainfuck, with
their small number of building blocks, would be harder to learn.



is strange. I'm not sure, have you actually looked at Brainfuck? Maybe 
there is also confusion what means "learning" a programming language. 
For me, learning a language does not mean to remember the rules and 
keywords, but to be able to write useful programs. Indeed, Brainfuck 
with its 8 commands is easy to remember, but it comes at a very high 
price: you can't do anything useful with it with reasonable effort. It 
is unusable even for pure computer science stuff. It is easy to see that 
BF is Turing complete, so please write a BF program to compute the 
ackermann function. Should be easy, just three rules ;) I'd definitely 
choose Python to do it here.


In that sense, Scheme also appears to be the Brainfuck of functional 
programming to me. It is not much more than the pure untyped lambda 
calculus, and by definition this allows you to compute anything, just 
like Brainfuck is a Turing machine. Actually it is impressive that you 
can write actual useful code with such a minimalist language (infix 
math? Pure bloat!). OTOH it feels like "assembly" compared to more 
evolved functional languages like, e.g. Haskell.


  Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Ben Bacarisse]

"Avi Gross"  writes:

> Thanks for sharing. I took a look and he does have a few schemas for Ada and
> C from TWO YEARS ago. Nothing about the infinite number of other languages
> he plans on supporting, let alone Python. And what he has is likely not
> enough to do what he claims he can do easily and rapidly.

The C schema says almost nothing about C.  It lists one kind of comment
and a few type names.  Significantly, it says almost nothing about the
semantics of even the tiny fragment of C presented.

Attempts at a universal compiler stalled in the 1980s (though there may
have been some new developments since I stopped looking) because
expressing the semantics of different languages is so very hard.  In
fact, much of the interest in pursuing the idea came from benefits that
would be derived simply from having a language's semantics formally
described.

I don't think there is anything to see here.  If the author had come up
with some new ways to tackle any of the problems, he would be telling
people about these, not saying "be patient" (and bad-mouthing CPython).

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New Python implementation

[Avi Gross via Python-list]

Christian,

Thanks for sharing. I took a look and he does have a few schemas for Ada and
C from TWO YEARS ago. Nothing about the infinite number of other languages
he plans on supporting, let alone Python. And what he has is likely not
enough to do what he claims he can do easily and rapidly.

What gets me is that many languages severely overload the use of some
characters and tokens so they can mean many things based on the context and
capturing that is much harder than declaring what is a keyword. Worse, some
languages like PERL make so many things optional, that you can write very
brief programs that keep implicitly assuming the previous part stored
results in $_ and seem at first to be magical as the actual code does not
seem connected to anything. I am not so sure there is a reasonable way to
program ALL existing language his way & to have one ring-like compiler to
rule them all, albeit you might be able to consolidate several somewhat
similar languages.

I also wonder how efficient such a universal compiler (maybe technically not
a compiler) would be but if it was only used once, maybe not. But didn't he
also say this thing would work in an interactive mode line by line?

It reminds me of when I was studying concepts about various takes on a
Turing Machine for my thesis. It has been proven that a Turing Machine can
theoretically solve any problem you can solve with a non-quantum computer. I
emphasize  it is theoretical because we are talking about an infinite tape
with squares containing symbols that are read by a head that moves over it
either to the left or right based on the current state and so on. Fairly
simple programs like copying a million instances of "1" in a row can take
quite a while and really complex programs need near-infinite times or
infinitesimal time per step. What is POSSIBLE is far from useful.

I feel the same way about NEOS. Given a sufficiently advanced and convoluted
schema you can write a sufficiently convoluted computer program that might
halt with an answer -- meaning it will compile a valid program written in a
language that is completely defined by that schema and perhaps additional
info. We know it can be done because each language has existing compilers
and/or interpreters that do so, without an explicit schema.

But to have a program that can take any schema whatsoever and do what is
needed is a bit much. Existing languages were simply not designed with this
in mind and new/old languages might feel constrained about designing new
features that will not be able to fit within an existing schema.

In particular, how do you handle multiple versions of a language like Python
2.X and the incompatible Python 3.X and the eventual re-re-designed Python
4.Y? They all may be placed in files ending in .py!

There is nothing wrong with thinking out of the box or making grand plans.
But I have known people ranging from overly optimistic to manic who think
nothing of making extraordinary claims and may actually believe it. I would
not be shocked if a subset of what is being suggested for NEOS might be done
by a large team in a few decades but by then, we may all be using quantum
computers and a whole new set of languages to take advantage of new
paradigms like superposition ...

-Original Message-
From: Python-list  On
Behalf Of Christian Gollwitzer
Sent: Tuesday, February 16, 2021 2:25 AM
To: python-list@python.org
Subject: Re: New Python implementation

Am 15.02.21 um 21:37 schrieb Roel Schroeven:
> 
> So your claim is that your compiler is able to, or will be able to, 
> compile any language just by specifying a small schema file. Great!
> 
> Do you maybe have a proof-of-concept? A simple language with a simple 
> schema file to test the basic workings of your compiler,

Here is the git repo:

https://github.com/i42output/neos

under languages/ you'll find different schema files.

Christian
--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Alan Gauld via Python-list]

On 16/02/2021 07:35, Christian Gollwitzer wrote:
> Am 16.02.21 um 06:36 schrieb dn:
>> Pascal's value as a teaching language was that it embodied many aspects
>> of structured programming, and like Python, consisted of a limited range
>> of items which could be learned very quickly
> 
> ROFL. Maybe that was true for Python when it was first invented. Today 
> it is not "a few simple things". Even just the core language, 

Python v1 was a good teaching language. v2 complicated it a bit
but it was still usable. v3 is no longer a good teaching language
(unless maybe you are teaching CompSci at university.)

In fact in v3 things are so complex that I seriously considered
dropping Python as the core language for my programming tutorial.
Until I started looking for an alternative, and there really isn't
anything much better. At least not that can also be used for real
projects once you've learned it.

But the sort of change that has made it complicated for beginners
is range(). range() used to be simple - it returned a list of numbers
in the range specified. The hardest thing to explain was why it
stopped one short of the upper limit. Now range returns a
"range object". Say what? How do explain a range object to a beginner?
And you can't avoid it because the name pops up in the interpreter.

And that's just one example, the language is now full of meta goodness
that makes it incomprehensible to beginners. In a teaching environment,
with a teacher present to answer questions, it's probably usable,
but for a self guided course it's increasingly inscrutable.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[David Lowry-Duda]

> In Norway, where I try to teach mathematics to highschoolers, 
> programming has recently entered the teaching of stem subjects.
> 
> Even if Python is my choice language for personal projects, I am not 
> certain it is the right language to use in a classroom context.
> ...
> I am not sure I agree that a language like Scheme or Logo or 
> Brainfuck, with their small number of building blocks, would be harder 
> to learn.

Does this mean that you also try to teach programming to highschoolers, 
or is there a different (maybe dedicated) teacher to that? What language 
do they use? And does it influence math education at all? (Coming from 
someone who sometimes tries to teach undergraduates about math).

- David Lowry-Duda
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Tarjei Bærland via Python-list]

Christian Gollwitzer writes:

> Am 16.02.21 um 06:36 schrieb dn:
>> Pascal's value as a teaching language was that it embodied many aspects
>> of structured programming, and like Python, consisted of a limited range
>> of items which could be learned very quickly (in contrast to PL/I's many
>> 'bells and whistles'). 
>
> ROFL. Maybe that was true for Python when it was first invented. Today 
> it is not "a few simple things". Even just the core language, anything 
> that's built into the interpreter if you leave out any standard 
> function, is enormous. To name a few: List comprehension, format 
> strings, iterator protocol, asynchronous programming, everything called 
> __dunderland. A minimal language with only very few basic rules, that 
> would be Scheme e.g. Of course, it doesn't mean that Scheme is easier to 
> program, but it is easier to write a compiler for it than for Python.
>
> That is a misundestanding often presented - a language that is simple in 
> the sense of having a few simple rules, is usually hard to use. (e.g. 
> Brainfuck). A language which is easy to use, often comes with a large 
> variety of building blocks, to give you the right tool to choose for the 
> job at hands (e.g. Python), and therefore is "complex".
>
>   Christian

In Norway, where I try to teach mathematics to highschoolers, programming has
recently entered the teaching of stem subjects.

Even if Python is my choice language for personal projects, I am not certain it
is the right language to use in a classroom context. My feeling is that Python
comes with way too much packed in, making it very hard for the students to get
to a level where they can sit down and be creative with their own
programming. You either guide them very, very deliberately, exposing piece by
piece of the language ... or you let them loose, having to explain the
difference in scoping between list comprehensions and for loops after three
weeks.

I am exaggerating ... a little.

I am not sure I agree that a language like Scheme or Logo or Brainfuck, with
their small number of building blocks, would be harder to learn.

To me, Python is the lego boxes from the early 2000s, where there were so many
specialized pieces that you felt that the original design might as well be the
only design.

Regards,
Tarjei
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Christian Gollwitzer]

Am 16.02.21 um 06:36 schrieb dn:

Pascal's value as a teaching language was that it embodied many aspects
of structured programming, and like Python, consisted of a limited range
of items which could be learned very quickly (in contrast to PL/I's many
'bells and whistles'). 


ROFL. Maybe that was true for Python when it was first invented. Today 
it is not "a few simple things". Even just the core language, anything 
that's built into the interpreter if you leave out any standard 
function, is enormous. To name a few: List comprehension, format 
strings, iterator protocol, asynchronous programming, everything called 
__dunderland. A minimal language with only very few basic rules, that 
would be Scheme e.g. Of course, it doesn't mean that Scheme is easier to 
program, but it is easier to write a compiler for it than for Python.


That is a misundestanding often presented - a language that is simple in 
the sense of having a few simple rules, is usually hard to use. (e.g. 
Brainfuck). A language which is easy to use, often comes with a large 
variety of building blocks, to give you the right tool to choose for the 
job at hands (e.g. Python), and therefore is "complex".


Christian

--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Christian Gollwitzer]

Am 15.02.21 um 21:37 schrieb Roel Schroeven:


So your claim is that your compiler is able to, or will be able to, 
compile any language just by specifying a small schema file. Great!


Do you maybe have a proof-of-concept? A simple language with a simple 
schema file to test the basic workings of your compiler, 


Here is the git repo:

https://github.com/i42output/neos

under languages/ you'll find different schema files.

Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Dan Stromberg]

On Mon, Feb 15, 2021 at 9:37 PM dn via Python-list 
wrote:

> On 16/02/2021 17.57, Dan Stromberg wrote:
> > On Mon, Feb 15, 2021 at 8:52 PM Igor Korot  wrote:
> >
> >> Hi, guys,
> >> Let me try to throw in another one - PL/1.
> >> This guys used to be very popular with the accounting community...
> >>
> >
> > Actually PL/I is basically proprietary Pascal - from IBM.  My Intro Comp
> > Sci classes at the University of Cincinnati were in PL/I, because IBM had
> > an office not far from the University, and they liked to hire interns
> from
> > UCinci.  I was told that otherwise the classes would've been in Pascal.
>
>
> Might a coincidence of location have been conflated with language
> development?
>
Nah.  All 3 are in the Algol family: Algol, Pascal, PL/I.

I'll grant you that PL/I is a "big language" though.  It didn't rely on
external libraries as much as it should have.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[dn via Python-list]

On 16/02/2021 17.57, Dan Stromberg wrote:
> On Mon, Feb 15, 2021 at 8:52 PM Igor Korot  wrote:
> 
>> Hi, guys,
>> Let me try to throw in another one - PL/1.
>> This guys used to be very popular with the accounting community...
>>
> 
> Actually PL/I is basically proprietary Pascal - from IBM.  My Intro Comp
> Sci classes at the University of Cincinnati were in PL/I, because IBM had
> an office not far from the University, and they liked to hire interns from
> UCinci.  I was told that otherwise the classes would've been in Pascal.


Might a coincidence of location have been conflated with language
development?


PL/I (note the Roman "one") was developed out of the IBM System/360
effort, ie one computer architecture for all types of users (cf
different computers for 'commercial' and 'scientific' clients - which
you can see again today in AWS' range of compute options, for example).
It was to be 'one language to rule them all'.

Initially, it was based on FORTRAN. We joked that it took all of the bad
parts of FORTRAN and COBOL and mashed them into a single ... language.
However, like many such efforts, it attempted to take 'the best' from
many sources (including ALGOL).

Sadly, (maybe) it, like Ada (another attempt to be 'all things to all
men') only ever really existed in a niche market.


Pascal, named after the mathematician and philosopher the French credit
with 'inventing the computer', was developed in the European world -
which even back-then had marked differences in thinking to the American
approach/domination of computing.

Prof Niklaus Wirth published a seminal book "Algorithms + Data
Structures = Programs" (which I seem to have lost, somewhere in the
mists of time). I don't think it gave examples in Pascal, but it did use
a pseudo-code/-language which illuminated various ideas and ways of
developing programmatic solutions. As I recall, it (and Pascal) was very
ALGOL like, and thus heavily influenced by "stack architecture" (cf
IBM's collections of "registers" in an ALU). Certainly the language was
clearly based upon ALGOL-60. Clearly it led to the refinement and/or
development of Pascal.

Pascal's value as a teaching language was that it embodied many aspects
of structured programming, and like Python, consisted of a limited range
of items which could be learned very quickly (in contrast to PL/I's many
'bells and whistles'). Thus, once absorbed, learning attention could be
directed to ComSc/algorithms + data!

Pascal was also very efficient, to compile and to execute, which made it
a competent fore-runner of Micro-Python (etc) in the micro and
single-board computer arenae/arenas.

Without Python, I think I'd prefer to use (an updated) UCSD-Pascal or
Borland Turbo-Pascal to this very day! PL/I, not so much - even on a
mainframe project!
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Dan Stromberg]

On Mon, Feb 15, 2021 at 8:52 PM Igor Korot  wrote:

> Hi, guys,
> Let me try to throw in another one - PL/1.
> This guys used to be very popular with the accounting community...
>

Actually PL/I is basically proprietary Pascal - from IBM.  My Intro Comp
Sci classes at the University of Cincinnati were in PL/I, because IBM had
an office not far from the University, and they liked to hire interns from
UCinci.  I was told that otherwise the classes would've been in Pascal.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Igor Korot]

Hi, guys,
Let me try to throw in another one - PL/1.
This guys used to be very popular with the accounting community...

Thank you.

On Mon, Feb 15, 2021 at 9:51 PM Alan Gauld via Python-list
 wrote:
>
> On 15/02/2021 22:24, Roel Schroeven wrote:
> > Grant Edwards schreef op 15/02/2021 om 21:59:
> >> On 2021-02-15, Roel Schroeven  wrote:
> >>
> >>> Is it your intention to not only compile procedural and object-oriented
> >>> languages, or also functional languages such as Haskell, Ocaml, Scheme?
> >>
> >> And Prolog!
> >
> > Ha, yes, that one was the next one I thought about, but in the I decided
> > to leave it out.
>
> Yes, Prolog is definitely different. When I was at Uni' in the mid 80s
> we all got taught Prolog because the Japanese had promised to produce
> a 5th generation computer by 1990 and it would be based on Prolog.
> We're still waiting, but in the meantime we got the internet and GUIs.
>
> Looks like Sun got it right - "the network is the computer"...
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Alan Gauld via Python-list]

On 15/02/2021 22:24, Roel Schroeven wrote:
> Grant Edwards schreef op 15/02/2021 om 21:59:
>> On 2021-02-15, Roel Schroeven  wrote:
>>
>>> Is it your intention to not only compile procedural and object-oriented
>>> languages, or also functional languages such as Haskell, Ocaml, Scheme?
>>
>> And Prolog!
> 
> Ha, yes, that one was the next one I thought about, but in the I decided 
> to leave it out.

Yes, Prolog is definitely different. When I was at Uni' in the mid 80s
we all got taught Prolog because the Japanese had promised to produce
a 5th generation computer by 1990 and it would be based on Prolog.
We're still waiting, but in the meantime we got the internet and GUIs.

Looks like Sun got it right - "the network is the computer"...

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Dan Stromberg]

On Mon, Feb 15, 2021 at 3:25 PM Grant Edwards 
wrote:

> On 2021-02-15, Avi Gross via Python-list  wrote:
> Of all the languages I've used, Prolog was by far the hardest to get
> my head around. The dialect I used the most (which still wasn't much)
> was part of Digitalk's Smalltalk system. I don't recall if Digitalk
> Prolog was written entirely in Smalltalk, or if it was just integrated
> into the Smalltalk system as an opaque object.
>
I actually found Prolog to be a lot like /usr/bin/make.

It's an OK language if everything you need to do can be solved well using a
depth first search. Otherwise, it kind of gets in the way.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Grant Edwards]

On 2021-02-15, Avi Gross via Python-list  wrote:

> Haven't thought about Prolog in a LOOONG time but it had some wild
> twists on how to specify a problem that might not be trivial to
> integrate with other languages as our now seemingly censored person
> with much delusion of grandeur suggests. It is a language that does
> not specify what to do but more what rules an answer must abide by.

Of all the languages I've used, Prolog was by far the hardest to get
my head around. The dialect I used the most (which still wasn't much)
was part of Digitalk's Smalltalk system. I don't recall if Digitalk
Prolog was written entirely in Smalltalk, or if it was just integrated
into the Smalltalk system as an opaque object.

--
Grant

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Roel Schroeven]

Grant Edwards schreef op 15/02/2021 om 21:59:

On 2021-02-15, Roel Schroeven  wrote:


Is it your intention to not only compile procedural and object-oriented
languages, or also functional languages such as Haskell, Ocaml, Scheme?


And Prolog!


Ha, yes, that one was the next one I thought about, but in the I decided 
to leave it out.


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Buck Evan]

On Thu, Feb 11, 2021 at 1:49 PM dn via Python-list 
wrote:

> When I first met it, one of the concepts I found difficult to 'wrap my
> head around' was the idea that "open software" allowed folk to fork the
> original work and 'do their own thing'. My thinking was (probably)
> "surely, the original is the authoritative version". Having other
> versions seemed an invitation to confusion and dilution.
>
> However, as soon as (open) software is made available, other people
> start making it 'better' - whatever their own definition of "better".
>
> Yes, it is both a joy and a complication.
>
> ...
>
> Wishing you well. It seems (to (neos-ignorant) me at least) an ambitious
> project. There are certainly times when 'execution speed' becomes a
> major criteria. Many of us will look forward to (your development of) a
> solution. Please let us know when it's ready for use/trials...
>

Well put! Thank you for this thoughtful and informative message. You
obviously put substantial work into it.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New Python implementation

[Avi Gross via Python-list]

Grant,

Haven't thought about Prolog in a LOOONG time but it had some wild twists on
how to specify a problem that might not be trivial to integrate with other
languages as our now seemingly censored person with much delusion of
grandeur suggests. It is a language that does not specify what to do but
more what rules an answer must abide by. 

Perhaps he should go to work for the Star Trek Federation and improving
their Universal Translator that can learn any alien language in about two
sentences. I am sure he will tell us it would be trivial for him or her
along with other Fibbles he/she tells.

Am I the only one who found it amusing, back to Python, that a recent attack
on Python was about a fairly trivial problem to solve in most languages, let
alone Python. Toy language does not normally apply to a fairly mature
language, regularly extended to do many things in many ways, unless anything
not fully standardized is a toy. I consider many such to become toys as they
end up near the end of their lives and hard to extend further. 

I think the question was as simple as how to find the first period in a
string (assuming it exists?) and replace it with an @ and not subsequent
ones. Not very challenging even using very basic commands in a computer
language. Computing 101?

Can you name any language where that is hard to do from scratch? Sure, many
will provide a ready-made function that does it in one line of code (or a
partial line) but most languages let you use something like a loop that lets
you look at one letter of a "string" variable at a time and perhaps copy it
to a new one. A logical variable can be set so you conditionally replace
just the first instance. Whether changed in place or in a copy, it seems
trivial.

So why snide comments that you need more than a toy language when this is
precisely what is doable even in a toy language, but so commonly done that
many better languages (and Python definitely is included) give you an
assortment of built-in functionality to make it easy, and then dozens of
other ways in modules you can load ...

Now there are fairly complex things that a user cannot easily build from
scratch or find a ready-made solution. There may well be say a PROLOG
program that is simple and elegant and very hard to solve using Python, let
alone a toy language.

To me, all languages are toys, albeit for different age/experience groups.

-Original Message-
From: Python-list  On
Behalf Of Grant Edwards
Sent: Monday, February 15, 2021 4:00 PM
To: python-list@python.org
Subject: Re: New Python implementation

On 2021-02-15, Roel Schroeven  wrote:

> Is it your intention to not only compile procedural and 
> object-oriented languages, or also functional languages such as Haskell,
Ocaml, Scheme?

And Prolog!

--
Grant



--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Igor Korot]

And C.

Thank you.


On Mon, Feb 15, 2021, 3:56 PM Grant Edwards 
wrote:

> On 2021-02-15, Roel Schroeven  wrote:
>
> > Is it your intention to not only compile procedural and object-oriented
> > languages, or also functional languages such as Haskell, Ocaml, Scheme?
>
> And Prolog!
>
> --
> Grant
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Grant Edwards]

On 2021-02-15, Roel Schroeven  wrote:

> Is it your intention to not only compile procedural and object-oriented 
> languages, or also functional languages such as Haskell, Ocaml, Scheme?

And Prolog!

--
Grant



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Roel Schroeven]

Mr Flibble schreef op 15/02/2021 om 0:32:

On 14/02/2021 23:00, Christian Gollwitzer wrote:
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.


So your claim is that your compiler is able to, or will be able to, 
compile any language just by specifying a small schema file. Great!


Do you maybe have a proof-of-concept? A simple language with a simple 
schema file to test the basic workings of your compiler, like your 
neoscript or perhaps something like a minimal variant of Python? I'm 
curious what such a schema file would like look, and especially how you 
use it to not only specify the syntax but also the semantics of the 
various languages.


Is it your intention to not only compile procedural and object-oriented 
languages, or also functional languages such as Haskell, Ocaml, Scheme?


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Abdur-Rahmaan Janhangeer]

After reading the thread i'm like: where can i try it out ...

On Thu, 11 Feb 2021, 16:38 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).
>
> 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() = 

Re: New Python implementation

[Dan Stromberg]

On Sun, Feb 14, 2021 at 3:05 PM 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.
>
Hopefully CFFI, not libffi:  https://cffi.readthedocs.io/en/latest/

I'm not saying that it is unfeasible or very difficult. I'm saying that
> it is a lot of work


It is.

However, IronPython and Shedskin do not have a full Python standard
library.  I'd still call them "Python".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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: New Python implementation

[Christian Gollwitzer]

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.



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, )


Christian

--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Igor Korot]

Of course not.
Its like saying "JAVA sucks" without any citation or proof.

And I'm just curious  -  why not use C directly, since he is so great
developer for whatever task he needs to do?

Fun time reading... Hope it will continue.

Thank you.


On Sun, Feb 14, 2021, 1:22 AM Christian Gollwitzer  wrote:

> Am 14.02.21 um 01:19 schrieb Chris Angelico:
> > 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.
>
> This is a message to all commentators on this list: Mr Flibble is known
> on comp.lang.c++ for making very confident claims and announcements of
> the greatest software product since the invention of the wheel.
>
> He is indeed a capable C++ programmer, but he frequently underestimates
> the work needed for such big projects so that you can easily count them
> as vaporware for now. For example, he created his own "cross-platform,
> modern" GUI toolkit neoGFX[*] just because he thinks that QT is bad (it
> uses non-standard C++). Of course, cross-platform for now means it runs
> on Windows and anything else is far into the future, also the optical
> design looks modern / OK right now, but will look outdated soon. There
> is no evidence that any other designer will join the project to keep the
> look up to date.
>
> 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.
>
> So my advice is to waste your time in this discussion if you find it
> entertaining, but don't expect to have a usable product soon.
>
> Best regards,
>
>Christian
>
> [*] https://github.com/i42output/neoGFX
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Christian Gollwitzer]

Am 14.02.21 um 01:19 schrieb Chris Angelico:

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.


This is a message to all commentators on this list: Mr Flibble is known 
on comp.lang.c++ for making very confident claims and announcements of 
the greatest software product since the invention of the wheel.


He is indeed a capable C++ programmer, but he frequently underestimates 
the work needed for such big projects so that you can easily count them 
as vaporware for now. For example, he created his own "cross-platform, 
modern" GUI toolkit neoGFX[*] just because he thinks that QT is bad (it 
uses non-standard C++). Of course, cross-platform for now means it runs 
on Windows and anything else is far into the future, also the optical 
design looks modern / OK right now, but will look outdated soon. There 
is no evidence that any other designer will join the project to keep the 
look up to date.


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.


So my advice is to waste your time in this discussion if you find it 
entertaining, but don't expect to have a usable product soon.


Best regards,

  Christian

[*] https://github.com/i42output/neoGFX
--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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

[Mr Flibble]

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

[Alan Gauld via Python-list]

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?

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.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Grant Edwards]

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.





-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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

[Mr Flibble]

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

[Mr Flibble]

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

[Mr Flibble]

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

[Ned Batchelder]

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.

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New Python implementation

[Avi Gross via Python-list]

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  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 out

Re: New Python implementation

[Chris Angelico]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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

[Mr Flibble]

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

[Igor Korot]

Hi,
But most importantly - what is the reason for this ?
I mean - what problems the actual python compiler produce?

Thank you.


On Sat, Feb 13, 2021, 3:26 PM Alan Gauld via Python-list <
python-list@python.org> 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?
>
> 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?
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Alan Gauld via Python-list]

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?

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?

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Terry Reedy]

On 2/12/2021 4:42 PM, Mr Flibble wrote:

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.


https://pypi.org/project/neos/ shows
import neos.makers as makers
import neos.cls as cls

When you wrote 'neos' without qualification right after the neos package 
url, I though you were referring to the package, not your neos.  My 
mistake and your unclear writing.


--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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

[Alan Gauld via Python-list]

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?

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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

[Mr Flibble]

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

[Terry Reedy]

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?


--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Alan Gauld via Python-list]

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?

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

While a universal compiler is  certainly an interesting
and challenging project I'm not sure how much it tells us
about existing Python implementations.

On the other hand, if you are planning on rewriting the
existing interpreter in something other than C, what
is that something?

> 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...

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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

[Mr Flibble]

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

[Greg Ewing]

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.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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

[Dan Stromberg]

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/
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: New Python implementation

[Avi Gross via Python-list]

I may be the only one who does not deal well with a condescending attitude.

I have to wonder what international standards body ever completes a task in 
finite time, only to find the real world has moved on. Having standards can be 
a great idea. When the standard does not properly describe any implementations 
either because some leave out things and others have partial or enhanced 
implementations, then it is just a goal.

May I ask if the proposed product itself needs standardization? Since it claims 
to support many (or amusingly ANY) language fully, perhaps they can share their 
Ada or other version before they do Python, or are they working on all of them 
at once?

Realistically, many languages have chosen various paths and a model that 
captures them all will have to be fairly complex and perhaps needlessly 
complex. Does it need multiple ways to deal with issues like scope and perhaps 
keep track of that if a program crosses several boundaries? Will it be able to 
handle something like an R program running  a package that allows a parallel 
running of a Python program as they work jointly on the same or copied data 
structures? I have been writing those lately and in the future may incorporate 
additional languages to take advantage of the strengths and features of each 
while avoiding the weaknesses or missing aspects of another.

Anyone who considers the task specified to be a small problem is either 
brilliant or perhaps not well informed.

If they can do what they say well, great. But I have seen other such attempts 
such as finding a way to translate between word processor formats that try to 
deal with overlapping but different concepts and do imperfect translations. 
That may of course not be relevant here if what is produced is code that runs 
and yet follows the expected rules as if it was being interpreted.
But a more pleasant attitude may make the same points, not that I am sure what 
those are and what is being asked. It sounds more like being told.

-Original Message-
From: Python-list  On 
Behalf Of Mr Flibble
Sent: Thursday, February 11, 2021 1:15 PM
To: python-list@python.org
Subject: 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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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

[Dan Stromberg]

On Thu, Feb 11, 2021 at 10:21 AM Mr Flibble 
wrote:

> 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.
>
I'm inclined to agree, though Python has done surprisingly well at
fostering multiple implementations despite having a reference
implementation for so long.

The thing it'd probably help the most with, is slowly down the rate of
change in the language.  The Core Devs seem to want to improve CPython
rapidly, which is not great for the many other implementations - EG Jython
and IronPython.  Also, "improvements" in CPython are frequently tending
toward featuritis, since the complexity of a language tends to grow with
the square of its feature count.

Does your project have a name yet?  I'd like to follow it through google
alerts or an announcement mailing list.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[dn via Python-list]

On 12/02/2021 08.53, Chris Angelico wrote:
> On Fri, Feb 12, 2021 at 6:47 AM dn via Python-list
>  wrote:
>> 3
>> My mind is whirling in an attempt to understand "show me a better time".
>> Does this perhaps indicate that @Chris' social life leaves something to
>> be desired? Are Python-nerds really the ones to turn-to for dating
>> advice, or is that not what @Chris means by "(having) a good time"?
> 
> LOL! I was referring to the fact that my demonstration snippet
> included a rudimentary timing bracket, and that, if existing Python
> implementations are indeed abysmally slow, it should be possible to
> run the same code on a different interpreter and get a lower number -
> a "better" time being shorter.


Agreed.

I've been 'bitten' by running 'the same' interpreter on different
hardware/configs and finding that one part of the program[me] ran faster
on the dev-machine, and another part faster on the prod-box. Felt a bit
like a no-win situation! Timing was an important contribution. However,
needing to perform same in-situ was a surprise. 'Gotcha'!

There are a lot of variables in the efficiency-game. It's not completely
cut-and-dried to say this, but as a general rule-of-thumb one does not
select Python for applications/components which have significant
execution-time constraints/requirements. However, Python is rarely
bettered when it comes to developer-time! Horses for courses...


As to being outrageously cheeky: even if COVID travel-restrictions have
been lifted, knowing the Tasman Sea remains between us,
allowed/emboldened me to go for the prize(?) for finding at least some
word-play to laugh-about in this whole conversation.

PS my version of bravery is that if you come after me carrying a big
stick, I shall run in the opposite direction - very quickly!

PPS speaking of travel: have you taken advantage of any of the
"vouchers" offered by your (Fed?State) government as an economic
stimulus/recovery for the hospitality industry?
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Chris Angelico]

On Fri, Feb 12, 2021 at 6:47 AM dn via Python-list
 wrote:
> 3
> My mind is whirling in an attempt to understand "show me a better time".
> Does this perhaps indicate that @Chris' social life leaves something to
> be desired? Are Python-nerds really the ones to turn-to for dating
> advice, or is that not what @Chris means by "(having) a good time"?

LOL! I was referring to the fact that my demonstration snippet
included a rudimentary timing bracket, and that, if existing Python
implementations are indeed abysmally slow, it should be possible to
run the same code on a different interpreter and get a lower number -
a "better" time being shorter.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[dn via Python-list]

On 12/02/2021 07.14, Mr Flibble wrote:
> 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:

> I am starting work on creating a new Python implementation from
> scratch
... (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...
>>>
>>> I am not particularly interested in any of the existing
>>> implementations as they bear no relation to the design of my language

...not being standardized; those steering
>>> the language need to grow a pair and get Python standardized
>>> preferably as an ISO Standard.
...
> 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


When I first met it, one of the concepts I found difficult to 'wrap my
head around' was the idea that "open software" allowed folk to fork the
original work and 'do their own thing'. My thinking was (probably)
"surely, the original is the authoritative version". Having other
versions seemed an invitation to confusion and dilution.

However, as soon as (open) software is made available, other people
start making it 'better' - whatever their own definition of "better".

Yes, it is both a joy and a complication.


Such is contrary to the principle of "standards". At its extreme, a
standard says there is only one way to do the-whatever. This is why many
'standard programming languages' then offer the 'out' of having various
levels of 'standard'. For example, despite being one of the longest
standardised languages, many COBOL implementations achieve only part of
"the standard" - and one has to dive (deep) into the 'small print' to
establish which 'bits' are in their particular 'pick and mix'. Yet, they
still (quite legally) refer to their product as 'standard'!

The second issue with standards is the time and effort it takes to
achieve an agreement and thus reach the point of publishing.

A third issue, and possibly the reason why attempting a standard is a
"losing battle", is that programming and languages are in a constant
state of flux - we call it "ongoing development". Even though Python
v3.10 is reaching a state of anticipation, there are organisations and
libraries that still work using Python 2. Thus, and HTML/"the browser
wars" is an example of this, as fast as a standard is discussed, someone
(even those contributing to said standards) is doing his/her best to
build 'more advanced features' beyond the standard... "Standards" and
'driving development forward' are at least in tension, at worst,
complete-opposites.

Standards, like "waterfall" project specifications, cannot be 'cast in
stone' because the world keeps changing. Standards are insufficiently
agile and Agile!


Whereas the likes of COBOL had "owners", if not as a point-of-fact, at
least in terms of (commercial) 'might' and 'power', Python has its
"Python Software Foundation" (https://www.python.org/psf/). Please feel
free to approach that group to talk about 'what is Python' and
'standardisation'.

Rather than a process of "imposing" a standard, Python has a more 'grass
roots' democratic process which involves PEPs (Python Enhancement
Proposal). These are 'great ideas', even intentions-to-build or
proofs-of-concept, documented, and presented for the community to
consider. The better ones make it through and become part of the
language and its eco-system.

Has the above proposal started on that 'standards path'? Is it
'documented', or merely an idea?


Another aspect of open source is its 'meritocracy' - respect for those
who have demonstrated their abilities (and commitment). Certain names
'crop-up' on PEPs, and more tellingly, on "accepted" PEPs.

Of the three names appearing in this thread, which two have been seen
before, and have contributed to PEPs or to this list, in the past?

Is there a choice to 'stand on the shoulders of giants', or to 'walk all
over ... in hob-nailed boots'? Has this conversation illustrated
respect, or (perhaps unintentionally) torn-down others' sweat-and-tears
without offering something (better) for consideration/approval/use? Is
there any proof that you/I/someone-else can actually "do" better? An
applicable saying is "the proof is in the pudding". So, rather than
claims, shouldn't we be dealing with facts, eg system-A does better than
system-B under the following conditions?


A community comprises people who 

Re: New Python implementation

[Mr Flibble]

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

[Paul Bryan]

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.

Paul

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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

[Mr Flibble]

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

[Chris Angelico]

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.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Chris Angelico]

On Fri, Feb 12, 2021 at 4:52 AM Mr Flibble
 wrote:
>
> 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.
>

Okay, cool, then I misunderstood the point of neoscript (I thought you
would compile Python to neoscript and then neoscript to binary).

As Dan says, go for it, give it a go. I think it'll give you a very
good demonstration of how CPython, and especially PyPy, are actually
highly performant languages :)

> You are timing the arithmetic library rather than the interpreter.

Hmm, I didn't call on any library functions. The crucial and
time-consuming operations were entirely implemented using operators on
constants.

(I also deliberately reused the name "time" in multiple ways, just to
stress-test anything that tries to restrict data types.)

In any case, it's not Python if it can't handle arbitrarily large
numbers. Python is an excellent language for mathematics.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Mr Flibble]

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

[Mr Flibble]

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

Re: New Python implementation

[Dan Stromberg]

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.

You may be interested in the approaches of Pypy, Cython, Shedskin and
Nuitka.

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.

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.

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.

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.

Good luck!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Chris Angelico]

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,
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?

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.

> 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?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list