Parametric polymorphism: Difference between revisions
→{{header|F_Sharp|F#}}: Add Fortran.
m (→{{header|REXX}}: added/changed comments and whitespace, changed separator.) |
(→{{header|F_Sharp|F#}}: Add Fortran.) |
||
Line 415:
let t2 = t1.Map(fun x -> x * 10)
</lang>
=={{header|Fortran}}==
Fortran does not offer polymorphism by parameter type, which is to say, enables the same source code to be declared applicable for parameters of different types, so that a contained statement such as <code>X = A + B*C</code> would work for any combination of integer or floating-point or complex variables as actual parameters, since exactly that code would be workable in every case. Further, there is no standardised pre-processor protocol whereby one could replicate such code to produce a separate subroutine or function specific to every combination.
However, with F90 came the MODULE protocol with facilities suitable for defining "generic" subroutines or functions, or so it appears: <lang Fortran> MODULE SORTSEARCH !Genuflect towards Prof. D. Knuth.
INTERFACE FIND !Binary chop search, not indexed.
MODULE PROCEDURE
1 FINDI4, !I: of integers.
2 FINDF4,FINDF8, !F: of numbers.
3 FINDTTI2,FINDTTI4 !T: of texts.
END INTERFACE FIND
CONTAINS
INTEGER FUNCTION FINDI4(THIS,NUMB,N) !Binary chopper. Find i such that THIS = NUMB(i)
USE ASSISTANCE !Only for the trace stuff.
INTENT(IN) THIS,NUMB,N !Imply read-only, but definitely no need for any "copy-back".
INTEGER*4 THIS,NUMB(1:*) !Where is THIS in array NUMB(1:N)?
INTEGER N !The count. In other versions, it is supplied by the index.
INTEGER L,R,P !Fingers.
Chop away.
L = 0 !Establish outer bounds.
R = N + 1 !One before, and one after, the first and last.
1 P = (R - L)/2 !Probe point offset. Beware integer overflow with (L + R)/2.
IF (P.LE.0) THEN !Aha! Nowhere! And THIS follows NUMB(L).
FINDI4 = -L !Having -L rather than 0 (or other code) might be of interest.
RETURN !Finished.
END IF !So much for exhaustion.
P = P + L !Convert from offset to probe point.
IF (THIS - NUMB(P)) 3,4,2 !Compare to the probe point.
2 L = P !Shift the left bound up: THIS follows NUMB(P).
GO TO 1 !Another chop.
3 R = P !Shift the right bound down: THIS precedes NUMB(P).
GO TO 1 !Try again.
Caught it! THIS = NUMB(P)
4 FINDI4 = P !So, THIS is found, here!
END FUNCTION FINDI4 !On success, THIS = NUMB(FINDI4); no fancy index here...
END MODULE SORTSEARCH </lang>
There would be a function (with a unique name) for each of the contemplated variations in parameter types, and when the compiler reached an invocation of FIND(...) it would select by matching amongst the combinations that had been defined in the routines named in the INTERFACE statement. The various actual functions could have different code, and in this case, those for searching CHARACTER arrays differ, because the character comparison operations differ from those for numbers. Thus, function FIND would appear to be a polymorphic function, but it is not. That said, some systems had polymorphic variables, such as the B6700 whereby integers were represented as floating-point numbers and so exactly the same function could be presented with an integer or a floating-point variable (provided the compiler didn't check for parameter type matching - but this was routine) and it would work - so long as no divisions were involved since addition, subtraction, and multiplication are the same for both, but integer division discards any remainders.
More generally, using the same code for different types of variable can be problematical. A scheme that works in single precision may not work in double precision (or ''vice-versa'') or may not give corresponding levels of accuracy, or not converge at all, ''etc.'' While F90 also standardised special functions that give information about the precision of variables and the like, and in principle, a method could be coded that, guided by such information, would work for different precisions, this sort of scheme is beset by all manner of difficulties in problems more complex than the simple examples in text books. Polymorphism just exacerbates the difficulties, but sometimes it is not so troublesome, as in [[Pathological_floating_point_problems#The_Chaotic_Bank_Society]]
=={{header|Go}}==
The parametric function in this example is the function average. It's type parameter is the interface type intCollection, and its logic uses the polymorphic function mapElements. In Go terminology, average is an ordinary function whose parameter happens to be of interface type. Code inside of average is ordinary code that just happens to call the mapElements method of its parameter. This code accesses the underlying static type only through the interface and so has no knowledge of the details of the static type or even which static type it is dealing with.
| |||