[Oberon] identity of two VARs

[dlightfoot at brookes.ac.uk]

Dear all
The problem here is that Oberon, in common with most similar languages,
simply, and reasonably, does not offer facilities for such tests *within
the language*.

Using the facilities of SYSTEM is stepping outside the language itself,
and using addresses is a rather machine-oriented solution to what might be
considered a more general task, possibly for some 'reflection' facility,
namely to determine whether two *actual* parameters are 'disjoint'.

In any case, SYSTEM.ADR(source) will deliver the machine address at which
the formal parameter 'source' resides, not the array (string) to which
source refers, and so this will necessarily differ from
SYSTEM.ADR(target), since the two locations are disjoint. Notations within
Oberon for dereferencing pointers will not help since the strings are not
regarded by the Oberon program as being referred to via pointers. The test
SYSTEM.ADR(source[0]) = SYSTEM.ADR(target[0]) would appear to be the right
one.

If working in a design-by-contract style we would say that it is the
caller's responsibility to ensure that the two actual parameters are
disjoint -- this can be quite straightforward. But it nonetheless it would
seem useful to be able to test for this.

I am interested in knowing opinions as to what language facilities might
be appropriate for making tests such as disjointedness of actual
parameters, and whether people think their inclusion in a language would
be worth the trouble, given that it seems they would not be frequently
needed. There are other, more complex cases too.

If such a need is felt, I should like to formulate a general language
feature, and to suggest it to the designers of Zonnon for possible
inclusion in that language.

Best wishes

David Lightfoot
Co-editor, with Brian Kirk, of 'Zonnon Language Report'.
Language designers: Prof Dr Juerg Gutknecht and Dr Eugene Zueff, ETH Zuerich


> Op Wednesday 14 September 2005 17:48 schreef shark at gulfnet.sd64.bc.ca:
>
>  > PROCEDURE Identical*(VAR source, target: ARRAY OF CHAR):integer;
>  > (* Return 0, 1, 2 or 3 according to identity of location and
>  >    identity of content strings. *)
>  > VAR
>  > 	identicallocation, identicalcontent: INTEGER;
>  > BEGIN
>  > 	IF ?? THEN (* source and target are the same array *)
>  > 		identicallocation := 1 ELSE identicallocation := 0
>  > 	END;
>  > 	IF source = target THEN (* the strings in source and target match. *)
>  > 		identicalcontent := 1 ELSE identicalcontent := 0
>  > 	END;
>  > 	RETURN((2*identicalcontent)+identicallocation)
>  > END Identical;
>
> Why not:
>
> PROCEDURE Identical*(VAR source, target: ARRAY OF CHAR):integer;
>    (* Return 0, 1, 2 or 3 according to identity of location and
>       identity of content strings. *)
>
> BEGIN
>   IF  ??  THEN
>      RETURN (3)
>   ELSE
>      IF  src=target  THEN
>         RETURN (1)
>      ELSE
>         RETURN (2)
>      END
>   END;
>   RETURN (0)	(* Just in case.,.. *)
> END Identical;
>
> There are only THREE outcomes. If the strings are at the same location,
> they MUST be identical. So that's outcome 1. If they are in different
> places, they MAY be equal, so that's two more outcomes. So in total, you
> have three possible results, not four.
>
> As Wirth proclaims: if the code is unclear, your basic analysis was wrong.
> Back to the drawing table.
>
>  > More briefly,
>  > PROCEDURE Identical*(VAR source, target: ARRAY OF CHAR):integer;
>  > BEGIN
>  > 	RETURN((2*(source=target))+??)
>  > END Identical;.
>
> If Niklaus would have been dead (which he isn't to my knowledge and I hope
> it will stay so for many years to come), he would have turned in his grave
> after such a monstrous piece of code.
>
> Also, Martin Reiser is very explicit about this in 'Programming in
> Oberon':
>
>  | 4.2.2 Type rules.
>  |
>  | Let us look at a second set of syntactically well-formed expressions:
>  |
>  | 	"a" + 3.14159
>  | 	(a=b) - sqrt ("144")
>  |
>  | It is not clear how these expressions should be evaluated. What sense
>  | does it make to add a character constant to a number? Can a truth value
>  | be used as a number? There are various schools of thought with respect
>  | to these questions. Some languages (e.g. PL/I) define elaborate type
>  | conversion rules or treat truth values as the numerical constants 0 and
>  | 1 (e.g. APL). We believe that what such languages teach us is the way
>  | not to do it.
>
> I prefer longer code over C style functions.
>
> --
> Met vriendelijke groeten
>
> Jan Verhoeven
> http://fruttenboel.verhoeven272.nl
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://www.mail.inf.ethz.ch/lists/listinfo/oberon
>