Is this the sort of language where an interpreter would be impossible because it's subjective what a lyric means, or does it have a finite set of possible commands? If the latter, it might help to put that list on the page. IFcoltransG (talk) 04:37, 12 December 2019 (UTC)
- Well, I hoped an interpreter was possible for this language -- something like a natural language processor that could easily be built upon to support new code examples, but you've hit on the thing that makes it difficult. I definitely didn't want the command set to be limited to a single construct per operation, which I think is a problem with some other Category:Pseudonatural esolangs I've seen. They become standard imperative languages with clumsy syntax, and ugly repetitive programs get written that work, but don't look remotely natural. Part of this original concept was to allow and encourage creativity to invent new constructs to get programmatic effects, and the challenge is to use an existing lyric form to compose algorithms. I don't think I made this very clear in the language write up, so it's a good question, and it's probably the main point of intended difference. My original idea was that MC's (the programmers) should and would extend the language spec by writing new lyrics (programs), and the "community" could accept and re-use constructs for their own lyrics and the language would grow organically, as a deliberate analogy to how slang and genres evolve, and how highly lyrical based genres make use of references and catch phrases to build up identity. This could be implemented by a FLOSS interpreter that would be changing all the time, every new program would add to the language and grammar corpus. I had not worked with natural language parsers before, which is why I took the shortcut of writing equivalent code in python rather than trying to start on a proper implementation and give a false idea of a finalised reference interpreter.
- Grime MC commands are emphatically NOT meant to be finite, natural language is meant to be a living thing
- MCs are free to extend the genre, but only by creating fully realised lyrics -- you can't propose an extension without picking up a mic
- the crowd and other MCs have some influence on accepting changes, but this is all pretty subjective -- the act of getting up and doing it counts for quite a bit
- schisms, forks, and feuds (beef) are perfectly acceptable
- people will argue passionately about trivia (aka really fundamental differences) "That's Drill, not Grime!"
- I like the idea of public dis tracks that dispute the validity of other programs
- An implementation should be possible to some degree of success, but it'd have to be a bit clever in enabling the constant extension and variants
- Versioning will be hell
- The one practical thing in this language's favour is that, at any given point in time, the number of used commands will be very countably finite because no one cares that much, and the rate of change is likely to stay low. Thanks for taking an interest :)
- As a Category:Pseudonatural esolang, Grime MC is trying to explore the idea of required creativity within a deliberately narrow form that needs to maintain a distinct identity (I'm hoping this is not a completely awful analogy to being a real MC), and have some degree of algorithmic comprehensibility. Also how the specs for natural languages are derived from surveying real examples -- linguistic description rather than prescription. Code examples come first, and validity comes from lyrical skill and popularity (or just by being bold and doing it first). Sure, it doesn't make implementation easy, and maybe there are flaws, but it's an esolang to be engaged with and described, rather than proscribed. Salpynx (talk) 23:57, 12 December 2019 (UTC)