If you’re going to store the source in a canonical format and unpack that to suit each developer… why should the canonical format just be regular source code?

All the same tools can exist with a text backend, and you get grep/sed support for free too!

▲

psychoslave 4 days ago | parent | next [-]

That’s seems like a genious remark actually. If you store the abstract objects and have the mechanism to transform to whatever the desired output form is, it’s almost trivial to expose a version as files and text rendering for tools that are thus oriented, isn’t it?

▲

danielheath 3 days ago | parent [-]

Originally my fathers idea from back in the 90s to create a language with a whole suite of syntactic representations to suit your preferences.

Want it to look like C? Lisp? Pascal? Why not!

	▲	psychoslave 2 days ago \| parent [-]
		Do you have more references about what your fathers did back then?

▲

giveita 4 days ago | parent | prev [-]

My grep may not work on your settings for the same code.

This becomes an issue with say CI where maybe I add a gate to check something with grep. But whose format do I assume? My local (that I used to test it locally) or the canonical (which means I need to switch local format to test it)?

▲

brabel 4 days ago | parent | next [-]

You really rely on grep on CI? How fragile is that ?! This is a good argument for storing non-text. Grepping code is laughably unreliable. The only way to write things like that reliably is by actually parsing the code and working in its AST. Working in text is like writing code in a completely untyped language. It can be done, but it’s beyond stupid for anything where accuracy matters.

▲

treadmill 4 days ago | parent | prev [-]

You're misunderstanding the idea I think.

You would use the format on disk for the grep. "Your format" only exists displayed in your editor.

	▲	giveita 4 days ago \| parent [-]
		Aha