What is Expressiveness in a Computer Language

[Rob Thorpe]

Matthias Blume wrote:
> "Rob Thorpe" <robert.thorpe at antenova.com> writes:
> > Andreas Rossberg wrote:
> >> Rob Thorpe wrote:
> >> >>
> >> >>>No, that isn't what I said.  What I said was:
> >> >>>"A language is latently typed if a value has a property - called it's
> >> >>>type - attached to it, and given it's type it can only represent values
> >> >>>defined by a certain class."
> >> >>
> >> >>"it [= a value] [...] can [...] represent values"?
> >> >
> >> > ???
> >>
> >> I just quoted, in condensed form, what you said above: namely, that a
> >> value represents values - which I find a strange and circular definition.
> >
> > Yes, but the point is, as the other poster mentioned: values defined by
> > a class.
> > For example, in lisp:
> > "xyz" is a string, #(1 2 3) is an array, '(1 2 3) is a list, 45 is a
> > fixed-point number.
> > Each item that can be stored has a type, no item can be stored without
> > one.  The types can be tested.  Most dynamic typed languages are like
> > that.
>
> Your "types" are just predicates.

You can call them predicates if you like.  Most people programming in
python, perl, or lisp will call them types though.

> > Compare this to an untyped language where types cannot generally be
> > tested.
>
> You mean there are no predicates in untyped languages?

Well, no there aren't.  That's what defines a language as untyped.

Of-course you can make them with your own code, in for example
assembler, but that's outside the language.

> >> They all have - the whole purpose of a type system is to ensure that any
> >> expression of type T always evaluates to a value of type T.
> >
> > But it only gaurantees this because the variables themselves have a
> > type, the values themselves do not.
>
> Of course they do.

I think we're discussing this at cross-purposes.  In a language like C
or another statically typed language there is no information passed
with values indicating their type.  Have a look in a C compiler if you
don't believe me.  You store 56 in a location in memory then in most
compilers all that will be store is 56, nothing more.  The compiler
relys entirely on the types of the variables to know how to correctly
operate on the values.  The values themselves have no type information
associated with them.

> >  Most of the time the fact that the
> > variable they are held in has a type infers that the value does too.
> > But the value itself has no type, in a C program for example I can take
> > the value from some variable and recast it in any way I feel and the
> > language cannot correct any errors I make because their is no
> > information in the variable to indicate what type it is.
>
> Casting in C takes values of one type to values of another type.

No it doesn't. Casting reinterprets a value of one type as a value of
another type.
There is a difference.  If I cast an unsigned integer 2000000000 to a
signed integer in C on the machine I'm using then the result I will get
will not make any sense.

> >> So when you
> >> look at type systems formally then you certainly have to assign types to
> >> values, otherwise you couldn't prove any useful property about those
> >> systems (esp. soundness).
> >
> > Yes, but indirectly.
>
> No, this is usually done very directly and very explicitly.

No it isn't.
If I say "4 is a integer" that is a direct statement about 4.
If I say "X is and integer and X is 4, therefore 4 is an integer" that
is a slightly less direct statement about 4.

The difference in directness is only small, and much more indirectness
is needed to prove anything useful about a system formally.