[comp.lang.modula2] Re^6: Error in PD Modula-2 compiler? Or just in my brain?

federico@actisb.UUCP (Federico Heinz) (06/07/89)

kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes:


>And I am waiting for apologies from Martin Neitzel.

  Er... excuse me for getting in your way,  but aren't you getting
carried away?  This has been just an exchange of opinions, and a pretty
technical one at that.  All arguments I've seen exposed (and I inspected
all of them pretty thoroughly, since I was the one who asked) were
pretty well thought out.  Why make a personal question out of it?  You
both presented your interpretations of the matter, and the message that
cleared the question was one describing the current ETH implementation,
not How It Should Be Done, since Wirth doesn't seem to know that himself
(and I don't think that's a blame).  Don't get angry for nothing, both
your and Martin's contributions were insightfull and illuminating, and
are a good example of fuzziness in the Modula-2 definition (which I
hadn't noticed until now).

  And talking definition: there is something I've been wondering some
time now, and I don't know whether it's been answered here before. 
Wirth doesn't include any facilities to initialize structures at
compile-time, neither in Pascal nor in Modula (don't know about Oberon).
Not only that, there aren't any structured constants in either language.
I'm planning to program yet another uucp packet-driver protocol for the
ATARI ST in this summer holidays, and I selected C as the language of
choice exactly because it offers this capability (which is vital to my
approach to communication protocols).  I'd rather program it in Modula,
but I can't think of a way of doing it without an endless string of
initialazation assignments, which consumes time (not that important, it's
done only once per run) and memory space (IMPORTANT).  Most of the data
could be read from a file, but I also need initialized PROCEDURE
variables in the structure, and you can't file those out.  Does anybody
out there know WHY there aren't any structured constants in Wirth's
languages? Is there any academic background to this limitation, is it
just to keep the compiler simple, or is it to keep the language
compatible with some (weird) machines that don't support an initialized
data space?  An inquiring mind (if you can call mine that) wants to
know...

-- 
		Federico Heinz     "I can resist anything but temptation"
                                        -- Oscar Wilde
 From Europe:   ...!mcvax!unido!tub!actisb!federico
 From elsewhere: ...!uunet!pyramid!/

neitzel@infbs.UUCP (Martin Neitzel) (06/09/89)

kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes:
JK>
JK>	And I am waiting for apologies from Martin Neitzel.

In article <346@actisb.UUCP> federico@actisb.UUCP (Federico Heinz) writes:
FH>
FH>	  Er... excuse me for getting in your way,  but aren't you getting
FH>	carried away?  This has been just an exchange of opinions, and a pretty
FH>	technical one at that.

Note quite, I really did attack him in an unfair way.  In the summary
line in the reply to his description of VAL() in the TUM-compiler, I
accused him incorrectly world wide for posting "misinformation".   In
addition, the first sentence of this reply was written in a rude tone.

All this was unjustified.  I reviewed all concerned articles yesterday
and have learned that I most probably misinterpreted Jeske Kloppenburg
and that he probably very well _can_ disseminate the Mod2 definition
from its implementations.  His summary lines from both his articles
mark them explicitly as implementation specific.  This alone invalids
my insult because of misinformation.  A public apology from my side
*is* appropriate:  Es tut mir wirklich leid.

It has become a popular custom in the country both Jelske and I live in
to explain unfortunate, foolish, or plain wrong statements with the
word "blackout".  :-)  Such one must have hit me, too. :-(  I promise
to behave cooler next time.

[The basic reason for the blackout was that I personally can't stand it
when someone argues about matters of a programming language with the
behaviour of his compiler as reference for "correctness".  This is one
of the reasons for the poor s/n ratio in comp.lang.c and I don't want
to see c.l.m2 following it.  I didn't see Jelskes summary lines in his
postings at that time, misunderstood his contribution as an explanation
of the "official" term "type transfer", and ...uh... forgot myself...]

								Martin