xcriber51

External User

 

Posts: 1

Hi

A very simple question (couldn't find the answer in the Help of BlackBox).
I want to create a string as a lookup table, so I want to make it a
constant. e.g.

CONST Encodings = "01230124022455012623017272";

But then, since I want to use it as a lookup table, I want to access it
with an index, e.g.

ch := Encodings[i];

Unfortunately, the compiler tells me this is a no-no. What exactly is the
reasoning behind this rule?

Thanks.


-- Ken


--
Message posted using http://www.talkaboutprogramming.com/group/comp.lang.oberon/
More information at http://www.talkaboutprogramming.com/faq.html

stefano ferrari

CONST strings are not arrays!

You can do this

CONST Encodings = "01230124022455012623017272";

VAR encodings: ARRAY 32 OF CHAR;

ecodings$ := Encodings;

ch := encodings[i];

Regards
Stefano

xcriber51

External User

 

Posts: 1

Thanks Stefano. However, the result is the same: the compiler refuses to
assign that constant to a variable. However, when I use that same constant
as input to the "Extract" function in the "Strings" module, it works.

PROCEDURE constarray*(dummy: ARRAY OF CHAR);
CONST Encodings = "01230124022455012623017272";
VAR buff: ARRAY 2 OF CHAR;
encodings: ARRAY 32 OF CHAR;
BEGIN
(* Doesn't work *)
(*encodings$ := Encodings*);

(* Works *)
Strings.Extract(Encodings,5,1,buff);
log.String("{"+buff+"}"); log.Ln

END constarray;

I find this pretty confusing. Also, my question was do you know the
"reasoning" behind this -- i.e. why are constant strings not treated as
arrays in BlackBox (or the Oberon specification?) when we know that
strings (at least their internal representation) can only be an array of
characters?

Thanks again.


-- K


--
Message posted using http://www.talkaboutprogramming.com/group/comp.lang.oberon/
More information at http://www.talkaboutprogramming.com/faq.html

stefano ferrari

Sorry I posted a wrong solution.

The correct one is

CONST Encodings = "01230124022455012623017272";


VAR encodings: ARRAY 32 OF CHAR;


ecodings := Encodings; (* omit $ symbol *)


ch := encodings[i];


Constant strings are assignment compatible with array of char, but
they are not arrays

stefano ferrari

As follow up never trust on internal representation, because this way
also integer and real numbers can be seen as a sequence of bytes. That
would lead to a C or BCPL programming style.

Regards
Stefano

xcriber51

External User

 

Posts: 1

OK, Stefano, thanks for the advice.

I was only relying on what almost every programmer has come to view
strings as, but obviously Oberon designers are smarter than the rest of
us.

What you gave me, however, was again only an assertion, not a REASON. I
asked why was this decision made. Because, you see, then I can do the
following:

MODULE ConstAccess;

IMPORT
log:= StdLog, Strings;

CONST
Encodings = "01230124022455012623017272";

PROCEDURE Helper(a: ARRAY OF CHAR; idx: INTEGER);
VAR buff: ARRAY 2 OF CHAR;
BEGIN

buff[0] := a[idx]; buff[1] := 0X;
log.String("|"+buff+"|"); log. Ln

END Helper;

PROCEDURE Do*(dummy: ARRAY OF CHAR);
VAR ch: CHAR;
buff: ARRAY 2 OF CHAR;
encodings: ARRAY 32 OF CHAR;
BEGIN
encodings := Encodings;

ch := encodings[5];
log.Char('['); log.Char(ch); log.Char(']'); log.Ln;

Helper(Encodings,5);

Strings.Extract(Encodings,5,1,buff);
log.String("{"+buff+"}"); log.Ln

END Do;

END ConstAccess.

So, in the "Do" routine here, I cannot access the Encodings constant
directly from within, but when I pass it as a parameter to another one,
that routine can.

Any explanation for this design choice?


-- K


--
Message posted using http://www.talkaboutprogramming.com/group/comp.lang.oberon/
More information at http://www.talkaboutprogramming.com/faq.html

stefano ferrari

In PROCEDURE Helper(a: ARRAY OF CHAR; idx: INTEGER) the 'a' parameter
is not a string, is an open array of char. Cause strings are
assignment compatible with array of char you can pass a string to it.

About the REASON I have no idea

chris burrows

By definition, a CONST in Oberon-2 / Component Pascal is truly a *constant*.
i.e. it must be possible to evaluate it at compile time and it cannot be
changed at runtime. If you were able to access a CONST string as an array as
suggested e.g.

CONST Encodings = "01230124022455012623017272";

ch := Encodings[i];

then according to the rules associated with arrays it would also be possible
to write:

Encodings[i] := ch;

which is counter to the definition of a CONST.

The design of Oberon-2 / Component Pascal typically avoids these sorts of
inconsistencies.

Furthermore, the Oberon-based languages intentionally only include the
general-purpose language features that are deemed to be 'necessary and
sufficient'. If a particular task can be achieved in one way then it is not
seen to be necessary to implement several additional alternative ways to
reach the same goal.

For this particular example, you can achieve what you are trying to do by
declaring 'encodings' as a read-only variable in a separate module and
setting its value in the initialisation code of the module that it is
declared in.

e.g.

MODULE Constants;

VAR
encodings-: ARRAY 27 OF CHAR;

BEGIN
encodings := "01230124022455012623017272"
END Constants.

Client modules are then able to inspect the values of individual elements of
'encodings'

e.g.

ch := Constants.encodings[i]

but they are unable to change them.

--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp

fmw

Stefano Ferrari <ferrarst@tiscali.it> writes:


Oberon constants are named literals, they have simple types, not
compound types. Strings being the obvious (and useful) exception, so
the special rule about "assignment compatibility" is added.

From a compiler implementor's perspective, this makes things very
pleasant. You don't have to worry about constants being non-primitive
data types - note how Oberon has no "array literal" or "record
literal" notation the way C does. Constants always fit into
registers, they can be immediate operands in machine instructions. You
don't need fancy memory management to hand them around the compiler's
internals: they will always fit into a variable of simple type.

String constants have a "primitive" and nameless type. Only a few
operations are defined, such as assignment to an array (which is what
happens when you pass a string constant as a procedure parameter),
determining their size, and so on.

Thus, a compiler only has to be "aware" of string constant types in a
few special cases, not in the full general case where they could occur
in qualified identifiers. They can be added almost as an aftertought
when the compiler is almost finished.

Keep in mind that Oberon and C have different ideas what an array is:
in C, an array is a pointer (thus, a primitive data type). In Oberon,
an array is the entire memory area used to store the data of the array
in.

Cheers,
Florian

--
..O. This thing, that hath a code and not a core,
...O Hath set acquaintance where might be affections,
OOO And nothing now
Disturbeth his reflections. -- Ezra Pound, "An Object"

christian_luginbühl

This is untrue.

In C, an array is a consecutive sequence of elements, in very much the same
way as in Oberon.

Christian.