3 ms·
Regarding that second link about the bad merge, I think there is a deeper problem at hand. Namely that we still work with the textual representation of a progra
by codetrotter 7y ago
Regarding that second link about the bad merge, I think there is a deeper problem at hand. Namely that we still work with the textual representation of a program as the “source of truth”, but each time we save and commit this way, a lot of information is lost.
What I would like is instead of representing source code as text to have a binary representation of the AST of the software that I am writing where, crucially, all edit operations are recorded into history.
Perhaps such a binary format could even be slightly faster to work with in terms of time taken for editor and compiler to parse it?
And not only record edit operations, but differentiate between instancing and copying a node, so that we can express whether code that we duplicate should be edited everywhere automatically in the codebase when we change it, or if they should be allowed to diverge. (Both of which make sense in different contexts and would be great to actually express in the source representation and have the IDE read and understand.)
Furthermore, such a representation could allow for more freedom when positioning elements of the code because we aren’t constrained to just lines and lines of text with characters next to each other and lines above and below each other.
Now, a lot of non-textual editors exist already but I haven’t seen any that I like and besides I don’t want another language, I want to write Rust code in such a way as outlined here.
- the_duke 7y agoThis seems to be exactly what the Unison language [1] tries to do. I actually have been thinking about how the concept could be implemented for Rust. [1] https://news.ycombinator.com/item?id=22009912 https://news.ycombinator.com/item?id=22009912