I'm currently fascinated about storing and editing code in a way that is consistent with its semantics, rather than using plain text for everything and requiring that each tool parses and understands the code separately. I know that lsp has done a bunch here, but it's not quite as far as it could go.
but having said that, no idea what to do with this fascination.
As long as there's a standard parser that's easily embeddable, does it matter?
I mean, that's why compilers, clang especially, produce a. AST for e.g. editor or linters to work on.
@unwesen sure, it's not the biggest problem in the world! (if we stick to plain text being the primary way we write code which realistically is going to be tricky to get away from)
Languages like idris allow such a great editing experience even with it being text-based but you could push it further
This blog post shows one alternative flow for editing code: https://petevilter.me/post/datalog-typechecking/
There's also unison, which uses plain text for presentation and editing, but not storage: https://www.unisonweb.org/
@unwesen I guess I'm thinking there's a whole bunch of possibilities that are slowly being explored, and I'm excited by it. Having a VCS that was aware of the semantics of my code and could perform a merge or show diffs based on this. True, this doesn't mean we need to move away from a plain-text/parser architecture and processing power is cheap, but it might be made simpler and easier if plain text isn't the only choice
@sjm Hmm, character limit swallowed my response.
I understand quite well what you mean. I went into that direction for only somewhat related reasons. The TL;DR is, VCS work on patches, because patches work on lines of text, and lines of text is a data model you can apply to a huge variety of inputs. That flexibility is what makes VCSes so powerful.
Of course, a kind of VCS that worked with a kind of OT on an AST would provide much better features, but at the cost of requiring some custom code per supported language. The posts approach may reduce the amount of customisation necessary, and you could fall back to patches, but the cost remains.
So I'm more in favour of keeping a data transport/exchange generic, and shifting the burden of interpretation to the application. There's probably some good middle ground there, too, but other than something like OT (which has limitations), I don't see it quite yet.
Specifically storage has good reason for working on a simple data model. Any operation that isn't block aligned has the potential of being very expensive - with the exception of replacement (without modifying length) and appending.
In a sense, it's the job of databases to translate between more complex higher level operations into simpler block level operations. I mean, that's only part of the job, of course. But without it you don't have speed and reliability.
The original server operated by the Mastodon gGmbH non-profit