Features in Dragon Composer (plan)

Input Language

Primarily python style: Indentation is the main method of scoping, EOL is the mark of end of statement with optional ';' and ':'.
Perl style function call: Parenthesisless function call is allowed, as well as conventional "f(x)" type.
Embedded perl printf style string: "this is a string with variable $v embedded and a format specification %.3f", value
where both v and value are variables.
Automatic variable declaration and type inferrence: If a parsing of a statement fails at semantic layer, the parser will try to declare an encountered new identifier as variable at local scope and try parse it again. The type of a new variable will be inferred from the value of an assignment.
"foreach i in container": i is an iterator. i.index refers to the index of the element if the container is ordered
Aliases: Caseless keyword, and allow scoped aliases to variables.
"goto"?: I tend to allow the use of goto. However I realize goto is inherently conflict with the structured internal program sturcture. I will try my best to give the parser the ability to automaticaly recognize some form of goto into loop or switch structures. In many case, thinking in "goto" is more direct than conceiving the right structure.
(Less notorious, but equally troublesome are "break" and "continue".)
...: More

Display Language

Variable declaration: Always have variable declaration at the beginning of a scope
Consistent look: All function call is in the style of f(x, ...); all keyword in the form of Capfirst; ...
...: More

Internal Structure

Scope: Scope is the unit of program. Each scope can have local variables, parameters, and a sequence of statements. Essentially, they are equivalent to the functions in a functional language.
Global Parameter Passing: This dangerous but I would like to have with caution. If a parameter name follows certain naming convention, the parameter can be passed through the local variable of the calling scope or the variables from the outer scope (global variable). How to devise the naming scope to minimize accidental name collision is kind of tricky.
During the definition of a scope, the statements in the definition can refer to variables defined in the outter scope; however, all those inherited variables will automatically become part of the parameters with special naming convention or variable options, thus allowing the defined scope directly useable in a different scope or even a different program.
The scope can even be directly used as a whole program, at which point, an commandline or configuration file passing routine will be (semi)intelligently added and its return will become either printout or exit code.
Standard type of "array", "hash", "set", etc.: I tend to implement a generalized container type and to classified to specific container type at compile time derived from its actual usage. For example, if it involves mostly push and pop action, make it a stack.
Macro?: I definitely would like to have a macro type of construction in dragon composer, I don't like to use defines which leaves the macro difficulte to trace. I am thinking of using the exact same form as scope, but allowing metastatements.
Meta-Statement?: Yes, those statment that instead of manipulating variables, it manipulats the program itself. For example, a statement adds a "print name" statement in every scope.
...: More

Compilation

Portability: The program should be able to be compiled into a variety of platforms or even languages upon a few settable options. In the definition of a scope, it can optionally be defined as a switch cases on program options and for each case is an implementation of how to compile. The important point is the switch cases is always the top structure of a scope, thus reduces the hassle of a maintainer to repetitively considering #ifdef's. There is no need to specify the protable implementation of each possible platform; for those unspecified platform, a default, but friendly, non-destructive stub will be used.
Possible options are "Win32", "C", "Python", "Perl", "i386", "assembly", "COFF", ..., "Dragon". The last one is the implementation in dragon composer's dragon language, which is the default.
Default Scope: Dragon composer allows incomplete scope, such as incomplete functions, classes, switches. In these cases, an default implementation will be used which is semi-intelligently designed according to the usages, and trying best to be non-intrusive and traceable. Specifically, throw non-catchable or difficult to catch exceptions everyplace is not desirable.
...: More

Overall Goals

I would like dragon composer to be an ultimately write once and use forever type of programming environment.
For example, I would like to only write once the algorithm of quicksort and called in all the places by only change its parameters. It should accept a scope which defines the cmp routine, and accepts any container with a possible index implementation; and I would like it to compile into efficient code with all the statically resolvable checking or switching resolved before compilation. I don't want unreachable code and extra, mindless checking in the compiled form, be it binary or c code.
The above mentioned quicksort is not necessary have to a mammoth. For example, the code to check whether the container is an array or list is deligated to the definitions in the array or list, and in quicksort, it just need to call "container[i]".

Disclaimer

I honestly don't know whether it is possible to implement all these features satisfactorily. I haven't done it yet, and I don't see any imposibility in these features either. If you think some of them is impossible, or impractical, or stupid, I appreciate it if you would let me know.