| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
But still feels rough:
Variable names are still funky: 'k' and 'm'.
Field names still not copacetic: single-touch-event. Foolish
consistencies..
|
| | |
|
| | |
|
| |
|
|
| |
No way to quit yet, though.
|
| | |
|
| |
|
|
| |
Reorg.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Rip out keyboard for now, add notion of cursor.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
More editor experiments.
a) I'm starting out with just a doubly linked list of characters as the
editor data structure. Haven't actually started using it yet.
b) Rather than provide a top-left-bottom-right bounding box up front, I
think I want to allow the bounding box to flow indefinitely down given
top, left and right. The old approach mimics traditional windowing
systems, while the new one mimics html flowing; I want a single
scrollbar for all my rendered elements within a single column.
|
| | |
|
| | |
|
| |
|
|
|
| |
But this is getting too complex too fast. Let's get a simple editor
working first without color.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two columns: edit code on left and run code on right.
In both columns, the action is at the top of the screen, and stuff
gradually flows downward unless pulled back up.
Stuff you run on the right side will eventually become reproducible test
cases that runs constantly on every change.
We also have a tentative signature for the 'edit' routine: it'll take an
input string and return an output string when it finishes.
More columns expand to the right. Number of columns shown will remain
fixed at any time depending on screen width. But for now we support
exactly two columns.
|
| | |
|
| | |
|
| |
|
|
| |
I've tried to update the Readme, but there are at least a couple of issues.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'default-scope' is now 'default-space'
'closure-generator' is now 'next-space-generator'
The connection to high-level syntax for closures is now tenuous, so
we'll call the 'outer scope' the 'next space'.
So, let's try to create a few sentences with all these related ideas:
Names map to addresses offset from a default-space when it's provided.
Spaces can be strung together. The zeroth variable points to the next
space, the one that is accessed when a variable has /space:1.
To map a name to an address in the next space, you need to know what
function generated that space. A corollary is that the space passed in
to a function should always be generated by a single function.
Spaces can be used to construct lexical scopes and objects.
|
| | |
|
| | |
|
| |
|
|
|
| |
We expect users to come across mu from arbitrary bits of code, so try to
make each line as self-contained as possible.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We have cases where 'type' is stored in memory, so it can't be a
literal type like 'offset'.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
They need a type table to work, but I'm keeping type tables next to
the tests.
Everything needs to be a test from now on.
(But first some fixes to the terminal primitives.)
|
| | |
|
| |
|
|
|
| |
Why did it take forever to realize nobody will set the array length, that I
have to do it for myself?
|
| | |
|
| | |
|
| |
|