What is Expressiveness in a Computer Language

[Rob Thorpe]

Andreas Rossberg wrote:
> Rob Thorpe wrote:
> >Andreas Rossberg wrote:
> >>Rob Thorpe wrote:
> >>
> >>>>>"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.
>
> I'm sorry, but I still think that the definition makes little sense.
> Obviously, a value simply *is* a value, it does not "represent" one, or
> several ones, regardless how you qualify that statement.

You've clipped a lot of context.  I'll put some back in, I said:-

> > 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.
> > Compare this to an untyped language where types cannot generally be
> > tested.

I think this should make it clear.  If I have a "xyz" in lisp I know it
is a string.
If I have "xyz" in an untyped language like assembler it may be
anything, two pointers in binary, an integer, a bitfield.  There is no
data at compile time or runtime to tell what it is, the programmer has
to remember.

(I'd point out this isn't true of all assemblers, there are some typed
assemblers)

> >>>Well I haven't programmed in any statically typed language where values
> >>>have types themselves.
> >>
> >>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,
>
> No, variables are insignificant in this context. You can consider a
> language without variables at all (such languages exist, and they can
> even be Turing-complete) and still have evaluation, values, and a
> non-trivial type system.

Hmm.  You're right, ML is no-where in my definition since it has no
variables.

> > But the value itself has no type
>
> You mean that the type of the value is not represented at runtime? True,
> but that's simply because the type system is static. It's not the same
> as saying it has no type.

Well, is it even represented at compile time?
The compiler doesn't know in general what values will exist at runtime,
it knows only what types variables have.  Sometimes it only has partial
knowledge and sometimes the programmer deliberately overrides it.  From
what knowledge it you could say it know what types values will have.

> > 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.
>
> Nothing in the C spec precludes an implementation from doing just that.

True, that would be an interesting implementation.

> The problem with C rather is that its semantics is totally
> underspecified. In any case, C is about the worst example to use when
> discussing type systems. For starters, it is totally unsound - which is
> what your example exploits.

Yes.  Unfortunately it's often necessary to break static type systems.

Regarding C the problem is, what should we discuss instead that would
be understood in all these newsgroups we're discussing this in.