Porting I/O libraries from ISO Modula-2 to Logitech 3.4 Modula-2

[modsquad]

Hello:

Q1.) Has anyone ported the I/O libraries of ISO Modula-2 to Logitech
3.4?

Q2.) What is involved in doing the port?

Q3.) In doing a port, are you allowed to call the existing Logitech I/
O libraries:
FileSystem, Terminal, etc?

In general, I find the I/O in Logitech adequate, but for portability,
I would like to create a Logitech version of at least the main ISO
Modula-2 input/output libraries.

Sincerely
Modulan1
The ModuleSquad

[Gaius Mulley]

Post by modsquad
Q1.) Has anyone ported the I/O libraries of ISO Modula-2 to Logitech
3.4?
Q2.) What is involved in doing the port?
Q3.) In doing a port, are you allowed to call the existing Logitech I/
FileSystem, Terminal, etc?
In general, I find the I/O in Logitech adequate, but for portability,
I would like to create a Logitech version of at least the main ISO
Modula-2 input/output libraries.
Sincerely
Modulan1
The ModuleSquad

Hi,

I'm not familiar with Logitech 3.4 (but I used an earlier version).
However
to port ISO libraries you really need an ISO compiler as many of the
libraries
raise exceptions and a few use COMPLEX and LONGCOMPLEX types.

regards,
Gaius

[aaaaaaaaaaaaaaaaaaaaaaaaaa]

Post by modsquad
Q1.) Has anyone ported the I/O libraries of ISO Modula-2 to Logitech
3.4?

No. I don't like anything that is ISO. :O)But I have ported other
libraries to other compilers and I am now porting Mocka's TextIO
library (or better MODULE) to MHC.

Post by modsquad
Q2.) What is involved in doing the port?

You KEEP the definition module intact as much as possible and you
change the IMPLEMENTATION module. In the case of TextIO I had to go
around some intricacies of MHC. So I created a new variable "Done"
that keeps the state of file.res. Later it turned out that there
already is a PROCEDURE Done () so now the variable will be renamed
"done". EOF is simply a "RETURN file.eof" statement.

Post by modsquad
Q3.) In doing a port, are you allowed to call the existing Logitech I/
FileSystem, Terminal, etc?

You can do anything you do in normal programs. In my TextIO example I
have

PROCEDURE OpenInput (VAR file : FileSystem.File; name : ARRAY OF
CHAR);

BEGIN
FileSystem.OpenReader (file, name);
IF file.res = 0 THEN done := TRUE ELSE Done := FALSE END
END OpenInput;

You can use any GetChar you want. The one from FileSyste.GetChar, the
one in InOut.GetChar and of course the native one (which is of course
suited best since it has direct access to all local variables).

My advice: only use qualified imports (InOut.WriteString) so there are
no ambiguities like in the languages that cherish overloading.

Post by modsquad
In general, I find the I/O in Logitech adequate, but for portability,
I would like to create a Logitech version of at least the main ISO
Modula-2 input/output libraries.

Good thinking. As long as you keep the DEFINITION module intact, all
is fine.

[Chris Burrows]

Post by aaaaaaaaaaaaaaaaaaaaaaaaaa
IF file.res = 0 THEN done := TRUE ELSE Done := FALSE END

Assuming a typo and 'done' and 'Done' are supposed to be the same variable,
this simplifies to:

done := file.res = 0

(a style recommended in the earlier Jensen & Wirth Pascal User Manual and
Report)

Regards,
Chris Burrows
CFB Software
http://www.cfbsoftware.com/modula2

[aaaaaaaaaaaaaaaaaaaaaaaaaa]

Post by Chris Burrows

Post by aaaaaaaaaaaaaaaaaaaaaaaaaa
IF file.res = 0 THEN done := TRUE ELSE Done := FALSE END

Assuming a typo and 'done' and 'Done' are supposed to be the same variable,

It was a typo indeed. I saw it after I logged off...

Post by Chris Burrows
done := file.res = 0
(a style recommended in the earlier Jensen & Wirth Pascal User Manual and
Report)

Yes, you are right (as usual), but I use the IF THEN ELSE construct
ONLY because it is clear to all kinds and levels of programmers. I
take the extra 10 microseconds execution time for granted... :o)

Some people write your version as

done := (file.res = 0);

to indicate the fact that the assignment is a condition.

[Chris Burrows]

Post by aaaaaaaaaaaaaaaaaaaaaaaaaa
Yes, you are right (as usual), but I use the IF THEN ELSE construct
ONLY because it is clear to all kinds and levels of programmers. I
take the extra 10 microseconds execution time for granted... :o)
Some people write your version as
done := (file.res = 0);
to indicate the fact that the assignment is a condition.

Yes. That is an improvement. I'm not always right ;-)

I'm not particularly worried about the saving of execution time. I believe
in the saying 'When in Rome do as the Romans do'. We might just have to
disagree on whether it is better to write your code to best suit the
language in use or to defer to programmers who are locked into a particular
mindset.

To my mind if a Pascal / Modula-2 / Oberon programmer does not understand
how to use boolean variables properly (I'm not suggesting you are in this
group BTW) and develops a poor style, there is a risk of ending up with code
like this:

IF NOT(toggle = FALSE) THEN
toggle := FALSE
ELSIF (toggle = FALSE) THEN
toggle := NOT(FALSE)
END;

instead of:

toggle := NOT(toggle);

Admittedly that is an extreme hypothetical example to illustrate a point.
However, I have actually seen some examples in real life that are almost as
bad :-(

Regards,
Chris

[Marco van de Voort]

Post by Chris Burrows
IF NOT(toggle = FALSE) THEN
toggle := FALSE
ELSIF (toggle = FALSE) THEN
toggle := NOT(FALSE)
END;
toggle := NOT(toggle);

Well, with all the additions lately, the former person might be preparing
for dealing nullable types? :-)

[Chris Burrows]

Post by Marco van de Voort
Well, with all the additions lately, the former person might be preparing
for dealing nullable types? :-)

Does that mean we would then be able to have an IF ... THEN ... ELSE ...
MAYBE ... statement? ;-)

[Marco van de Voort]

Post by Chris Burrows

Post by Marco van de Voort
Well, with all the additions lately, the former person might be preparing
for dealing nullable types? :-)

Does that mean we would then be able to have an IF ... THEN ... ELSE ...
MAYBE ... statement? ;-)

but evaluating such variable fixates a maybe to a non MAYBE value, the so
called Schroedinger extensions :-)

Then there is the Heisenberg extensions; when you determine one aspect of a
a variable, all other aspects are undefined. (sizeof(x) means you can't do
other things with the var then sizeof()).

There was a whole list of that somewhere (and more funnily phrased than I do
here from memory), but that's aeons ago. (nineties BBS times)