Importing a whole module: which compilers? 
Author Message
 Importing a whole module: which compilers?

Now, I haven't done any M2 coding since university, so don't shout too
loud at me :)
I used two M2 compilers, both for DOS; TopSpeed and the FTL one[1].
In TopSpeed, you could just do IMPORT IO; at the top of your module,
and then use IO.WriteString and so on in the code. In FTL, you
couldn't; you had to do FROM IO IMPORT
WriteString,ReadString,WhateverElse; [2] and then just use WriteString
in the code.

Which is the norm? I found the TopSpeed way much easier and tidier,
but was that a TopSpeed specific thing, or is it the Right Thing to do
and supported in most M2 compilers?

Cheers for any help,

Aquarius

[1] I think :)
[2] the IO module might have been called InOut or something.....


http://www.*-*-*.com/
"I would not bet against the existence of time
 machines; my opponent may have seen the future and
 know the answer" - Stephen Hawking



Fri, 31 Aug 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:

> Now, I haven't done any M2 coding since university, so don't shout too
> loud at me :)
> I used two M2 compilers, both for DOS; TopSpeed and the FTL one[1].
> In TopSpeed, you could just do IMPORT IO; at the top of your module,
> and then use IO.WriteString and so on in the code. In FTL, you
> couldn't; you had to do FROM IO IMPORT
> WriteString,ReadString,WhateverElse; [2] and then just use WriteString
> in the code.

> Which is the norm? I found the TopSpeed way much easier and tidier,
> but was that a TopSpeed specific thing, or is it the Right Thing to do
> and supported in most M2 compilers?

> Cheers for any help,

> Aquarius

> [1] I think :)
> [2] the IO module might have been called InOut or something.....

If I remember the ISO standard correctly, both forms are still valid. In
particular, I *know* that IMPORT <module list> is still valid as that is
the form that I always use.

--
        -- Aron

+-------------------------------------------------------------------------+
|     _   NB: Om du vil svare med e-post,     |"Sometimes the magic works,|
| __/\_\      m? du fjerne "spam-block."      | sometimes it doesn't."    |
|/\_\/_/      fr? adressa mi.                 |                           |
|\/_/\_\  NB: If you want to reply by e-mail, |    -- Chief Dan George,   |
|   \/_/      you have to remove "spam-block."|       in "Little Big Man" |
|             from my address.                |                           |
+-------------------------------------------------------------------------+



Fri, 31 Aug 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:

> I used two M2 compilers, both for DOS; TopSpeed and the FTL one[1].
> In TopSpeed, you could just do IMPORT IO; at the top of your module,
> and then use IO.WriteString and so on in the code. In FTL, you
> couldn't;

Whatever kind of compiler FTL might have been (or is, I have never
seen this acronym before), it does neither conform to PIM3 (Modula-2
standard before ISO) nor to ISO Modula-2.

It seems to me that the ``IMPORT module...''-construct originally
served to resolve ambiguities, i.e. if the same identifier is defined
in two definition modules. Later, this construct was preferred by
many programmers over the ``FROM module IMPORT ident...''-variant
because of the better readability if all references to imported
identifiers are qualified. Oberon dropped apparently for this reason
the ``FROM module IMPORT ident...''-construct. This was a wise
decision because this encourages to shorten exported identifiers that
cannot be used without a preceding module name. Instead of something
like Files.OpenFile you have now Files.Open.

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/



Fri, 31 Aug 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:


>> I used two M2 compilers, both for DOS; TopSpeed and the FTL one[1].
>> In TopSpeed, you could just do IMPORT IO; at the top of your module,
>> and then use IO.WriteString and so on in the code. In FTL, you
>> couldn't;

>Whatever kind of compiler FTL might have been (or is, I have never
>seen this acronym before), it does neither conform to PIM3 (Modula-2
>standard before ISO) nor to ISO Modula-2.

Actually it did conform to PIM3, or at least as closely as feasible given
all the ambiguities in PIM3.  I guess Aquarius just never noticed that
both of those compilers supported both forms of import.  Not surprising,
because as I recall it the differences weren't explained all that clearly
in PIM.  When I first started using Modula-2 I found it quite difficult to
understand the QUALIFIED keyword - which was dropped from the
language somewhere between PIM1 and PIM3, but which left a trail
of confusion behind it.  Part of the problem was that the explanation
was all tied up with the complexities of exporting from nested modules;
while in fact only about 1% of the modules I've ever written had
nested submodules, and I suspect the figure would be similar for other
programmers.

The present system is not too bad, but a beginner still needs a good
teacher to explain it.

FTL, by the way, was one of the early Modula-2 compilers for the PC,
and it was a pretty good one.  (Much better than Logitech, which was
its main competitor at the time.)  I miss it; in particular I miss the
feature where opaque variables could be arbitrary records, i.e. they
didn't have to be pointers.

As so often happens, the compiler died after its developer stopped
working on it.

--

See http://eepjm.newcastle.edu.au for OS/2 information and software



Fri, 31 Aug 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:



> >> I used two M2 compilers, both for DOS; TopSpeed and the FTL one[1].
> >> In TopSpeed, you could just do IMPORT IO; at the top of your module,
> >> and then use IO.WriteString and so on in the code. In FTL, you
> >> couldn't;

> >Whatever kind of compiler FTL might have been (or is, I have never
> >seen this acronym before), it does neither conform to PIM3 (Modula-2
> >standard before ISO) nor to ISO Modula-2.

> Actually it did conform to PIM3, or at least as closely as feasible given
> all the ambiguities in PIM3.

Thank you for this information.

Quote:
> I guess Aquarius just never noticed that
> both of those compilers supported both forms of import.  Not surprising,
> because as I recall it the differences weren't explained all that clearly
> in PIM.  When I first started using Modula-2 I found it quite difficult to
> understand the QUALIFIED keyword - which was dropped from the
> language somewhere between PIM1 and PIM3, but which left a trail
> of confusion behind it.

Pardon but the keyword QUALIFIED was never dropped and continues its
life now in ISO Modula-2. Instead the formerly mandatory ``EXPORT
QUALIFIED'' clause in definitions modules was dropped (1984 in the paper
``Revisions and Amendments of Modula-2'' that followed PIM1 and preceded
PIM3). The motivation for requiring an explicit export list in
definition modules was probably the consistency in syntax
between local and global modules. But it was soon found to be inconvienent
to specify all identifiers twice: once in their declaration and another
time in the export list considering that a definition module can be
viewed as export list in itself.

Quote:
> Part of the problem was that the explanation
> was all tied up with the complexities of exporting from nested modules;
> while in fact only about 1% of the modules I've ever written had
> nested submodules, and I suspect the figure would be similar for other
> programmers.

I like local modules in Modula-2 and I am missing them in Oberon.
In my opinion, modularization should always designed along the interfaces
without considering the size of a module. In other words, if you have
an elegant interface and no code inside your module that could be
usefully factorized out, it is perfectly acceptable if it becomes huge.
In these cases, local modules become extremely helpful in organizing
such huge modules and in keeping them maintainable.

Quote:
> FTL, by the way, was one of the early Modula-2 compilers for the PC,
> and it was a pretty good one.  (Much better than Logitech, which was
> its main competitor at the time.)  I miss it; in particular I miss the
> feature where opaque variables could be arbitrary records, i.e. they
> didn't have to be pointers.

> As so often happens, the compiler died after its developer stopped
> working on it.

Do you know more about FTL, in particular when it became available and
who wrote it?

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/



Sat, 01 Sep 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:

>FTL, by the way, was one of the early Modula-2 compilers for the PC,
>and it was a pretty good one.

There was also a CP/M-80 version, which is still available, I believe,
at the Unofficial CP/M site.

Greg

http://www.korax.net/~telic
March 16, 1999, Toronto, Canada.



Sat, 01 Sep 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:

> I used two M2 compilers, both for DOS; TopSpeed and the FTL one[1].
> In TopSpeed, you could just do IMPORT IO; at the top of your module,
> and then use IO.WriteString and so on in the code. In FTL, you
> couldn't; you had to do FROM IO IMPORT

A lot of it's stylistic. My opinion is that there are cases for both and I
tend to mix both usages. TopSpeed v1.17 and v3.10 definitely accepts both
forms, the Z80 FTL compiler v1.32 definitely accepts both (I've got a
common codebase I run through both).

However, I know from Dave Moore that the FTL Z80 and MS-DOS compilers
don't have common source, so there's always a possibility that the one you
had was broken. Where did you study?

-- Mark Morgan Lloyd

--
-- [Opinions above are the author's, not those of his employers or
colleagues]
--
-- ** Internet feed may be unreliable- please cc anything important by
email **



Sat, 01 Sep 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:

>> in PIM.  When I first started using Modula-2 I found it quite difficult to
>> understand the QUALIFIED keyword - which was dropped from the
>> language somewhere between PIM1 and PIM3, but which left a trail
>> of confusion behind it.

>Pardon but the keyword QUALIFIED was never dropped and continues its
>life now in ISO Modula-2. Instead the formerly mandatory ``EXPORT
>QUALIFIED'' clause in definitions modules was dropped (1984 in the paper
>``Revisions and Amendments of Modula-2'' that followed PIM1 and preceded
>PIM3).

My apologies, you are quite correct.  I was fooled by the fact that
QUALIFIED is now used only for a feature of the language that I rarely use.

Quote:
>> FTL, by the way, was one of the early Modula-2 compilers for the PC,
>> and it was a pretty good one.  (Much better than Logitech, which was
>> its main competitor at the time.)  I miss it; in particular I miss the
>> feature where opaque variables could be arbitrary records, i.e. they
>> didn't have to be pointers.

>> As so often happens, the compiler died after its developer stopped
>> working on it.

>Do you know more about FTL, in particular when it became available and
>who wrote it?

Wonder of wonders, I have even found the manual!  FTL stands for
"faster than light", and indeed the compiler was quite fast.  The author
was Dave Moore, who had a business called Cerenkov Computing in
Brisbane, Australia.  The distributor was JED Microprocessors, of
Victoria, whose main business was (if I recall correctly) microprocessor
hardware.  My copy of the manual is dated September 1987.  Quoting
from an appendix to the manual:
   "The Z80 compiler was our first compiler.  It was introduced in the
   middle of 1985, though it was not widely available until early 1986.
   This compiler is written in our own Pascal compiler which we never
   released.  All the other compilers are written in FTL Modula-2."
By the time that manual was written, there were versions for CP/M
and the Atari, and two versions (large and small memory model) for
MS-DOS.

--

OS/2 help and software at
  http://eepjm.newcastle.edu.au/HTML/os2home.html



Sat, 01 Sep 2001 03:00:00 GMT  
 Importing a whole module: which compilers?
"Mark Morgan Lloyd " spoo'd forth the following:

Quote:


>> I used two M2 compilers, both for DOS; TopSpeed and the FTL one[1].
>> In TopSpeed, you could just do IMPORT IO; at the top of your module,
>> and then use IO.WriteString and so on in the code. In FTL, you
>> couldn't; you had to do FROM IO IMPORT
>However, I know from Dave Moore that the FTL Z80 and MS-DOS compilers
>don't have common source, so there's always a possibility that the one you
>had was broken. Where did you study?

I had TopSpeed at university. I wanted to do some M2 in my spare time,
and TopSpeed costs lots of real money, so I had a play with FTL on my
own machine. I didn't use it for long, anyway.
It would appear that I am completely wrong about this and it *did*
support it; possibly I was just dim :) I suspect that perhaps the
examples supplied with the compiler used the FROM X IMPORT Y format,
and I assumed that IMPORT AWholeModule was a TopSpeed extension
without actually checking this....

As a corollary to this, is there a FAQ around? Last time I read the
FAQ (which was a while ago, I have to admit), it had a list of free
and commercial M2 compilers for various OSes; I'd like to get back
into M2 coding, and I shall therefore need a compiler :)
I've got a box here with Minix on it (a cut-down free Unix, the
predecessor to Linux) which has the Amsterdam Compiler Kit included,
which can be used to compile M2, C and something else; has anybody
used this, and what was it like? Which free (or extremely cheap :)
compilers would you recommend for MS-DOS and/or 32-bit MS-Windows?

Did Peter Moylan ever finish porting PMOS to FTL? I liked the look of
that, but it was TopSpeed only when I looked at it :)

Aquarius is off to check www.faqs.org


http://www.kryogenix.albatross.co.uk/
"I would not bet against the existence of time
 machines; my opponent may have seen the future and
 know the answer" - Stephen Hawking



Sat, 01 Sep 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:

> As a corollary to this, is there a FAQ around?

ftp://FTP.twu.ca/pub/modula2/m2faq.html

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/



Sat, 01 Sep 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:

>    This compiler is written in our own Pascal compiler which we never

There's mention of something called Night Parrot Pascal in some of the
library sources.

-- Mark Morgan Lloyd

--
-- [Opinions above are the author's, not those of his employers or
colleagues]
--
-- ** Internet feed may be unreliable- please cc anything important by
email **



Sat, 01 Sep 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:



>> > ... complexities of exporting from nested modules;
>> > while in fact only about 1% of the modules I've ever written had
>> > nested submodules, and I suspect the figure would be similar for other
>> > programmers.

>> I wrote one program that had nested modules.  By the time it was done I
>> had decided it was a bad idea and would have been better done another
>> way.

>I've done it loads.  I wanted effect of generic supplier model.
>No such thing in my modula.  So wrote the supplier as local module
>in terms of generic parameter types, and simply pasted it into
>every client that needed it.  Client defines types and supplier
>gets them by virtue of nested scope.

I've been thinking some more about why I rarely nest modules, and
I've concluded that it's essentially the same question as arises when
you nest procedure definitions.  (I do nest procedure definitions fairly
often, but I'm sometimes uncomfortable about it.)

Consider the example:

    PROCEDURE P1;
           VAR v1, v2, v3: REAL;
           PROCEDURE P2;
                  VAR v4: REAL;
                  BEGIN
                        (* Body of P2. *)
                  END P2;
           BEGIN
                 (* Body of P1. *)
           END P1;

In practice I'd add a bit more white space and separate things with
comment lines, but for the sake of this discussion we can take that
as given.

Now, this works well enough if P2 is short.  Once P2 is more than
about ten lines long, some problems appear:
  1.  There's a big textual gap between the declarations of variables
      v1, v2, v3 - and also things like P1's parameters, if it has any -
      and their use in the body of P1.  As it happens I consider it
      very bad practice to have a big distance between declarations
      and use.  I'm forced to do it for global variables, of course,
      but that's OK because in my style of programming there
      usually aren't many global variables.
  2.  The effective length of P1, as far as the reader of the code is
      concerned, is from the initial PROCEDURE declaration to the
      final END P1.  With nested procedures, this can add up to
      several pages.  As we all know, it becomes a lot harder to
      produce bug-free code when procedures are more than
      about a page long.  When I'm editing this sort of code, I have
      to use a lot of page up/page down cursor operations to
      double-check that I'm being consistent in my coding.
  3.  Once P2 is long enough, it becomes less obvious whether the
      code you're reading is part of the body of P1 or part of the
      body of P2.  The indentation is supposed to help here, but
      indentation starts losing its effectiveness once the thing
      you're indenting extends over many lines.

The trouble with nested modules is that they have exactly the same
problems, but on a larger scale.

All these problems are instances of two general problems: how to
understand the large-scale structure of something that's textually
long, and how to understand the relationship between parts of your
code that won't fit on the screen simultaneously.  These might be
seen to be editor problems rather than language problems.  Most
M2 implementations come with an editor that let you open two views
of the same file (I only wish the XDS editor could do this), and
that's a partial solution, but still not ideal.

What I'd really like is an editor with a "collapse details" option
that let you decide whether nested blocks should be hidden.  If I
had such a thing, I'd probably be more willing to use nested modules.
I've heard of an editor called, I think, Boxer that could do this,
but I seem to recall that that was tied to one programming language.
(Not that I'd mind that; but the language wasn't one I use.)

In fact, if I had such an editor I'd probably even be willing to
accept the Oberon-style abandonment of definition modules.
--

See http://eepjm.newcastle.edu.au for OS/2 information and software



Mon, 03 Sep 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Peter Moylan wrote in Nachricht ...

Quote:
>I've been thinking some more about why I rarely nest modules, and
>I've concluded that it's essentially the same question as arises when
>you nest procedure definitions.  (I do nest procedure definitions fairly
>often, but I'm sometimes uncomfortable about it.)

>Consider the example: [...]

>In practice I'd add a bit more white space and separate things with
>comment lines, but for the sake of this discussion we can take that
>as given.
>Now, this works well enough if P2 is short.  Once P2 is more than
>about ten lines long, some problems appear:
>  1.  There's a big textual gap between the declarations of variables
>      v1, v2, v3 - and also things like P1's parameters, if it has any -
>      and their use in the body of P1.  As it happens I consider it
>      very bad practice to have a big distance between declarations
>      and use.  I'm forced to do it for global variables, of course,
>      but that's OK because in my style of programming there
>      usually aren't many global variables.

I thought the main reason for nesting procedures were the nested scopes
determing visibility of the local variables. Use a folding editor designed
for M2 and the drwabacks you describe are gone, which concludes that this is
not really a problem of the language.

With nested modules the same idea of scoped variables bundled with their
porcedures applies. The same effect can be produced by putting the module in
a separate file.

Someone complained that dedicating a file for a small module clutters the
file directories. For this reason I often combine various small modules into
a single file called xxx_hlp. The few global variables used need not be
separated in their own module :-)

H. Ellenberger



Mon, 03 Sep 2001 03:00:00 GMT  
 Importing a whole module: which compilers?

Quote:

> Use a folding editor designed
> for M2 and the drwabacks you describe are gone, which concludes that
> this is not really a problem of the language.

Didn't the original editor with Wirth's Lilith have folding?

-- Mark Morgan Lloyd

--
-- [Opinions above are the author's, not those of his employers or
colleagues]
--
-- ** Internet feed may be unreliable- please cc anything important by
email **



Tue, 04 Sep 2001 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. module name errors (trying to import curses functions from modules as needed)

2. How to access a module's namespace within the module at import

3. import selected module variables within that module's procedures

4. new release of MLton, a whole-program optimizing SML compiler

5. The worst compiler in the whole wide world

6. import Image vs from PIL import Image vs import PIL.Image

7. How to 'from package import module; from module import variable'?

8. IMPORTING MODULES

9. For all of you: General ASCII import module for free

10. Visual Objects: importing many modules

11. Imports in definition and implementation modules

12. IMPORT in definition module

 

 
Powered by phpBB® Forum Software