christian_luginbühl

It is always possible to write this ;-)

But there is no reason a compiler would have to accept it as valid. It can check
that the target is constant and reject the statement.

Of course, it would make the compiler more complex.

I see two possible reasons why the feature is not in:

- nobody thought of it, or found it was useful.
- Its usefulness did not appear to be worth the complication in the compiler, therfore
violating the KISS Principle.

Christian.

august karlstrom

But in C an array decays into a pointer when it is passed as an argument
to a function. In Oberon the entire array is copied.


August

august karlstrom

You cannot directly retrieve the size of a string, the function LEN is
only defined for arrays, but of course the compiler knows the size of a string. [...]

Not entirely true. On the other hand an array decays into a pointer when
passed to a function.


August

stefano ferrari

.... unless in Oberon array are passed as by reference (VAR parameters)

Stefano

fmw

August Karlstrom <fusionfive@comhem.se> writes:


Yeah, I was glossing over The semantics of arrays have become more
elaborate with every new standard.

The point is, in C you "think" of arrays in terms of pointers, and of
array operations as pointer arithmetic. In Oberon, the notion of
"array" is entirely separate from the notion of "pointer".

Interestingly, learning Oberon, and dabbling at writing an oberon
compiler, has taught me a lot about C, and made me better at writing C
code.

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"

xcriber51

External User

 

Posts: 1

OK, thanks everyone for dropping an explanation. Can't say I have fully
appreciated the technical reasons, but I think I now know the human
reasons involved.

In summary, We have 3 solutions here:

1) declare a string variable instead of a constant:

StringVar: ARRAY <length> OF CHAR;
...
String := "<string-value>";

c := StringVar[i];


2) place the string in a read-only variable in another module:
MODULE Mod1;
VAR StringVar-: ARRAY <length> OF CHAR;

END Mod1. BEGIN
StringBVar := "<string-value>";

MODULE Mod2;

...

c := Mod1.StringVar[i];

END Mod2.

Drawback: Hassle of creating/maintaining a semantically spurius
"constants" module.

3) place the string in a constant, and then use a helper routine to extract items:
CONST StringConst = "<string-value>";

...
PROCEDURE Get(a: ARRAY OF CHAR; i: INTEGER): CHAR;
BEGIN
RETURN a[i];
END Get;

...
c := Get(StringConst,i);

Drawback: Has a funny feeling, and the extra routine is a hassle.

Thanks again.


-- K


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

chris burrows

I propose a fourth solution that might go something like:

PROCEDURE SoundexMap(ch: CHAR): INTEGER;
BEGIN
CASE CAP(ch) OF
"A", "E", "I", "O", "U":
RETURN 0 |
"B", "F", "P", "V":
RETURN 1 |
"C", "G", "J", "K", "Q", "S", "X", "Z":
RETURN 2 |
"D", "T":
RETURN 3 |
"H", "L":
RETURN 4 |
"M", "N":
RETURN 5 |
"R":
RETURN 6 |
"W", "Y":
RETURN 7
END
END SoundexMap;

It should be as efficient but much less obscure than the other three
solutions. Readers / maintainers of the code then have a better chance of
verifying that this algorithm is doing what it is intended to do. e.g. it
might lead to the question: Shouldn't "W", "Y" and "H" return 0 instead of
7, 7 and 4?

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

xcriber51

External User

 

Posts: 1

Chris, thanks for your suggestion, but the discussion wasn't "what is the
most efficient way to implement the soundex algorithm." It was "why can't
we access constant strings the way we can variable ones." I picked that
example off the top of my head, so that's irrelevant.

Nevertheless, it's nice to learn that using the "CASE" construct produces
such efficient code in Oberon. I'll start converting all my table lookups
to CASEs.

Anyway, this should settle my question. I got my answers, and thanks to
everyone.


-- K

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

august karlstrom

Stefano Ferrari skrev:


Of course. I was primarily comparing call by value semantics in Oberon
with C.


August

chris burrows

Fair enough - but not totally irrelevant. I am interested to learn of
alternative tasks that could *best* be implemented by accessing constant
strings as if they were an array rather than using any of the alternative
approaches that are possible in Oberon. If such tasks exist then that would
support the introduction of such a feature into future descendants of Oberon
/ Component Pascal / Zonnon etc.

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