Compliance with AshPaper's informal spec

[shnewto]

👋 👋 Hello! I love this project so much!

I recently took a stab at implementing the AshPaper's spec in Rust and wanted to share it with you. It's at https://github.com/shnewto/ashpaper. Please do let me know if you have any issues or concerns with my approach or the language's representation. I really want to do right by this project, it's been such an inspiration.

I also ran into a couple unknowns in the process. Hoped you'd be willing to shed some light. 🙏

• The rules for the words 'like' and 'as' I've taken to mean simply the presence of the patterns 'like' or 'as'. So the rule for 'like' has the potential to match 'likes' and 'has' to match the rule for 'as' (barring any other rule that takes precedence). I'm wondering whether I've interpreted that correctly.
• I haven't give the title any special treatment, which means that it can be taken as any instruction if it matches something that isn't "store syllables". It occurred to me that if it was special cased to always store syllables, we could free it up to use capital letters or commas, etc. But if that's not a desired behavior, that's okay with me!
• I found myself wanting to add comments while writing some .eso files and added a new rule to my implementation. If the pattern ;; appears at the beginning of a line, and at the bottom of the file, it's basically a noop. (I'd like to fortify it so anything in the pattern ;;.*\n has no effect on the program and the beginning of a line and end of file caveats no longer apply). Would love to know what you're thoughts are on comments 😄
• (I was stumped for awhile by the / rule using the inactive register but while writing all this up, realized that was my own oversight and not an issue with the spec. I'll update my project's documentation to reflect that tonight.)

Thank you!

[wphicks]

Oh wow! I'm delighted that you took the time to do this, @shnewto. And it gives me an excuse to play with Rust a bit, which I don't often get to do! Answering things in order:

• Ah, good question! I actually intended it to be a complete word, so "likes" or "has" would not count. I'll update the spec and check if my implementation is actually doing that.
• One of my thoughts with leaving the title as a non-special-case is that it would allow one poem to be called after another as a sort of subroutine. I'd even thought at one point of implementing execution rules for a collection of poems, where you could add a "table of contexts" (sic) that would allow you to specify an order for calling a series of poems. That being said, please don't feel bound by my original ideas! I love the idea of seeing forks of AshPaper (or my other Esopos) that experiment with new things and see what bizarre, cool things emerge.
• Ah, now this is one I did think about a fair bit. None of my Esopo languages allow comments because it's too easy to cheat with them one way or another. That is, one could include poetic language in comments that doesn't quite fit in the logical flow of the program, obviating the aesthetic constraints of the spec. On the other hand, if one is using comments to clarify something in the logical flow of the program, it breaks you out of the human reading of the poem. But again, don't let me tell you what to do on any of these things! If you have cool ideas for aesthetic/logical/... opportunities opened up by comments, don't you dare let anything I say stop you from making it happen! ;)
• Good to know! I'll try to clarify the wording in the spec.

The upshot of all this is: Don't be afraid to mess with this thing! There's a poet (I'm sorry, I forget who) who talks about the value of building on others' work in literature, who says that you should treat such things like a stolen car, not a borrowed car. If you've just borrowed it, you're going to be really careful with it and concerned about doing justice to the original. If you've stolen it, you're going to drive like a maniac and not worry about adding a few dings. So, steal it, make it yours, make it beautiful!

Thanks for giving this project a new life in the Rustlands.

[shnewto]

Ah! I really appreciate your thoughts here, they mean a lot to me. And I'm glad to hear you support me taking it for a spin! It's been a pleasure.

I'm certainly excited to continue drive recklessly 😄 and I'm looking forward to continuing to fortify what I've got so far and build on what's possible with it.

I've chewed a bit on your design decisions around comments and special casing the title and I'm feeling quite convinced and happy with them are they're presented. Thank you for that.

One more thing I'd be very interested in your thoughts on is the potential for extending the spec to account for Unicode characters. There are a lot of unknowns for me there. It would certainly present some interesting challenges (but hopefully surmountable?) when it comes to syllables, rhymes, and alliteration but would also open an exciting door to poetry in other languages.

[wphicks]

Oh, I'm definitely down for Unicode! In terms of other languages, there are some really interesting issues there. You're absolutely right that determining what constitutes rhymes/syllables/alliteration/... becomes really tricky when you start to move across languages, but more to the point, many of those terms are either much more clearly defined or else entirely irrelevant in the poetic tradition of that language. The obvious example there is haiku, where Western writers put an emphasis on counted syllables (since that's important to the Western poetic tradition), but the relevant traditional constraint on haiku is not exactly "syllables" as such.

So, I'd be even more interested in variants on this spec that speak to the traditions that are relevant to the natural language that the poem/program is written in. For example, if I recall correctly, Ethiopian poetry continues to place significant value on consistent end-rhyme, so an Ethiopian esopo probably shouldn't compile without end-rhyme. In contemporary American English poetry, though, end rhyme is significantly de-emphasized, which is why the AshPaper spec has such a highly specialized logical operation for end rhyme (You have to really mean it if you want to use it!).

All that's mostly daydreaming, though. I'd enjoy just seeing some good end-rhyme detection code that sorta, kinda works with some subset of Unicode characters. ;)