I think what we need is "Elm error messages" (http://elm-lang.org/blog/compiler-errors-for-humans) for AST editors. Take paredit for example. If you're trying to delete a closing parenthesis, instead of refusing to do so and silently fail, display a tooltip that explains why such action is disallowed, and a list of (heck, hard-coded even, like some Elm errors) likely actions the user's trying to take. Deleting the list? Deleting just a token? Show the keybindings. Or even automatically pick the most likely action after a second invalid delete attempt.
I actually believe the constraints imposed by structural editing can be very beneficial (again, see paredit which helps your program stay syntactically valid). But constraints are good when they're visible. You can exhaustively check what's there. Constraints are frustrating when they're invisible and you repeatedly accidentally stumble against them.
(Ideally you'd also provide a free-form mode where you can edit things as plain text. But from personal experience I'd just go back to this instead of learning the AST editing keybindings.)
The thing I'm wondering is why people are so obsessed with this kind of AST editing. I don't find that code text entry speed is the limiting factor for any of my coding. The limiting factor is usually a) understanding the problem well enough, and b) understanding the existing code well enough. A good IDE with symbol/type and usage lookup usually suffices for the latter.
EDIT: If the point here is to prevent invalid ASTs, then I don't really see how much that helps. The number of invalid programs with valid ASTs is going to be huge, so you need good error handling anyway.
You can always get instant feedback (types, errors) because your code is always a valid AST. No ambiguous braces etc.
Also things like markdown comments and inline evaluation.
My attempt: http://sediment.io
Actually, I do have a question: do you have a blog or thought dump I can read?
[1] https://www.youtube.com/watch?v=HnZipJOan54 [2] http://shem.io/
The title translates to "biblical speak" pretty well haha
Are the semantics available anywhere? I've been waiting for someone to create a Lisp with pure/monadic IO, but I don't know whether Shem is what I imagine.
"Shem is a new compiled-to-JS, statically typed, pure-by-default functional programming language. The semantics are based on Haskell but the language evaluates strictly in a similar way to PureScript."
The document, unfortunately, doesn't go deeper into what about the semantics are derived from Haskell. A better HN title might be "Shem: a Statically Typed Compile-to-Javascript LISP".
[1]: The lower bound wasn't updated correctly which should made it loop indefinitely.
This may be the case. But these people (myself included!) are getting older by the day, and will eventually die or move into management roles. The students in the audience of the talk may well end up working at Facebook using AST editors, and in 10 years that will simply be the new normal.
loop (fn []
(loop))I explicitly stated that I at least don't perceive editing (keystroke) speed as a limiting factor, so I'm not sure what you're trying to say. My perceptions may obviously be wrong, but I think this places the burden of proof on those claiming an improvement.
My point (or contention, if you will) is that the power gained through local refactoring like this (moving a bunch of parenthesized code around quickly) is absolutely negligable in the grand scheme of things.
> By itself it's not that useful, but combine it with type awareness, semantic awareness, you have an expert system, not just a code editor.
That's really the crux isn't it? I can only say that I haven't seen anything even close to this yet even from AST-only editors, and we've been promised it for sooooo many years.
As of now IntelliJ IDEA/Eclipse can do far more advanced refactorings at the press of a few buttons... and some of these refactorings are actually non-trivial -- as opposed to just doing a block-select and moving code.
Granted, I'm sure they have a lot of code to achieve that, but I'd wager that the actual parsing from text->AST is a very minor portion of the refactoring code. I'm pretty sure the most difficult bit of that refactoring code is the bit that guarantees that the refactor preserves semantics.
EDIT: What I'm saying is basically this: I think it's naïve to think that the AST is the big problem when doing IDE/editor-supported refactoring.
When I think Haskell, I think lazy evaluation and only providing purely functional type patternmatching predicates.
On the other hand... with an AST-only editor I now have to mentally tune in even more to the way the editor will behave while typing code and any deviation from the expected behavior becomes absolutely crippling[1]. For me, personally, this can become more overhead than it's worth to correct a few misplaced ")" or "]" or ";" or whatever when I've finished typing the gist of my idea. (I honestly don't know what would be faster overall, and I suspect it depends on hideously complex factors like "how much time do you intend to spend on learning IDE-X vs. learning to 'edit files', etc. I guess we could start with studies on "does it work?" as in medicine, even if we have no clue as to how it supposedly works.)
I'm saying that given the enormous success (all things considered, etc.) of text-based editing the claimants have the burden of proof.
(Actually, I'll happily admit that I was at one point on the hype-train regarding AST-editing, but I'm more skeptical these days. The thing is that it's easy to produce the 80% solution at to make it look awesome, but the problem is that getting those last 10% is a killer. Just look at Chris Granger's project for an example of just how difficult it is to get to 90%.)
[1] The machine is a machine and can do ASTs perfectly all day long, but if I'm a bit sleepy or drunk it suddenly becomes impossible to edit and type in code because I can't do a perfect job at prediction...? That would be strange indeed!
Naive question; is "defn" really necessary?, isn't "let" and "lambda" enough to express a program?.
This is particularly true in clojure, since it's being compiled to java byte-code, and the jvm has a few default settings for how deep it'll look into the call tree for inlining. See https://www.youtube.com/watch?v=0tUrbf6Uzu8 for a talk that mentions this.
Although it does 'flatten' the bindings. Defn a, Defn b… is the same as let a = … in let b = … in …
The problem is the further away you go from lists of symbols, the more complicated the AST is to edit and to present to the user, and the more complicated the interface is for the user. It's not an insurmountable problem though.