Follow

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.

· · Web · 1 · 0 · 1

@sjm
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: petevilter.me/post/datalog-typ

There's also unison, which uses plain text for presentation and editing, but not storage: 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.

@sjm
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.

@sjm
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.

@unwesen yeah, definitely a set of trade-offs there. It's always possible that a language/environment could layer these enhancements on top of a generic vcs to avoid the issue and keep the positives. Not necessarily an easy problem, though

Any semantic storage and editing should probably come with easy transformations to/from plain text too...I think editing, viewing, running (and distributed computing, according to unison) could all be improved

again, dunno what to do with this. Just cool 🤔

@sjm
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.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!