Modula 2

Modula 2

[Peter Rowley]

Another yes vote for net.lang.modula2.  With the native 8086 version just
announced by Logitech, there could be quite a bit of use of the language
if that's a good product, esp. since there's an order form for it in the
front of the corrected 2nd ed. of the Programming In Modula 2 book.
The newsgroup might also discuss the Lilith machine Wirth built to run
the language (and now sold in the US by Diser Inc., Utah).

Time to join the fold?

[Mike Silva]

Sometime this year my company will embark on a bigger and better version of
their industrial controller product family.  The current product uses a 16
bit chip programmed in C (I'm the main programmer, BTW), while the next
generation will be 32 bit (not yet chosen).  While I don't know Ada, I've
lurked here for a while, and have been reading the "Ada vs C++ vs Java"
thread with great interest.  Now I feel that I would be remiss not to
investigate Ada (Ada95 specifically) as an alternative to migrating our
current C code to the new products, and have ordered some books to start
learning the language.

Now for my questions (all assuming that I determine that switching to Ada is
a good idea).  First, how long would it take me (a long-time C [and a bit of
C++] programmer) to get productive in Ada?  Second, what is the best way to
present the case to my boss?  He's open-minded, but switching to a new
language that I don't know is bound to require plenty of justification.  I
know of most of the main Ada web sites and the success stories and "why Ada"
articles they have, but I was wondering if some of you might have further
opinions and/or experiences in "converting" a project or company to Ada.
Thanks a bunch for any insights.

Mike Silva

Re: Time to join the fold?

[Tucker Taft]

Mike Silva (mjsilva@jps.net) wrote:

: ...
: Now for my questions (all assuming that I determine that switching to Ada is
: a good idea).  First, how long would it take me (a long-time C [and a bit of
: C++] programmer) to get productive in Ada?  

Not long.  If you tend to be a C programmer who writes one ".h"
file for every ".c" file, and who tries to minimize the amount of
information exposed in the .h file, then you already know the fundamental
idea of a package and a private type, with a separation between package 
spec and body.  Using packages right is really the key to using Ada,
and to some extent using appropriate modularization via .h/.c pairs
is the key to using C right.

One of the great things about Ada is that the compiler is so picky,
that it helps you learn the rules of the language more quickly.
You can make that even better by minimizing your use of predefined
numeric types like "Integer," but instead defining your own numeric 
types with the appropriate range.  Then the compiler will help more in
catching the use of the wrong type as an array index, or the wrong
type passed to a function or procedure.

: ... Second, what is the best way to
: present the case to my boss?  He's open-minded, but switching to a new
: language that I don't know is bound to require plenty of justification.  

Almost all of the Ada 95 compilers have excellent interoperability with
C.  Rather than trying to rewrite the whole thing right away, pick
a well defined abstraction (i.e. one of those .h/.c pairs), and rewrite
that in Ada.  For fun, you might want to pick one that has been a major 
source of bugs in the past.  For simplicity, pick one that has relatively
few external interface points exposed in the .h, but plenty of groddy
internal interactions in the .c.

Or pick a new abstraction associated with some particular enhancement,
and write that part in Ada, while the main part of the program is still
in C.

: I know of most of the main Ada web sites and the success stories and "why Ada"
: articles they have, but I was wondering if some of you might have further
: opinions and/or experiences in "converting" a project or company to Ada.

Start with a small piece, and work up slowly.  Try to keep track of
how many bugs are caught by the compiler, caught by run-time checks,
or left to you to track down at run-time.  I think you will be very
impressed with how few bugs make it through to the painful debugging
stage.  A remarkable percentage of mistakes, sometimes even relatively
deep "logic errors," are caught by the compiler and the compiler-generated 
run-time checks.

My usual analogy is giant slalom gates on a ski slope.  Any hacker
on skis can make it through one giant slalom gate.  But if you
start to pepper the slope with slalom gates, only a skier who has
a deeply correct approach to skiing can make it through them all.

Each compile-time and compiler-generated run-time check is trivial
in its own right, just checking that two types match, or that a value
is in some range.  But for a program to make it all the way through
all of these consistency checks, it needs to be internally consistent
and logical in a deep sense.  Otherwise it is almost certain to be
tripped up by one of these "trivial" checks.  And based on empirical
experience, a program with a bug generally gets tripped up by
one of these checks remarkably close to the source line where the
underlying flaw resides.

: Thanks a bunch for any insights.

: Mike Silva

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Time to join the fold?

[Mike Silva]

I want to thank everybody who has responded to my questions, both here and
in private.  Your comments have been quite interesting and helpful.  I spent
the weekend perusing "Ada95 for C and C++ Programmers" and "Concurrency in
Ada" (others are also on the way) and my head is naturally swimming.  FWIW
here are some of my very early impressions:

- Ada is wordy.  Luckily I'm a touch typist <g>.  However, I recognize that
I sometimes get myself into trouble in C because it *is* so easy to write a
quick function, and then another, and then...  Presumably the Ada
requirement (as I perceive it) to "spell it all out" helps encourage "think
twice, write once" programming.

- Ada is powerful.  As I read along I found myself consistently thinking "C
is more versatile here", only to learn on the next page that Ada, perhaps
via one of the libraries, has multiple ways to do it, some of which are more
powerful than the the equivalent C mechanisms.  Which leads to

- Ada is big.  This is intimidating, but more than that I feel like I've
entered a very large candy store.  It appears that there are functions (in
the broad sense), somewhere in the core language or one of the standard
libraries, to do *anything*.  I get the sense of a *very* well thought out
and self-contained universe.  The concurrency facilities, to choose just one
example out of many, seem quite exciting.

Now for another question.  Some people have mentioned getting into the Ada
"mind-set".  What are the main components of this mind-set?  What, IOW,
should I pay special attention to in order to avoid simply writing "C in
Ada" (whatever that might mean).  Thanks again for the help.

Mike Silva

Re: Time to join the fold?

[dennison]

In article <78i8s4$hth$1@its.hooked.net>,
  "Mike Silva" <mjsilva@jps.net> wrote:

> Now for another question.  Some people have mentioned getting into the Ada
> "mind-set".  What are the main components of this mind-set?  What, IOW,
> should I pay special attention to in order to avoid simply writing "C in
> Ada" (whatever that might mean).  Thanks again for the help.

For the most part, that's just something you'll have to work out. (Is there a
support group for recovering C coders?)

One good example that does spring to mind is string handling. C coders want
to be able to assign a length 5 string into a length 12 string because strcpy
would do that for them. So their first try tends to be:  Str : String(1..12);
begin  Str := "hiho!";

Which won't work in Ada because the two arrays aren't the same size. Then
they will try using a loop or slice to assign the 5 characters only. Then
they try to print the twelve character string. This won't do what they want,
because Ada strings aren't null terminated. Then they discover that they have
to instantiate a generic routine to ouput a number as a string, and they are
liable to get insanely frustrated.

The problem is that the approach is all wrong. Ada developers tend to handle
strings as literals or constants whenever possible. The '&' operator on
strings makes this much easier to deal with. Scalar numbers can be converted
to strings inline w/ "'image". In a severe jam a declare block can be used to
get a localized constant string, or one of the ada.strings packages can be
used.

This is just one example of many. I guess the main point is that you have to
think in terms of the tools at your disposal, not in terms of the tools you
*don't* have.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Time to join the fold?

[Matthew Heaney]

dennison@telepath.com writes:

> In a severe jam a declare block can be used to get a localized
> constant string, or one of the ada.strings packages can be used.

Rather odd to describe using a declare block to declare a string object
only in a "severe jam," since this is the normal, intended usage!

   declare
      Name : constant String := Get_Name (File);
   begin
   ...


Or

   declare
      Name : String := Get_Name (File);
   begin
      Make_Uppercase (Name);
      ...

Dynamicly declaring arrays (was: Time to join the fold?)

[dennison]

In article <m3aeyz8mw1.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> dennison@telepath.com writes:
>
> > In a severe jam a declare block can be used to get a localized
> > constant string, or one of the ada.strings packages can be used.
>
> Rather odd to describe using a declare block to declare a string object
> only in a "severe jam," since this is the normal, intended usage!
>

True, that is what they are there for. But my style is to avoid declare
blocks if I can help it. Typicaly I'd try to break off a proper subroutine
first. When I do use declare blocks, its usually just to provide a localized
exception handler (and in that case of course the "declare" isn't nessecary).

I'm not entirely sure I can defend this aversion to declare blocks in a
rational way, so if anyone has a rationale as to why its perfecly acceptable
to have declare blocks liberally sprinkled throught their code, I'm all ears.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[robert_dewar]

In article <794gg7$ib$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> I'm not entirely sure I can defend this aversion to
> declare blocks in a rational way, so if anyone has a
> rationale as to why its perfecly acceptable to have
> declare blocks liberally sprinkled throught their code,
> I'm all ears.

Why on earth does it need a rationale to use a feature
in the language that is obviously useful and has an ancient
and well accepted understanding as useful (blocks were
after all in Algol-60).

THe principle of using blcoks to make temporaries as
local as possible is of course familiar to any programmer
in an algol style language.

People can have allergies to anything, but a person with
an allergy to strawberries cannot reasonably ask a normal
healthy person to give a rationale for eating strawberries.

In this case we have a thread that clearly shows a use of
declare, and the response "that's nice, but I don't like
to use declare blocks" is indeed not convincing!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[news.oxy.com]

robert_dewar@my-dejanews.com wrote in message
<7963q0$ail$1@nnrp1.dejanews.com>...
>In article <794gg7$ib$1@nnrp1.dejanews.com>,
>  dennison@telepath.com wrote:
>> I'm not entirely sure I can defend this aversion to
>> declare blocks in a rational way, so if anyone has a
>> rationale as to why its perfecly acceptable to have
>> declare blocks liberally sprinkled throught their code,
>> I'm all ears.
>
>Why on earth does it need a rationale to use a feature
>in the language that is obviously useful and has an ancient
>and well accepted understanding as useful (blocks were
>after all in Algol-60).
>
>THe principle of using blcoks to make temporaries as
>local as possible is of course familiar to any programmer
>in an algol style language.


I could also mention that this was also used  in   Modula-2 as well (inner
modules).
Modula-2 had many features that later was implemented in Ada.
E.g. module in Modula-2 corresponds to package in Ada, IMPORT clause in
Modula-2 corresponds to WITH clause in Ada ,concept of "safe&reliable"
programming, concept of hiding implementation details using module
specifications  e.t.c.

Ability to reduce the living scope and name scope  of any king of objects
within large program can significantly increase the reliability of the
program.

Local blocks are especially useful in conjunction with some of other
powerful Ada features and give you ability
 1. To use  USE  and/or  USE TYPE clauses within declaration block so you do
not need to type fully qualified names and at the same time there is no
possibility of names clashes within program scope
 2. To locally  rename long packages and function names and create local
instances of  generic packages.
   2.1. both  1 &2  greatly increase readability of the program and show
programmer intentions.
 3. To declare local objects that should  be deleted on exit of the block
scope.
     This is very useful in conjunction with the use of controlled types
that is used to implement some kind of user defined garbage collection;
 4.  To define  local exception handlers  within block.

This list is not full. It is just short outline.
The real feeling of all that things will come with time and experience.

Regards,
Vladimir Olensky
(vladimir_olensky@yahoo.com)
(Vladimir_Olensky@oxy.com)
Telecommunication specialist,
Occidental C.I.S. Service, Inc. ( www.oxy.com )
Moscow,
Russia.

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[nabbasi]

In article <7973lb$mdl$1@remarQ.com>, "news.oxy.com" says...
>
 
>Modula-2 had many features that later was implemented in Ada.

didn't Modula-2 come after Ada? 

Nasser 

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[dennison]

In article <797595$ede@drn.newsguy.com>,
  nabbasi@earthlink.net.NOSPAM wrote:
> In article <7973lb$mdl$1@remarQ.com>, "news.oxy.com" says...
> >
>
> >Modula-2 had many features that later was implemented in Ada.
>
> didn't Modula-2 come after Ada?

According to FOLDOC (
http://www.instantweb.com/foldoc/foldoc.cgi?query=modula-2 ) Modula-2 was
designed by Niklaus Wirth in 1978. The last *requirements* document for Ada
(Steelman) was completed in 1978. The language design was not completed until
1983.

For more info on the history of Ada, see http://www.adahome.com/History/ and
the links contained therein.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[robert_dewar]

In article <797io4$jt7$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> The language design was not completed until 1983.

That's misleading of course, this is the date of
standardization, and cannot be compared with the M2 date,
since there was no ISO standard for M2 as far as I know.

The design of Ada in terms of major features (blocks yes or
no?) was complete long before then. The 1979 preliminary
Ada document really had most of the design complete, and it
was just polishing from there on.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[William Clodius]

robert_dewar@my-dejanews.com wrote:
> <snip>
> That's misleading of course, this is the date of
> standardization, and cannot be compared with the M2 date,
> since there was no ISO standard for M2 as far as I know.
> <snip>

Modlua 2 was standardized in 1996 over the objections of the USA, Japan,
and the Netherlands. The document includes a number of extensions to
Wirth's original language, clarifies a number of ambiguities, and
provides a detailed semantic description using the Vienna definition
model. The base language (subsequent publications have added object
orientation and generics) is 707 pages long. There was a strong feeling
by many observers that the extensions and the reliance on VDM got out of
hand, given that Wirth's original definition was, I believe, well under
50 pages.

Further information can be found in comp.lang.modula2

For what its worth Modula 1 predates Ada though not widely used.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: Dynamicly declaring arrays (was: Time to join the fold?)

[Robert A Duff]

William Clodius <wclodius@lanl.gov> writes:

>...There was a strong feeling
> by many observers that the extensions and the reliance on VDM got out of
> hand, given that Wirth's original definition was, I believe, well under
> 50 pages.

Wirth's language descriptions are quite short, primarily because he
tends to leave out a lot of important details, IMHO.  That's his style.
I would expect a definition of any of Wirth's languages, suitable for
standardization, would be much longer than Wirth's original, even if
there were *no* extensions or use of VDM.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Modula 2

[William Clodius]

Robert A Duff wrote:
> <snip>
> Wirth's language descriptions are quite short, primarily because he
> tends to leave out a lot of important details, IMHO.  That's his style.
> I would expect a definition of any of Wirth's languages, suitable for
> standardization, would be much longer than Wirth's original, even if
> there were *no* extensions or use of VDM.
> <snip>

Yes it would be longer, but not fifteen to twenty times longer. Note for
example that ISO Pascal ISO 7185:1990 is 78 pages long, which is two to
three times the size of Wirth's original definition, and extended Pascal
is 214 pages long, about six to eight times the size of Wirth's original
definition after adding numerous extensions. (Yes I agree page count can
be misleading, but that is the main data I have at the moment.)

Wirth's Modula 2 was a more complicated than his Pascal, but not a lot
more complicated. A Modula 2 standard giving the main syntax and
semantics in 100-125 pages and additional libraries in 100-125
additional pages would have been viewed as a reasonable extension and
clarification.

To put it into other perspectives:

	The Modula 2 base language document is (in terms of page count) almost
40% larger than the Ada 95 standard, without providing object
orientation or generics. Including the separate later documents giving
these extensions results in a nominal definition well over 50% larger
than the Ada standard, but still less functional than Ada 95.

	The Modula 2 base language document is (in terms of page count) about
2% smaller than the C++ standard. The library is not nearly as
functional as that of C++.

	Algol 68's two level grammar, that provides precision comparable to the
VDM, was used to define a language of comparable complexity (excluding
libraries) in complete detail in, Robert Dewar will probably correct
this, I believe a little under 200 pages.

	The VDM specification has not fulfilled the role the committee espected
for it when standardization started. They hoped to be able use the VDM
as input to automatic tools to verify the self consistency of the
standard, but resource limitations kept the tools from being completed.
It has instead resulted in extra work that delayed publication and made
the standard more difficult to read for those unfamiliar with VDM (most
compiler writers and reviewers of the draft standard are unfamiliar with
VDM).

	The exception handling mechanism specified in the Modula 2 document is
very different from PL/I, Ada, or C++, and was widely viewed as an
unwise experiment for a language standard.

	The libraries as a whole were rather experimental and had little match
to those described by Wirth in his Modula 2 texts.

	Some "countries", e.g., Sweden, that did not file formal objections to
the standard, included comments to the effect that the standard when
adopted would kill the language.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov