On Thursday, March 3, 2022 at 8:52:57 AM UTC-5 Edward K. Ream wrote:
> In this Engineering Notebook post I'll explore changing Leo while Leo is
> running.
>
> Imo, changing Leo "on the fly" is impossible, but thinking about what
> would be necessary might suggest potential improvements to Leo
> [snip]
> All apps, regardless of language, are *inherently inflexible*:
>
> 1. The architecture can't change. In particular, APIs are contracts that
> can't easily be broken. Refactoring implies restarting the app.
>
> 2. Objects (instances of classes) contain data that must be retained. In
> general, changing any module might change the data that the module computes.
>
I generally agree with these statements, but they aren't always as rigid as
is stated here. I'm going mostly by my ancient experience with Forth,
which I've mentioned in another thread. Back in those days, there was
basically no fancy memory management, and DOS or even CP/M would be the
operating system. Forth did not use OS calls, and as it came for DOS, read
and wrote raw disk sectors, not OS files. So you could run Forth or DOS,
but not both at the same time from the same drive (a floppy disk drive).
Forth commands were, except for a few primitives, just lists of other Forth
commands. They were invoked by name, and the commands were executed by
looking up the address of the next command, and executing its code list.
All data was kept on a stack, and commands had no arguments. They were
expected to push and pop the stack to get or save data. The Forth
primitives were coded in assembler, and all other Forth commands - called
"words" - were built up ("defined") from those, even flow control commands
like IF. You didn't save programs, you saved that Forth image which
included all the commands defined to date. In this respect it was rather
like Smalltalk.
Here's what I've been leading up to. I was able to convert my Forth image
to use standard DOS files instead of raw disk sectors. I did it on the
fly. First I defined a command to perform interrupts (there was a way to
have your command list be a series of ASM instructions instead of being
Forth words). The BIOS used Int21, and DOS used Int27, IIRC. Once I had
this working, I could define new words that called DOS and BIOS services.
>From there, I defined new Forth words to read and write files using DOS
files. Then I could save even the Forth image to a DOS file. After that,
Forth and DOS could co-exist on the same disk. Life became much easier. I
was also able to change the original line-by-line editor to a full-screen
editor bit by bit in a similar way. That was interesting because you
needed the editor to write your new words, so it always had to work even as
you changed it..
I would call that "changing Forth on the fly". I think that one key to the
ability to make such changes is that there was no global data in Forth.
Each word pushed data onto the stack and popped data from it. So words had
to cooperate to maintain the contents of the stack correctly - that was the
equivalent of an API contract. But the data was produced and consumed
locally in an ephemeral way.
Of course, this has almost nothing to do with Leo and "live programming".
But it's an interesting perspective on the question.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/66a6aa4c-0aff-44cb-a169-2df4bbd82dedn%40googlegroups.com.
