🚀 go-pugleaf

In article <INFO-M2%89111611481682@UCF1VM> Modula2 List <INFO-M2%UCF1VM.BITNET@PSUVM.PSU.EDU> writes:
>Reply to John Baker's question about type transfer in Modula-2:
>
>I guess, your trouble about type transfers arises from the fact, that
>type transfers represent low-level facilities that are NOT DEFINED in
>the Modula-2 language definition. Wirth writes in his "Programming in
>Modula-2" (second edition, page 125):
>
>   " ... The correspondences (of transferred types) are NOT defined
>     by the language Modula. They must be supplied by additional
>     system-dependent information."
>
>Therefore type transfers depend on the actual implementation of the
>compiler one uses. So neither the text book you use nor the guy you
>asked are right. Type transfer functions are low level facilities
>that should be used only in machine-dependent system programs. They
>are NOT intended for high-level programming (for this purpose, Modula
>provides explicite type conversion on basic types by the standard
>procedure VAL).

I take Wirth's quote to mean that transferred types will not necessarily
result in the same values on different machines.  i.e. if 1234 (CARDINAL)
corresponds to 1.234 (REAL) on one machine, it may correspond to 4.321
on another.  (Unrealistic of course, but you get the idea.)  However, even
though both of my types were exactly the same length, the type transfer
itsself caused a run-time error!  Extending "correspondence" to include
the alignment of variables is an unfortunate burden on Modula-2 programmers.

I strongly disagree with your statement that type transfers should only
be used in system programs.  Nearly every good Modula-2 program will
use the CARDINAL and INTEGER type transfers at least.  In order to
increment a pointer, it is frequently necessary to convert it to type
ADDRESS and back.  The list goes on and on.  The ability to transfer
types is one of my favorite enhancements over PASCAL.

    - John Baker