I just finished and pushed out the new and improved regexp implementation of Nuit. It went from this unmaintainable ugly hacky 240 line mess that even I couldn't understand:
Although it doesn't look like it uses regexps much, in the few areas that it does use them, it's a big help. The primary benefit of the rewrite was my cleanup and improvement of the pseudo-continuation-passing-style.
That is now a 100% complete Arc implementation of the Nuit spec. All it needs is a serializer and JSON/YAML meta-format. I also just realized that you could write a meta-format for Nuit that would blow the pants off of Markdown: it'd be so awesome!
I also rewrote basically all the non-Unicode stuff in the spec. Not much really changed, I just wrote down a bunch of stuff that was previously implied but unwritten. I also tried to be much more precise about things like indentation rules.
---
With that out of the way... I can now focus on rewriting my playlist program. I expect it to be much more convenient and much faster once I'm done.
"JSON unicode escapes have four hexadecimal characters (per RFC 4627), and you're missing a u."
Ah, thanks! I'll fix that right away. The reason I left off the leading 0s is that some languages (like Racket) let you do that. Always using 4 is less ambiguous and more portable, so I'll change that.
---
"You now say "It is invalid for a non-empty line to be indented if it is not within a list, comment, or string," but the whole file is in a list. :-p"
You and your pedantry! The top-level implied list doesn't count. I would hope that's obvious enough that I don't need to explicitly say it, but... unfortunately I know how some people are.
Hm... come to think of it... I could just give the implied list the same rules as explicit lists. Which means that it's okay for top-level expressions to be indented, just so long as they're all the same indent. That solves the issue while being more flexible and consistent. I'll do that instead, and thanks to the rewrite, it's a trivial change to make.
Looks like your pedantry saved the day (again)!
---
"The lack of informative commit messages made it difficult to catch up with the spec changes. Just saying. ^_^"
Well, I usually end up putting a lot of changes into a single commit, so just reading the diffs should be enough? In any case, as said, the spec itself didn't really change much, things just got clarified.
Nuit hasn't changed very much from when I first posted it, except that # and " are now multi-line block prefixes, whereas # used to be single-line and " used to be a delimiter like in JSON/YAML.
Oh yeah, it also ignores whitespace now, thanks to your suggestion. It used to throw an error. Oh! And the second part of the @ list can now be any arbitrary sigil rather than just a string. I think that's about it...
I honestly don't expect Nuit to change much from this point onward. I think things are in a pretty stable state. But I'm still not entirely sure about handling whitespace at the start/end of a string, and I've been mulling over the idea of getting rid of the \ sigil...
"The reason I left off the leading 0s is that some languages (like Racket) let you do that."
Hmm, I thought JavaScript was like that too, but it appears ECMAScript 5 doesn't allow it, and Chrome's implementation doesn't like it either.
---
"Well, I usually end up putting a lot of changes into a single commit, so just reading the diffs should be enough?"
There were lots and lots of indentation-only changes. If those were separated into their own commits, with commit messages that indicated that the indentation was all that changed, it would have been easier.
I trust you to know that ultimately, it doesn't matter what's easy for me as long as it's easy for you. :-p
---
"Nuit hasn't changed very much from when I first posted it[...]"
The wordings changed. Even if you had commit messages that stated your intentions like this, I would have looked at the changes carefully in case something became contradictory or ambiguous by accident.
In hindsight, I should have just checked out the old and new versions of the project and done a diff, lol.
Don't trust me to go to this effort all the time, but I guess I was in the mood for it.
---
"Oh! And the second part of the @ list can now be any arbitrary sigil rather than just a string."
That was the most significant change, in my mind. This example of yours should be a good test case for Nuit implementations:
"There were lots and lots of indentation-only changes. If those were separated into their own commits, with commit messages that indicated that the indentation was all that changed, it would have been easier."
Sure, but that woulda been more work for me. :P I honestly wasn't expecting you to pore through the commit log... Since I am used to working alone, I just use git as essentially a safety net: it lets me go back to an old version just in case the new version doesn't work out. So commit messages aren't nearly as important to me as they would be in a team-based environment.
---
"The wordings changed. Even if you had commit messages that stated your intentions like this, I would have looked at the changes carefully in case something became contradictory or ambiguous by accident."
Then the commit messages would have been useless anyways, right? :P
---
"In hindsight, I should have just checked out the old and new versions of the project and done a diff, lol."
Github even lets you do a diff on their website! :D
---
"Don't trust me to go to this effort all the time, but I guess I was in the mood for it."
I honestly wasn't expecting anything like that.
---
"That was the most significant change, in my mind. This example of yours should be a good test case for Nuit implementations:"
Check out "nuit-test.arc" which should have conformance tests for everything in the Nuit spec:
"I've been wondering about that too. It seems like " or ` will work just as well for those cases."
Yeah, I know. I guess it's because the only single-line thing is a non-sigil, and I wanted to be able to slap anything in without worrying about it, so \ was a single-line escape thingy. But I think I can safely get rid of it.
