IS Extacy Oberon-2 Oberon-2? 
Author Message
 IS Extacy Oberon-2 Oberon-2?

My question is whether Extacy is conformant to Oberon-2 specvification.
The problem is with constant expressions those are defined differently in
Oberon and Oberon-2 Reports. Oberon Report states that a constant expression is
one which "operands are constants", while Oberon-2 Report adds to this "or
predeclared functions that can be evaluated at compile time." Normally,
such functions as SIZE can be "evaluated at compile time", however, Extacy
prohibits their use in constant expression, in particular, as an operand of
an expression defining size of an array. Does it mean that Extacy Oberon-2
is not conformant to the specification of Oberon-2 from ETH?

In my opinion, Oberon-2 Report is much more contradictionary an poorer than
Oberon-1, in general and in paritucalr in this point; morever, in my opinion
use of predeclared functions in constant expressions should be prohibited; but
the question is about compliance, not about the best solution for the problem.

David Tolpin.



Wed, 06 Mar 1996 03:56:22 GMT  
 IS Extacy Oberon-2 Oberon-2?

Quote:

>My question is whether Extacy is conformant to Oberon-2 specvification.
>The problem is with constant expressions those are defined differently in
>Oberon and Oberon-2 Reports. Oberon Report states that a constant expression is
>one which "operands are constants", while Oberon-2 Report adds to this "or
>predeclared functions that can be evaluated at compile time." Normally,
>such functions as SIZE can be "evaluated at compile time", however, Extacy
>prohibits their use in constant expression, in particular, as an operand of
>an expression defining size of an array. Does it mean that Extacy Oberon-2
>is not conformant to the specification of Oberon-2 from ETH?

Quite some time ago, when I only had access to the (in)famous OberonM
(which does not evaulate expressions at compile time), I asked the author
of OP2 is certain expressions were legal (such as SIZE) at compile time.
The answer was yes.   I also asked how agressive OP2 was when evaluating
constant expressions at compile-time.  The answer was a very specific: VERY.

The Oberon reports do not specifically say that you have to evaluate all
constant expressions at compile time, but if you have code that is
accepted by one compiler, but rejected by another on the basis of constant
expressions, I would say that the non-accepting compiler is not conforming.

Taylor "Sept 21.... Sept 21.... Sept 21" Hutt
Championing worldwide usage of Oberon-2!



Fri, 08 Mar 1996 19:47:45 GMT  
 IS Extacy Oberon-2 Oberon-2?

Quote:

>My question is whether Extacy is conformant to Oberon-2 specvification.
>The problem is with constant expressions those are defined differently in
>Oberon and Oberon-2 Reports. Oberon Report states that a constant expression is
>one which "operands are constants", while Oberon-2 Report adds to this "or
>predeclared functions that can be evaluated at compile time." Normally,
>such functions as SIZE can be "evaluated at compile time", however, Extacy
>prohibits their use in constant expression, in particular, as an operand of

[ deleted ]

Normally yes (can be evaluated at compile time) but not in
the case of Oberon to C translator, where the size
depends on platform, C compiler using, C compiler options, ...

Quote:
>In my opinion, Oberon-2 Report is much more contradictionary an poorer than
>Oberon-1, in general and in paritucalr in this point; morever, in my opinion
>use of predeclared functions in constant expressions should be prohibited; but

Why do you want to prohibit the use of such functions as CAP, ORD,
LONG, SHORT in the constant expressions?
There is nothing wrong in it.

-- Alex

-----------------------------------------------------
Institute of Informatics Systems, Novosibirsk, Russia



Fri, 08 Mar 1996 14:22:28 GMT  
 IS Extacy Oberon-2 Oberon-2?


Quote:

>>while Oberon-2 Report adds to this "or
>>predeclared functions that can be evaluated at compile time." Normally,
>>such functions as SIZE can be "evaluated at compile time", however, Extacy
>>prohibits their use in constant expression, in particular, as an operand of
>[ deleted ]

>Normally yes (can be evaluated at compile time) but not in
>the case of Oberon to C translator, where the size
>depends on platform, C compiler using, C compiler options, ...

I think you should be able to define a macro that deals with the problem.
Instead of evaluating the value at the time the Oberon compiler runs, create
a name for the constant and refer to that constant, e.g.

        x: ARRAY SIZE(T)*10 OF CHAR

becomes

        #define _const0001 (sizeof(T)*10)

        CHAR x[_const0001];

This way, the C preprocessor and the C compiler will deal with the problem.

Marc

Marc-Michael Brandis
Institute for Computer Systems
ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland



Sat, 09 Mar 1996 19:27:52 GMT  
 IS Extacy Oberon-2 Oberon-2?

: Normally yes (can be evaluated at compile time) but not in
: the case of Oberon to C translator, where the size
: depends on platform, C compiler using, C compiler options, ...

The question was not whether it is possible or not, but is it allowed for a con-
forming compiler to reject use of SIZE() in constant expressions. I do know
about problems of design of a something-to-C translator. I wrote some.

David. Still trying to get the answer.



Sun, 10 Mar 1996 04:33:16 GMT  
 IS Extacy Oberon-2 Oberon-2?
: Oberon Report states that a constant expression is
: one which "operands are constants", while Oberon-2 Report adds to this "or
: predeclared functions that can be evaluated at compile time." Normally,
: such functions as SIZE can be "evaluated at compile time", however, Extacy
: prohibits their use in constant expression, in particular, as an operand of
: an expression defining size of an array. Does it mean that Extacy Oberon-2
: is not conformant to the specification of Oberon-2 from ETH?

I don't feel like playing language lawyer today. Here are
some other criterion.

#1. POWEROberon ( an ETH based compiler ) accepts
        BLOCK = ARRAY SIZE( INTEGER ) OF CHAR;

#2. The customer is always right. Extacy won't compile my
ETH Oberon code. Extacy is broken.

I doubt this is a serious problem. RTA is very good at
fixing these kind of things promptly. Best yet is that
the interim solution is trivial.

It is too bad they didn't get this right. They have support for
printf().

BTW, Here is a more serious problem with Extacy. My
Out.String("hello world\n") doesn't code work properly
and fixing it is much more difficult.

        hello world\n

Whitney



Mon, 11 Mar 1996 01:08:06 GMT  
 IS Extacy Oberon-2 Oberon-2?

Quote:
>The question was not whether it is possible or not, but is it allowed for a con-
>forming compiler to reject use of SIZE() in constant expressions. I do know
>about problems of design of a something-to-C translator. I wrote some.

If you ask me I'll say yes (a conforming compiler can reject..),
but as usual we should wait for ETH response..

Quote:
>David. Still trying to get the answer.

Still acompaning you.

-- Alex

Russia today is the country of 2 presidents.
Is it the maximum value?



Sun, 10 Mar 1996 19:47:00 GMT  
 IS Extacy Oberon-2 Oberon-2?

Quote:

>I think you should be able to define a macro that deals with the problem.
>Instead of evaluating the value at the time the Oberon compiler runs, create
>a name for the constant and refer to that constant, e.g.

>        x: ARRAY SIZE(T)*10 OF CHAR

>becomes

>        #define _const0001 (sizeof(T)*10)

>        CHAR x[_const0001];

>This way, the C preprocessor and the C compiler will deal with the problem.

A very simple example:

VAR x: ARRAY SIZE(T) OF CHAR;

  x:="ABC";

It is impossible to decide is it assignement compatible or not!

-- Alex

-----------------------------------------------------
Institute of Informatics Systems, Novosibirsk, Russia



Sun, 10 Mar 1996 19:42:17 GMT  
 IS Extacy Oberon-2 Oberon-2?

Quote:


>: Normally yes (can be evaluated at compile time) but not in
>: the case of Oberon to C translator, where the size
>: depends on platform, C compiler using, C compiler options, ...

>The question was not whether it is possible or not, but is it allowed for a
>conforming compiler to reject use of SIZE() in constant expressions. I do know
>about problems of design of a something-to-C translator. I wrote some.

The Oberon-2 report is very clear on this.

        5. Constant declarations

        A constant declaration associates an identifier with a constant value.

                ConstantDeclaration     = IdentDef "=" ConstExpression.
                ConstExpression         = Expression.

        A constant expression is an expression that can be evaluated by a mere
        textual scan without actually executing the program. Its operands are
        constants (Ch.8) or predeclared functions (Ch.10.3) that can be
        evaluated at compile time.

SIZE is one of the predeclared functions in Ch.10.3. A conforming Oberon-2
compiler must allow SIZE in constant expressions, and as pointed out in my
previous posting, I do not really see a problem in allowing it.

Marc

Marc-Michael Brandis
Institute for Computer Systems
ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland



Mon, 11 Mar 1996 17:16:30 GMT  
 IS Extacy Oberon-2 Oberon-2?
Hello,

Quote:

>The question was not whether it is possible or not, but is it allowed for a
> con-
>forming compiler to reject use of SIZE() in constant expressions. I do know
>about problems of design of a something-to-C translator. I wrote some.

>David. Still trying to get the answer.

It is my personal opinion and not necessarily official opinion of  xTech
and/or RTA.

I do agree with your complain. You are right, but I think it is not  our
fault.

Situation is following. SIZE is havily platform, compiler, memory model,
and compiler swithes dependant.

TYPE abc = RECORD
  c1: CHAR;
  i1: INTEGER;
  c2: CHAR;
  i2: LONGINT;
  c3: CHAR;
END;

This record size vary from 9 to 40 bytes  depending  on  size  of  basic
types and alignements. Moreover, you will  get  different  results  even
using different C compilers on MS DOS.

So, Extacy cannot know in advance SIZE(T) (even in simple  cases  -  you
could easily change basic types in RTS header file X2C.h).

Definitely Extacy can generate correct code in such cases - it is not  a
problem.

However, Modula-2 and Oberon-2 are  known  as  "safe"  languages.  Among
other things this means that compiler should perform ALL possible checks
during compilation. It is impossible for SIZE(T) pseudo-constant.

Having  a  choice  between  safeness  and  ETH   conformance,   compiler
developers chose safeness.

Taking into account it is perfectly legal from "Oberon-2  report"  which
can be thought as standard language specification, I do  believe  it  is
perfectly legal solution.

Moreover, my personal impression is that there  is  very  bad  style  to
declare SIZE-dependant data structures and  constants  which  should  be
prohibited.

I cannot accept "it works with PowerOberon but not with Extacy" as valid
argument.

Oberon-2 report specify the Oberon-2 syntax and semantics, and Extacy is
completely conformant with this specification.

Reference to another implementation cannot be  accepted  simply  because
ETH implementations differ from platform to platfrom. DOS version is  16
bits,   Mac   implementation   contain    unique    extenstions,    UNIX
implementations contain interface to  X11  etc,  Ceres  version  contain
another set of unique extensions, and so on.

So which version should be taken as the prototype?

Another question:

MODULE test;

VAR
  i : INTEGER;
  j, k : LONGINT;

BEGIN
  j := 0;
  FOR i := -32768 TO 32767 BY 11 DO
    INC (j)
  END;
  out (j DIV 65536);
END test.

What is the result on your version of Oberon? And what do you  think  is
the correct result?

I know 3 different answers, and ETH Oberon for DOS gave  me  the  4th  -
crash.

I think the reason is ETH put too many things  into  "machine-dependant"
and "implementation-dependant" area.

I think it is up to ETH to say the final word and give or  not  to  give
their blessing :-).

With best regards,

Andrew Cadach

--
 ----------------------------------------------------------


 Real Time Associates             CompuServe: 71333,2346
 Canning House, 59 Canning Road   Tel: (+44) (0)81 656 7333
 Croydon, Surrey, CRO 6QF, UK     Fax: (+44) (0)81 655 0401
 ----------------------------------------------------------



Mon, 11 Mar 1996 17:46:32 GMT  
 IS Extacy Oberon-2 Oberon-2?

Quote:

>Hello,


>Situation is following. SIZE is havily platform, compiler, memory model,
>and compiler swithes dependant.

>TYPE abc = RECORD
>  c1: CHAR;
>  i1: INTEGER;
>  c2: CHAR;
>  i2: LONGINT;
>  c3: CHAR;
>END;

>This record size vary from 9 to 40 bytes  depending  on  size  of  basic
>types and alignements. Moreover, you will  get  different  results  even
>using different C compilers on MS DOS.

>So, Extacy cannot know in advance SIZE(T) (even in simple  cases  -  you
>could easily change basic types in RTS header file X2C.h).

You are correct.  ETH is correct.  A solution I see to this dilemma is to
put out an 'implementation limitation' type error message.  In your
document which explains this error, you should describe the problems
encountered with constant expressions in a translator such as Extacy.

Quote:
>Moreover, my personal impression is that there  is  very  bad  style  to
>declare SIZE-dependant data structures and  constants  which  should  be
>prohibited.

I disagree here.  Here is an example that is rather silly, but is does
show a good reason to have this.  (LEN falls into constant category,
doesn't it?  (I hope so)).

CONST
   Copyright = "Copyright (c) 1900";

VAR
   CopyrightMsg : ARRAY LEN(Copyright) OF CHAR;

Quote:
>I cannot accept "it works with PowerOberon but not with Extacy" as valid
>argument.

In general, I agree.  But, here we have a case of an 'assumed to be
compliant' compiler and a third party compiler.  Comparing Extacy to a
known compiler (produced by the people holding the language definition in
their hands) is valid, much as comparing Borland C++ to C-front would be
valid.

Quote:
>Reference to another implementation cannot be  accepted  simply  because
>ETH implementations differ from platform to platfrom. DOS version is  16
>bits,

DOS version is 32 bits.

- Show quoted text -

Quote:
>Another question:

>MODULE test;

>VAR
>  i : INTEGER;
>  j, k : LONGINT;

>BEGIN
>  j := 0;
>  FOR i := -32768 TO 32767 BY 11 DO
>    INC (j)
>  END;
>  out (j DIV 65536);
>END test.

>What is the result on your version of Oberon? And what do you  think  is
>the correct result?

I will try this on my version and see what results I get.  But, with my
logic, you have to compare my result to Oberon386, so if I don't crash, my
answer is wrong?!? :-)

thutt-man
Championing worldwide usage of Oberon-2!



Mon, 11 Mar 1996 20:04:44 GMT  
 IS Extacy Oberon-2 Oberon-2?
: >Situation is following. SIZE is havily platform, compiler, memory model,
: >and compiler swithes dependant.
: >
: >TYPE abc = RECORD
: >  c1: CHAR;
: >  i1: INTEGER;
: >  c2: CHAR;
: >  i2: LONGINT;
: >  c3: CHAR;
: >END;
: >
: >This record size vary from 9 to 40 bytes  depending  on  size  of  basic
: >types and alignements. Moreover, you will  get  different  results  even
: >using different C compilers on MS DOS.
: >

: >So, Extacy cannot know in advance SIZE(T) (even in simple  cases  -  you
: >could easily change basic types in RTS header file X2C.h).
: >

Sounds like you need a configuration file for the front end ( XC ).
This file would specify the size of the basic types. It would need
to be in agreement with the backend for the XC/C compiler pair to
work properly.

: >I cannot accept "it works with PowerOberon but not with Extacy" as valid
: >argument.

It wasn't intended to be. I should have written the full expression.
"The customer is always right no matter how wrong they are."

It is annoying for CONST size=SIZE(T) to work with compiler but
not another.

Whitney



Mon, 11 Mar 1996 20:54:29 GMT  
 IS Extacy Oberon-2 Oberon-2?

Quote:

>The Oberon-2 report is very clear on this.

>        5. Constant declarations

>        A constant declaration associates an identifier with a constant value.

>                ConstantDeclaration     = IdentDef "=" ConstExpression.
>                ConstExpression         = Expression.

>        A constant expression is an expression that can be evaluated by a mere
>        textual scan without actually executing the program. Its operands are
>        constants (Ch.8) or predeclared functions (Ch.10.3) that can be
>        evaluated at compile time.

>SIZE is one of the predeclared functions in Ch.10.3. A conforming Oberon-2
>compiler must allow SIZE in constant expressions, and as pointed out in my
>previous posting, I do not really see a problem in allowing it.

According to the definition given above, it is perfectly acceptable for Extacy
to reject SIZE in a constant expression since Extacy cannot evaluate SIZE
at compile time.

        "Its operands are constants (Ch. 8) or predeclared functions (Ch.10.3)
         that can be evaluated at compile time"

                ^---- Extacy can't evaluate SIZE at compile time so no problem
                      here.

I know that this is playing semantic games, but if you really mean that
predeclared functions such as SIZE *MUST* be allowed in constant expressions,
it should be stated explicitly - not left to individual interpretation!

i.e. Its operands are constants or the predeclared functions SIZE, ...

Dave.

--
_______________________________________________________________________________

Dave Fox                                      'Some really funny and
Real Time Associates Ltd                         devastatingly witty quote
Canning House, 59 Canning Road                     would normally go here,
Croydon, Surrey CR0 6QF,                             but I can't think of one!'
UK
------------------------------------------------------------------------------



Tue, 12 Mar 1996 00:07:18 GMT  
 IS Extacy Oberon-2 Oberon-2?
Hello,

Quote:

>        A constant expression is an expression that can be evaluated by a mere
>        textual scan without actually executing the program. Its operands are
>        constants (Ch.8) or predeclared functions (Ch.10.3) that can be

                                                                ^^^^^^^^

Quote:
>        evaluated at compile time.

>SIZE is one of the predeclared functions in Ch.10.3. A conforming Oberon-2
>compiler must allow SIZE in constant expressions, and as pointed out in my
         ^^^^^^
>previous posting, I do not really see a problem in allowing it.

>Marc

I see huge difference between "must" and "can". Definitely you can gimme
$1000, but you will be very surprised if I say "you must give me $1000",
isn't it? I think, the same logic should be applied in this case, or  am
I wrong?

Why do you think SIZE can be evaluated  at  compile  time?  What  if  it
cannot?

I thought this "can be"  means  "if  compiler  implementation  evaluates
predeclared function(s) at compile time". If  it  means  "compiler  must
necessarily calculate all predeclared functions  at  compile  time"  the
word "must" should be used. I think people at  ETH  perfectly  know  the
difference between "can" and "must", and this  particular  case  is  put
into "compiler-dependant" area.

With best regards,

Andrew Cadach
--
 ----------------------------------------------------------


 Real Time Associates             CompuServe: 71333,2346
 Canning House, 59 Canning Road   Tel: (+44) (0)81 656 7333
 Croydon, Surrey, CRO 6QF, UK     Fax: (+44) (0)81 655 0401
 ----------------------------------------------------------



Mon, 11 Mar 1996 18:06:37 GMT  
 IS Extacy Oberon-2 Oberon-2?

Quote:

>: >Situation is following. SIZE is havily platform, compiler, memory model,
>: >and compiler swithes dependant.
>: >
>: >TYPE abc = RECORD
>: >  c1: CHAR;
>: >  i1: INTEGER;
>: >  c2: CHAR;
>: >  i2: LONGINT;
>: >  c3: CHAR;
>: >END;
>: >
>: >This record size vary from 9 to 40 bytes  depending  on  size  of  basic
>: >types and alignements. Moreover, you will  get  different  results  even
>: >using different C compilers on MS DOS.
>: >

>: >So, Extacy cannot know in advance SIZE(T) (even in simple  cases  -  you
>: >could easily change basic types in RTS header file X2C.h).
>: >

>Sounds like you need a configuration file for the front end ( XC ).
>This file would specify the size of the basic types. It would need
>to be in agreement with the backend for the XC/C compiler pair to
>work properly.

>Whitney

    The MAINSAIL language provides the size of basic types which differ
from implementation to implementation.  The value SIZE(x) DIV intSize
would give the number of integer size multiples of x.

Doug Danforth
--
UMECORP, The creator of UME Voice
73 Digital Drive
Novato, CA 94949
pho (415) 883-1500, fax (415) 883-1711



Tue, 12 Mar 1996 01:49:12 GMT  
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Oberon libraries for Extacy.EXE

2. Extacy portable Oberon-2 and Modula-2 compiler demo is available on ftp

3. Extacy Oberon-2/Modula-2 available on ftp

4. Extacy Oberon-2/Modula-2 available on ftp

5. Extacy portable Oberon-2 and Modula-2 compiler demo is available on ftp

6. Extacy Modula-2/Oberon-2 is available on ftp

7. I am excited about Oberon again!!!!!

8. Frage Oberon 3 / Question Oberon 3

9. CD-Oberon - Oberon/F

10. CD-Oberon Oberon 3 Printer Problem

11. Oberon System 3 / Native Oberon projects

12. inquiry about Visual Oberon/PC Native Oberon System 3

 

 
Powered by phpBB® Forum Software