- Parallelism using list comprehensions like nesl
- Seamless parallelism over a network like erlang, with ability to extend with encryption/security
- Turing-complete type-system like Qi, but with implicit runtime verification
- Turing-complete macros like Lisp (i.e. extending the compiler), but maybe just the ability to have function parameters optionally evaluated which would give you the equivalent, assuming all computations that can be evaluated at compile-time are
- Expose the interpreter/compiler for meta-circular evaluation
- Arbitrary meta-data like Java annotations or .NET attributes on all source code nodes, not just functions.
- Full source reflection at runtime, compile-time, anytime (although this might not be necessary if the IDE has scripting — see below)
- In other words, blur distinction of compile/run/etc. times
- Bi-directional mappings for implicit parsing and printing (i.e. syntax skinning) with ability to use them inline (which would, among other things, give you the usefulness of reader macros)
- Seamless FFI and importing of Java libraries — we have to build on top of something so it might as well be the thing with the most well-developed libraries to make the language a viable option for production code
- Seamless interaction with the native platform when needed
- Infinite data structures like Haskell — I guess this means lazy evaluation
- Seamless language-integrated persistence
- Type inference with useful error messages when my programs fail to type-check
- Namespaces — I've never seen a language sustain large applications without these, and many languages have failed to catch on
- Modules and true functors (i.e. functions over modules)
- Type-classes — they're really useful
- User-definable monads
- Examples/test cases in source
- Searching by function type-signature, which will also return functions that can be used with simple coercion functions on the parameters (e.g. using
stringOfExp : exp -> stringas an implicit coercion)
- Graphing of module and function dependencies so I can see where the entry-points are when I am trying to look for something in a module I'm not familiar with
- Profiling which feeds back into the editor (color-coded perhaps) so I can see where I should optimize when I'm editing
- Scripting like Emacs but in the language that it edits, not a variant of Lisp or some other random language that the editor happens to be written in
- Incremental background compilation with automatic dependency analysis
- Knowledge of the abstract syntax tree to allow for (scripted) refactoring. In fact, why not define parts of the language (or skin) as mappings between UI events and semantics, taking the idea of bridging the gap between abstract syntax trees and the user even further.
- Type inference that feeds back into the editor, as if you had typed it in
- A graphical window designer like Visual Studio's Form Builder or Xcode's Interface Builder
- Toggling of debug output which is structured, not just text, so that more information can be expanded without re-running. Toggling should be optionally automatic by tracking which pieces of code have changed recently and only showing dataflow affected by the changes.
- Good data-structures (e.g. hash tables, balanced trees, heaps, graphs, etc.)
- Hash functions on common types and typed encryption algorithms (i.e. an
'a rsa_encryptedtype) with an interface that makes them easy to use (i.e. no coding cost and little knowledge of encryption algorithms required)
- A hardware/platform abstraction layer for every-day drawing using a box-model similar to CSS
Is this technically feasible? Absolutely. Just about all of it's been done before in one form or another.
Is this realistic? No. But no one ever made it anywhere interesting without dreaming big.
I'll add to this post's list when I think of something else.