Making a Python interpreter in 1024 bytes
101–110 of 120 posts
Re: Making a Python interpreter in 1024 bytes
#102Earlier quoted context omitted.
By that standard, this is totally over-engineered. Just hardcode it.
Good idea. Write a python script, and then code the minimal c interpreter possible to make that specific script work, utilizing the script itself as string reference (and any other way one can manage to utilize it in the interpreter itself).
Re: Making a Python interpreter in 1024 bytes
#103The author lost me right away. >> I started with the most basic code I could think of: 1 + 2 OK, how did you fit that into 512/1024 bytes??? Did you try print(3 * * 1000)?
That said, if I was building a small ugly toy Python implementation, I would probably also not implement long integers. Or the power operator. At least not in the first iteration.
Re: Making a Python interpreter in 1024 bytes
#104Interesting, especially when you know they used to ship a complete BASIC interpreter in less than 32 KB in the past..
Re: Making a Python interpreter in 1024 bytes
#105I don't understand the point of this. If they wanted to make a Python interpreter, why didn't they just ask an AI to do it?
Re: Making a Python interpreter in 1024 bytes
#106Earlier quoted context omitted.
I like python subset . However, many don't see it that way.
It's not a subset of python. For instance this program works in this interpreter, but not in python: fxx i in rxxxx(10): pxxxx(i)
Re: Making a Python interpreter in 1024 bytes
#107Interesting, especially when you know they used to ship a complete BASIC interpreter in less than 32 KB in the past..
Re: Making a Python interpreter in 1024 bytes
#108Interesting, especially when you know they used to ship a complete BASIC interpreter in less than 32 KB in the past..
Re: Making a Python interpreter in 1024 bytes
#109I don't understand the point of this. If they wanted to make a Python interpreter, why didn't they just ask an AI to do it?
Why do anything. Why even do the AI version of this. Probably curiosity. If there's an AI version of code golfing, I'd be curious to see it. Maybe they golf worse or much better than us meat bags.
Re: Making a Python interpreter in 1024 bytes
#110Earlier quoted context omitted.
Truly, indentation is the moveable feast. Even on ancient typewriters, you could adjust your tabs depending on what you are doing. And people who have dissimilar tastes in tabbage will certainly write stuff that doesn't appear that great in each others' editors. > What business does a compiler have worrying about display width? The business of the compiler is to insure that code that it deems acceptable is not ambigu…
> people who have dissimilar tastes in tabbage will certainly write stuff that doesn't appear that great in each others' editors. Not for code, no. People will do that for spaces. For tabs it's a 1:1 correspondence with indentation level with any visual adjustments done by the editor. Reading between the lines I suspect you are operating with the flawed idea of using tabs for alignment. One must never use tabs for al…
No, I vehemently disagree with most of what you wrote. We certainly agree on basic things that tabs do not have a fixed width, and that a "compiler never has any control over (source code) display." (What a bizarre idea; whoever said it did?)
> I'd dispute that the compiler needs to care about where your editor places the left margin.
This isn't just about editors. I well remember green-bar.
> As long as the prefix remains consistent across a given level of indentation then there's no cause for concern.
No, if someone uses 8 character tabs, and then wants to space over half a tab for visual reasons, things completely break. We probably agree that's wrong, and that the answer is some variant of the answer to "Doc, it hurts when I do this" and I maintain the answer is to dispense with tabs completely.
Look the tabs-vs-spaces war is as old as the big-endian/little-endian war, and I am probably older than you. We'll probably never convince each other of any of this. Have a good day.