Assuming types have methods (and maybe properties, events, etc.) the scope would say, “For this type, only allow that which is common to all the types specified, or if in a type-scope (recursive case), further restrict what can be done.” In other words, take the intersection of methods (or whatever) for all the types specified, and that set is what is strongly-typed checked. Or in plainer terms, if it could work, let it work. (Casting can be done, and when that cast fails, throw a run-time exception.)

It would look something like this (I am using a C-like syntax):

a as String, List, b as float, int, Imaginary, Matrix
{
a.Size; // Ok.
a.Reverse(); // Ok
a.ToUpper(); // Compiler error: List does not implement ToUpper.
b.Absolute(); // Ok
b.Invert(); // Compiler error: float, int, Imaginary do not implement ToUpper.
a as String
{
a.ToUpper(); // Now this is OK as a is only a String
}
if a is String
{
a.ToUpper(); // This is OK to as a is only a String
}
Method2(a); // This will be ok if Method2 takes one paramter of type
// String or List

In effect, a limited type-inference is being done. Not only is the type considered, but so is the method or property or whatever is being invoked on/with the object. One can imagine the declaration being a list of methods (including the types) that determine if a type will pass static-type checking.

I think I would prefer the idea of the OP, which is the same idea that I have wanted for a while, but this seems like a “more type-safe” compromise.

While I am at it, how about declarations like this: *.ToString(), *.DoesThis(), *.HasThis, etc. This would save having to implement interfaces for the sake of being able to do this.

As for my background in relation to dynamic typed languages:

I have used Python (after much C/C++) coding, and despite my fears about no static typing, I found I was able to code productivily, correctly and quickly while feeling that the language was not getting in my way nearly as much as C/C++ did.

I was suprised that my mind set seemed to change in that I quickly adpated to the lack of strong typing and became more careful somehow such that I did not have anywhere near the number type errors that I was predicting.

One rule that I have heard is “strong testing not strong typing”, which I think in the end must be true, but I think strong typing still is helpful for its ability to help me to try to do what I want to do.

I am now using C# and really like that language. However, I miss multiple-inheritance and especially the dynamic typing. I don’t miss as much things like changing the signature of a type. Oh, and indenting for blocks, I really liked that too.

I once worked on a Smalltalk GUI project where I was responsible for some C++ work that implemented a capatible interface for things (network and DBMS) that needed to be called by smalltalk but for which the C-callable libraries needed a nicer wrapper. In three months the (experienced) smalltalk developers delivered code for a user application that I would have estimated would take 9 months to develop in C++ or Java. I then switched to testing. After 6 months we were still finding bugs, most relating to the extensive use of duck typing that the developers had engaged in.

While C++ templates might seem the answer the current state of the art leaves much to be desired. When they work they work well. It is in development when you unwittingly pass in a class and get an error message 100 lines long. Someday it will be possible for the compiler to tell you “Template Foo called from Template Bar at line 999 of the Fraz routine requires that class Baz implement a function iterator()”. Figuring this out from the error messages C++ compilers today give is almost impossible. At least Python gives you a stack crawl that gives you the information at a glance even if is already runtime.

Built-in classes include:

Eq — provides == and /=
Ord — requires Eq, and also has comparison operators
Enum — for enumerable types
Num — requires Ord and Enum, provides the most fundamental numeric support
Show — has the show method which is very like Java’s toString()
Read — the inverse of Show: has a read method to read the type from a string. Note how dispatch to the correct implementation of read is based solely on the required *return* type, not the data in the string — something you cannot do in Java or Python
Monad — difficult to explain, it’s related to the ability to hide repetative plumbing code, and allows use of the “do”-notation for syntactic sugar

See the Haskell report for more on this.

In my experience is definitely more fun to type, but not worth the extra effort in terms of code maint. as the project gets better. As a lazy programmer, IDE’s should be doing my language testing and correction. I should be doing only the logical errors.

In practice, I find ironically that static typing allows me to think at a higher level and stay there. I know I’m not the only programmer who feels that way.

http://www.beust.com/weblog/archives/000269.html