Lambda the Ultimate

This one is a bit unusual for using modal keybindings (like VI) rather than chords (like "Ctrl-W").

Also, ease in cutting and pasting syntactic units is a lot more interesting in a language in which every syntactic unit is an s-exp than it is in a language with a more "algol-style" syntax.

If someone knows the author of the video, pass long this idea: Don't get hung up on making auto-completion lexically precise. It's good if it's lexically precise wrt the top level environment (including imported libraries) because those are pretty stable, but: within the file, complete from any symbol previously written, perhaps using proximity (character distance or S-exp traversal distance) to prioritize. That way, I can introduce and start completing on identifiers before I get around to inserting the declaration. Also, copy the UI of emacs' complete functions (especially the "hippie complete") package, in so far as, instead of (or in addition to) picking from a menu, one should just be able to cycle through completions. So, I hit complete and something is filled in, but if I hit the complete button again, immediately after, the next possible completion is substituted.

Finally: Scheme needs some s-exp notation for comments -- ideally in a form that you can explicitly attach a comment to some expression.

-t

Do you mean a comment associated with an expression, or the expression itself commented? And turned into whitespace at parse time, or a persistent "comment" node in the tree to be ignored, but saved persistently and printed again later?

I was thinking srfi-62 using #; prefix notation to comment an expression might work as a read macro turning #;foo into comment (nb foo) — assuming a new nb comment special form. Something like that?

This would resemble equivalence of ,foo and (unuote foo). Darn: I see teletype font doesn't work.

Edit: how about special form (nb foo ...) which evaluates to the value of foo, and ignores anything after foo? Is that better? (Reading the comments on srfi-62, I see #; has a mare's nest of problems resulting from mapping one s-expr to zero expressions, with resulting weird asymmetries.)

All I mean is that comments should not be separated from the rest of a language by some phase that just "strips them out". "strips" is a good approximate model for newbies but I want a comment syntax with semantic impact. Like, I want all the source code comments that apply most directly to a given machine instruction in a binary, or all the comments for some trace of the history of a value.

In general, I don't like the idea that source is a sequence of characters. It's just some datum. Yet popular comment syntaxes can't be explained any other way than by regarding source as a sequence of characters.

-t

I completely agree that a language should not treat comments as whitespace. However I believe though that the syntax of comments should have a toolset impact rather than a semantic one. In Cat for example I opted for a YAML inspired syntax to allow tools to parse meta-data from comments in soruce files.

I think strong static type systems should count as comments with a semantic impact. I agree that what is called a comment shouldn't have semantic meaning, since it's mostly just there so that when you go back to your code a few months later you don't scratch your head so much. Documentation generation using comments isn't really unknown, though.

Regarding auto-completion: yes, we are doing what you proposed. We're scanning for identifiers in the source buffer, and sort them by proximity to the cursor. Pressing tab repeatedly cycles over the possible completions.

To Falcon: thanks for the link to Citris!

and Emacs has been doing it for a few decades.

but I welcome our new vi-like Lisp editor overlords! :)
who knows? It might spur some change of pace inside the emacs community...

And as Tom Lord says above, you can't really begin to appreciate editing over s-exps in a stroke in languages like Java. All those lots of irritating silly parentheses sure come in handy for source code navigation in the right editor... :)

and Emacs has been doing it for a few decades.

And here's a paper to prove it: Structured Editing with a Lisp by Richard M. Stallman, 1978. (Ironically, behind a paywall.)

But we go through cycles in computing, in which we have to reinvent everything to fit the latest context. It's like other kinds of evolution: apes did lots of the same sort of things humans do, long before humans did them. Think of DrScheme and DivaScheme as the equivalent of homo sapiens... or maybe they're the monolith that'll transform us.

Not sure how they missed the obvious clue when they were examining the original monolith.

what do you mean? It's obvious that the monolith infused them with enough lambda calculus to make them reach human-level intelligence. It's in our blood to think recursively! :)

But we go through cycles in computing, in which we have to reinvent everything to fit the latest context.

Not only this. It's also a selection filter to get rid of legacy. Things worth being supported will be reinvented within another context. Many species / solutions get wiped out. Unfortunately we are used to think like economists ( scarity / waste of resources ) so we are trained not to see simple truths.