This is really cool! It's so fun to see what you can achieve and what's optional. I have seen the 'single character variable' limitation in some other minilangs before, but using the source itself as the target of function calls and loops is new to me. It does make a lot of sense but I wouldn't have thought of that.
For those who actually need something like this in production, there is Snek: <https://sneklang.org/> “Snek is a tiny embeddable language targeting processors with only a few kB of flash and ram.”
Yes, but compiling or modifying Snek from source is very challenging. I wish it was one single C file for an example base like Posix, instead of many files for many platforms plus a custom parser in Python (Lola).
Or you just forbid mixing spaces and tabs in the same indentation sequence, the way most whitespace-sensitive languages seem to end up doing. Or you make a slightly more reasonable rule: spaces may follow tabs, but no tabs may follow a space. That's at least unambiguous.
But it also feels arbitrary and annoyingly restrictive. On top of that there are at least 25 whitespace codepoints in UTF. Should your language really be opinionated about when, where, and in what order (for example) the "mongolian vowel separator" appears?
How so? In what scenario would you ever need to use a sequence like <tab><space><tab> in indentation in your source code? Let alone using esoteric Unicode whitespace characters for indentation. I think it is perfectly reasonable for the language to make the restriction that indentation must be either all tabs, tabs followed by spaces, or all spaces.
Right, pointers to strings but yeah. Essentially the whitespace count specifies the stack depth at which a line is to be executed. A decrease in stack depth means all superior levels are terminated.
I meant users of languages ( application programmers) as opposed to compiler programmers, not python programmers specifically, so I'm including devs that use other languages and see in python a tool that they would consume.
This is really cool! It's so fun to see what you can achieve and what's optional. I have seen the 'single character variable' limitation in some other minilangs before, but using the source itself as the target of function calls and loops is new to me. It does make a lot of sense but I wouldn't have thought of that.
For those who actually need something like this in production, there is Snek: <https://sneklang.org/> “Snek is a tiny embeddable language targeting processors with only a few kB of flash and ram.”
Yes, but compiling or modifying Snek from source is very challenging. I wish it was one single C file for an example base like Posix, instead of many files for many platforms plus a custom parser in Python (Lola).
This seems to be in the same spirit as Justine Tunney's SectorLISP. Very cool.
https://justine.lol/sectorlisp/
A lot of criticism of python often mentions the whitespace as lexical scope tokens, and that criticism is usually posited by users of the language.
As implementer of an interpreter, did you feel that whitespace for lexical scoping made the job of writing the lexer significantly more complex?
And, there are multiple white space symbols!
<space><space><tab><space>
is different than
<space><tab><space><space>
So you also have to track the actual sequence of counts of white space used for each level, rather than just a simple count.
Or you just forbid mixing spaces and tabs in the same indentation sequence, the way most whitespace-sensitive languages seem to end up doing. Or you make a slightly more reasonable rule: spaces may follow tabs, but no tabs may follow a space. That's at least unambiguous.
But it also feels arbitrary and annoyingly restrictive. On top of that there are at least 25 whitespace codepoints in UTF. Should your language really be opinionated about when, where, and in what order (for example) the "mongolian vowel separator" appears?
> and annoyingly restrictive
How so? In what scenario would you ever need to use a sequence like <tab><space><tab> in indentation in your source code? Let alone using esoteric Unicode whitespace characters for indentation. I think it is perfectly reasonable for the language to make the restriction that indentation must be either all tabs, tabs followed by spaces, or all spaces.
> <space><space><tab><space> is different than <space><tab><space><space>
in my view, both are the same, both `is` (or ===) an IndentationError raise
It's just a stack containing strings at the end of the day. Really not a big deal.
Right, pointers to strings but yeah. Essentially the whitespace count specifies the stack depth at which a line is to be executed. A decrease in stack depth means all superior levels are terminated.
Doesn't affect function call stacks though.
For a 1024 byte implementation (and even way more complex impl.) You would just force one whitespace char, and definitely no mixing.
> that criticism is usually posited by users of the language.
Uhhh, no. Sure, it's posited by people who feel they are are forced to use it, but it's basically unlearning other syntax.
Here's a study about people with no experience. They do better with python:
https://www.researchgate.net/publication/262256894_An_Empiri...
When the scala language made whitespace optional, it was very divisive, but now it's extremely well accepted.
I meant users of languages ( application programmers) as opposed to compiler programmers, not python programmers specifically, so I'm including devs that use other languages and see in python a tool that they would consume.
Good use of free will and well-written. Very nice walkthrough austin!
I was very disappointed that this is “interpreting” some tiny made up language.
This is not Python, or even within three orders of magnitude of Python.
It’s true, the title should have said “Python-like”
TBF the fizzbuzz code works just fine in CPython.
the blog post is pretty well-written! loved how he wrote about the the code-golfing part.