Article View: comp.lang.misc
Article #238Re: Fortran90 and Arrays
From: Peter da Silva
Date: Wed, 15 Apr 1992 18:28
Date: Wed, 15 Apr 1992 18:28
55 lines
3696 bytes
3696 bytes
In article <STEPHEN.92Apr14162524@estragon.uchicago.edu> stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
> I surely can over the restricted domain. But the idea I was trying to
> capture was this: suppose you have two representations of a "point",
> one cartesian and one polar. Both are IMPLEMENTED as pairs of floats,
> and so they have the same CONCRETE representation. Both represent
> points on a plane, so they have the same intensional type. The same
> list of operators is provided for both variants. Question: do they
> have the same "type" or not?
No, because one supports the operation "extract X co-ordinate" and the
other supports the operation "extract distance from origin". You can
convert one to the other, and this might be a transparent operation
(apart from considerations such as execution speed), but they are not
the same type.
> There are actually cases where it is fully legitimate. Consider a
> routine that compares strings. In general one wishes to maintain the
> opacity of the character type - which character code is in use is an
> implementation-private affair - but the string comparison routine may
> LEGITIMATELY happen to know that chars are stored as 8 bit unsigneds
> with an alphabetically compatible order (let's say). From an external
> perspective, you'd say that the routine was punning. Internally,
> presumably, it is just in a scope where character and 8bit unsigned
> are identified.
Right, so you have a non-portable (that is, dependent on undefined
behaviour) routine. In general you want to avoid this, so you hide
this sort of code behind a subroutine interface. At least if you're
smart you do.
C is, by the way, not a good language for illustrating types because
issues of type, machine type, storage class, and even scope are all
muddied (for example, the same keyword is used to define static storage
class and file scope). All you hot compiler hackers, come out with some
good compilers for your language I can cheaply bootstrap and I'll dump
C like a hot potato.
> The representation selector does a good job, and chooses a one-word
> representation, packing all those fields together: "success" is
> represented by that word being > 1, in which case that word as a whole
> encodes the string value; otherwise the word as a whole is the error
> value (the compiler is making use of special knowledge that no string
> is stored at addresses below a certain number, of course. It's allowed
> to.).
Tough to do in C. Impossible to do portably. But sounds like a good way
to do things in a higher level language. In C you would have to create
a set of accessor macros that did appropriate tests and coercions, and
fix the implementation up for each new platform (for example, on the 286
it's very easy for a string to compare numerically less than 0).
--
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX 77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S
Technical Details
Message-ID:
<id.HHXO.DK9@ferranti.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!menudo.uh.edu!lobster!nuchat!sugar!ficc!peterReferences:
<STEPHEN.92Apr11201347@estragon.uchicago.edu> <id.OCVO.D6A@ferranti.com> <STEPHEN.92Apr14162524@estragon.uchicago.edu>Show Full Headers
Complete Article Headers
Newsgroups: comp.lang.misc Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!menudo.uh.edu!lobster!nuchat!sugar!ficc!peter From: peter@ferranti.com (Peter da Silva) Subject: Re: Fortran90 and Arrays Message-ID: <id.HHXO.DK9@ferranti.com> Sender: peter@ferranti.com (peter da silva) Organization: Xenix Support, FICC References: <STEPHEN.92Apr11201347@estragon.uchicago.edu> <id.OCVO.D6A@ferranti.com> <STEPHEN.92Apr14162524@estragon.uchicago.edu> Date: Wed, 15 Apr 1992 18:28:30 GMT Lines: 55