The Artima Developer Community
Sponsored Link

Weblogs Forum
Comp. Sci. 101: Definition of Type

19 replies on 2 pages. Most recent reply: Dec 17, 2004 7:28 AM by Gregg Wonderly

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 19 replies on 2 pages [ « | 1 2 ]
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Comp. Sci. 101: Definition of Type Posted: Dec 9, 2004 4:06 PM
Reply to this message Reply
Advertisement
> > Not every semantic classification of values is a type,
> but
> > every type is a semantic classification of values.
>
> I agree with that statement, but doesn't that mean your
> definition requires further precision?

Maybe, but I can't see how I can refine it any further without becoming language specific.

> >I could
> > easily design a positive number type, or a negative
> >number
> > type, so I don't see how it is irrelevant.
>
> Well, yes, or a "Foo" or a "Bar". If the problem is "What
> subset of 'semantic classifications of values' is worth
> defining as the set of types we'll be using in our
> system,"

I think this is a separate issue to the definition of what type is.

> In your reply you said both that two types can have
> identical behavior (I assume you include range of values)
> and a single type can have multiple underlying
> representations. I'd submit that you're shifting
> perspective to argue both sides of the coin.

Not at all, both two statements are true. It is not a question of perspective.

> I argue that
> within a given language, a type is what a type does.

Without intending to be rude, that seems to be too broad of a definition to be useful.

> Yes, one can define two types that are identical but which
> have different type identifiers. C-style enums strike me
> as the closest common example to 'identical but usefully
> distinct,' but even enum directions { Left, Right } and
> enum political_leanings { Left, Right } have different
> behavior in that they can't be assigned interchangeably:
> that constraint is imposed by the type system, true, but
> that's the point -- types constrain behavior.

Nonetheless, two types can still have the same behaviour, yet differ in their representation or their label.

Consider the C++ example of:

struct Fu { int m; };
struct Bar { int m; };
Both Fu and Bar have the same behaviour and even the same structure but are separate types.

> If you
> create two identical types that have identical behavior
> (including range of values and assignment compatibility),
> surely it's fair to say that one of the two is erroneous?

No. They might be used to distinguish two ideas that may be disjoint, and may later on have future behavioural differences.

> My point about the von Neumann architecture echoes some of
> the concerns you had about Toby's response, although I
> think you are too quick to dismiss his perspective. The
> primacy of types in discussions of computer science is not
> coincidental to the primacy of the von Neumann
> architecture.

I don't understand what you mean here. Toby was referring to layout of bits which is far too narrow of a view of what a type is, even disregarding the assumptions of von Neumann architectures.

> In your reply to Toby you say "types don't necessarily
> have bits," which I don't follow.

Consider the void type, or an empty abstract base class.

Larry O'Brien

Posts: 7
Nickname: lobrien
Registered: Jul, 2003

Re: Comp. Sci. 101: Definition of Type Posted: Dec 10, 2004 11:09 AM
Reply to this message Reply
Your original question was whether your proposed definition was correct and complete. I believe it's correct, but incomplete. In short, I think that to be complete, you need to include the consequences of the type system ("... that constrains the way a variable of that type can be used" or somesuch).

However, you seem pretty happy with your definition and if it suits your needs, that's all that matters. I look forward to trying out Heron.

Cheers,
Larry

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

I think importance of Type is overemphasized Posted: Dec 14, 2004 10:48 PM
Reply to this message Reply
Definitely over-emphasized among the C++/Java static typing crowd.

The key design error in these languages is the confusion of type with protocol. I don't usually care what type something is as long as it conforms to a protocol. From a practical standpoint, protocol is what best determines substitutability. (You can pick up your car with a forklift to change a tire - the lifting device needn't be of "type" jack).

Unfortunately, in static environments, its type - which results in a sort of shallow hierarchy with lots of multiple inheritance (mixins) and excessive abstraction to gain reasonable flexibility.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: I think importance of Type is overemphasized Posted: Dec 14, 2004 11:20 PM
Reply to this message Reply
> Definitely over-emphasized among the C++/Java static
> typing crowd.

I don't think there is a problem with typing, but rather a misuse of type.

> The key design error in these languages is the confusion
> of type with protocol.

Type can be very useful to express conformance to a given protocol (or behaviour as it is commonly called). In fact this is arguably a more appropriate usage of type than to describe structure (i.e. bit layout).

> I don't usually care what type
> something is as long as it conforms to a protocol.

What other method do you have for verifying protocol conformance?

> From a
> practical standpoint, protocol is what best determines
> substitutability. (You can pick up your car with a
> forklift to change a tire - the lifting device needn't be
> of "type" jack).

The device should however be of type "lifting device", otherwise we can't know until run-time whether an arbitrary object will do the job or not.

> Unfortunately, in static environments, its type - which
> results in a sort of shallow hierarchy with lots of
> multiple inheritance (mixins) and excessive abstraction to
> gain reasonable flexibility.

You may be interested in my article "Polymorphism without Planning" at ttp://www.codeproject.com/cpp/retrofitpolymorphism2.asp on how to do behavioural subtyping in C++. Which is essentially a method of describing protocols, and conformance to protocols, but using types.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: I think a compiler/language tutorial and a memory content exercise help Posted: Dec 17, 2004 7:28 AM
Reply to this message Reply
In discusions involving language tools, the phrases "syntactic structure" and "semantic meaning" come up regularly. When you mix in "machine representation", you start to elevate all the visible issues that I think are important to understanding 'type'.

An example, bad C language program to demonstrate how the machine can be confused by 'machine representation' when the semantics of the type are not controlled by the languages syntactic structures.
void main( int argc, char args[][] ) {
    char arr1[20];
    int v1;
    char arr2[20];
    int v2;
    char arr3[20];
    int v3;
 
    v1 = -1;
    v2 = -2;
    v3 = -3;
    // copy in a 20 byte string
    strcpy(arr1, "0123456789012345678");
    // copy in 20 bytes
    memcpy(arr2, "01234567890123456789", 20);
    // mistakenly copy in a 21 byte string
    strcpy(arr3, "01234567890123456789");
    
    printf ("arr1: %s, arr2: %20.20s, arr3: %s, v1: %d, v2: %d\n", arr1, arr2, arr3, v1, v2, v3 );
}

You might also then include the same example in another language, such as Java and show the difference in what happens at runtime with type semantics.

public class x {
    public static void main( String args[] ) {
        byte arr1[] = new byte[20];
        int v1;
        byte arr2[] = new byte[20];
        int v2;
        byte arr3[] = new byte[20];
        int v3;
 
        v1 = -1;
        v2 = -2;
        v3 = -3;
 
        // create a 19 byte array
        byte[] b = "01234567890123456789".getBytes();
        // create a 20 byte array
        byte[] b2 = "01234567890123456789".getBytes();
        // create a 21 byte array
        byte[] b3 = "012345678901234567890".getBytes();
 
        // copy in a 20 byte string
        System.arraycopy(arr1, 0, b, 0, b.length );
 
        // copy in 20 bytes
        System.arraycopy(arr2, 0, b2, 0, b2.length );
 
        // Try to copy in a 21 byte string
        System.arraycopy(arr3, 0, b3, 0, b3.length );
 
        System.out.println("arr1: "+arr1+
            ", arr2: "+arr2+
            ", arr3: "+arr3+
            ", v1: "+v1+
            ", v2: "+v2+
            ", v3: "+v3+
            "" );
    }
}

Type safety is one aspect of types that should allow students to understand why certain languages are more useful in particular circumstances, than others.

You could use some shell functions to show how non-typed protocols that are just named function. Create a shell script such as
#!/bin/bash
 
. $1
 
# do something here with a function in the file 
# provided on the command line
...


This will show some elements of all the things that type conveys in various languages. The everything's a string flexibility of the shell and other similar scripting languages can be highly exploited. Used correctly, it can be quite impowering. Exploited for the sake of laziness, it can be disasterous.

If I really had to say a sentence or so about what type means, and provide no other explanation, ever, for a particular crowd, I think I'd say something like the following.


A type is like a human being. It has an outward appearence that is recognizable by visible attributes, but it also has an inner content and behavior which may not be understood without extensive investigation. Humans typecast because that groups and simplifies how many differences we really have to distinguish.

In computer programs, types (or typecasts) are used in similar ways. Somethings such as gender transend time (unless altered by a system change), while body shape, hair and eyesight vary over time, and don't necessarily change how a person interacts with the world.

Computer system types have similar life cycles because these systems do change over time. They are adapted to new uses and extended for new behaviours. Humans go to school to be trained for new behaviours. A computer program doesn't loose its training because it is a program. A Human might neglect its training through oversight or through distraction.

The misrepresentation of computer types by a language implementation can cause software to misbehave if distracting software is injected into the system. Viruses are a form of distracting software. Also, a software system can be misconfigured by an ignorant person or poorly written automation software and this can cause it to create incorrect results. HTML page syntax errors can be exploited to cause nondefensive programs to be compromized.


You could of course go on and on with similar ties between human type casts and computer types to show how many things are tied into this basic human need for compartmentalization and simplification.

Gregg

Flat View: This topic has 19 replies on 2 pages [ « | 1  2 ]
Topic: Excerpt: Beyond Lifestreams, the inevitable demise of the Desktop Metaphor Previous Topic   Next Topic Topic: Pitching a Fit

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use