| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Longer name, but it doesn't lie. We have no data structure right now for
combining multiple code points. And it makes no sense for the notion of
a grapheme to conflate its Unicode encoding.
|
| |
|
|
|
|
| |
I'm loading them in uncompressed ASCII format, and all streams and gap
buffers all over the place need to get massively scaled up to 256KB
capacity. But the tests don't yet run out of RAM, so I'll keep going.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've always been dissatisfied with the notion of escaping. It introduces
a special-case meta-notation within the tokenizer, and the conventional
approach leads to exponential "leaning toothpick syndrome" with each
level of escaping.
One potential "correct" solution is to keep string terminals
parameterizable:
[abc] => abc
[=] => =
[=[abc]=] => abc
[=[a]bc]=] => a]bc
[==[a]=]bc]==] => a]=]bc
..and so on. Basically the terminals grow linearly as the number of
escapings grow.
While this is workable, I'd like to wait until I actually need it, and
then gauge whether the need is a sign of the stack growing too complex,
with too many layers of notation/parsing. Mu's goal is just 3 notations,
and it's going to require constant vigilance to keep that from growing.
Therefore, for now, there are two notations for string literals, one
symmetric and one balanced:
"abc" => abc
[abc] => abc
The balancing notation permits nested brackets as long as they balance.
[abc [def]] => abc [def]
If you need unbalanced square brackets, use the symmetric terminals:
"abc [def" => abc [def
If you need double quotes inside strings, use the balanced notation:
[abc "def] => abc "def
If you need _both_ square brackets (whether balanced or unbalanced) and
double quotes, you're currently shit outta luck.
|
| |
|
|
|
|
| |
The Mu shell has no string literals, only streams. No random access,
only sequential access. But I've been playing fast and loose with its
read pointer until now. Hopefully things are cleaned up now.
|
| |
|
|
| |
One error message gets a bit worse.
|
| |
|
|
| |
We're now down to 4 failing tests. But these will require surgery.
|
| | |
|
| |
|
|
| |
First step: undo operator support in tokenization.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is going better than expected; just 3 failing tests among the new
ones.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
General plan:
stop skipping newlines during tokenization
introduce a new indent token, initially skip it transparently
start doing cleverer things
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We still don't support _any_ fractional literals, positive or negative.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We now use traces everywhere for error-checking. Null traces introduce
the possibility of changing a functions error response, and therefore its
semantics.
|
| | |
|
| |
|
|
|
|
|
|
| |
In the process I spent a long time tracking down a stray TODO in 108write.subx
that I thought would abort but didn't since the switch to baremetal.
Then after I reintroduced that assertion I had to go track down a bunch
of buffer sizes. Stream sizes continue to be a huge mess.
|
| |
|
|
|
| |
Also bare-bones syntax highlighting for .limg files. Doesn't work when
.limg file is first file opened with Vim.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I was forgetting that callers sometimes reuse outputs between successive
tokens.
|
| | |
|
| |
|
|
| |
We're calling them streams since they support appending.
|
| | |
|
| | |
|
| | |
|
| | |
|