After a month of work (and many more months of planning), Retina 1.0 is finally done. It should soon be available on TIO. In the meantime, if you're interested you can get a headstart with the changelog and the documentation.

Fair warning: the new documentation is massive, but the tripled (!) length is actually an indication of how much more powerful the language is now. I'll get to work on a more digestible tutorial soon, but if anyone has the time and patience to read the documentation, please do let me know if anything is unclear.

Retina actually has almost as many lines of unit tests as actual code, but I'm sure there are still bugs in the interpreter. Do let me know if you encounter any.

^ (random): Instead of keeping the first match in each group, the last match will be kept.

I assume this should be (reverse)

yes, thanks

fixed

The following escape sequences are known (only for convenience — you can also embed most of the characters directly in the source code): \a (bell, 0x07), \b (backspace, 0x08), \f (form feed, 0x0C), \n (line feed, 0x0A, if you want to embed this literally, use ¶), \r (carriage return, 0x0D), \t (tab, 0x09), \v (vertical tab, 0x0B), \¶ (pilcrow, 0xB6).

0x07, 0x08 and 0xB6 aren't inline code, I assume they should be

!| (transliterate once):

is that supposed to be two characters?

yes

stage-specific options are now two characters (prefixed by !)

github.com/m-ender/retina/wiki/… re two-char options

ah right, Split stages also use that

still, that was a good read

did you actually read the entire thing? :O

Managed to golf 5 bytes off FizzBuzz with Retina 1.0, but I feel like it should be possible to go even shorter. codegolf.stackexchange.com/a/58682/8478

Oh good. Retina 1.0 has a different TIO link. I was wondering if I'd have to update my programs.

Quick note: In the documentation before the string "(each line should be thought of as a separate program)", the backticks are not literal backticks.

@mbomb007 thanks, fixed.

Do the History and Running Log features have implications for execution time or memory usage?

@mbomb007 Mostly memory usage. It's currently impossible to have an infinitely running program that doesn't run out of memory eventually. I'll probably add a global flag soon to either disable the running log or limit its size.

Thinking about it, I'll probably add a bit more fine-grained control over writing to the history: a) an option that toggles whether a stage registers with the history, b) a global flag that defaults all stages to not registering, c) a global flag to limit the size of the log.

Couldn't you check at the beginning of execution whether the program has a possibility of using the history or log? For example, if the code contains no Eval stage, and no references to history or log in a replacement.

If the program has no possibility of making use of it, you could automatically "optimize" it away by not writing to them.

But I agree that a "silent" flag for history or logging could be useful.

Well, I made it about half way through reading the docs. I'll have to finish later.

@mbomb007 dynamic elements can also access the history. I guess if those aren't used either, it might be possible. Those additional flags would still be useful though.

I'd have to parse all substitutions before the start of the program, but that should be possible.

@MartinEnder you actually might have beaten Luis' MATL book

@MartinEnder regarding the fizzbuzz, I don't understand why does the third line doesn't require a $ to avoid matching only the greatest-divisible-by-3 portion, while the fifth line does need it

Nevermind, I didn't consider the anchor