NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/fortran/3331

Internet Message Format | 1992-09-01 | 3.7 KB

Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Newsgroups: comp.lang.fortran
Subject: Re: Scientists as Programmers (was Re: Smal
Message-ID: <[e-mail]>
Date: 1 Sep 92 13:55:54 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
Lines: 66

In article <[e-mail]> [e-mail] (Jim Giles) writes:
>In article <[e-mail]>, [e-mail] (Chris Flatters) writes:

            ..................

<|> It is rarely necessary to violate type constraints in a strongly typed language.
<|> When it is necessary it is possible to localize the code that does this.  Most
<|> typesafe languages provide mechanisms to avoid the constraints of the type
<|> system in these rare cases (eg. the WORD data type in Modula 2).

>The definition of the term `strongly typed' is that the types of all
>expressions are known to the compiler at compile time (it would be
>preferable if that were called static typing, but that's now used to
>mean that the data is statically *allocated* - oh well).  It is, however,
>*often* useful to be able to violate type constraints (if you know what
>you're doing - it's always a machine/system dependent thing to do).

>No one is recommending (and Herman didn't) that strict typing be abandoned.
>It is possible to have type coercion and *still* be able to statically
>determine type.  For example, the following declaration might be introduced
>(in no particular language):

>      float :: x(500)
>      type float_internal is
>         bit.1  :: sign
>         bit.8  :: exponent
>         bit.23 :: significand
>      end type float_internal
>      map x as float_internal    ! overlay the structure of floats on the array
>      ...
>      x.sign(1) = x.sign(1)+1    ! change the sign of x(1)
>      x.exponent(5) = x.exponent(5)+1    ! multiply x(5) by 2

I did mean that the user should be able, when appropriate, to completely
ignore the type.  This should be a deliberate act, however, by one who
knows what is being done.

The above example shows some of the problems.  The multiplication above
will work provided there is no overflow and x(5) != 0.  If the leading
bit of normalized numbers is present, it will also work if x(5) = 0, but
dividing by 2 by subtracting one from the exponent will not work.

Exponent arithmetic is slightly different than expected, and some machines
have a hardware instruction to do it.  It is necessary to be careful.

>This is much better than some anonymous `word' type.  Notice that
>everything used above is strongly typed.  The notion of `bit.n' as
>being n-bit unsigned integers was used, as well as the notion that
>a structure or record of such things is *packed* and remains in
>the order declared.  The only thing machine dependent is the map
>itself: otherwise the struct, or its components, behave exactly
>as any other objects of their respective declared types.

<|> [...]
<|> Restrictions on the introduction of new operators arise from practical
<|> considerations.  The introduction of a new infix operator changes the
<|> syntax of the language significantly.

>Well, it depends on how your syntax is specified and processed.  Haskell
>allows just about anything to be used as an operator and yet never has
>its syntax changed by user definitions.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!pop.stat!hrubin(UUCP)