Sector C might have some insights into how to make this even smaller or more featurefull. It has some interesting hacks. https://xorvoid.com/sectorc.html
Making a Python interpreter in 1024 bytes
111–120 of 120 posts
Re: Making a Python interpreter in 1024 bytes
#112Earlier quoted context omitted.
> 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…
> I'll instead observe that it seems to follow from what you said that you actually agree with me. As long as the prefix remains consistent across a given level of indentation then there's no cause for concern. 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 bi…
I could not successfully search for green-bar; I was turning up a brand of rebar made from fiberglass and various vegan bars and restaurants in different cities... but nothing related to coding or text editing. Do you have a link handy that would explain what the green-bar you're referring to is? Or, failing that, could I ask you for a brief (one or two sentences) explanation/summary? Would be appreciated. (UPDATE: Figured it out, see P.S. below)
BTW, if you've been reading my responses you'll see that I've landed in the same "get rid of tab characters" camp, because while they're nice in theory, they cause pain in practice.
EDIT to add this P.S.: Figured it out. I eventually came across https://elpa.gnu.org/packages/greenbar.html which mentioned the alternating white and green bands of color on old printer paper. I remember those, but I never heard them called "green-bar" which is why I couldn't place the term.
Re: Making a Python interpreter in 1024 bytes
#113Earlier quoted context omitted.
That's the spirit! (Slightly less silly: the folks at https://github.com/faster-cpython are doing great work, too.)
Are they still? I thought this project was no longer really active.
I'm not actually sure about this specific project, but people are still hard at work making CPython faster. Many of them the same people as where in this project.
Re: Making a Python interpreter in 1024 bytes
#114Earlier quoted context omitted.
If you are willing to sacrifice performance, you can implement dicts via linear lookup in much less code than a proper hash table.
Because Python dicts guarantee iteration order is the same as insertion order ( https://docs.python.org/3.7/library/stdtypes.html#typesmappi... ) Python dicts aren’t just proper hash tables. Because of that it wouldn’t surprise me much if that sped up some standard benchmarks, for example ones parsing lots of small json objects into dictionaries.
I would be very surprised if my silly suggestion would speed up some standard benchmarks, because even if you do insertion only you have to do a linear probe to find duplicates.
The way Python guarantees to preserve insertion order is pretty clever and doesn't really cost you much at runtime. They pretty much only added this guarantee because it was basically free to offer given the implementation choices they already wanted to make for other reasons.
Re: Making a Python interpreter in 1024 bytes
#115Earlier quoted context omitted.
> I'll instead observe that it seems to follow from what you said that you actually agree with me. As long as the prefix remains consistent across a given level of indentation then there's no cause for concern. 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 bi…
I could not successfully search for green-bar; I was turning up a brand of rebar made from fiberglass and various vegan bars and restaurants in different cities... but nothing related to coding or text editing. Do you have a link handy that would explain what the green-bar you're referring to is? Or, failing that, could I ask you for a brief (one or two sentences) explanation/summary? Would be appreciated. ( UPDATE :…
Sorry, didn't mean to send anybody on a wild goose chase. Glad you found a reference, and also somewhat glad that the reference says that the the term was "often" used -- maybe I'm not quite ready for the dementia ward yet?
> BTW, if you've been reading my responses you'll see that I've landed in the same "get rid of tab characters" camp, because while they're nice in theory, they cause pain in practice.
I had to go back and look. You obviously have more patience than I do for this sort of debate. :-)
I don't think people who fall down on the tab side of the debate have thought things through. Tabs are about alignment, of course, but why did we transport the typewriter alignment to printers? (Many printers had escape sequences that let you set the tab spacing.) Arguably, it was to save computation time, storage space, data transmission time, and even (for faster printers) to make your print job come out faster. People forget how precious all those were.
Today, a tab key on a keyboard is a perfectly cromulent method to get to your next alignment boundary, but there's a reason that every single usable code editor lets you program the tab key to emit a certain number of spaces.
Re: Making a Python interpreter in 1024 bytes
#116Earlier quoted context omitted.
I like python subset . However, many don't see it that way.
You're right, mathematically it's undeniably true. However... One could imagine an even smaller subset interpreter. It's an interpreter for a subset of Python, consisting only of the programs that print "Hello World". Since it doesn't do any error checking, for all other programs the output is undefined. Implementing it is very simple: Just ignore the input file, and print "Hello World". As a bonus, it's an interpret…
This has actually been done:
https://esolangs.org/wiki/Hello
While quines (programs that print their own source code) aren't possible in Hello, there's a version that makes it possible:
https://esolangs.org/wiki/Hello_Plus_Plus
And if you say the original isn't good enough because it can't do anything else... well, esolangs have you covered there too:
https://esolangs.org/wiki/HQ9_Plus
(It should be noted that these are all joke esolangs. There are actual languages on the wiki that are very interesting though - I would definitely recommend you take them out!)
Re: Making a Python interpreter in 1024 bytes
#117Earlier quoted context omitted.
I could not successfully search for green-bar; I was turning up a brand of rebar made from fiberglass and various vegan bars and restaurants in different cities... but nothing related to coding or text editing. Do you have a link handy that would explain what the green-bar you're referring to is? Or, failing that, could I ask you for a brief (one or two sentences) explanation/summary? Would be appreciated. ( UPDATE :…
Sorry, didn't mean to send anybody on a wild goose chase. Glad you found a reference, and also somewhat glad that the reference says that the the term was "often" used -- maybe I'm not quite ready for the dementia ward yet? > BTW, if you've been reading my responses you'll see that I've landed in the same "get rid of tab characters" camp, because while they're nice in theory, they cause pain in practice. I had to go…
I'm sure it was often used, but I spent a lot of my childhood and early adolescence in the non-English-speaking country where my father worked for many years. So "green-bar paper" is not the only apparently-commonly-used English term that I had to learn later in life, since when I was growing up, I heard English mostly from my parents and coworkers, and that's not a term that they happened to use a lot. So although it's my native tongue, I'm constantly finding holes in my vocabulary — usually 80's or 90's slang terms that my (extensive) reading habit couldn't teach me because most of the English-language books I had access to in the 80's or 90's were published in the 1970's or earlier.
In other words, don't take my not knowing a term as evidence that it wasn't commonly used; my childhood was unusual by the standards of most Americans. :-)
Re: Making a Python interpreter in 1024 bytes
#118Earlier quoted context omitted.
Because Python dicts guarantee iteration order is the same as insertion order ( https://docs.python.org/3.7/library/stdtypes.html#typesmappi... ) Python dicts aren’t just proper hash tables. Because of that it wouldn’t surprise me much if that sped up some standard benchmarks, for example ones parsing lots of small json objects into dictionaries.
I would be very surprised if my silly suggestion would speed up some standard benchmarks, because even if you do insertion only you have to do a linear probe to find duplicates. The way Python guarantees to preserve insertion order is pretty clever and doesn't really cost you much at runtime. They pretty much only added this guarantee because it was basically free to offer given the implementation choices they alread…
> because even if you do insertion only you have to do a linear probe to find duplicates.
Yes, but that is almost free for the first insert and need not be much work for the second and third. Also, that naive implementation will use less memory.
The kind of benchmark I was thinking of are the “large_random” and “Kostyra” ones from https://github.com/simdjson/json_benchmark_results that parse arrays of small objects with very short keys.
For such objects, as I said, it wouldn’t surprise me _much_ if the extremely naive implementation were faster.
Re: Making a Python interpreter in 1024 bytes
#119Earlier quoted context omitted.
You're right, mathematically it's undeniably true. However... One could imagine an even smaller subset interpreter. It's an interpreter for a subset of Python, consisting only of the programs that print "Hello World". Since it doesn't do any error checking, for all other programs the output is undefined. Implementing it is very simple: Just ignore the input file, and print "Hello World". As a bonus, it's an interpret…
This has actually been done: https://esolangs.org/wiki/Hello While quines (programs that print their own source code) aren't possible in Hello, there's a version that makes it possible: https://esolangs.org/wiki/Hello_Plus_Plus And if you say the original isn't good enough because it can't do anything else... well, esolangs have you covered there too: https://esolangs.org/wiki/HQ9_Plus (It should be noted that these…
> I would definitely recommend you take them out!
I obviously meant "check them out" here. I was using speech recognition and it clearly misheard what I said.
I'd edit, but it's been long enough since I posted that HN isn't offering that option for this comment any more.
Re: Making a Python interpreter in 1024 bytes
#120Earlier quoted context omitted.
And, there are multiple white space symbols! is different than So you also have to track the actual sequence of counts of white space used for each level, rather than just a simple count.
It's just a stack containing strings at the end of the day. Really not a big deal.
Care to give it a go? I'm curious to see how many bytes of the 1024 bytes your implementation would eat up.