Post by Chris BurrowsPost by Roman MiroCan I set array with constant values in section CONST? How?
The short answer is no.
...
Post by Chris BurrowsFirst of all you need to decide what range of tasks you are trying to
support with this type construct, and what it is NOT designed to be used
for. For your simple small example
{1,2,3,4}
I can't really see that such a feature is necessary. I would have just
initialised this with a loop to make it clear to the reader that there was a
pattern (assuming there is?) to the data. Even if the four values had been
random it is no big deal to have four assignment statements.
I can see plenty of use for such features, personally. Structured
type constructors are a vital tool for avoiding tedium-inducing code
bloat.
Post by Chris BurrowsIt is fairly straightforward to design a system to initialise just small
one-dimension arrays of integers but that does not extend well to more
complex data structures e.g. 3-dimensional arrays, arrays of records
(structures) etc. etc. It also becomes unmaintainable once you go beyond a
number of items that you can quickly count (e.g. 10 or so).
So... don't use them past the point where they can be easily
understood? I mean seriously, you're saying here "this construct can
be abused, so it shouldn't be there". I've seen WHILE and FOR loops
abused. Therefore they shouldn't be in a language. Oops. I've seen
IF statements abused with seventeen nested levels of IF, ELSIF, ELSE.
There goes the axe.
Post by Chris Burrows{1,5,2,6,4,1,4,7,8,5,4,8,2,6,9,0,5,3,4,2,5,2}
Now, are you *really* sure that was the 19th value?. You have to count at
least twice.
How is this different from having a string of assignments where
MyArray(18) is accidentally assigned twice? (18) and (19) look pretty
damned similar at 2AM during a major crunch when they're in a huge
column of assign statements, don't they?
Also, smart people, when assigning large numbers of values to an
array, do something like this:
{1, 5, 2, 6, 4,
1, 4, 7, 8, 5,
4, 8, 2, 6, 9,
0, 5, 3, 4, 2,
5,2}
Can you spot the 19th value now? I sure can! Without even having to
count twice!
Post by Chris BurrowsAlso having seen the way C's constant initialisation feature is often
abused - humongous constant sections that embed images, fonts etc. in source
code, using programs that convert the binary data to a text form - we went
for a different approach.
How is this abuse? For some environments (hint: not all systems have
file system capabilities!) this kind of thing is not only not an
abuse, it's absolutely *necessary*. Using what amounts to a DSL
compiler which happens to generate C array/structure initialization
statements is not an abuse any more than using a high level language
which generates processor object code is.
Post by Chris BurrowsTypically on a PC system, this sort of constant data would be stored in a
file to be read at runtime or as a 'resource file' embedded in the
executable. The solution we use has features from both. We handle large
blocks of constant data by gathering together all of the relevant data files
(binary data, images, fonts etc.) at link time and appending them to the
linked executable to be stored in Flash ROM when the program is uploaded.
How is this less abusive? Help me see this. One way you have clear
object identities in your language's runtime. The other way you have
linked raw blobs which you have to read through APIs into objects in
your language's runtime. One way has the data instantly available at
the moment of execution. The other requires a potentially complicated
(and certainly error-prone) initialization phase. I'm not seeing the
second as being much of an improvement, frankly.
Language minimalism is a good idea, but not if you go too far.
Modula-3, for example, is very much a minimal language (by modern
standards) and yet has most of the power of C++ (minus the really
arcane -- and troublesome, and unreadable -- bits of the latter).
Somehow this yearning for minimalism (fifty-page language spec) didn't
stop them from having constructors for complex types: sets, arrays,
records, objects, etc. The designers also didn't seem to use the
logic "this could be abused so it will be cut" (without following
through to loops or branching for some reason).
I also think there's something a little wonky in your reasoning vis a
vis string literals. Everything you say about array literals applies
fully to STRING literals. Which Oberon has, last I checked (which was
a few minutes ago as I read what you typed up there). You say you
don't want array literals because it could be confusing if you got,
say, a 30,000-byte array literal in generated code. How, precisely,
would this be different if you got a 30,000-character string literal?
My own reaction to someone saying "this code is unreadable because of
the 30,000-character string" is "don't use a 30,000-character string
then". Which would be very similar to my "don't use a 30,000-byte
array" response for the former case, oddly enough.
If you want to be both consistent and minimalist, why not strip string
literals from Oberon? I mean really, a string literal is just
syntactic sugar for accessing the individual offsets of each
character, right? "Hello, world!" could easily be coded in a series
of assignments to a string-declared variable:
MyString(0) := 'H';
MyString(1) := 'e';
MyString(2) := 'l';
MyString(3) := 'l';
.
.
.
Hell, that's how PDP-8 assemblers coded strings! Here's "Hello,
world!" in PAL-III (PDP-8 assembler):
STRNG, 310
345
354
354
357
254
240
367
357
362
354
344
241
0
It's a sight for sore eyes, that! No potentially abusable syntax in
sight!