Been having a lot of fun writing the report. Spending maybe a bit too much time on layouting and reproducibility rather than content.
codesize r = O(regex_size r). Should
be easy, can I add it? -> there is already a form of this with
regards to compsizeAd. Aurèle’s review:
Introduction
“Linden provides a complete and practical…” the word JavaScript should appear somewhere in that sentence (I know technically it should only be EcmaScript, but people know JS more than ES)
“JavaScript” is Oracle’s trademark and I would rather avoid it
I like the glossary, but are you sure you don’t want to define e.g. haystack the first time you use it?
I will inline the definition in the margin when first introducing a term
I have an issue with the “Formal verification gives us tools to address these issues” sentence. You just said before it was hard to reason about, so it will be hard to do formal verification no? I feel like this is out of order, or that something is missing
I am not sure I understand. I meant that it is hard to reason about, hence it was not attempted fully in the past
Background
I like the regex size section, but I’m not sure we understand why it is defined here
I needed it when talking about the size of the extracted literal. Should I move it there?
Literal extraction
you don’t want to use title case for section titles? (you do what you like, it’s just in case it was a mistake)
I don’t think I want to
Nothing which means 𝑟 matches exactly the empty string” don’t you want to write down “Exact”“” ? And maybe you can use the epsilon syntax for that example so that it does not look like a C comment.
I want to avoid using Linden syntax for consistency
“despite having the same complexity” you just said before that this could be quadratic in the size of the string, so is it really the same complexity?
Yes, it was a typo. It should have been O(|ss| \cdot |s|) instead of O(|s| \cdot |s|)
Continue writing the thesis.