What is Expressiveness in a Computer Language

[Chris F Clark]

Pascal Costanza wrote:
> Consider a simple expression like 'a + b': In a dynamically typed
> language, all I need to have in mind is that the program will attempt to
> add two numbers. In a statically typed language, I additionally need to
> know that there must a guarantee that a and b will always hold numbers.

"Marshall" <marshall.spight at gmail.com> replied:
> I would not expect that the dynamic programmer will be
> thinking that this code will have two numbers most of the
> time but sometimes not, and fail. I would expect that in both
> static and dynamic, the thought is that that code is adding
> two numbers, with the difference being the static context
> gives one a proof that this is so.

I don't think the the problem is down at the atom level.  It's really
at the structure (tuple) level.  If we view 'a + b' as applying the
function + to some non-atomic objects a and b.  The question is how
well do we specify what a and b are.  From my limited exposure to
programs that use dynamic typing, I would surmise that developers who
use dynamic typing have very broad and open definitions of the "types"
of a and b, and they don't want the type system complaining that they
have nailed the definitions down quite yet.  And, if you read some of
the arguments in this topic, one assumes that they want to even be
able to correct the "types" of a and b at run-time, when they find out
that they have made a mistake without taking the system down.

So, for a concrete example, let b be a "file" type (either text file
or directory) and we get a whole system up and running with those two
types.  But, we discover a need for "symbolic links".  So, we want to
change the file type to have 3 sub-types.  In a dynamic type system,
because the file "type" is loose (it's operationally defined by what
function one applies to b), this isn't an issue.  As each function is
recoded to deal with the 3rd sub-type, the program becomes more
functional.  If we need to demo the program before we have worked out
how symbolic links work for some operation, it is not a problem.  Run
the application, but don't exercise that combination of type and
operation.

In many ways, this can also be done in languages with type inference.
I don't understand the process by which one does it, so I can't
explain it.  Perhaps someone else will--please....

Back to the example, the file type is not an atomic type, but
generally some structure/tuple/list/record/class with members or
fields.  A function which renames files by looking at only the name
field may work perfectly adequately with the new symbolic link subtype
without change because the new subtype has the same name field and
uses it the same way.  A spell-check function which works on text
files using the "contents" field might need to be recoded for symbolic
links if the contents field for that subtype is "different" (e.g. the
name of the target).  The naive spell check function might appear to
work, but really do the wrong thing, (i.e. checking if the target file
name is made of legal words).  Thus, the type problems are not at the
atomic level (where contents is a string), but at the structure level,
where one needs to know which fields have which meanings for which
subtypes.

-Chris