> A programming language that could be PROGRAMMATICALLY REFACTORED would be a HUGE home run.
The go people are poking at this. They ship a tool, 'go fix', that can safely refactor your code to deal with backwards-incompatible API changes. Go also has a tool, 'go fmt', that most people use to enforce tabs vs spaces, etc., but has a 'rewrite' flag that you can use to do simple, arbitrary transformations.
They also ship some AST tools for go, though I haven't seen much use made of them.
One recent use of the Go parsing and printing packages is goimports, a tool that automatically adds and removes import statements based on the code you've written.
I haven't delved into Go, but have occasionally "glanced" at it with curiosity. One of the most powerful principles I got a whiff of was that it was designed up front with the goal of providing a powerful tool chain -- an open parsing library and the like.
That provides some incredible power and may be the thing about Go that impresses me the most.
What if we also made programming language decisions about syntax, modularity constructs, etc., all with that goal in mind? (And perhaps Go has to a large degree).
Plus, I love Lisp! It even has a lot of the characteristics that would allow what I'm talking about. I was just trying to articulate that what I'm saying requires more than just SEXP's and Lisp macros (although that does go a long way).
And Slamhound is definitely barking up the same tree. Very interesting!
I suspect that this is a very clever joke. And possibly that I might be the butt of the joke. But I suspect that even so, the joke is so good that I'd still laugh heartily at it.
Unfortunately, I freely admit that the joke goes right over my head. I used to know something about Riemann surfaces, so I could invest some time and eventually get the joke perhaps, but I just don't have time now. :)
Set Theory
Natural Numbers
Integers
Rationals
Real Numbers
Complex Numbers
Calculus
Riemann Surfaces
(as the Apple ads say, some steps skipped)
The only point I was making was that the level you were thinking at was much higher than the level SEXPs are at. Trying to envisage how we get there remains hard. TL;DR I was agreeing with you. :)
Goimports is a fork of gofmt, so you can use it as a drop-in replacement. We're considering whether to merge the functionality back into gofmt. Goimports is still pretty experimental, so this might not happen until Go 1.4, if it does at all.
Heck I'd be thrilled to have a smart identifier/type renamer. Maybe it's just me but I like things to be named properly but I tend to be very bad at it until its 3rd or 4th use. I also like short(ish) names, so many variables tend to have the similar names across scopes which makes it impossible to do a quick replace-all.
You should be able to specify a type name, identifier, or module and its' replacement (optionally file & line to be specific) via CLI. It should do the replacement automatically, and fail if it at all changes the semantics (e.g. clash or variable shadowing) and give an overridable warning on a non-semantics-changing possible problem (like an unused shadowed variable).
Sure, this is a normal feature for an IDE, but I feel like it should be simpler (and I don't like IDE bloat anyways). Maybe the tools you mentioned can already do this.
The go people are poking at this. They ship a tool, 'go fix', that can safely refactor your code to deal with backwards-incompatible API changes. Go also has a tool, 'go fmt', that most people use to enforce tabs vs spaces, etc., but has a 'rewrite' flag that you can use to do simple, arbitrary transformations.
They also ship some AST tools for go, though I haven't seen much use made of them.