Perhaps this is a bad idea. It feels arbitrary, what methods Lua happens
to include in string and table objects without having to go through the
respective modules.
When should code go in the template used by new apps vs the .lua files
distributed with Teliva?
- from a privilege perspective there's no difference
- from a compatibility perspective stuff in .tlv will not get upgraded
with Teliva.
- for me the maintainer, functions in .lua files are easier to upgrade
in a single place.
- for the reader of an app, functions in .lua files will not show up to
be edited. They can still be overloaded, but the current version isn't
as discoverable. Putting something in the app is a slight nudge to
readers that they're encouraged to mess with it.
- Stuff in .lua files can use local functions and so have more internal
complexity. Apps can also hide details within functions, but that'll
make them more likely to run into limitations with Teliva's editing
environment.
I'm not yet sure how to reason about the second point in practice.
- Stuff in .tlv files I don't have to worry about compatibility
guarantees for.
- Stuff in .lua files I _do_ have to worry about compatibility
guarantees for.
Perhaps this means I'm doing things exactly wrong in this commit?
Functions like map/reduce/filter/append seem more timeless, whereas I'm
still just feeling my way around with start_reading and start_writing.
We'll see. For now I'm ruled by the fourth point. Messing with tasks and
the scheduler is much more advanced than anything else in template.tlv;
it seems to make sense to add some friction to modifying them.
Bottomline: Complex sub-systems go in .lua files. Simple, self-contained
definitions go into apps. Both are probably equally burdensome now from
a compatibility perspective.
They may take more or less from it (sieve.tlv in particular takes
nothing since call depth doesn't help at all there), but what they take
is in the right order so that you can compare across apps.
File operations now always return a channel (or nil on error or
permission denied).
When start_reading() from a filename, you can repeatedly :recv() from
the channel it returns.
When :recv() returns nil, you're at the end of the file. Stop.
When you start_writing() to a filename, you can repeatedly :send() to
the channel it returns.
When you're done writing, :close() the channel. Writes to the file won't
be externally visible until you do.
To make this work I'm now always starting up the scheduler, so I need to
fix sieve.tlv.
Transparently running the scheduler is an abstraction, and whenever I
create an abstraction I always worry about how it might fail. There's
a hopefully-clear error when you read past end of a file.
If we press a key the computation now restarts instantly.
There's no fiction of multi-threading in Teliva. If the application
doesn't work right, it beach-balls. If it doesn't beach-ball under
normal circumstances you're more certain it'll never beach-ball. It's
more work up-front, but there's less variability in outcomes.
Tasteful apps should only perform side-effects through 'window'
arguments rather than the 'curses' module directly. It's ok however to
read constants like curses.A_NORMAL or curses.stdscr().
There are some limitations, unfortunately. Ncurses wasn't designed with
testability in mind. For example, there's no way to curs_set or
assume_default_colors without the 'curses' module. Oh well.
Lua is often not very functional. Available primitives often mutate data
destructively rather than create new values. Perhaps I shouldn't be
trying to go against the grain. We'll see. The above changes are based
on using Teliva intensively for 2 weeks of Advent of Code 2021. But that
isn't quite the ideal use case for Teliva.
Kartik K. Agaram