Exporting variables from DEF modules 
Author Message
 Exporting variables from DEF modules

Peter Moylan wrote in another topic.

Quote:
>  Typically I'd have
>only one or two types declared in a definition module, and no
>constants and no variables.  (I regard it as one of the major faults
>of Modula-2 that exporting a variable is legal.)

I say no way. Exporting variables is not a fault.

Why is it a fault?

--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom



Mon, 25 Aug 2003 05:13:25 GMT  
 Exporting variables from DEF modules

Quote:

> Peter Moylan wrote in another topic.

> >  Typically I'd have
> >only one or two types declared in a definition module, and no
> >constants and no variables.  (I regard it as one of the major faults
> >of Modula-2 that exporting a variable is legal.)

> I say no way. Exporting variables is not a fault.

> Why is it a fault?

I agree. I use exported variables in just about every module. E.g.

        DEFINITION MODULE Files;
        (* ... *)
        TYPE StatusCode = (OK, IOError, InvalidFileName, (* ... *) );
        VAR Status : StatusCode;
        (* ... *)
        END Files.

        MODULE SomeProgram;
        IMPORT Files;
        (* ... *)
        BEGIN
        Files.Open(FileName, (* ... *) );
        IF Files.Status # Files.OK THEN
            (* deal with the error *)
            END (* IF *);
        (* ... *)
        END SomeProgram.

Although this means that the procedures in the modules actually have
side-effects (and, as a matter of principle, I do not approve of side-effects),
this kind of exported variable does allow for readable yet compact code. My own
convention is, of course, that these exported variables are only assigned values
within the implementation module, which makes this side-effect compromise
something with which I can live.

--
        -- Aron

NB: To reply by e-mail, remove "spam-block." from my address.
- - - - - - - - - - -
"A pedestal is as much a prison as any small, confined space."

        -- Gloria Steinem



Mon, 25 Aug 2003 06:07:42 GMT  
 Exporting variables from DEF modules



Quote:

> > Peter Moylan wrote in another topic.

> > >  Typically I'd have
> > >only one or two types declared in a definition module, and no
> > >constants and no variables.  (I regard it as one of the major faults
> > >of Modula-2 that exporting a variable is legal.)

> > I say no way. Exporting variables is not a fault.

> > Why is it a fault?

Usually there are major semantic restrictions to who is allowed to change an
exported and therefore global variable, but no one can enforce that this
restrictions are met by an other module.

Quote:

> I agree. I use exported variables in just about every module. E.g.

> DEFINITION MODULE Files;
> (* ... *)
> TYPE StatusCode = (OK, IOError, InvalidFileName, (* ... *) );
> VAR Status : StatusCode;
> (* ... *)
> END Files.

> MODULE SomeProgram;
> IMPORT Files;
> (* ... *)
> BEGIN
> Files.Open(FileName, (* ... *) );
> IF Files.Status # Files.OK THEN
>     (* deal with the error *)
>     END (* IF *);
> (* ... *)
> END SomeProgram.

> Although this means that the procedures in the modules actually have
> side-effects (and, as a matter of principle, I do not approve of
side-effects),
> this kind of exported variable does allow for readable yet compact code.
My own
> convention is, of course, that these exported variables are only assigned
values
> within the implementation module, which makes this side-effect compromise
> something with which I can live.

If you made your exported variable a privat variable of the implementation
module and used a procedure "GetStatus" to access this variable, then the
compiler would enforce your convention that only one module is allowed to
change the variable. This is the way I usually avoid exporting variables.

Quote:
> --
>         -- Aron

> NB: To reply by e-mail, remove "spam-block." from my address.
> - - - - - - - - - - -
> "A pedestal is as much a prison as any small, confined space."

>         -- Gloria Steinem

Georg


Mon, 25 Aug 2003 21:10:00 GMT  
 Exporting variables from DEF modules

Quote:


>> Peter Moylan wrote in another topic.

>> >  Typically I'd have
>> >only one or two types declared in a definition module, and no
>> >constants and no variables.  (I regard it as one of the major faults
>> >of Modula-2 that exporting a variable is legal.)

>> I say no way. Exporting variables is not a fault.

>> Why is it a fault?

>I agree. I use exported variables in just about every module. E.g.

>    DEFINITION MODULE Files;
>    (* ... *)
>    TYPE StatusCode = (OK, IOError, InvalidFileName, (* ... *) );
>    VAR Status : StatusCode;
>    (* ... *)
>    END Files.

You're not alone.  Wirth did something similar in his PIM books, and
I think the TopSpeed libraries also had something like this.

Modules like this are completely useless to me, because almost
everything I write is multi-threaded.  In a program with multiple
threads you need to be able to answer the question "which file
does this status code belong to?"  That is, a line like

        IF Files.Status # Files.OK THEN

needs to be replaced by something like

        IF Files.Status(f) # Files.OK THEN      

so that the exported variable has now become a function.

The real hazard comes when someone used to writing single-threaded
programs discovers that an extra thread is necessary.  I've seen
students caught by this over and over again.  They fail to realise
that the variable they're working with could be changed by
another thread.  Banning exported variables would not solve this
problem entirely, but it would reduce the likelihood of such
an error.

In a multithreaded environment, every static variable is potentially
a shared variable, so you have to think about critical section
protection for the static variables.  That pretty much rules out
exported variables, unless you start writing baroque and
hard-to-read code to get around the problem.

Now, it's true that the fact that I work always with multithreaded
applications biases my response here.  I believe, though, that
almost every software developer has to be able to cope with
multitasking.  It's needed for proper performance with modern
operating systems (at the very least, you have to separate the
screen display from the computation), and I believe it's needed
in almost all industrial applications where you're doing
embedded control, communications, monitoring, etc.

--

http://eepjm.newcastle.edu.au



Mon, 25 Aug 2003 21:21:12 GMT  
 Exporting variables from DEF modules

Quote:
>does this status code belong to?"  That is, a line like
>IF Files.Status # Files.OK THEN
>needs to be replaced by something like
>IF Files.Status(f) # Files.OK THEN

I use a record for file records so I have.
 IF ThisParticularFile.status <> 0 THEN

Yes threaded code needs to avoid the tradition global variable and use
thread local storage. However you can use a global variable in some DEF to
hold the thread local storage "key". Win32 and Unix pthreads both use "keys"
to access thread local storage. So a global variable is still useful here
and multiple modules may want to access the thread local storage key. Of
course you could not put the index global in the DEF but rather the IMP and
have a procedure to return your data, but then this is two procedure calls
verses one, (your call, and then one to the system), to fetch thread local
data.

Quote:
> It's needed for proper performance with modern
> operating systems (at the very least, you have to separate the
> screen display from the computation),

You bet! I hate the various Unix application I have begun using where the UI
goes dead when something big happens. Of course this is the same issue with
Win32 programs, but threads are still an after thought to much of the Unix
world. Win32, and OS/2, had threads in mind from the ground up.

Quote:
>and I believe it's needed
> in almost all industrial applications where you're doing
> embedded control, communications, monitoring, etc.

It all depends. Is the system/hardware dedicated to a task. Polling is
faster than "threading" and "interrupts". However, hardware is so fast these
days the overhead of task switching and interrupts is not an issue. My
partner designed hardware decades ago where polling verses interrupts was a
very real performance consideration.

--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom


Quote:


> >> Peter Moylan wrote in another topic.

> >> >  Typically I'd have
> >> >only one or two types declared in a definition module, and no
> >> >constants and no variables.  (I regard it as one of the major faults
> >> >of Modula-2 that exporting a variable is legal.)

> >> I say no way. Exporting variables is not a fault.

> >> Why is it a fault?

> >I agree. I use exported variables in just about every module. E.g.

> > DEFINITION MODULE Files;
> > (* ... *)
> > TYPE StatusCode = (OK, IOError, InvalidFileName, (* ... *) );
> > VAR Status : StatusCode;
> > (* ... *)
> > END Files.

> You're not alone.  Wirth did something similar in his PIM books, and
> I think the TopSpeed libraries also had something like this.

> Modules like this are completely useless to me, because almost
> everything I write is multi-threaded.  In a program with multiple
> threads you need to be able to answer the question "which file
> does this status code belong to?"  That is, a line like

> IF Files.Status # Files.OK THEN

> needs to be replaced by something like

> IF Files.Status(f) # Files.OK THEN

> so that the exported variable has now become a function.

> The real hazard comes when someone used to writing single-threaded
> programs discovers that an extra thread is necessary.  I've seen
> students caught by this over and over again.  They fail to realise
> that the variable they're working with could be changed by
> another thread.  Banning exported variables would not solve this
> problem entirely, but it would reduce the likelihood of such
> an error.

> In a multithreaded environment, every static variable is potentially
> a shared variable, so you have to think about critical section
> protection for the static variables.  That pretty much rules out
> exported variables, unless you start writing baroque and
> hard-to-read code to get around the problem.

> Now, it's true that the fact that I work always with multithreaded
> applications biases my response here.  I believe, though, that
> almost every software developer has to be able to cope with
> multitasking.  It's needed for proper performance with modern
> operating systems (at the very least, you have to separate the
> screen display from the computation), and I believe it's needed
> in almost all industrial applications where you're doing
> embedded control, communications, monitoring, etc.

> --

> http://eepjm.newcastle.edu.au



Tue, 26 Aug 2003 05:51:50 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. modules share variables without class def

2. Exporting global variables from a Fortran 90 (CVF) module into Borland C++ Builder

3. EQUIVALENCE(variable inside module, variable outside module) ????

4. def self.foo in a module

5. Module with INTERFACE def. replacing INCLUDE Statements

6. Module with INTERFACE def. replacing INCLUDE Statements

7. referring to variables in the scope outside the def

8. def within def

9. Q: Function to convert 'abc+def = (abc def)

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

11. exporting a module to another application

12. ifort 8.0: exporting module procedure bug

 

 
Powered by phpBB® Forum Software