Board index » delphi » Question about type identity

Question about type identity

I guess I don't understand type identity. If I say

  type
    Cookie = type integer;

I've declared Cookie as a new type, distinct from integer, yes? So how
come I can also say

 procedure Foo(N: integer); begin end;

 var
    X: integer = 1;
    Y: Cookie  = 2;

  begin
    X := Y;
    Y := X;
    Foo(X);
    Foo(Y);
  end.

What does type identity mean, if not that integer's and Cookie's aren't
assignment compatible?

--

http://www.midnightbeach.com    - Me, my work, my writing, and
http://www.midnightbeach.com/hs - my homeschool resource pages

 

Re:Question about type identity


: Jon Shemitz <j...@midnightbeach.com> wrote:

Quote
>I guess I don't understand type identity. If I say

>  type
>    Cookie = type integer;

>I've declared Cookie as a new type, distinct from integer, yes?

No. Only separate RTTI.

--
Replies that overquote or underquote are ignored.
If you attach any data to your message,
I will never see your message.

Re:Question about type identity


Quote
Stefan Hoffmeister wrote:

> : Jon Shemitz <j...@midnightbeach.com> wrote:

> >I've declared Cookie as a new type, distinct from integer, yes?

> No. Only separate RTTI.

Hmm. What's the point of that?

--

http://www.midnightbeach.com    - Me, my work, my writing, and
http://www.midnightbeach.com/hs - my homeschool resource pages

Re:Question about type identity


Quote
In article <3A9DE57E.4217F...@midnightbeach.com>, Jon Shemitz wrote:
> I guess I don't understand type identity. If I say

>   type
>     Cookie = type integer;

> I've declared Cookie as a new type, distinct from integer, yes? So how
> come I can also say

>  procedure Foo(N: integer); begin end;

You have declared N as value parameter, so passing something to this
parameter is equivalent to an assignment statement. For that type
*compatibility* is what determines whether the compiler will accept the
statement. Try to declare N as a Var parameter and you will get Foo(Y)
rejected by the compiler.

Peter Below (TeamB)  100113.1...@compuserve.com)
No e-mail responses, please, unless explicitly requested!
Note: I'm unable to visit the newsgroups every day at the moment,
so be patient if you don't get a reply immediately.

Re:Question about type identity


: Jon Shemitz <j...@midnightbeach.com> wrote:

Quote
>Stefan Hoffmeister wrote:

>> : Jon Shemitz <j...@midnightbeach.com> wrote:

>> >I've declared Cookie as a new type, distinct from integer, yes?

>> No. Only separate RTTI.

>Hmm. What's the point of that?

Property editors.
--
Replies that overquote or underquote are ignored.
If you attach any data to your message,
I will never see your message.

Re:Question about type identity


Quote
Jon Shemitz wrote:
>   type
>     Cookie = type integer;

> I've declared Cookie as a new type, distinct from integer, yes?

Thanks, Stefan and Peter. I guess I better understand what it does, now.

Seems strange, though, still. If it *did* allow you carve out Cookie as
a distinct type from integer, so that you couldn't inadvertently mix
Cookies with normal integers, then it would seem sort of useful in some
situations. As is, it seems like just a bizarre little footnote.

--

http://www.midnightbeach.com    - Me, my work, my writing, and
http://www.midnightbeach.com/hs - my homeschool resource pages

Re:Question about type identity


: Jon Shemitz <j...@midnightbeach.com> wrote:

Quote
>If it *did* allow you carve out Cookie as
>a distinct type from integer, so that you couldn't inadvertently mix
>Cookies with normal integers, then it would seem sort of useful in some
>situations.

How true, how utterly true.

You might want to report this as an enhancement request to Borland.
--
Replies that overquote or underquote are ignored.
If you attach any data to your message,
I will never see your message.

Re:Question about type identity


Re:Question about type identity


Stefan Hoffmeister <Borland.Newsgro...@econos.com> wrote in
<8rdt9tk24v0gor4j56cskc8gnp7qhgg...@4ax.com>:

Quote
>: Jon Shemitz <j...@midnightbeach.com> wrote:

>>If it *did* allow you carve out Cookie as
>>a distinct type from integer, so that you couldn't inadvertently
>>mix Cookies with normal integers, then it would seem sort of
>>useful in some situations.

>How true, how utterly true.

I totally agree with this _fact_. In programming as often in real
life, we need to be able to declare functionally equivalent types,
yet be able to distinguish between them in formal parameters (you
know, the variable declarations in the procedure declaration) in
order to use the inbuilt safe type system to help us catch potential
programming errors.

Quote
>You might want to report this as an enhancement request to
>Borland.

However, I do not see how such an enhancement would be possible,
backgrafted into an existing type system either without introducing
other weird behaviour, nor without a lot of work.

Unfortunately most programming languages today (including Pascal,
Modula, C, Haskell, Prolog ...) are based on the idea of
_type_equivalence_ which has some very desireable theoretical
properties. Or worse yet, an entirely broken version of type
equivalence specifically designed to make it a little more "real
world" (thankfully Pascal fits in here). Either way you end up with a
type system with some nice mathematical properties (but not good for
a generally accepted real world language), or, a type system that is
an absolute hack but that works acceptably for a fair dinkum
programming language. An example of pure type equivalence follows
(sorry if I get the syntax a bit up the creek, I'm new at Pascal, and
always have to refer to the docs, anyway it's not really Pascal ...):

type
  TPoint: record
    horiz: float;
    vert: float;
  end;

  TComplex: record   {To represent a complex number}
    x: float;
    y: float;
  end;

Now under pure type equivalence, these types are analysed and seen to
be records of two floats and therefore they are deemed type
equivalent, so the following is OK:

var
  MyPoint: TPoint = (horiz: 23.5, vert: 68.67);
  MyComplex: TComplex = (x: 15.1, y: -34.98);

begin
  MyPoint := MyComplex;  {This is _legal_!}
end;
Type equivalence does not look at how/where types are declared, just
the structure of the types and if structurally they are the same,
then they are deemed equivalent. This might be nice mathematically,
but is not how real life operates.

Thankfully Pascal specifically implemented a broken version of type
equivalence so that the above is illegal as obviously intended
(otherwise we would have just been done with one type declaration and
used it twice). Out the window goes the nice mathematical properties.

Besides these problems, most mainstream languages today lack proper
_Parametric_Polymorphism_ . Haven't you wanted to just have a TList
class that could hold values of any specific type, not just those
inherited from say TListItem. Enter Parametric Polymorphism (ie
polymorphic class behaviour based upon the parameter used to build
the class) C++'s templates sort of allow this, but WHAT a HACK!! More
like glorified sort of type safe proprocessor macros that duplicate
code instead of reusing it, ulch! (Please _don't_ do this in some
future version of Delphi). Here's an example:

IN THIS EXAMPLE THE CLASS PARAMETERS ARE POLYMORPHIC CLASS
PARAMETERS, _NOT_ INHERITED CLASSES!!

type
  TList: class(ItemType: class)
  begin
    { Whatever you need to make a polymorphic list class work }
    ...
    { Declaration for the polymorphic sorting function }
    procedure Sort(sorter: (function(val1,val2: ItemType):(-1..1)) )
    procedure Append(newitem: ItemType);
  end;

  TFloatList: TList(float);
  TBooleanList: TList(Boolean);  { Is that efficient storage? Duh }

var
  FloatList: TFloatList;
  BoolList: TBooleanList;

function FloatSortAscend(val1,val2: float): (-1..1);
begin
...
end;

{Just a handy little procedure that takes a _any_ list class and
 a suitable sorting function. Perhaps it pulls all the items out
 of the list into an internal array, and uses a very special sorting
 technique, then puts the items back into the list. A little
 contrived I know, but an example of parametric polymorphic power! }
procedure SpecialListSorter(TList(ItemType: class): class;
             SortFunc: (function(val1,val2: ItemType): (-1..1)) )

begin
  ...
  FloatList.Append(3.1415926535);  {OK}
  BoolList.Append(True);           {OK}
  FloatList.Append(True);          {No way!}
       {Compiler error: FloatList only stores floats, float expected}

  FloatList.Sort(FloatSortAscend); {OK}
       {Guaranteed compile-time correct: only a float sorter allowed}

  BoolList.Sort(FloatSortAscend);  {Compile-time error!}

  SpecialListSorter(FloatList, FloatSortAscend);  {OK}
  SpecialListSorter(BoolList, FloatSortAscend);  { Zap! }
       {Compile-time error! BoolList is a TList(Boolean), setting
        the ItemType to Bool in SpecialListSorter's declaration,
        which doesn't match the float type appearing in
        FloatSortAscend. }
end;

As you can see, this is pretty powerful compile-time type safe stuff!
(No run-time type checks in any of the above code.) Believe it or
not, I've only touched the surface of what is possible here ...

Now back-grafting Parametric Polymorphism into Delphi should not be
especially difficult and would give Delphi a _MAJOR_ advance over
existing _popular_ languages and without breaking existing code.

A friend and I have currently designed a programming language (no
compiler/interpreter yet :-( takes time!) for a Parametric
Polymorphic Object Oriented language based upon what we call 'Type
Matching' that is mathematically very nice _and_ real-world. There is
also automatic object freeing where _most_ freeing is calculated at
_compile-time_ _automatically_ and perfectly safe pointers to
local/stack objects passable as parameters in procedure calls with no
possibility of generating dangling pointers -- all checked at
_compile-time_ so there is no runtime performance hit. Object/class
inheritance can occur safely at _runtime_ with no performance hit and
no run-time type checking needed! Finally _most_ object usage results
code as efficient as C. This is unlike Delphi's object pascal (AFAIK,
correct me if I'm wrong ... the universal object polymorphism _must_
generate slower code IMHO) and C++ which take a significant
performance hit with object usage due to indirect table lookups
(although optimisers can get pretty intelligent). This inherant
efficiency allows _all_ types to universally be objects without
compromising performance. + the list of features goes on.

In summary:

Hopefully one day we will get a _real_world_ highly efficient (like
C/Fortran?) language with a modern sophisticated type system for
powerfully type-safe programming with most of the freedom found in C.
It _is_ possible! (If only some of there brilliant theoretical type
could just be a little more practical. Oh well, it might be a wait.)

David Bowers

Re:Question about type identity


Quote
: fuzthe...@hotmail.com (FuzTheCat) wrote:
>A friend and I have currently designed a programming language

I am very interested in learning more - because what you describe sounds
very good. URL / literature - anything greatly appreciated.

Quote
>There is
>also automatic object freeing where _most_ freeing is calculated at
>_compile-time_ _automatically_

This is a very nice property.

Quote
>and perfectly safe pointers to
>local/stack objects passable as parameters in procedure calls with no
>possibility of generating dangling pointers -- all checked at
>_compile-time_ so there is no runtime performance hit.

Your problem here is that with increasing complexity of an application,
compile time might grow exponentially.

IOW, you need a very strong compile-time expression evaluator, essentially
a program prover to the extent it is possible. The type system definitely
is a vital aspect of this.
--
Replies that overquote or underquote are ignored.
If you attach any data to your message,
I will never see your message.

Re:Question about type identity


Quote
> A friend and I have currently designed a programming language (no
> compiler/interpreter yet :-( takes time!) for a Parametric
> Polymorphic Object Oriented language based upon what we call 'Type
> Matching' that is mathematically very nice _and_ real-world.

I *definitely* want more information about that!  A URL or mailing list
address, anything.

Re:Question about type identity


This is probably off-topic now, and further discussion should
probably occur elsewhere, just Email me.

Stefan Hoffmeister <Borland.Newsgro...@econos.com> wrote in
<mb03at4t2k7f3rcvdrl5r5c1ouht40t...@4ax.com>:

Quote
>: fuzthe...@hotmail.com (FuzTheCat) wrote:

>>A friend and I have currently designed a programming language

>I am very interested in learning more - because what you describe
>sounds very good. URL / literature - anything greatly appreciated.

Hmm, sorry not too much avail at the moment, look at Ron's web page:
http://www.sci.usq.edu.au/staff/house/ The programming language is
called gUd, probably try E-mailing him?
Otherwise I could give you some URL/papers on parametric polymorphism
and another similar compile-time enhanced garbage collection
technology.

Quote
>>and perfectly safe pointers to
>>local/stack objects passable as parameters in procedure calls
>>with no possibility of generating dangling pointers -- all
>>checked at _compile-time_ so there is no runtime performance hit.

>Your problem here is that with increasing complexity of an
>application, compile time might grow exponentially.

True if you assume that the burden of _all_ proof for _any_
_arbitrary_ program is on the compiler ...

Quote
>IOW, you need a very strong compile-time expression evaluator,
>essentially a program prover to the extent it is possible. The
>type system definitely is a vital aspect of this.

True if you assume that the compiler is trying to prove that _any_
_given_  program is correct. The best way to do this is to just run
the program and look for any run-time errors :-). But of course that
defeats the whole purpose.

However this is not what we are doing. The compiler only tries to
establish the correctness of programs that can be done essentially in
linear time. When a given program cannot be proven so easily, the
place where the compiler has difficulty establishing safe
pointer/object lifetimes (or other type issues) is clearly pointed
out. Either there is a type error (the programmer fixes it) or just
not enough type information for the compiler to establish correctness
(the programmer adds some more type information).

The philosophy is: The programmer proves that the program is correct
(with as little effort as possible), and the compiler verifies this
proof. In practice it is surprising how little extra effort is
required for this extra type information proof ... much less than
managing all freeing/deallocation in C or pascal _correctly_, a
little more effort than for a fully run-time garbage collected
language with its associated run-time collection performance penalty.
(Although the fexibility of our type system allows pretty well both
extremes anywhere in the program.)

Other Threads