Typically AlgolFamily-style languages are divided into two camps: static or "strict" typing, and "dynamic" typing. But why can't a language have ''both'' features? 

Although I believe ItsTimeToDumpCeeSyntax, I'll assume a C-like/JavaScript-like style here for examples to make them familiar. 

If one does not supply an explicit type, it would act like a dynamic variable (called type "object" or "variant" in some languages):

  function foo(x, int y) { // x is dynamic, y is static
    var a;   // dynamic
    int b;   // static
    ...
  }
If we want to "force" explicitness, then perhaps a keyword can used:

  '''strict''' function foo(int x, int y, z) { // "z" is invalid
    int a;
    int b;
    var c; // INVALID, flagged by interpreter/compiler
    ...
  }
Module or class level:

  '''strict''' class myModule {
    ...
    function foo(int x, int y, z) {  // "z" is invalid
      var a;  // INVALID, flagged by interpreter/compiler
      int b;
      ...
    }
    ...
  }
And an optional language-wide or folder-wide configuration or marker file could force an entire application to be static if desired.

(Note that I prefer keywords come ''after'' the module, function, or variable name, more like Pascal, but here I'm using C convention.)

Internally, the structure for a variable/value/object may resemble:

* Static flag - "true" if static, "false" if dynamic
* Type tag (AKA "type indicator")
* Value (data bytes)

But it depends on the compiler/interpreter design. I doubt it would be as efficient as a "pure" static language in terms of performance, but that's a sacrifice for flexibility.

Even though there are languages that allow one to declare a variable dynamic, one has to explicitly label it as such. I'd prefer that lack of a named type be enough to declare it dynamic. We shouldn't have to declare it as type "object" or "variant" or what not.

Types can be converted as needed (if dymamics allowed per scope):

  var x;
  x = "123";
  myFunc(x);  // works
  x = "abc"
  myFunc(x);  // type conversion ERROR
  ...
  function myFunc(int a) {
     print(a);
  }
Here, the first value of x is coerced (converted) into type "int" inside the function. The second would trigger a run-time type-conversion error, such as "value or content cannot be converted into type 'int'." Note that the "type tag" of "a" would be "int" regardless of the type tag of "x".

Maybe make classes and objects be the same thing, except for a "single" key word that locks an object from being multi-instantiated, making it behave like a class. Or perhaps a max instantiation count along the lines of 0, 1, or "many". "1" is for singleton-like classes. One may also want to "lock" children from adding and/or overriding methods. Something to ponder and tune.

--top

''I quite like it.  It's reminiscent of -- and achieves the same goals as -- C#'s 'dynamic' type, but your approach encourages DynamicTyping whilst C# doesn't encourage it.''

One could say the default is dynamic, and restrictions are added by architects as needed. It follows a similar philosophy to DynamicRelational, which defaults to dynamic and loosy-goosy, but can be "locked down" like current RDBMS if desired, and incrementally.

A DualTypingLanguage would be better suited for browsers than JavaScript because the "base" GUI and system-like libraries would lock everything down, mid-level libraries such as shop-specific utils would use an in-between style, and application-level developers could use a more "scripty" angle (where not required by the deeper levels).
-------
CategoryLanguageTyping