FISH Design Goals

Here are the design goals:

A Frame Interpreter SHell (FISH) A Frame (of Reference) is a Software Construct which can be used as both an Object and a Context

@author Kevin Greer

GOALS/RATIONALE

Why FISH, what makes it different, or "why bother"?

1. "Context-Oriented" No Globals. No implicit global namespace.

Instead use explicit Contexts. FISH is to be a "Components and Contexts" language. Extend OO's "is-a" with CO's "in-a".

2. Extensible syntax. The parser is to be in the same namespace as the rest of the language so that you can manipulate the parsing of your program from within your program. You will be able to load new syntaxes just as you load new libraries. This is useful for things like SQL, Regex, XML, Macros, JSP, Reports, "here documents", etc. You can also use this feature to decorate the CLI/REPL to add things like auto-completion, history, help, etc.

3. Richer Object/Component model. Something like an extended JavaBeans component model will be standard. Among other things this will include "Facet Management" and Properties which are real Objects ie. instead of "user.getName()" you would have "user.name().get()" This lets you use "user.name()" as a mini-model and pass it to a View without having to adapt it. I want super-smart high-level powerful Objects, not just fancy structs.

4. I want to write as much of FISH in FISH as possible. I want to build it up from a small core language (a subset of Scheme in this case). This should mean that it will be easy to port/re-target to JVM, C, Parrot, Io, etc.

5. Prototype-Based / Object-Based. Things are much simpler if you remove the class/object duality. I believe that Proto's are the better way. I'm going to either prove or disprove this to myself.

6. Image based. At least as an option. I would like to develop on a continously running application rather than be forced into an edit/compile/run cycle. Support both models if possible.

7. Suitable as both a CLI shell to replace csh/bash/ksh and as a full programming language.

8. Make "supporting" information part of language. ie. requirements, design docs, bugs, todo's, unit tests, etc. A program should not be just a list of instructions for a computer. It should answer all questions: Who, what, when, where, why. Instead of generating static JavaDocs, FISH will let you dynamically browse/edit its supporting information. It will be its own living document.

9. (SECONDARY) Partial Evaluation. Self/Java/Hotspot like JIT compilation, code-generation, and some types of caching can all be done with partial evaluation. If I can build this into the language then it would make a lot of things much easier and would give FISH a chance of not being the slowest language on the planet.

Notes: Seems very similiar to Albert.