Oberon2 Questions 
Author Message
 Oberon2 Questions


Quote:
>I've been reading "The Programming Language Oberon-2" by Mossenbock and
>Wirth and have a few questions for anyone out there who can answer:

>[1] I've noticed that the receiver for type-bound procedures can be
>declared as variable (VAR).  What exactly does this mean?

>   PROCEDURE (VAR t: Tree) Insert(node: Tree);
>   ...

>Does it mean I can actually replace the receiver in the type-bound
>procedure (and not merely modify fields of the receiver)?

>   t := t.left

The VAR is only applicable when the formal receiver type is a record (not a
pointer). It is mostly useful when you have a statically allocated record
variable and want to call it's methods. The compiler (at the call site) can
be smarter about the call and not go through the normal method dispatch.

Assuming that Tree is a record type (not a pointer) you can make the
assignment. It's legal. Remember VAR parameters must 'match' (i.e., be of
identical type).

Quote:
>[2] Numeric types 'include' the values of smaller numeric types.
>Specifically, REAL 'includes' LONGINT.  Modula-2 (and C) compilers
>I'm familiar with  for 32-bit architectures implement REAL and LONGINT
>using 4-bytes. This apparently won't do for Oberon.  A fifth byte is
>needed to preserve the precision.  Is this how SPARC implementations of
>Oberon-2 do it (cf. Turbo Pascal 6-byte reals)?  Or does LONGREAL=REAL?

Huh? REAL usually is implemented with 4 bytes. Remember the interal format
for floating point numbers differs radically from integer types. You do not
lose precision going from integer to real. Going the other direction requires
the explicit use of ENTIER, and yes you lose the fractional part of the real
number when you do this. But that's what you want when you use ENTIER.

Quote:
>[3] According to the syntax of Oberon-2 in Appendix B., the
>types of procedure formals can be declared by any of the following:

>Type        ::= Qualident
>    | ARRAY ...
>    | RECORD ...
>    | POINTER TO ...
>    | PROCEDURE ...

>However, according to Appendix A, 'matching formal parameter lists'
>require 'same' or 'equal' types, which seems to render pretty useless
>formal types declared as:

[ specific example deleted]

Quote:
>No actual parameter (or result type) would ever match.  Why wasn't the
>grammar properly constrained to prevent this possibility?  Or am
>I missing something?

Yes, this is where structural equivalence is used instead of name equivalence.

Quote:

>[4] It's still not clear: Are strings ALWAYS null (0X) terminated?

Yes.

Quote:
>What about string assignment?

>  s: ARRAY 2 OF CHAR;

>  s := "12";

>What does s contain?  ("12" or "1"+0X)

No, you get a compiler error as "s" is too small to hold "12" plus the null.
Strings are always, always, always null terminated.

Quote:
>[5] Let's say MAX(INTEGER) = 2**15-1.  Can I do the following?

>    i: INTEGER;
>    i := 0FFFFX;  <- this should be 0FFFFH

>And does i = -1?

Yes. Though compiler may have a special syntax for negative hex numbers, as
0FFFFH could be either -1 or 65535. The former is OK for an INTEGER, the
latter is not. Compilers derived from the ETH front-end OP2 force you to
write 0FFFFFFFFH to get a -1.

Quote:
>[6] Type SYSTEM.PTR appears to be the same as Modula-2's ADDRESS.
>ADDRESS is defined as POINTER TO WORD.  Is SYSTEM.PTR defined as
>POINTER TO SYSTEM.BYTE? Or is it opaque?

SYSTEM.PTR is a pointer to something, and you don't know what. It's intended
use is for writing modules for implementing persistent objects. You must know
about type descriptors and other stuff. If you are a compiler writer or
system implementor you can use SYSTEM.PTR. Otherwise, ignore it. But then
why are you using SYSTEM anyway? (unless you're a compiler writer or other
low-level system hacker type).

--
Chuck Lins               | "Shut up! Be happy!" -- Jello Biafra
Apple Computer, Inc.     | Oberon-2 Paladin
20525 Mariani Avenue     |




Wed, 08 Jun 1994 01:54:39 GMT  
 Oberon2 Questions


|> >I've been reading "The Programming Language Oberon-2" by Mossenbock and
|> >Wirth and have a few questions for anyone out there who can answer:
|> >
|> >[1] I've noticed that the receiver for type-bound procedures can be
|> >declared as variable (VAR).  What exactly does this mean?
|> >
|> >   PROCEDURE (VAR t: Tree) Insert(node: Tree);
|> >   ...
|> >
|> >Does it mean I can actually replace the receiver in the type-bound
|> >procedure (and not merely modify fields of the receiver)?
|> >
|> >   t := t.left
|> >
|>
|> The VAR is only applicable when the formal receiver type is a record (not a
|> pointer). It is mostly useful when you have a statically allocated record
|> variable and want to call it's methods. The compiler (at the call site) can
|> be smarter about the call and not go through the normal method dispatch.
|>
|> Assuming that Tree is a record type (not a pointer) you can make the
|> assignment. It's legal. Remember VAR parameters must 'match' (i.e., be of
|> identical type).

If Tree is a record type, also extensions of Tree may be passed to Insert.
Type identity is required in case of pointers and all other types.

|> >[2] Numeric types 'include' the values of smaller numeric types.
|> >Specifically, REAL 'includes' LONGINT.  Modula-2 (and C) compilers
|> >I'm familiar with  for 32-bit architectures implement REAL and LONGINT
|> >using 4-bytes. This apparently won't do for Oberon.  A fifth byte is
|> >needed to preserve the precision.  Is this how SPARC implementations of
|> >Oberon-2 do it (cf. Turbo Pascal 6-byte reals)?  Or does LONGREAL=REAL?
|> >
|>
|> Huh? REAL usually is implemented with 4 bytes. Remember the interal format
|> for floating point numbers differs radically from integer types. You do not
|> lose precision going from integer to real. Going the other direction requires
|> the explicit use of ENTIER, and yes you lose the fractional part of the real
|> number when you do this. But that's what you want when you use ENTIER.

If LONGINT and REAL are implemented with 4 bytes we lose some precision
on implicit conversions from LONGINT to REAL simply because a REAL
presentation needs some bits for the exponent.
Consequently, REAL includes LONGINT only in the sense, that the range
of LONGINT values is covered by the range of REAL values.

|> >[3] According to the syntax of Oberon-2 in Appendix B., the
|> >types of procedure formals can be declared by any of the following:
|> >
|> >Type  ::= Qualident
|> >      | ARRAY ...
|> >      | RECORD ...
|> >      | POINTER TO ...
|> >      | PROCEDURE ...
|> >
|> >However, according to Appendix A, 'matching formal parameter lists'
|> >require 'same' or 'equal' types, which seems to render pretty useless
|> >formal types declared as:
|>
|> [ specific example deleted]
|>
|> >No actual parameter (or result type) would ever match.  Why wasn't the
|> >grammar properly constrained to prevent this possibility?  Or am
|> >I missing something?
|>
|> Yes, this is where structural equivalence is used instead of name equivalence.

Structural equivalence in case of procedure parameters applies only
in some limited form for open arrays. Following procedure is
syntactically correct, but there is no possiblity to call it:

   PROCEDURE BadProcedure(rec: RECORD a, b: INTEGER);
   END BadProcedure;

Structural equivalence is only used for procedure types (and as already
mentioned) in some limited form for open arrays. The former is necessary
to allow assignments like:

   TYPE MyProcType = PROCEDURE (i, j: INTEGER);
   VAR myproc: MyProcType;

   PROCEDURE Proc(i, j: INTEGER);
   END Proc;

   (* ... *) myproc := Proc; (* ... *)

|> >[4] It's still not clear: Are strings ALWAYS null (0X) terminated?
|> Yes.
|>
|> >What about string assignment?
|> >
|> >  s: ARRAY 2 OF CHAR;
|> >
|> >  s := "12";
|> >
|> >What does s contain?  ("12" or "1"+0X)
|>
|> No, you get a compiler error as "s" is too small to hold "12" plus the null.
|> Strings are always, always, always null terminated.

Here is a counter-example:

   s[0] := "1"; s[1] := "2";

This is legal and s becomes a string which is not null terminated.
Null terminated strings are *supported* by the language
(i.e. assignments of constant strings enforce a terminating 0X) and
hopefully by the library (which is, of course, optional).

|> >[5] Let's say MAX(INTEGER) = 2**15-1.  Can I do the following?
|> >
|> >    i: INTEGER;
|> >    i := 0FFFFX;  <- this should be 0FFFFH
|> >
|> >And does i = -1?
|>
|> Yes. Though compiler may have a special syntax for negative hex numbers, as
|> 0FFFFH could be either -1 or 65535. The former is OK for an INTEGER, the
|> latter is not. Compilers derived from the ETH front-end OP2 force you to
|> write 0FFFFFFFFH to get a -1.

An interesting feature of OP2 which is not covered by the report.

--



D-7900 Ulm, Germany     |   X.400:    S=borchert; OU=rz; P=uni-ulm; A=dbp; C=de



Wed, 08 Jun 1994 04:16:15 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Oberon->Oberon2 Question

2. Amiga Oberon2 compiler questions...

3. modula2 and Oberon2

4. Difference between Ada95 and Oberon2

5. Oberon2 Compiler Like LCC

6. Latest Oberon2 for win98 environment?

7. Oberon2 compiler for Windows98/ME

8. portability of Oberon2 codes

9. EBNF for Oberon2?

10. Modula2 vs Oberon2

11. lex/yacc files for Oberon2?

12. Atari ST Oberon2?

 

 
Powered by phpBB® Forum Software