======================================================================= 1 ===
Date:    Thu, 1 Sep 1994 05:30:09 GMT
From:    mat@mole-end.matawan.nj.us
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <340dcc$qn8@larry.rice.edu>, amitp@owlnet.rice.edu (Amit Jayant Pate
l) writes:

> I have often heard that "most" C++ programs use casts.  However, I
> haven't found any place where I needed them, other than const-casts,
> which are no longer needed with the 'mutable' keyword.
> 
> Can someone give examples of where casts are necessary in C++?  I have
> not worked on medium or large programs yet, so I may just be lacking
> experience.

I suspect that the author was accustomed to using C++ as though it were
Smalltalk and downcasting to get at a `universal' base class.  (Of course,
I could be entirely wrong.)

There _are_ some places where you end up writing _conversions_ (which get
expressed as casts); these typically are places where you need more
conversions than C++ will insert automatically, or where you need to
disambiguate.

Such casts are dangerous not because they violate the type system, but
because they might violate it someday when declarations are changed.  It
is for this reason that ANSI/ISO C++ will (almost certainly) contain
the `static_cast< T >( .. .. .. )' which will convert its parameter to
the type  T  _iff_ it can be done by a legal, legitimate conversion (e.g.
if the compiler could insert the conversion itself, if it knew your
intentions).  If such a conversion attempts to contravene the type system,
it is illegal and will be diagnosed.

-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
	(Training and consulting in C, C++, UNIX, etc.)


======================================================================= 2 ===
Date:    Thu, 1 Sep 1994 03:28:59 GMT
From:    ian@syacus.acus.oz.au (Ian Joyner)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

Aug29141346@samsun.us.oracle.com>

speters@samsun.us.oracle.com (Stephen Peters) writes:


>In article <1994Aug29.022054.4589@rcmcon.com> rmartin@rcmcon.com (Robert Marti
n) writes:
>> goochb@swim1.eng.sematech.org (Bill Gooch on SWIM project x7151) writes:
>> 
>> [responding as to why he enjoys dynamic typed languages]
>> 
>> >Actually, I think it's because I'm essentially a freedom junkie.
>> >I find that I'm much more comfortable (and productive) in an
>> >environment that lets me do pretty much whatever I want within
>> >the programming paradigm, and doesn't throw non-essential 
>> >constraints at me in the interest of "forcing" me to write
>> >"better" programs.  
>> 
>> I notice that you do not exercise your freedom with respect to the
>> spelling of the words in your posting.  Is this because you feel that
>> a certain amount of rigidity in the spelling and grammar of your
>> writings aids in communictaions?
                            ^^
Fairy vunny ;-)

>If I might respond to this rather silly analogy, I'm sure that he
>finds spelling "freely" rather obnoxious, considering that USENET as a
>whole tends to pop up "syntax errors" in the form of spelling flames.
>He's merely trying to get his words to compile cleanly.

No, Robert has an excellent analogy.  I read into it that all languages
are made up of tokens, but only certain combinations are valid.  In the
written word, a spell checker can to the tedious work of detecting
spelling errors (where the error does not result in another valid word
of the language).  Grammar checkers have been less successful, as
natural grammar is much more complex. 

However, with computer languages, the grammars are deliberately invented
so that mechanical checks can be made. This has to do with helping
the programmer, NOT limiting her freedom. A type system within a
language is a language of it's own that the programmer is inventing,
and this again can be checked. It helps detect inconsistencies that
we might be introducing, because of something purely mechanical that
our thought processes did not think of at the time. And it is good
programmers that know their own thought processes that admit we need
this kind of mechanical aid. This has got nothing to do with limiting
freedom or creativity. In fact it enhances it.

Further more it is not just syntax errors we are trying to catch, it
is semantic errors. If you get flamed on the net for spelling errors,
then the error has already propogated too far. When building software,
if this sort of error propogates to our customer, it costs us money,
to fix it and in lost faith. Even more so, if semantic errors get
through.

>Surely you don't think he wants to be *completely* free in his
>programming, do you?  I'd hate to see him then...writing gorgeous
>poems instead of C code and then ranting about the restrictions of the
>compiler! :-)

Well if programmers put as much thought, love and care into programming,
as a poet puts into crafting fine words, perhaps the industry would be
a better place. But then I would certainly rather be reading poetry than
C programs ;-{.
-- 
Ian Joyner           |"for when lenity and cruelty play   |All opinions are
Unisys (ACUS)        | for a kingdom, the gentler gamester|personal and are not
ian@syacus.acus.oz.au| is the soonest winner" W.S. Henry V|Unisys official comm
ent


======================================================================= 3 ===
Date:    Thu, 1 Sep 1994 05:12:06 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

amitp@owlnet.rice.edu (Amit Jayant Patel) writes:

>I have often heard that "most" C++ programs use casts.  However, I
>haven't found any place where I needed them, other than const-casts,
>which are no longer needed with the 'mutable' keyword.

>Can someone give examples of where casts are necessary in C++?  I have
>not worked on medium or large programs yet, so I may just be lacking
>experience.

Casts in C++ are not almost always unecessary and unwanted.  There are
times when dynamic_cast is useful, but this is more a test and less a
cast.  

If we ignore novices, Casts are most often used in C++ by people who
are used to programming in dynamically typed languages (like
Smalltalk).  They have difficulty with the type system and are not
used to the restrictions it imposes.  Thus they use casts to do the
same things that they would have done in their dynamically typed
language.  What they need to do instead, is change their style. 

The style needed for programming in a statically typed language is
quite different from that needed for a dynamically typed language.
Once this transition is made, the casts in C++ disappear.

-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 4 ===
Date:    1 Sep 1994 08:00:49 GMT
From:    nebbe@lglsun.epfl.ch (Robb Nebbe)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <DERWAY.94Aug31133058@alumni.ndc.com>, derway@ndc.com (D. Erway) wri
tes:
|> 
|> >>>>> "Amit" == Amit Jayant Patel <amitp@owlnet.rice.edu> writes:
|> 
|>  Amit> I have not used Eiffel, so I am not speaking from experience here, bu
t
|>  Amit> it seems like I have to anticipate what classes my users might want m
y
|>  Amit> class to be derived from (like Sortable) for them to use my class,
|>  Amit> while I am less likely to have to do so in C++.
|> 
|> Eiffel offers both unconstrained and constrained generics.  Use whichever is
|> appropriate.
|> 

Amit is correct in stating that in Eiffel you usually need to anticipate
the use of constrained genericity. In Eiffel unconstrained genericity
isn't the equivalent of templates in C++. In Eiffel as well as Ada the
generic contract is clearly documented which in my opinion should ease
reuse and maintenance. In C++ I would expect you would need a tool to
figure out the contract or depend on comments in the code.

- Robb Nebbe


======================================================================= 5 ===
Date:    Thu, 1 Sep 1994 04:57:34 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

bunbury@vienna.eiffel.com (Richard Bunbury) writes:

>As a contribution to the recent discussions on static versus dynamic
>typing on these newsgroups, ISE has prepared a short position
>paper on the Eiffel approach to typing. 


I wish this were more a position paper, and less a "Eiffel is better
than C++" paper.... 


>             Static typing is for dynamic programmers:
>                 On the Eiffel approach to typing.


>     C++ offers some of the typing mechanisms described below.  But
>static  typing  a la C++ is too constraining for realistic software
>development. 

Gee, all those programs that we've all been developing in C++ just
aren't realistic.  This is pure hype and has no place in a position
paper.

>This is evidenced by the  observation  that  most  C++
>programs use casts, that is to say, cheat with the type system.

Most "good" programs in C++ *don't* use casts. 

[...]

>Multiple inheritance
>====================

>This is used routinely in Eiffel (as opposed to  C++  where  it  is
>viewed  with suspicion; 

MI in C++ may be viewed with suspicion by novices and people who are
used to SI languages.  Most consumate C++ programmers use MI freely,
and without suspicion.

[...]

-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 6 ===
Date:    Thu, 01 Sep 94 08:55:00 EDT
From:    gwyant@cloyd.East.Sun.COM
Subject: can we kill the "dynamic vs. static typing" discussion ?


I don't see what the discussion has to do Modula-3 anymore. In fact, 
it seems to have degenerated into a defense of the C++ type system,
with the occasional advertisement for Eiffel and why it is better than C++.
I find this to be just so much noise at this point. If you insist 
on continuing this war of opinions, please do so on the Eiffel, C++, 
or comp.object mailing lists.

Just one person's grumpy request.

--geoff




======================================================================= 7 ===
Date:    Thu, 1 Sep 1994 17:06:51 GMT
From:    freeman@coolidge.coolidge.grenoble.xerox.fr (Steve Freeman)
Subject: Re: [Q] Description of Modula-3?


In article <CvEuFy.K3x@undergrad.math.uwaterloo.ca> bcrwhims@undergrad.math.uwa
terloo.ca (Carsten Whimster) writes:
> 
> In article <341b1e$qrh@rs18.hrz.th-darmstadt.de>,
> Michael Bonetsmueller <bogoethe@rbg.informatik.th-darmstadt.de> wrote:
> |  
> |  Hello M3ers,
> |  
> |  I'm a bloody beginner even in OOP. Does anybody know where to find a good
> |  Manual/Tutorial an M3? I don't need a compiler description, i want to get
> |  taught how to program in M3. Is there anything the like on the Net?
> |  
> |  I browsed already the FAQ, but there are only big, expensive books. :-(
> 
> I suppose it is probably what you would call a big expensive book, but
> I would recommend "Modula-3", Sam Harbison.
> -- 

Apologies to Sam Harbison, but you could also get hold of the technical
report which describes the language from SRC (or ftp it from 
gatekeeper.dec.com) and pull over some of the libraries to see how they
do it. It may take a while to get your head around some of the concepts,
but it's worth it.

steve

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Steve Freeman, Research Scientist, Rank Xerox France.

Surface:  Rank Xerox Research Centre,
          6, chemin de Maupertuis, 38240 Meylan, France.
Internet: steve.freeman@xerox.fr
Phone:    +33 76 61 50 21
Fax:      +33 76 61 50 99


but wotthehel wotthehel
toujours gai
  -- mehitabel the cat


======================================================================= 8 ===
Date:    Thu, 1 Sep 1994 09:42:23 -0500 (CDT)
From:    "William D. Gooch" <goochb@swim5.eng.sematech.org>
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

On Thu, 1 Sep 1994, Ian Joyner wrote:

> Aug29141346@samsun.us.oracle.com>
> 
> speters@samsun.us.oracle.com (Stephen Peters) writes:
> 
> >If I might respond to this rather silly analogy, I'm sure that he
> >finds spelling "freely" rather obnoxious, considering that USENET as a
> >whole tends to pop up "syntax errors" in the form of spelling flames.
> >He's merely trying to get his words to compile cleanly.
> ....
> However, with computer languages, the grammars are deliberately invented
> so that mechanical checks can be made. This has to do with helping
> the programmer, NOT limiting her freedom. A type system within a
> language is a language of it's own that the programmer is inventing,
> and this again can be checked. It helps detect inconsistencies that
> we might be introducing, because of something purely mechanical that
> our thought processes did not think of at the time. And it is good
> programmers that know their own thought processes that admit we need
> this kind of mechanical aid. 

So your assertion is that in order to be a "good programmer" one is 
required to "admit that we need this ... aid."   I think not.

>  This has got nothing to do with limiting
> freedom or creativity. In fact it enhances it.

Depends on your point of view and the kind of freedom you want to 
have, I suppose.  In an email discussion that spun off from this 
thread, I elaborated:

... as in the freedom to not worry about static typing and other 
such constraints when I am doing development.  This freedom allows me to 
concentrate on dealing with the complexities of the problem at hand, 
rather than being concerned about extraneous issues that have more to do 
with the quality of the implementation than the quality of the solution.  
I find that I am much better off if I have the choice of deferring those 
issues until I am on the downhill run toward finishing.

And I simply cannot agree with you when you say that static typing 
"enhances" creativity.  What exactly do you mean, that you could make 
such a claim?  Creativity, in my experience, is limited whenever there 
are extraneous distractions from uninhibited ideation.  Dealing with 
static type specification is one such distraction.  This isn't an issue 
if dynamic typing is also available, but I still don't see how static 
typing can possibly _enhance_ creativity.


======================================================================= 9 ===
Date:    1 Sep 1994 17:45:52 GMT
From:    heinze@i41s5.ira.uka.de (Ernst A. Heinz)
Subject: Modula-3 for Solaris 2.3 alias SunOS 5.3

Is the SOLsun port of Modula-3 release 3.3 or 3.4 up and running?
If so, is there also a comprehensive file somewhere with all
necessary patches?

My question relates to the following installation problem that I am
experiencing right now when executing ``m3boot'' with release 3.3 from gatekeep
er.

Undefined                       first referenced
 symbol                             in file
ieee_handler                        ../../libm3/SOLsun/libm3.a(FloatMode_m.o)
sigfpe                              ../../libm3/SOLsun/libm3.a(FloatMode_m.o)
ieee_flags                          ../../libm3/SOLsun/libm3.a(FloatMode_m.o)
ld: fatal: Symbol referencing errors. No output written to m3c
*** error code 1
"/a/senilix/files/senilix10/labs/pelab/Modula-3/release-3.3/boot-SOLsun/m3build
/templates/COMMON.BOOT", line 52: command execute failed
*** call stack ***
"/a/senilix/files/senilix10/labs/pelab/Modula-3/release-3.3/boot-SOLsun/m3build
/templates/COMMON.BOOT", line 52: call to built-in exec
"./make.boot", line 367: call to procedure boot_prog

Please answer by email to ernhe@ida.liu.se or heinze@ira.uka.de --- thanks.

=Ernst=

-- 
+--------------------------------------------------------+-------------------+
| Ernst A. Heinz              (email: heinze@ira.uka.de) |                   |
| Institut fuer Programmstrukturen und Datenorganisation | Make it as simple |
| Fakultaet fuer Informatik, Universitaet Karlsruhe      | as possible, but  |
| Postfach 6980, D-76128 Karlsruhe, F.R. Germany         | not simpler.      |
| (Voice: ++49/(0)721/6084386, FAX: ++49/(0)721/694092)  |                   |
+--------------------------------------------------------+-------------------+

"It has recently been found out that research causes cancer in rats!"


======================================================================= 10 ===
Date:    1 Sep 94 08:57:29
From:    doug@monet.ads.com (Doug Morgan)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <340dcc$qn8@larry.rice.edu> amitp@owlnet.rice.edu (Amit Jayant Patel
) writes:
>I have often heard that "most" C++ programs use casts.  However, I
>haven't found any place where I needed them, other than const-casts,
>which are no longer needed with the 'mutable' keyword.
>
>Can someone give examples of where casts are necessary in C++?  I have
>not worked on medium or large programs yet, so I may just be lacking
>experience.

Some (many, all?) C++ compiler/linker environments are incapable of
recognizing *all* cases of template functions (member or not) that
never deference, overload, dispatch, etc. on objects of pointer type
declared as template arguments.  Such functions could have just one
implementation that works for pointers to all types of objects.
Therefore, to prevent code bloat, programmers sometimes "must" use
templates with (inlined) casts of pointers to/from void* with actual
operations carried out by a single implementation in terms of void*.

Similarly, in order to get reasonable behavior from virtual functions,
programmers sometimes have to cast pointers returned by virtual
functions (to pointers to more derived classes).  The need for this
has been removed by some ANSI committee decisions, but that doesn't
help everybody today.  (Reflects the issue of what you mean by "C++".)

I find casts to be helpful in rapidly coding/decoding/reformating
binary data.  Maybe there are better ways, but I've never bothered
thinking about it.

Doug




======================================================================= 11 ===
Date:    Thu, 1 Sep 1994 18:39:21 GMT
From:    stef1638@mach1.wlu.ca (stefanovich boris)
Subject: AUSTIN PARK



AUSTIN PARK MANAGEMENT - The Number One UNIX Recruiters in Canada

We are currently recruiting candidates with 2+ years of work experience in
sofware development, technical support, MAC, and Q.A. Testing. If you have
OOP, RDBMS (Sybase or Oracle), LAN/WAN, or Internet implementation experience,
we'd like to talk to you about opportunities with our client companies.

Call us at (416) 488-9565, Fax us at (416) 488-9601 or Snail us at:

AUSTIN PARK MANAGEMENT
40 Eglinton Avenue West
Suite #207
Toronto, Ontario
M4P 3A2

*************************call us before we call you!!************************



======================================================================= 12 ===
Date:    1 Sep 94 14:04:21
From:    emery@goldfinger.mitre.org (David Emery)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

> This isn't an issue if dynamic typing is also available, but I still
>don't see how static typing can possibly _enhance_ creativity.

Do you believe in abstraction?  Do you believe in automating the
details and bookkeeping?  

Static type checking (whether in the language, such as Ada, or in some
related tool, such as lint for C) helps creativity by allowing the
programmer to concentrate on the big issues, and using the tools to
automate checking of the small issues.  

				dave

--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------


======================================================================= 13 ===
Date:    Thu, 1 Sep 1994 16:20:02 GMT
From:    heyman@acad.stedwards.edu (Jerry Heyman)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

Richard Bielak (richieb@bony1.bony.com) wrote:
> In article <CvEFLs.3vz@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak
) writes:

> >
> >Recall this sentiment of an old programmer:
> >
> >    "Testing only proves the existence of errors, not their absense."
>                                                              ^^^^^^^
> >
> >On the other hand, a type checker proves the _absense_ of type errors.

Well, I guess this is true - but what if the programmer casts a variable?
The type might be correct (because they cast it to the type they need), but
is the data valid?

> ...richie
> -- 
> * Richie Bielak   (212)-635-4835   | 

jerry
-- 
Jerry Heyman                by day  : IBM AIX Development, RISC System/6000 Div
                            Internet: jerry@austin.ibm.com
heyman@acad.stedwards.edu   by nite : Adjunct Lecturer, St. Edward's Univ.
*All comments are my own and should not be construed to represent any one else


======================================================================= 14 ===
Date:    2 Sep 94 06:18:12 GMT
From:    priest@fraser.sfu.ca (David Priest)
Subject: Logitech M2 v4.0 Student Pak

  I can get Logitech's Modula-2 v4.0 student package.  Is it worth it?  I
currently use FST's Modula, and have had a great time with it: I think
I should be buying a package.  My choices seem to be FST and Logitech
(or, I suppose, move on to Modula-3)...
 
  So the question boils down to: is the Logitech student package ag
any good?  Bugs?  How's the development environment?  And does it 
have object extensions like FST does?
 
  Thanks for any help,
  david_priest@fraser.sfu.ca



======================================================================= 15 ===
Date:    Sat, 03 Sep 1994 02:03:21
From:    j_mcarthur@BIX.com (Jeffrey McArthur)
Subject: Re: Logitech M2 v4.0 Student Pak

David Priest asks
>  I can get Logitech's Modula-2 v4.0 student package.  Is it worth it?  I
>currently use FST's Modula, and have had a great time with it: I think
>I should be buying a package.  My choices seem to be FST and Logitech
>(or, I suppose, move on to Modula-3)...
> 
>  So the question boils down to: is the Logitech student package ag
>any good?  Bugs?  How's the development environment?  And does it 
>have object extensions like FST does?

I don't have any experience with the student package.  I have the "normal"
package.  The Logitech 4.0 package is a very good development platform. 
There are only two problems with it.  First it is not very flashy. 
Personally I prefer this.  I run from the command line.  Second, and much
more serious, the product is orphaned.

Symantech purchased Multiscope a while ago.  Symantech decreed that ALL
development would be done in C++.  So this killed all support for the very
good Modula 2 product.

Actually the Logtech 4.0 package uses a slighly modified version of the
Stonybrook compiler.  Stonybrook is still around.  So you can buy the
compiler directly from them.  The newest release of the Stonybrook compiler
is STILL in beta test (how long has it been?).

The only bugs I have found in the Logitech 4.0 package relate to LONGCARD. 
I have found 4 separate bugs in the way the compiler handles arithmatic
with LONGCARD.  LONGINT works, but LONGCARD is broken.

The other option is Clarion's TopSpeed compiler.  Again it is not flashy. 
It does have object oriented extensions.  There is a student version of the
compiler that gets very good reviews (it is based on version 1.17 while the
current release is 3.10).

In my opinion, Modula-3 is not quite ready for "prime time".  I am spoiled.
 I got used to reasonably fast compiles and links with Modula-2.  Modula-3
generates C code which then must be compiled and linked.  This is a VERY
SLOW process.  So until someone has a native code Modula-3 I will not use
it (I just don't have the time to wait around for the slow compiler and
linker).

The other option is to go to Oberon-2.  Oberon is the successor to
Modula-2.  Oberon-2 is the sucessor to Oberon.  There are several very
interresting packages available for Oberon.  One of the more interresting
is the OM2 compiler.  It comes with a full Modula-2 and Oberon-2 compiler. 
The compiler generates 32 bit code.  It looks very good.  Unfortunately you
cannot link in forign modules.  I need the ability to link in forign
modules (e.g. the Paradox Engine or CodeBase).  There is also the Window's
based POW.  This looks very good also.
----
    Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur
    a.k.a. Jeffrey McArthur          email: j_mcarthur@bix.com
    phone: (301) 210-6655
    fax:   (301) 210-4999
    home:  (410) 290-6935

The opinions express are mine.  They do not reflect the opinions
of my employer.  My access to the Internet is not paid for by my
employer.


======================================================================= 16 ===
Date:    2 Sep 1994 20:18:44 -0700
From:    bunbury@vienna.eiffel.com (Richard Bunbury)
Subject: Real C++ programmers don't use casts [was Re: Static vs Dynamic Typing
]

>From Robert Martin <rmartin@rcmcon.com>:

>Casts in C++ are [] almost always unecessary and unwanted.  There are
>times when dynamic_cast is useful, but this is more a test and less a
>cast.  

>If we ignore novices, Casts are most often used in C++ by people who
>are used to programming in dynamically typed languages (like
>Smalltalk).
                [The place marked [] contained the word "not" but
                I assume this is a typo.]

Well, this is not what we hear from the field  - i.e. from disgruntled C++
programmers, an ever fresh source of new Eiffel fans. Or from the
literature either. Just today we received the September 1994 issue
(volume 12, number 9) of "The C/C++ Users Journal"). And sure enough,
the longest article in the issue is entitled "Code Capsules: Conversions
and Casts", by Chuck Allison (perhaps a "Novice"?). Here is a quote from
that article:

-------- Begin quotation --------------------------------------
  A cast is your way of telling the compiler to allow you to do something
  potentially dangerous, because you think you know what you're doing. Too
  often, though, you don't know what you're doing (no offense!), and you
  spend days tracking down an insidious pointer conversion error or similar bug
.

    [Note by RB: No, this is NOT Eiffel propaganda literature.
    It does come from the C/C++ Users Journal, September 1994.]

  It's interesting that programmers
  use a single cast notation for so many different purposes:

  + to reinterpret the bit pattern of an object
  + to widen or narrow a value
  + to traverse a class hierarchy
  + to cast-away `const' or `volatile'
  + to do some implementation-dependent magic
-------- End quotation --------------------------------------

Frankly, to an Eiffel programmer, this all sounds pretty repulsive. In
particular we do not think that object-oriented software construction
should be about "magic".

But even if you find nothing wrong with this, the scope of things for
which the author cites a need to use casts in C++ seems rather broad,
supporting the obvious observation of my earlier message that practical C++
programming requires casting.

In fact, the same article by Mr. Allison tells us that "C++ defines four
new cast mechanisms". Now if casts are not needed, how come there are
four more kinds?

To repeat comments made in an earlier message: in Eiffel, you can
do everything WITHOUT casts, in a type-safe manner. The key is a
flexible enough type system.

By the way, the lead article in the same issue of the C/C++ Users Journal
is entitled "Using Windows Memory Management", by David Singleton.
It comes with a program listing. Here are a few pretty typical lines
from that listing:

  FP_FHB current_block_pointer = (FP_FHB) p_fhb ;
  ...
  _segment cur_seg = (_segment) SELECTOROF (this)
  ...
  (WORD) (this_block -> in_use_list) 

Looks like some casting is going on. But perhaps the author is a
novice, or a freshly retrained Smalltalk programmer?

-- 
Richard Bunbury
ISE Eiffel Customer Support
Reply to: <info@eiffel.com>


======================================================================= 17 ===
Date:    Fri, 2 Sep 1994 20:14:32 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

"William D. Gooch" <goochb@swim5.eng.sematech.org> writes:

>And I simply cannot agree with you when you say that static typing 
>"enhances" creativity.  What exactly do you mean, that you could make 
>such a claim?  Creativity, in my experience, is limited whenever there 
>are extraneous distractions from uninhibited ideation.  Dealing with 
>static type specification is one such distraction.  This isn't an issue 
>if dynamic typing is also available, but I still don't see how static 
>typing can possibly _enhance_ creativity.

Creativity is the art of solving problems in the face of limitations.
One person says it is impossible, another gets creative and solves the
problem.   It is not the absence of limitations that enhances
creativity, it is creativity that conquers limitations.

-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 18 ===
Date:    Fri, 2 Sep 1994 18:39:05 GMT
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: TCP Module strangeness. Intended?


> 	- The strace showed a call to connect like:
> connect(4, {sin_family=AF_INET, sin_port=htons(57616), ...

The previous post does not mention the conclusion. The htons function
included for LINUX was for big endian instead of for little endian.
This has been fixed (libm3/src/unix/linux/Uin.m3) and will show up
in the next SRC release and LINUX binaries, as usual.
--

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029



======================================================================= 19 ===
Date:    3 Sep 1994 17:37:20 GMT
From:    satish@sun.mcs.clarkson.edu (Satish Thatte)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

>From bunbury@vienna.eiffel.com (Richard Bunbury):
> From Robert Martin <rmartin@rcmcon.com>:
> 
>>If we ignore novices, Casts are most often used in C++ by people who
>>are used to programming in dynamically typed languages (like
>>Smalltalk).
> 
> Well, this is not what we hear from the field  - i.e. from disgruntled C++
> programmers, an ever fresh source of new Eiffel fans.
[extract from C/C++ Journal and comments by RB eleted]

Richard, perhaps you can post some examples where a C++ program
*requires* casting that a corresponding Eiffel program avoids
by some mechanism *other than* assignment attempt or covariance in
subclasses (which in a way are the same thing).

I am not saying such examples don't exist, but having heard this
argument going on for a long time, I still haven't seen any examples
that pinpoint the superiority of Eiffel typing over C++ in a way that
is not subsumed by RTTI features in forthcoming versions of C++.

Satish


======================================================================= 20 ===
Date:    Fri, 02 Sep 1994 21:20:00 +0100
From:    geert@dialis.hacktic.nl (Geert Bosch)
Subject: DEC's Modula 3

I just ftp-ed Modula-3 from gatekeeper.dec.com and I am wondering if anybody
has tips about setting it up. My ultimate wish would be to compile Modula-3
from within an OS/2 environment. Does anybody have experience in doing this?

Thanks in advance for your reply,

Greetings, Geert 


======================================================================= 21 ===
Date:    Sat, 03 Sep 94 20:59:55 GMT+0100
From:    atverm@ecp541.ecn.nl
Subject: Re: DEC's Modula 3

In  <778611866.AA07139@dialis.hacktic.nl>  geert@dialis.hacktic.nl (Geert Bosch
) writes:
| I just ftp-ed Modula-3 from gatekeeper.dec.com and I am wondering if anybody
| has tips about setting it up. My ultimate wish would be to compile Modula-3
| from within an OS/2 environment. Does anybody have experience in doing this?
|  
| Thanks in advance for your reply,
|  
| Greetings, Geert 

I wish you good luck, you'd be the first to succeed. If you're serious
I advise you to use the EMX 0.8h GCC environment to compile the beast.
You'll need a fair amount of Unix and C knowledge. I gather you've
taken the Linux port as a starting point? 
I once had the same plans as you, but I really don't have the time to
do it. I remember reading some message of another brave person about
two months ago who reported he got quake to work and he posted the
diffs needed for it. I didn't hear from it any more. If you make progress,
I am very much interested and would like to be kept informed, and I'm sure
much others are because there have been quite some requests for an OS/2
port in the recent year!

======================================================================
A.T. Vermeulen (Internet: a.vermeulen@ecn.nl; Phone: (+31)22464194)
Energy Research Foundation, PO Box 1, 1755 ZG  Petten, The Netherlands


======================================================================= 22 ===
Date:    03 Sep 1994 22:41:01 GMT
From:    tmb@arolla.idiap.ch (Thomas M. Breuel)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <1994Sep1.094653@lglsun.epfl.ch> nebbe@lglsun.epfl.ch (Robb Nebbe) w
rites:
|Amit is correct in stating that in Eiffel you usually need to anticipate
|the use of constrained genericity. In Eiffel unconstrained genericity
|isn't the equivalent of templates in C++. In Eiffel as well as Ada the
|generic contract is clearly documented which in my opinion should ease
|reuse and maintenance. In C++ I would expect you would need a tool to
|figure out the contract or depend on comments in the code.

You can make the contract explicit in C++ by defining a dummy function
that mentions all the facilities and properties you would like to put
in the contract.  You can (for example) specify the presence of member
functions, data members, and inheritance relations that way.

					Thomas.


======================================================================= 23 ===
Date:    Sun, 4 Sep 1994 03:47:16 GMT
From:    mikec@metronet.com (Mike Christiansen)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

>From: bunbury@vienna.eiffel.com (Richard Bunbury)
>Multiple inheritance
>====================

>     Multiple inheritance makes it possible to view an object  from
>two  or more viewpoints.  For example an E_MAIL_MESSAGE can be both
>an ASCII_DOCUMENT and a NETWORK_EXCHANGEABLE (capitalizing the name
>of  the  corresponding classes: the first will inherit from both of
>the next two). One of the main unvoiced reasons for  the  hostility
>to  static  typing  in  Smalltalk is that Smalltalk has only single
>inheritance; so in a case like this you would have to  choose  only
>one  of  the  two  viewpoints,  making  static  typing unacceptably
>constraining.

Sorry, But I missed this one altogether. What does MI have to do with dynamic 
typing. Yes, Smalltalk supports only linear inheritance and I have found it to 
be constraining in some cases. But with some though, and the application of 
other patterns of composition (such as wrappers and deligation) I have been 
able to work arround my problems.  But these problems would be there 
reguardless of the typing system. 

BTW. I would be interested in a discussion of the problems which would be 
introduced by supporting MI in Smalltalk. Tools, existing class libraries, 
legasy applications, etc. (although like this thread, it has probably been 
beat to death in the past :-)

*********************************************
Mike Christiansen
mikec@metronet.com
*********************************************


======================================================================= 24 ===
Date:    4 Sep 1994 06:50:09 GMT
From:    mbk@inls1.ucsd.edu (Matt Kennel)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

Richard Bunbury (bunbury@vienna.eiffel.com) wrote:
: To repeat comments made in an earlier message: in Eiffel, you can
: do everything WITHOUT casts, in a type-safe manner. The key is a
: flexible enough type system.

: By the way, the lead article in the same issue of the C/C++ Users Journal
: is entitled "Using Windows Memory Management", by David Singleton.
: It comes with a program listing. Here are a few pretty typical lines
: from that listing:

:   FP_FHB current_block_pointer = (FP_FHB) p_fhb ;
:   ...
:   _segment cur_seg = (_segment) SELECTOROF (this)
:   ...
:   (WORD) (this_block -> in_use_list) 

: Looks like some casting is going on. But perhaps the author is a
: novice, or a freshly retrained Smalltalk programmer?

This is the fault of Windows no doubt.  And the fact that the native
Windows API is C.  (yeah right language doesn't matter)

: -- 
: Richard Bunbury
: ISE Eiffel Customer Support
: Reply to: <info@eiffel.com>

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".


======================================================================= 25 ===
Date:    Sun, 4 Sep 1994 12:32:14 GMT
From:    robsch@robkaos.ping.de (Robert Schien)
Subject: Re: DEC's Modula 3

atverm@ecp541.ecn.nl wrote:
: In  <778611866.AA07139@dialis.hacktic.nl>  geert@dialis.hacktic.nl (Geert Bos
ch) writes:
: | I just ftp-ed Modula-3 from gatekeeper.dec.com and I am wondering if anybod
y
: | has tips about setting it up. My ultimate wish would be to compile Modula-3
: | from within an OS/2 environment. Does anybody have experience in doing this
?
: |  
: | Thanks in advance for your reply,
: |  
: | Greetings, Geert 

: I wish you good luck, you'd be the first to succeed. If you're serious
: I advise you to use the EMX 0.8h GCC environment to compile the beast.
: You'll need a fair amount of Unix and C knowledge. I gather you've
: taken the Linux port as a starting point? 

I would be interested in porting "the beast" to SVR4/386 and FreeBSD/NetBSD.
When I take the Linux port as a starting point, what is necessary
to port? I've looked at the various files in BOOT-Linux.tar and found
lots of assembler code. What is necessary to do the port?
BTW, in which way vary gcc and m3gcc?

Robert



======================================================================= 26 ===
Date:    Sun, 4 Sep 1994 03:55:18 +0000
From:    rob@brewster.demon.co.uk (Rob Heyes)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <1994Sep1.162002.24832@acad.stedwards.edu> heyman@acad.stedwards.edu
 (Jerry Heyman) writes:
> Well, I guess this is true - but what if the programmer casts a variable?
> The type might be correct (because they cast it to the type they need), but
> is the data valid?

Proper languages (e.g. Eiffel) don't provide casts (not strictly true, but
you have to jump through hoops to do it).  Assignment attempt is the safe
alternative in Eiffel.

Rob
-- 
It's going to be fun to see how long the meek can keep the earth when
they inherit it.

Rob Heyes (B3/5 w- dc g k s- r- p)             rob@brewster.demon.co.uk


======================================================================= 27 ===
Date:    Sun, 4 Sep 1994 14:35:55 +0000
From:    rob@brewster.demon.co.uk (Rob Heyes)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <341sem$82e@galileo.polito.it> amund@galileo.polito.it (A.Aarsten) w
rites:
> Also, derway@ndc.com (D. Erway) writes:
> 
> > C++ offers Unconstrained Genericity.  So you cannot write a template,
> > and limit the types that can be used to instantiate it.  Therefor you
> > cannot write code in EXCHANGE_LIST that uses the fact that the type is
> > known, so you can call a method.  You would have to first do a cast,
> > which throws away the type safety...
> 
> The types of the parameters are limited _implicitly_ by the features
> your generic class accesses. You just call the methods that you need,
> no casting. You can then use any class that provides those features,
> regardless of where it is located in the class hierarchy.

In other words, you can quite easily write a generic class in C++ that can
never be instantiated because no classes provide all the methods that are
used by that class.  And the designer of the generic class will never know.

Apart from anything else this seems to blow type safety completely out of the
water.  The absence of pre and post-conditions in C++ means that you have no
idea whether the features that you are using are appropriate.


> > Also, Eiffel allows you to inherit from a generic class to make a
> > specialized version, that is still generic.  C++ does not allow this.
> 
> Wrong! C++ does allow this.

Could you illustrate this?


> > Assignment attempt is an operation of the form
> >
> >     x ?= y
> >
> > Assignment  attempt  x ?= y  (...) looks at the actual
> > object type, performs the assignment if that type is compatible with
> > that of x, and otherwise  assigns to x a void value  (which you  can
> > then  test for).
> 
> What is the difference between this and the C++ dynamic_cast? They
> seem exactly the same to me.

I thought that dynamic_cast threw an exception rather than assigning a void
value.

Rob
-- 
It's going to be fun to see how long the meek can keep the earth when
they inherit it.

Rob Heyes (B3/5 w- dc g k s- r- p)             rob@brewster.demon.co.uk


======================================================================= 28 ===
Date:    Sun, 4 Sep 1994 03:55:14 +0000
From:    rob@brewster.demon.co.uk (Rob Heyes)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <342ib1$gpm@larry.rice.edu> amitp@owlnet.rice.edu (Amit Jayant Patel
) writes:
> If I want a sorted list, in C++'s templates, I can write a template
> class that uses the "operator <" on the class for sorting.  I can use
> ints or strings or any class that has an operator < defined on it.
> [Note:  operator < is not a method here; it is a "global" function.]

And as such has absolutely no semantics - all you can say about it is that
it is a binary operator and that its 'name' is "<".  In Eiffel you can
specify more properties of a given feature by means of the pre and post
conditions.  IMHO Eiffel's support for design by contract by the use of
assertions is its most important feature.


> However, ints, strings, and all my other classes are not all derived
> from some Sortable class.  I can't specify "derived from Sortable" in
> my template.
> 
> I have not used Eiffel, so I am not speaking from experience here, but
> it seems like I have to anticipate what classes my users might want my
> class to be derived from (like Sortable) for them to use my class,
> while I am less likely to have to do so in C++.

This is IMHO a point in Eiffel's favour.  You only need to specify enough
of the behaviour that is required to implement your class.  Eiffel's
version of multiple inheritance will generally let you do whatever you
want. Some people will probably complain that this may make it difficult
to store integers, reals and strings in a container class with a strange
ordering. But then how often do you only store integers, reals or strings
by themselves in a container?

Rob
-- 
It's going to be fun to see how long the meek can keep the earth when
they inherit it.

Rob Heyes (B3/5 w- dc g k s- r- p)             rob@brewster.demon.co.uk


======================================================================= 29 ===
Date:    05 Sep 1994 02:37:12 GMT
From:    tmb@arolla.idiap.ch (Thomas M. Breuel)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

In article <348puk$3o0@vienna.eiffel.com> bunbury@vienna.eiffel.com (Richard Bu
nbury) writes:
|[citing an article from the C/C++ journal:]
|>  A cast is your way of telling the compiler to allow you to do something
|>  potentially dangerous, because you think you know what you're doing.

Well, this is simply wrong.  Most casts are conversions between types
that are as typesafe as the same operations are in other languages,
including Eiffel.

|>  It's interesting that programmers
|>  use a single cast notation for so many different purposes:
|>
|>  + to reinterpret the bit pattern of an object
|>  + to widen or narrow a value
|>  + to traverse a class hierarchy
|>  + to cast-away `const' or `volatile'
|>  + to do some implementation-dependent magic
|[...]
|But even if you find nothing wrong with this, the scope of things for
|which the author cites a need to use casts in C++ seems rather broad,
|supporting the obvious observation of my earlier message that practical C++
|programming requires casting.
|
|In fact, the same article by Mr. Allison tells us that "C++ defines four
|new cast mechanisms". Now if casts are not needed, how come there are
|four more kinds?

Casts in C++ fulfill a number of functions and are used in a number
of contexts.  Here are some examples:

	(1) typesafe conversions (e.g. int to float)

	(2) interfacing to code written for different versions
	    of the C/C++ type system (e.g., pre-const and const)

	(3) interfacing to code written in a language with
	    a different type system (e.g., to CommonLisp or
	    assembly language)

	(4) writing user-defined memory allocators

	(5) accessing I/O registers and absolute memory
	    locations

	(6) accessing machine-dependent disk files

These are all things that real-world programs have to do every
now and then.  Casts have in the past provided a single, convenient
notation for doing these things.  However, over the last 20 years,
software engineering has changed, and programmers now prefer to
be able to document better the different uses of a cast.  That's
why C++ now has four different casts, each of which only covers
part of the functionality of the original notation, which has now
been deprecated.  The new notation also makes it easier to locate
places in the code where unsafe casts are being used.

Unfortunately, cast notation looks so harmless that inexperienced
programmers will also use them to hack around design flaws.  The
newer notation will hopefully make it clearer that this is a bad
idea.

|To repeat comments made in an earlier message: in Eiffel, you can
|do everything WITHOUT casts, in a type-safe manner. The key is a
|flexible enough type system.

You seem to be saying that Eiffel doesn't have to provide the
functionality of a cast because Eiffel's type system is more
flexible than that of C++.  Could you be more specific in what
way it is more flexible?

|By the way, the lead article in the same issue of the C/C++ Users Journal
|is entitled "Using Windows Memory Management", by David Singleton.
|It comes with a program listing. Here are a few pretty typical lines
|from that listing: [...]
|Looks like some casting is going on. But perhaps the author is a
|novice, or a freshly retrained Smalltalk programmer?

I'm not surprised that Windows memory management code requires
casts.  How would you carry out the same operations in Eiffel?

				Thomas.


======================================================================= 30 ===
Date:    4 Sep 1994 23:29:18 -0700
From:    bunbury@vienna.eiffel.com (Richard Bunbury)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

>From Mike Christiansen:

>Sorry, But I missed this one altogether. What does MI have to do with dynamic 
>typing. Yes, Smalltalk supports only linear inheritance and I have found it to
 
>be constraining in some cases. But with some though, and the application of 
>other patterns of composition (such as wrappers and deligation) I have been 
>able to work arround my problems.  But these problems would be there 
>reguardless of the typing system. 

The argument of the original message was this:

	- (A) Proponents of Smalltalk and other dynamically typed languages
	  claim that static typing is too constraining.

	- (B) Smalltalk does not (in general) support multiple inheritance.

	- (C) It is indeed true that without multiple inheritance static
	  typing would be unacceptably constraining (claim A).

	- (D) But examination of the typical examples used to support claim
	  A show, in our opinion, that the unacceptable restrictions are due
	  to the absence of multiple inheritance, and that with MI static
	  typing is in fact not a limitation.

Sorry if the reasoning was not clear enough.

 
-- 
Richard Bunbury
ISE Eiffel Customer Support
Reply to: <info@eiffel.com>


======================================================================= 31 ===
Date:    5 Sep 1994 11:18:22 GMT
From:    glyn@midland.co.nz (Glyn Webster)
Subject: Re: [Q] Description of Modula-3?

>Apologies to Sam Harbison, but you could also get hold of the technical
>report which describes the language from SRC 
>(or ftp it from gatekeeper.dec.com) ......
>- - - - - - - - - - - - - - - - - - - - - - - - - -
>Dr. Steve Freeman, Research Scientist, Rank Xerox France.

I've been lurking on Michael Bonetsmueller's message.
I tryed FTPing  gatekeeper.dec.com for the report last night but didn't 
know where to look: could you  tell me where in gatekeeper.dec.com 
the report is stored?


======================================================================= 32 ===
Date:    5 Sep 1994 01:38:08 +0100
From:    tom@smart.bo.open.de (Thomas Neumann)
Subject: Success - 3.3 on NeXT


I've just succeeded in bootstrapping release-3.3 on a NeXT/m68k
running NeXTSTEP 3.2.

Things look pretty good; it just finished compiling 
libm3 [the real thing, not the libm3 from the boot compiler] and
I compiled "m3pp" with the fresh libm3 for a test. Everything
looks ok, so I assume the compiler is working.

I have not heard of anyone else who succeeded in bootstrapping
a 3.x release on NeXTSTEP so far, and it was quite tricky
in some places, so this may indeed be the first port (?!)

To the SRC folks: Are you interested in my modifications ?
Maybe it would be a good idea to upload a pre-compiled, ready to
execute NeXT version somewhere ?

bye -- Thomas


======================================================================= 33 ===
Date:    6 Sep 1994 08:09:28 GMT
From:    fabre@osf.org (Christian Fabre)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

In article <34ac8g$rlc@library.erc.clarkson.edu>, 
	satish@sun.mcs.clarkson.edu (Satish Thatte) writes:

|> From bunbury@vienna.eiffel.com (Richard Bunbury):
[deleted]

|> Richard, perhaps you can post some examples where a C++ program
|> *requires* casting that a corresponding Eiffel program avoids
|> by some mechanism *other than* assignment attempt or covariance in
|> subclasses (which in a way are the same thing).

Too bad that you remove covariance from the argument. In my project, 
covariance is the perfect technique: 99.9% of the casts in my C++ code
would disapear in Eiffel.


|> Satish

Christian.


======================================================================= 34 ===
Date:    6 Sep 94 04:41:17 GMT
From:    dls@gwd.dsto.gov.au (David Silver)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

bunbury@vienna.eiffel.com (Richard Bunbury) writes:

>From Robert Martin <rmartin@rcmcon.com>:

>>Casts in C++ are [] almost always unecessary and unwanted.  There are
>>times when dynamic_cast is useful, but this is more a test and less a
>>cast.  

>>If we ignore novices, Casts are most often used in C++ by people who
>>are used to programming in dynamically typed languages (like
>>Smalltalk).
>                [The place marked [] contained the word "not" but
>                I assume this is a typo.]

>Well, this is not what we hear from the field  - i.e. from disgruntled C++
>programmers, an ever fresh source of new Eiffel fans. Or from the
>literature either. Just today we received the September 1994 issue
>(volume 12, number 9) of "The C/C++ Users Journal"). And sure enough,
>the longest article in the issue is entitled "Code Capsules: Conversions
>and Casts", by Chuck Allison (perhaps a "Novice"?). Here is a quote from
>that article:

>-------- Begin quotation --------------------------------------
>  A cast is your way of telling the compiler to allow you to do something
>  potentially dangerous, because you think you know what you're doing. Too
>  often, though, you don't know what you're doing (no offense!), and you
>  spend days tracking down an insidious pointer conversion error or similar bu
g.

>In fact, the same article by Mr. Allison tells us that "C++ defines four
>new cast mechanisms". Now if casts are not needed, how come there are
>four more kinds?

Preferred methods of moving around a class hierarchy with pointers that
take into account the type info that gets carried around with objects
these days.  They just make it more explicit exactly why you are doing
a cast to the human reader, and also dynamic_cast<> casts from a base
class down to a derived class in a hierarchy involving virtual bases,
where the pointer value must be modified, and type info is required to
do this correctly.

>To repeat comments made in an earlier message: in Eiffel, you can
>do everything WITHOUT casts, in a type-safe manner. The key is a
>flexible enough type system.

>By the way, the lead article in the same issue of the C/C++ Users Journal
>is entitled "Using Windows Memory Management", by David Singleton.
>It comes with a program listing. Here are a few pretty typical lines
>from that listing:
>  FP_FHB current_block_pointer = (FP_FHB) p_fhb ;

Turning the default pointer type into a "far" (32-bit segment:offset)
pointer.  *NOT NEEDED*

>  _segment cur_seg = (_segment) SELECTOROF (this)

Probably not needed, depends what the SELECTOROF() macro returns and what
_segment really is.  Ideally it makes sense that a "selector" would be an
_segment.

>  (WORD) (this_block -> in_use_list) 

Interpreting something as an unsigned 16-bit integer.  Depends on the 
context but it is probably not needed.

>Looks like some casting is going on. But perhaps the author is a
>novice, or a freshly retrained Smalltalk programmer?

Looks like you were picking on the code of a confirmed "cast-a-holic".
The only other reason I can think of for these casts is that he was
making the conversions explicit to do away with annoying compiler 
warning messages.
I use C++ extensively, and the only times I use casts are where
I have a collection class or iterator that returns a const 
pointer/reference and I need a non-const one.  
Does Eiffel have const?

-- David





======================================================================= 35 ===
Date:    06 Sep 1994 09:38:14 GMT
From:    devernay@sophia.inria.fr (Frederic Devernay)
Subject: Re: Modula-3 for Solaris 2.3 alias SunOS 5.3

This is because the sparc compiler takes /usr/lib/libm.so instead of
its own libm.so, which contains sigfpe et al. BUT WHY THE HELL DIDN'T
THEY INCLUDE THESE FUCTIONS IN /usr/lib/libm.so ?

The cure is to add a -L flag corresponding to where the sparccompiler
libraries are. I did a configuration file that allows dynamic
libraries among other things for Solaris 2.3. I still have the old
sparccompiler (2.0.1), though, so that you may have to modify some of
the configuration parameters (especially the -z2 option). The
pkg/m3build/templates/SOLsun file is included after this message.

Fred

---8<---snip-snip----
% Copyright (C) 1989, 1992 Digital Equipment Corporation 
% All rights reserved.
% See the file COPYRIGHT for a full description.
% 
% Last Modified On Thu Jun  2 11:21:38 PDT 1994 By kalsow  
% 
% Standard configuration file for SOLsun (Solaris 2.x w/Sun C)
%

%-------------------------------------------------- compilation environment ---

readonly TARGET = "SOLsun"
readonly DEFAULT_BUILD_DIR = TARGET

include ("PLATFORMS")  % get the target-dependent mappings
include (OS_TYPE)      % get the OS-dependent functions

readonly NAMING_CONVENTIONS = "0"
%                                        object files       libraries
%  0=Unix                          =>  .o   .io    .mo       libXX.a
%  1=Unix with a grumpy C compiler =>  .o   _i.o   _m.o      libXX.a
%  2=Windows/NT                    =>  .obj _i.obj _m.obj    XX.lib
%

%------------------------------------------------------------- export paths ---
% During the installation, destination directories that do not exist
% will be created.  You need the necessary permissions to do so; otherwise,
% the installation will fail, but can be restarted after you have 
% fixed the permissions.

BIN_INSTALL   = "/u/corse/0/devernay/modula3/bin"         % executables
LIB_INSTALL   = "/u/corse/0/devernay/modula3/" & TARGET   % libraries
DOC_INSTALL   = "/u/corse/0/devernay/modula3/doc"         % documents
PKG_INSTALL   = "/u/corse/0/devernay/modula3/pkg"         % packages
EMACS_INSTALL = "/u/corse/0/devernay/modula3/elisp"       % emacs lisp code
MAN_INSTALL   = "/u/corse/0/devernay/modula3/man"         % man pages
HTML_INSTALL  = "/u/corse/0/devernay/modula3/www"         % public hypertext

% The manual pages normally go in subdirectories man{1,...8} of
% the MAN_INSTALL directory.  If you prefer to have them all in
% a single section, define MAN_SECTION to be that section's name.
% MAN_SECTION = "l"

% On some systems (e.g. AFS) you must install public files in a different
% place from where you use them.  If that is the case for your system,
% specify the "use" location here, otherwise leave them alone.
BIN_USE   = BIN_INSTALL
LIB_USE   = LIB_INSTALL
PKG_USE   = PKG_INSTALL

readonly INSTALL_IMPLS = "TRUE"
% "TRUE"
%    => save all source files during the install
%    => makes debugging easier and browsing more fruitful
% "" (i.e. FALSE)
%    => save only the exported interfaces and templates 
%    => makes the installed system slightly smaller.

readonly NEED_OBJECTS = "TRUE"
% "TRUE"
%    => accumulate a list of derived objects in COMPILE_OBJECTS
%    => for building shared libraries in the library_hooks function below
% ""
%    => don't bother

%---------------------------------------------------------------------- X11 ---
% If you have X11R4 installed and would like the X11R4 binding interfaces
% to be built, define the procedure "import_X11R4" to import the libraries
% that are needed.  Otherwise, define "import_X11R4" to be an empty procedure.
%
% If you use the MIT server with DECnet support, you need X11 and dnet,
% otherwise X11 should be enough.
% 
% Since X11R5 is an extension of X11R4, you can use the X11R5 libraries
% instead of X11R4.  However, the Modula-3 binding interfaces have not
% yet been upgraded to X11R5.
%

readonly proc import_X11R4() is
  import_lib("Xaw", "/usr/openwin/lib")
  import_lib("Xmu", "/usr/openwin/lib")
  import_lib("Xext", "/usr/openwin/lib")
  import_lib("Xt", "/usr/openwin/lib")
  import_lib("X11", "/usr/openwin/lib")
end

%---------------------------------------------------------------------- TeX ---
% If you have TeX, define "DVIPS" to convert DVI files to PostScript (or
% whatever your printer accepts).  Otherwise, define "DVIPS" to be an
% empty procedure
%
% If you have TeX, the implementation notes can be recompiled at your
% site with whatever local modifications you make.
%

readonly proc DVIPS(f) is
  exec("dvips", f & ".dvi >", f & ".ps")
end

%-------------------------------------------------------------------- emacs ---
% If you have emacs and want to compile ".el" files to ".elc" files,
% fill in the function below.  Otherwise, define it to be a no-op.

readonly proc emacs_compile (el) is
  exec ("emacs -batch -f batch-byte-compile", el)
end

%-------------------------------------------------------- Modula-3 compiler ---
% The syntax for the values passed to most of the M3_CONFIG options is
% "@pgm@arg1@...@argn@" where "@" is an arbitrary character.  The
% separator character must begin and end the value.

% Where is the driver?
M3 = LIB_USE & "/m3"

% What are the standard flags?
M3OPTIONS = [ "-w1", "-why", "-g" ]

M3_CONFIG = [
   "-Y0@" & LIB_USE & "/m3c@-t" & TARGET & "@",
   % --- the Modula-3 to IL compiler

   "-Y1@/usr/ucb/cc@-pic@",
   % --- the C compiler, with options to compile Modula-3 code

   "-Y2@/usr/ucb/cc@-R/usr/ucblib:/usr/openwin/lib:" & LIB_USE & "@",
   % --- the C compiler, with options to link Modula-3 code

   "-Y3@/usr/ccs/bin/ar@cr@",
   % --- program to build library archives

   "-Y4@/bin/touch@",
   % --- program to create the table of contents in archives

   "-Y6@" & LIB_USE & "/m3cgc1@-quiet@-fpic@",
   % --- the Modula-3 IL to assembly language pass

   "-Y7@/usr/ccs/bin/as@-s@-K@PIC@",
   % --- the assembler

   "-z2@-L/opt/SUNWspro/SC2.0.1@-lm@",  % --- libraries systematically linked w
ith all programs

   "-z3" & LIB_USE & SL & "report_coverage.o",
   % --- library linked in programs compiled with "-Z" coverage option

   "-z5" & NAMING_CONVENTIONS,
   % Set the local naming conventions.

   "-z60",
   % Set the value of "-z6" to "0" if you want the m3 driver to split
   % library names and pass -L/-l arguments to the linker; otherwise ("-z61"),
   % the m3 driver will pass libraries with full path names.

   "-zA0",
   % The "-zA" option specifies the maximum size (in megabytes) that Pass0
   % is allowed to reach as a persistent server before the driver kills it.
   % Setting it to zero disables server mode.
   % NOTE: the current compiler is buggy, leave "-zA" alone!

   "-zB@-O@",  % --- pass 1 options implied by "-O"
   "-zC@-O@",  % --- pass 6 options implied by "-O"
   "-zD@@",    % --- pass 7 options implied by "-O"

   "-zE@-g@",  % --- pass 1 options implied by "-g"
   "-zF@-g@",  % --- pass 6 options implied by "-g"
   "-zG@@"     % --- pass 7 options implied by "-g"
]

proc build_standalone() is
   % --- reset the linker to avoid shared libraries.
   M3_CONFIG += "-Y2@/usr/ucb/cc@"
   M3_CONFIG += "-Y6@" & LIB_USE & "/m3cgc1@-quiet@"
   M3_CONFIG += "-Y7@/usr/ccs/bin/as@-s@"
   M3_CONFIG += "-z61"
end

proc build_shared() is
   % --- reset the linker to use shared libraries.
end

%-------------------------------------------------------------------- hooks ---
% These are the "last chance" hooks that are called each time a library
% or program is built.  They might build shared libraries or strip
% executables...

proc library_hooks(x) is
  local lib_a  = format ("lib%s.a", x)
  local lib_so = format ("lib%s.so", x) % version number is optional
  if defined ("_all")
    if stale (lib_a, lib_a)
      write ("missing ", lib_a, ": not building ", lib_so, CR)
    else
      if stale (lib_so, lib_a)
        exec ("/usr/ucb/ld -dy -G -z text -o", lib_so, COMPILE_OBJECTS)
      end
      %% _install_file (lib_so, LIB_INSTALL, "0644", "T")
      install_derived (lib_so)
    end
  end
  deriveds (lib_so, no_extension)
end

proc program_hooks(x) is
end

%---------------------------------------------------------------- bootstrap ---
% These functions are used during the bootstrap process
%

if defined("_bootstrap")
  BOOT_CC   = "/usr/ucb/cc"
  BOOT_ASM  = "/usr/ccs/bin/as"
  BOOT_AR   = "/usr/ccs/bin/ar cru"
  BOOT_RAN  = "touch"
  BOOT_LINK = "/usr/ucb/cc"
  include("COMMON.BOOT")
end

%------------------------------------------------------------- installation ---
% "install_file" is called during an "m3build install" for
% each file that neededs to be externally exported.

readonly proc install_file (src, dest, mode) is
  % exec ("install -c -m", mode, src, dest)
  exec ("cp -p", src, dest)
end

%---------------------------------------------- the rest of the environment ---

include ("COMMON")

--
       *          Frederic.Devernay@sophia.inria.fr          *
       * Projet ROBOTVIS -- INRIA Sophia Antipolis -- FRANCE *


======================================================================= 36 ===
Date:    06 Sep 1994 08:59:20 GMT
From:    baechler@lia.di.epfl.ch (Emmanuel Baechler)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?


There is another aspect of this question which hasn't been discussed yet: the e
ffect
on modelization.

Most of the object systems, either with compile-time or run-time
checks, create objects which are static in their properties throughout
their all life. They will have the same (according to the lisp
vocabulary) instance variables, methods ancestors and so on. Some
systems, like CLOS, enable some runtime modification of part these
properties. Most, especially the ones with static typing, don't. 

Now, if you consider the modelling of the real world, there are however 
many cases where this where this limitation is real troublesome. Consider
the very simple (and really not new) example of the modellization of people
status throughout their whole life:

A youg child has a name, a first name a birthdate and can do a few things.

When (s)he starts school, he may student a student number, go to a given
school, and follow several given courses teached by given professors. He may
take exams, get promoted and so on.

When (s)he starts the university he will probably lose its previous student
number and get a new one, attend a given faculty, have the choice between many
options and so on. Of course if (s)he doesn't go to thje university, he'll
follow a totally different path with totally different properties and actions.

And this will continue for his (her) whole life.

Some of these changes will superpose with other properties (for example,
being both a doctor and having a Phd), while other will cancel previously
valid propreties (for example leaving the universtiy after graduating and
get a job).

I have difficulties to see how an object system, either statically or
dynamically typed can model this in a quite natural and managable way.

Of course there are kludges. On can for example, create instances
containing all the possible porperties right at the start, but
checking that only the relevant ones (at a given time) are used will
be problematic. Such instances will probably be huge while they'll
contain much less information at a given time.

I can also imagine specialized functions for each possible transition
creating a new instance of the appropriate class, transfering the
relevant information and destroying the previous one. I fear however
that the number of these functions will be so high that the system will
soon become unmanagable. It's however true that a meta-object protocol,
as the one of CLOS, may help a lot in this domain.

The most natural tool that I can imagine is a frame system, which is even
more dynamic than dynamically type object systems. I am however not sure
that this is the only (and even the best) solution.

Any other idea, comment?
--
Emmanuel Baechler.                        | Tel.: ++41-21-314-29-06
Etat de Vaud                              | Fax:  ++41-21-314-45-55
Service des Hospices Cantonaux            | e-mail: baechler@lia.di.epfl.ch
Office Informatique                       |     or: baechler@liasun6.epfl.ch
Les Allieres                              | Standard Disclaimer
CH-1011 Lausanne	Switzerland

Political correctness = the replacement of historical biasses in the language 
                        by new ones that are more suitable for the speaker's
                        purposes
Gun control laws don't die, people do.
Ban the bomb. Save the world for conventional warfare.



======================================================================= 37 ===
Date:    Tue, 6 Sep 1994 07:31:28 GMT
From:    skj@oasis.icl.co.uk (Simon Johnston)
Subject: Re: DEC's Modula 3

atverm@ecp541.ecn.nl wrote:
: In  <778611866.AA07139@dialis.hacktic.nl>  geert@dialis.hacktic.nl (Geert Bos
ch) writes:
: | I just ftp-ed Modula-3 from gatekeeper.dec.com and I am wondering if anybod
y
: | has tips about setting it up. My ultimate wish would be to compile Modula-3
: | from within an OS/2 environment. Does anybody have experience in doing this
?
: |  
: I wish you good luck, you'd be the first to succeed. If you're serious
: I advise you to use the EMX 0.8h GCC environment to compile the beast.
: You'll need a fair amount of Unix and C knowledge. I gather you've
: taken the Linux port as a starting point? 
: I once had the same plans as you, but I really don't have the time to
: do it. I remember reading some message of another brave person about
: two months ago who reported he got quake to work and he posted the

I am that 'brave' person, I got quake working, and produced some OS2 template
files which appear to work with the EMX 0.8hpl9 environment. The main problem 
with this was that the OS2 command line cannot take all those file names on
the link/lib command name. The answer was to produce a response file for the
librarian and pass it on the command line, for the link phase produce a lib
first and then link the lib.

: diffs needed for it. I didn't hear from it any more. If you make progress,
: I am very much interested and would like to be kept informed, and I'm sure

I have had to stop work on this as my *real* work demanded the time and disk
space I was using. If I get back to it I will of course let the group know.

: much others are because there have been quite some requests for an OS/2
: port in the recent year!

Thanks for remembering the post, noone else seemed to have noticed the post
go by, I thought I was all alone out here!

MODULE Sig;
FROM ICL IMPORT StdDisclaimer;
FROM Interests IMPORT Modula2, Modula3, Linux, OS2;

BEGIN
(* ------------------------------------------------------------------------.
|Simon K. Johnston - Development Engineer              |ICL Retail Systems |
|------------------------------------------------------|3/4 Willoughby Road|
|Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk      |Bracknell, Berks   |
|Telephone : +44 (0)344 476320   Fax: +44 (0)344 476084|United Kingdom     |
|Internal  : 7261 6320    OP Mail: S.K.Johnston@BRA0801|RG12 8TJ           |
`------------------------------------------------------------------------ *)
END Sig.


======================================================================= 38 ===
Date:    6 Sep 1994 07:40:01 GMT
From:    mbk@inls1.ucsd.edu (Matt Kennel)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

Richard Bunbury (bunbury@vienna.eiffel.com) wrote:
: 	- (A) Proponents of Smalltalk and other dynamically typed languages
: 	  claim that static typing is too constraining.
: 	- (B) Smalltalk does not (in general) support multiple inheritance.
: 	- (C) It is indeed true that without multiple inheritance static
: 	  typing would be unacceptably constraining (claim A).
: 	- (D) But examination of the typical examples used to support claim
: 	  A show, in our opinion, that the unacceptable restrictions are due
: 	  to the absence of multiple inheritance, and that with MI static
: 	  typing is in fact not a limitation.

Where does this leave Modula-3?

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".


======================================================================= 39 ===
Date:    6 Sep 1994 10:50:47 GMT
From:    hanssgen@iraul1.ira.uka.de (Stefan Haenssgen)
Subject: Q: Modula-3 / GCC Backend for KSR-1?


Hello world,

I'm looking for an implementation of Modula-3 for the KSR-1 parallel
computer.
Since Modula-3 directly uses the GNU cc's backend, a gcc backend
description for the KSR-1 would be equally helpful.

Modula-3's threads should map well to the KSR's thread library, and
since Modula-3 is freely available, a version for the KSR-1 would
make an excellent parallel program / compiler experimentation
environment (which is exactly what I'm planning to do ;-)

Please send all replies by Email to haenssgen@ira.uka.de - I'll
post a summary if there is enough interest.

Thanks a lot in advance

        Stefan


PS:  I want to use the latest version of Modula-3, so taking version 2.x
     and compiling the resulting C code on the KSR is just a last resort.
PPS: Followup to comp.lang.modula3

-- 
      ,-----,------,--,--,   Stefan Haenssgen, Comp Sci, Uni Karlsruhe, Germany
     /     /      /  /  /   Email: haenssgen@ira.uka.de  or haenssgen@acm.org
    /  ---/-,  ,-/  /  /   IRC: sth   Phone: +49/721/593910   Fax: hoo nose
   /     / /  / /     /   Snail: Nuitsstr. 2c, D-76185 Karlsruhe, Germany
  /---  / /  / /  /  /   <I collect postcards from all over the world *hint* :>
 /     / /  / /  /  /   "Use the SOURCE, Luke!" (Return of the RedEye Nights)
'-----' '--' '--'--'   "I feel a great disturbance in the SOURCE"


======================================================================= 40 ===
Date:    Mon, 5 Sep 1994 23:10:08 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

"William D. Gooch" <goochb@swim5.eng.sematech.org> writes:

>On Thu, 1 Sep 1994, Ian Joyner wrote:

>> And it is good
>> programmers that know their own thought processes that admit we need
>> this kind of mechanical aid. 

>So your assertion is that in order to be a "good programmer" one is 
>required to "admit that we need this ... aid."   I think not.

Actually, I find that the best programmers know they need help, and
look for any they can get.  When discussing one's skills at
programming, the best tack is humility.  


-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 41 ===
Date:    Tue, 6 Sep 1994 13:33:10 GMT
From:    grp@dmu.ac.uk (Graham Perkins)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

In article <34ac8g$rlc@library.erc.clarkson.edu> satish@sun.mcs.clarkson.edu (S
atish Thatte) writes:
>
>Richard, perhaps you can post some examples where a C++ program
>*requires* casting that a corresponding Eiffel program avoids
>by some mechanism *other than* assignment attempt or covariance in
>subclasses (which in a way are the same thing).
>
>I am not saying such examples don't exist, but having heard this
>argument going on for a long time, I still haven't seen any examples
>that pinpoint the superiority of Eiffel typing over C++ in a way that
>is not subsumed by RTTI features in forthcoming versions of C++.
>
class LIST[T]
feature
head : T
tail : like Current
put( x:T ) is
  do tail := clone( Current )
     head := x
  end
empty : BOOLEAN is
  do Result := void( tail )
  end
end


class ORDERED_LIST[ T->COMPARABLE ]
inherit LIST[T] rename put as cons
                end
        LIST[T] redefine put
                end
feature

put( x:T ) is
  do if empty then cons( x )
     elsif x < head 
           then cons( x )
           else tail.put( x )
     end
  end
end

Here, the use of type anchoring allows me to define a recursive
data type (list = head:T plus tail:like Current) which I can
also derive more recursive data types from.  You try writing
the above scheme in C++ without using any casts.  I'll let
you off with a non-generic solution, since using templates
AND inheritance in the same C++ data structure leads to a
horrible, unreadable mess.




======================================================================= 42 ===
Date:    Tue, 6 Sep 1994 01:18:30 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

bunbury@vienna.eiffel.com (Richard Bunbury) writes:

>From Robert Martin <rmartin@rcmcon.com>:

>>Casts in C++ are [] almost always unecessary and unwanted.  There are
>>times when dynamic_cast is useful, but this is more a test and less a
>>cast.  

>>If we ignore novices, Casts are most often used in C++ by people who
>>are used to programming in dynamically typed languages (like
>>Smalltalk).
>                [The place marked [] contained the word "not" but
>                I assume this is a typo.]

That is correct.

>Well, this is not what we hear from the field  - i.e. from disgruntled C++
>programmers, an ever fresh source of new Eiffel fans. 

That some people are disgruntled with C++ does not surprise me.  It
will surprise me, however, if a large portion of them do not become
disgruntled over Eiffel as well.  This has nothing to do with the
quality of either language.  Any C++ programmer becomming disgruntled
about casts did not take the time to learn the language as well as he
should.  And so, will likely not take the time to learn Eiffel as well
as necessary...  This is just my opinion.

>Or from the
>literature either. Just today we received the September 1994 issue
>(volume 12, number 9) of "The C/C++ Users Journal"). And sure enough,
>the longest article in the issue is entitled "Code Capsules: Conversions
>and Casts", by Chuck Allison (perhaps a "Novice"?). Here is a quote from
>that article:

I know not whether Chuck Allison is a novice.

>-------- Begin quotation --------------------------------------
>  A cast is your way of telling the compiler to allow you to do something
>  potentially dangerous, because you think you know what you're doing. Too
>  often, though, you don't know what you're doing (no offense!), and you
>  spend days tracking down an insidious pointer conversion error or
similar bug.

Translation:  don't use casts.  It seems Chuck is not a novice.

>  It's interesting that programmers
>  use a single cast notation for so many different purposes:

>  + to reinterpret the bit pattern of an object
>  + to widen or narrow a value
>  + to traverse a class hierarchy
>  + to cast-away `const' or `volatile'
>  + to do some implementation-dependent magic
>-------- End quotation --------------------------------------

Does he quote figures here?  How many C++ programmers are actually
using these techniques?

I'll tell you that I think it is quite a few, and I believe that they
are novices.   It seems very unlikely to me that a seasoned C++
programmer would make rampant use of casts.  

>Frankly, to an Eiffel programmer, this all sounds pretty repulsive. 

I assume you meant to say: "To this Eiffel programmer".  Lets not cast
people into molds based upon the computer languages they use.  The
rule about casts applies in human relations as well as in C++.

>In
>particular we do not think that object-oriented software construction
>should be about "magic".

Nor do I.  Nor do a great many of the C++ programmers that I deal with
regularily.  In fact, I know of no programmer who thinks that sofware
should be about magic.  So, this is not an exclusive virtue of "the
Eiffel programmer."

>But even if you find nothing wrong with this, the scope of things for
>which the author cites a need to use casts in C++ seems rather broad,
>supporting the obvious observation of my earlier message that practical C++
>programming requires casting.

No.  As I read your quote (I did not read the article) the author was
saying that casts were "used" for these things.  Not that they must
be, or should be.  In fact, they needn't and shouldn't be.

>In fact, the same article by Mr. Allison tells us that "C++ defines four
>new cast mechanisms". Now if casts are not needed, how come there are
>four more kinds?

The four new kinds are to be used instead of the old more general
kind.  Specifically they are: "dynamic_cast" which is equivalent to
"?=" in Eiffel. (so if you call this a cast, then Eiffel has a cast
too!). "const_cast" which may only change the 'const' attribute of a
type.  "static_cast" which is used to make "legal" type changes such
as int -> long, and 'reinterpret_cast' which is like the old very
general C cast.

Of these 4, dynamic_cast and static_cast are completely type safe.
Invalid conversions cannot be made.  I do not recommend that the
others be used in most cases.

These new casts were added so that the kinds of casts which are 'safe'
could be seperated from those that weren't.  i.e. you can use a
static_cast as follows:

		double half = 1/static_cast<double>(2);

So.  These are not 4 new kinds of casts.  They are 4 divisions of the
old kind of cast.  At least one division of which is present in Eiffel.

>To repeat comments made in an earlier message: in Eiffel, you can
>do everything WITHOUT casts, in a type-safe manner. The key is a
>flexible enough type system.

And to repeat my own statement.  You can do everything in C++ without
casts.  Casts should be avoided.  It is only relatively inexperienced
C++ programmers who rely on them with any regularity.

>By the way, the lead article in the same issue of the C/C++ Users Journal
>is entitled "Using Windows Memory Management", by David Singleton.
>It comes with a program listing. Here are a few pretty typical lines
>from that listing:

>  FP_FHB current_block_pointer = (FP_FHB) p_fhb ;
>  ...
>  _segment cur_seg = (_segment) SELECTOROF (this)
>  ...
>  (WORD) (this_block -> in_use_list) 

>Looks like some casting is going on. But perhaps the author is a
>novice, or a freshly retrained Smalltalk programmer?

First of all, this looks like C code, and we were dicsussing C++.
Casts are much more prevalent in C than in C++ because C is not a
strongly typed language.  Thus casts are performed to convert types.
(generally to make sure that they fit in the right size integer) In
fact, many C programmers get into the habbit of using casts, even when
they aren't necessary.  I have even seen C coding standards that
dictate that "all function arguments and return types will be cast".
I have always thought this practice to be very silly.

Some old C programmers carry this practice into C++ when they first
start using it.  However, they should stop using the casts before
long.  C++ is strongly typed, and the casts are not necessary.

Now, let me quote Stroustrup from "The design and evolution of C++":

"I consider most casts in C++ progarms signs of poor design.  Some
casts are essential, but most aren't" -- pg 170







-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 43 ===
Date:    Tue, 6 Sep 1994 13:59:07 GMT
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: DEC's Modula 3


   I would be interested in porting "the beast" to SVR4/386 and FreeBSD/NetBSD.
   When I take the Linux port as a starting point, what is necessary
   to port? I've looked at the various files in BOOT-Linux.tar and found
   lots of assembler code. What is necessary to do the port?
   BTW, in which way vary gcc and m3gcc?

The assembly code is simply the Modula-3 compiler code cross-compiled 
from another platform. You first need to setup the compiler on one of
the existing platforms (LINUX, SPARC, DEC, HPPA...). Then you have to
modify the source files in order to get it working for your new platform.
This includes setting up gcc as a cross-compiler for the new platform,
adapting the OS interface for a different UNIX flavor and finally the
small system dependent portion of the run time library.
--

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029



======================================================================= 44 ===
Date:    06 Sep 1994 23:00:56 GMT
From:    tmb@arolla.idiap.ch (Thomas M. Breuel)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

In article <1994Sep6.133310.16406@dmu.ac.uk> grp@dmu.ac.uk (Graham Perkins) wri
tes:
|class LIST[T]
|feature
|head : T
|tail : like Current
|put( x:T ) is
|  do tail := clone( Current )
|     head := x
|  end
|empty : BOOLEAN is
|  do Result := void( tail )
|  end
|end
|
|
|class ORDERED_LIST[ T->COMPARABLE ]
|inherit LIST[T] rename put as cons
|                end
|        LIST[T] redefine put
|                end
|feature
|
|put( x:T ) is
|  do if empty then cons( x )
|     elsif x < head 
|           then cons( x )
|           else tail.put( x )
|     end
|  end
|end
|
|Here, the use of type anchoring allows me to define a recursive
|data type (list = head:T plus tail:like Current) which I can
|also derive more recursive data types from.  You try writing
|the above scheme in C++ without using any casts.  I'll let
|you off with a non-generic solution, since using templates
|AND inheritance in the same C++ data structure leads to a
|horrible, unreadable mess.

This code seems to have several serious problems.  In terms of
semantics, we have two major problems.  First, it treats ORDERED_LIST
as a kind of LIST, but ORDERED_LIST is _not_ a kind of list, in the
sense that it is often incorrect to substitute an ORDERED_LIST for a
LIST.  Second, it associates the type of list with each cons cell,
while being ordered is a property of the whole list.

In terms of performance, we also have several important problems.
First, the list contains a hidden variable of type T.  If T is
associated with scarce resources (memory, file descriptors, etc.),
this may be a problem.  Second, each cons cell contains a pointer to a
virtual function table, which wastes space (in the worst case, 50% per
list element), and, as we saw above, this space isn't even put to good
use.  Third, the use of "clone" and "like" seems to essentially
preclude a non-pointer implementation of type LIST.

In any case, the crucial point you seem to be driving at is that it
may be difficult to express the notion of "like Current" in C++
without casts.  Well, a typesafe C++ solution without casts is given
below; for the purposes of illustration, it lets OrderedList inherit
from List, even though I think that that's actually wrong for these
specific datatypes.  It also assumes a C++ implementation with garbage
collection.

The C++ version is longer than the Eiffel version for several
reasons.

First, the C++ implementation is considerably better, in that it
doesn't allocate memory for an empty list, carries around no hidden
variable of type T, and doesn't have any additional overhead
associated with the individual cons cells due to method tables.  No
doubt, some of these improvements could also be incoporated into the
Eiffel version.

Second, C++ forces you to be more explicit about what "like Current"
means; in this case, it means that List and OrderedList have a common
underlying representation, which is interchangeable.  That fact is
expressed through the introduction of the common Cons class for the
representation and the two additional construction/assignment
operations in class OrderedList.  Neverhteless, inheritance is used in
exactly the same way as in the Eiffel version: all operations on List
are inherited by OrderedList.

Third, C++ requires the programmer to be more explicit about what
assignment and construction means, and that leads to some additional
code.

				Thomas.

template <class T>
struct Cons {
    T head;
    Cons *tail;
    Cons(T head,Cons *tail):head(head),tail(tail) {}
};

template <class T>
struct List {
    Cons<T> *data;
    
    List():data(0) {}
    List(Cons<T> *data):data(data) {}

    void insert(T x) {data = new Cons<T>(x,data);}
    bool empty() {return data==0;}
    T head() {assert(data); return data->head;}
    List tail() {assert(data); return List(data->tail);}
};

template <class T>
struct OrderedList:List<T> {
    OrderedList() {}
    OrderedList(Cons<T> *data):List<T>(data) {}
    OrderedList &operator=(OrderedList<T> &list) {data = list.data; return *thi
s;}

    OrderedList(List<T> list):List<T>(list.data) {}
    OrderedList &operator=(List<T> &list) {data = list.data; return *this;}

    void insert(T x) {
	if(!data || data->head >= x) {
	    data = new Cons<T>(x,data);
	    return;
	} 
	Cons<T> *p = data;
	while(p->tail) {
	    if(p->tail->head >= x) {
		p->tail = new Cons<T>(x,p->tail);
		return;
	    }
	    p = p->tail;
	}
	p->tail = new Cons<T>(x,p->tail);
    }
};



======================================================================= 45 ===
Date:    6 Sep 1994 21:25:35 GMT
From:    madon@didec22.epfl.ch (Dominik Madon)
Subject: Re: Success - 3.3 on NeXT

Thomas Neumann (tom@smart.bo.open.de) wrote:

: I've just succeeded in bootstrapping release-3.3 on a NeXT/m68k
: running NeXTSTEP 3.2.

Great !

: To the SRC folks: Are you interested in my modifications ?
: Maybe it would be a good idea to upload a pre-compiled, ready to
: execute NeXT version somewhere ?

Good idea.

Is it difficult to compile an intel version ? I have NS/I 3.2.


Dominik


======================================================================= 46 ===
Date:    Tue, 6 Sep 1994 21:52:08 GMT
From:    haensgen@i43fs1.ira.uka.de (Stefan Haenssgen)
Subject: Q: Modula-3 / GCC Backend for KSR-1?


Hello world,

I'm looking for an implementation of Modula-3 for the KSR-1 parallel
computer.
Since Modula-3 directly uses the GNU cc's backend, a gcc backend
description for the KSR-1 would be equally helpful.

Modula-3's threads should map well to the KSR's thread library, and
since Modula-3 is freely available, a version for the KSR-1 would
make an excellent parallel program / compiler experimentation
environment (which is exactly what I'm planning to do ;-)

Please send all replies by Email to haenssgen@ira.uka.de - I'll
post a summary if there is enough interest.

Thanks a lot in advance

        Stefan


PS:  I want to use the latest version of Modula-3, so taking version 2.x
     and compiling the resulting C code on the KSR is just a last resort.
PPS: Followup to comp.lang.modula3
-- 
Stefan U. Haenssgen, IPD, Fakultaet fuer Informatik, Email: haenssgen@ira.uka.d
e
Universitaet Karlsruhe, Postfach 6980                Phone: +49/721/608-3972
D-76128 Karlsruhe, Germany                           Fax:   +49/721/694092



======================================================================= 47 ===
Date:    7 Sep 1994 10:01:02 GMT
From:    vogler@rzddec1.informatik.uni-hamburg.de (Jens Vogler)
Subject: Re: DEC's Modula 3

Robert Schien wrote:

[ ... ]
>I would be interested in porting "the beast" to SVR4/386 and FreeBSD/NetBSD.
>When I take the Linux port as a starting point, what is necessary
>to port? I've looked at the various files in BOOT-Linux.tar and found
>lots of assembler code. What is necessary to do the port?
>BTW, in which way vary gcc and m3gcc?

>Robert

One NetBSD port? Sounds interesting ;-) !!!
Please tell me more!

                   Yours etc.
               Jens "ABert" Vogler

P.S.: Sorry, I cannot help you. I just try to install NetBSD on my PC -- as you
can see, I cannot be an advanced coder.

--
 V   V  TTTTT   CCCC  Jens Vogler -- vogler@informatik.uni-hamburg.de
 V   V    T    C      Universitaet Hamburg (BR Deutschland)
  V V     T    C      VirusTestCenter
   V      T     CCCC  Amiga-Gruppe


======================================================================= 48 ===
Date:    Wed, 07 Sep 94 02:28:45 EST
From:    viper@cml.com
Subject: HELP!



     I am writing a report on careers in the programming field and would like
your help. If you could answer some or all of these questions it would be of
great help.

Thank you in advance.

1.   What kind of education do you need to get into the programming field?

2.   What are the languages to learn?

3.   Who are the companies to work for?

4.   What do you think are the coming things in programming?

5.   In what order do you think a person should learn the different
     languages?

6.   What is the best software in each language?

7.   Which school is the most respected in the Industry?

8.   In your opinion, what is the best way to get into the Industry?

9.   Do you still try to learn different languages, or learn more about the
     one that you use?

10.  Do you see a single language becoming the standard or do you see another
     language coming in to the field?


E-Mail viper@cml.com

 * SLMR 2.1a * It's not the money I want, it's the stuff!!

ComputerLink 'the easy way to bbs' (416) 233 - 7150 


======================================================================= 49 ===
Date:    7 Sep 1994 02:07:48 GMT
From:    cal@hk.super.net (Lindon Parker)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

Graham Perkins (grp@dmu.ac.uk) wrote:

[discussion deleted]
: >
: class LIST[T]
: feature
: head : T
: tail : like Current
: put( x:T ) is
:   do tail := clone( Current )
:      head := x
:   end
: empty : BOOLEAN is
:   do Result := void( tail )
:   end
: end


: class ORDERED_LIST[ T->COMPARABLE ]
: inherit LIST[T] rename put as cons
:                 end
:         LIST[T] redefine put
:                 end
: feature

: put( x:T ) is
:   do if empty then cons( x )
:      elsif x < head 
:            then cons( x )
:            else tail.put( x )
:      end
:   end
: end

: Here, the use of type anchoring allows me to define a recursive
: data type (list = head:T plus tail:like Current) which I can
: also derive more recursive data types from.  You try writing
: the above scheme in C++ without using any casts.  I'll let
: you off with a non-generic solution, since using templates
: AND inheritance in the same C++ data structure leads to a
: horrible, unreadable mess.

Gentlepersons,

All this is, I am sure, very interesting. But before responding further 
to this thread please note that in many peoples opinions it may now seem 
to be a discussion about C++, with some reference to Eiffel. Please also 
note the cross-posting going on. Its been a long time in this thread 
since I've seen Smalltalk, Objective-C or Modula-3 mentioned, thus I 
suggest you carefully consider deleting those news-groups you no longer 
consider relevant. I am sure those in c.l.smalltalk etc. can move to 
c.l.c++ to follow if they require....

regards,

Lindon Parker.



======================================================================= 50 ===
Date:    Wed, 7 Sep 1994 16:53:51 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

grp@dmu.ac.uk (Graham Perkins) writes:

>[...] since using templates
>AND inheritance in the same C++ data structure leads to a
>horrible, unreadable mess.

It does?

Graham.  Perhaps, for the benefit of those of us who do not read
Eiffel, you can post your example in C++ with casts, and then we can
try to remove the casts....  


-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 51 ===
Date:    Wed, 7 Sep 1994 17:02:47 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

>grp@dmu.ac.uk (Graham Perkins) writes:

 [presents a challenge, Translate this Eiffel code into C++ without Casts]

>|class LIST[T]

  [code elided]

tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

>Well, a typesafe C++ solution without casts is given
>below; 

  [code elided]

I think this particular bit of language war has illustrated the
salient principle of all language wars: 

       "The only valid critic of a language,
       is an expert in that language."

Corrollary:

       "If you don't code in it *alot*, then don't complain about it."



-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 52 ===
Date:    Wed, 7 Sep 1994 16:51:00 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

fabre@osf.org (Christian Fabre) writes:

>In article <34ac8g$rlc@library.erc.clarkson.edu>, 
>	satish@sun.mcs.clarkson.edu (Satish Thatte) writes:

>|> From bunbury@vienna.eiffel.com (Richard Bunbury):
>[deleted]

>|> Richard, perhaps you can post some examples where a C++ program
>|> *requires* casting that a corresponding Eiffel program avoids
>|> by some mechanism *other than* assignment attempt or covariance in
>|> subclasses (which in a way are the same thing).

>Too bad that you remove covariance from the argument. In my project, 
>covariance is the perfect technique: 99.9% of the casts in my C++ code
>would disapear in Eiffel.

But these cast ought to be dynamic_casts since, in C++, you are
downcasting a base argument to a specific derived class.    This
amounts to an assignment attempt (?=) in Eiffel.  Thus, 99.9% of the
casts in your C++ programs are using a structure that Eiffel admits as
necessary.  

However, this 99.9% must be a pretty small absolute number.  In my
experience with C++ the need for covariance (of argument types) is
pretty rare.  I use it specifically for comparison operators, and
probably nowhere else.


-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 53 ===
Date:    Wed, 7 Sep 1994 16:44:34 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

baechler@lia.di.epfl.ch (Emmanuel Baechler) writes:


>There is another aspect of this question which hasn't been discussed yet: the 
effect
>on modelization.

>Most of the object systems, either with compile-time or run-time
>checks, create objects which are static in their properties throughout
>their all life.

>Now, if you consider the modelling of the real world, there are however 
>many cases where this where this limitation is real troublesome. 

>A youg child has a name, a first name a birthdate and can do a few things.

>When (s)he starts school, he may student a student number, go to a given
>school, and follow several given courses teached by given professors. He may
>take exams, get promoted and so on.

>When (s)he starts the university he will probably lose its previous student
>number and get a new one, attend a given faculty, have the choice between many
>options and so on. Of course if (s)he doesn't go to thje university, he'll
>follow a totally different path with totally different properties and actions.

>And this will continue for his (her) whole life.

This is one of the difficulties intrinsic with the notion of "real
world modeling".  In fact, our models must be limited because we
cannot fully incorporate the real world into them.    We can "model
the real world", but only if we realize that those models, no matter
how complex they are, will always fail to capture the "real world" at
some level or another.

Now, the fact that objects change characteristics over their lifetime
is a common problem.  And there are dozens of ways to deal with it.
Many methodologies are based upon the notion of the "state" of an
object.  e.g. these methodologies model objects as presenting only
certain interfaces depending upon their current state.  

Other mechanisms try to capture the changing attributes into classes
which the primary class can contain.  e.g. A person class may contain
a student class.  There may be many derivatives of the student class,
one for each grade level.  The person class delegates certain of its
interfaces to its contained student class...

Yet all of these are weak models of the true real world.  There is,
after all, a significant mismatch between the cybernetic world, and
the real world.  The models within the computer must be quantized in
ways that are absurd in the real world.  So the models are always
inadequate in the general case.

-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 54 ===
Date:    Tue, 6 Sep 1994 13:09:43 GMT
From:    jcm@hgc.edu (James McKim)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

In article <34ac8g$rlc@library.erc.clarkson.edu> satish@sun.mcs.clarkson.edu (S
atish Thatte) writes:
>From bunbury@vienna.eiffel.com (Richard Bunbury):
>> From Robert Martin <rmartin@rcmcon.com>:
>> 
>>>If we ignore novices, Casts are most often used in C++ by people who
>>>are used to programming in dynamically typed languages (like
>>>Smalltalk).
>> 
>> Well, this is not what we hear from the field  - i.e. from disgruntled C++
>> programmers, an ever fresh source of new Eiffel fans.
>[extract from C/C++ Journal and comments by RB eleted]
>
>Richard, perhaps you can post some examples where a C++ program
>*requires* casting that a corresponding Eiffel program avoids
>by some mechanism *other than* assignment attempt or covariance in
>subclasses (which in a way are the same thing).

Hmmm... If we travel back in time a few years we might find the following
analagous request.

  "Please show me an example in language X that "requires" a "go to"
  which the corresponding code in language Y avoids by some mechanism
  other than an "if..then" or "while..do" (which in a way are the same
  thing).

People who use Eiffel are willing to trade off a certain amount of potentially
dangerous low level flexibility for safety and high level expressibility.

>
>I am not saying such examples don't exist, but having heard this
>argument going on for a long time, I still haven't seen any examples
>that pinpoint the superiority of Eiffel typing over C++ in a way that
>is not subsumed by RTTI features in forthcoming versions of C++.
>
>Satish


Regards,
-- Jim
-- 

*------------------------------------------------------------------------------
*
Jim McKim  (203)-548-2458     In exactly 3.2 seconds it will be a few 
Internet:  jcm@hgc.edu   minutes to 5:00.


======================================================================= 55 ===
Date:    Mon, 05 Sep 94 22:52:22 GMT
From:    michely@deliah.nemeter.dinoco.DE (Joachim Michely)
Subject: Re: Logitech M2 v4.0 Student Pak

In article <3499ib$iko@news.delphi.com> j_mcarthur@BIX.com writes:
>
>David Priest asks
>>  I can get Logitech's Modula-2 v4.0 student package.  Is it worth it?  I
>>currently use FST's Modula, and have had a great time with it: I think
>>I should be buying a package.  My choices seem to be FST and Logitech
>>(or, I suppose, move on to Modula-3)...
>> 
>>  So the question boils down to: is the Logitech student package ag
>>any good?  Bugs?  How's the development environment?  And does it 
>>have object extensions like FST does?
>
>I don't have any experience with the student package.  I have the "normal"
>package.  The Logitech 4.0 package is a very good development platform. 
>There are only two problems with it.  First it is not very flashy. 
>Personally I prefer this.  I run from the command line.  Second, and much
>more serious, the product is orphaned.

I think the Student edition is the "normal" edition maybe without the library
source ( you don't need them ).

>Symantech purchased Multiscope a while ago.  Symantech decreed that ALL
>development would be done in C++.  So this killed all support for the very
>good Modula 2 product.
>
>Actually the Logtech 4.0 package uses a slighly modified version of the
>Stonybrook compiler.  Stonybrook is still around.  So you can buy the
>compiler directly from them.  The newest release of the Stonybrook compiler
>is STILL in beta test (how long has it been?).

Logitech V4.0 has the Stonybrook compiler engine, but has a differnet set
of libraries. The libraries are Logitech conform, so that a Logitech 3.x 
user can switch to V4.0 without great pain.

>The only bugs I have found in the Logitech 4.0 package relate to LONGCARD. 
>I have found 4 separate bugs in the way the compiler handles arithmatic
>with LONGCARD.  LONGINT works, but LONGCARD is broken.

All bugs are now well defined and described ( also with workarounds ).
The Version 4.0 will be suported by : Terra Datentechnik, Zurich,
Switzerland and they fixed nearly all bugs ( LONGCARD too ).
They have a good team of developers and will support ( and bug fix ) the
compiler in the future.

You can also buy the Logitech Version 3.4 which is bug FREE ( from Terra ).

>The other option is Clarion's TopSpeed compiler.  Again it is not flashy. 
>It does have object oriented extensions.  There is a student version of the
>compiler that gets very good reviews (it is based on version 1.17 while the
>current release is 3.10).
>
>In my opinion, Modula-3 is not quite ready for "prime time".  I am spoiled.
> I got used to reasonably fast compiles and links with Modula-2.  Modula-3
>generates C code which then must be compiled and linked.  This is a VERY
>SLOW process.  So until someone has a native code Modula-3 I will not use
>it (I just don't have the time to wait around for the slow compiler and
>linker).
>
>The other option is to go to Oberon-2.  Oberon is the successor to
>Modula-2.  Oberon-2 is the sucessor to Oberon.  There are several very
>interresting packages available for Oberon.  One of the more interresting
>is the OM2 compiler.  It comes with a full Modula-2 and Oberon-2 compiler. 
>The compiler generates 32 bit code.  It looks very good.  Unfortunately you
>cannot link in forign modules.  I need the ability to link in forign
>modules (e.g. the Paradox Engine or CodeBase).  There is also the Window's
>based POW.  This looks very good also.
>----
>    Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur
>    a.k.a. Jeffrey McArthur          email: j_mcarthur@bix.com
>    phone: (301) 210-6655
>    fax:   (301) 210-4999
>    home:  (410) 290-6935
>
>The opinions express are mine.  They do not reflect the opinions
>of my employer.  My access to the Internet is not paid for by my
>employer.
>

--
Joachim Michely
Voice/Fax  : ++49 (0)2241 337938
Internet   : michely@nemeter.dinoco.DE
CompuServe : 100024,2476



======================================================================= 56 ===
Date:    8 Sep 1994 00:50:28 GMT
From:    vbidarko@classic4.cs.ttu.edu (Vinod Bidarkoppa)
Subject: QUESTIONNAIRE ON OOAD

NOTE :
This is for people who are involved directly or indirectly with
Object oriented software development. Please fill up the required information
and mail it to vbidarko@cs.ttu.edu.
Students and faculty are also welcome to reply.

Thanks in advance.

***************************************************************************




Questionnaire  on  requirements of  Object Oriented Analysis and Design Methodo
logy

INTRODUCTION

	This survey is to obtain information from the real world 
regarding the requirements of OOAD methodology. This is a part of 
masters thesis research in the Computer Science department at the 
Texas Tech University.
All the information will remain anonymous. The information from the
 questionnaires will be used to specify a set of practical requirements
 for an OOAD and also to evaluate the existing methodologies based on this.
	Completed questionnaires may be sent by post  or e-mail to:

	Vinod Bidarkoppa
	Department of Computer Science
	Texas Tech University
	Mail Stop 3104
	Lubbock, TX 79409

 E-mail : vbidarko@cs.ttu.edu
	  bed85@ttacs1.ttu.edu

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-----------------------

1. GENERAL INFORMATION

1.1	Organization 
	
	a) Name  :	
	b) Address :
	c) City :
	d) State :
	
1.2	Area(s) of Company business   ( Mention areas which use OO  )

	

	
1.3 	Personal Information
	a) Name :
	b) Your role in the organization :

1.4 	OO Methodologies used at present  in your organization
	 ( e.g. Booch, Coad and Yourdon, Shlaer and Mellor,OMT, Wirfs-Brock) an
d
 	in which projects / applications.
 	e.g.  G. Booch (1994 ed.)	Realtime Process Control

	
	
	
2.	METHODOLOGY REQUIREMENTS
	( Please rate  one of the categories from A to E.
	 ( A= Extremely Important,  B= Important, C= Not so important,
	  D= Unimportant, E= No comment)

2.1	Structural Concepts
2.1.1	Degree of  OO support
	1. The methodology should support the usual
	meaning of the terms object (instance) and class.	( )
 	
	2. The class should be described in terms
	of its distinct parts: an interface and body.		( )	
		
		
	3. Encapsulation and information hiding
	should be supported by the methodology			( )	
		
	4. The methodology should support metaclasses		( )

2.1.2	Relationships

	1. The methodology should support  :
	i) Single inheritance					( )	
	ii) Multiple inheritance				( )
	iii) Aggregation (container )				( )
	iv) Associative						( )
	v) The associative relationships should include cardinalities	( )

	2. The methodology should include / distinguish
	subclassing ( inheritance implementation with 
	redefinition and / or restriction as well as addition ) 
	and subtyping ( just addition).				( )

2.2 	Behavioral Concepts

2.2.1	Instances

	1. The methodology should provide facility for 
	dynamically creating and destroying objects.		( )

	2. The methodology should support
	i) Notion of object state.				( )
	ii) Export Control / Visibility  e.g. Private, Protected, Public
	( )	
	iii) Persistent Objects					( )	
	iv) Concurrent objects					( )
	v) Embedded Objects					( )	
	vi) Active ( instances executing in parallel) and passive
	(executing in serial with others) instances		( )	

2.2.2	Messages or events

	1. The methodology should facilitate message passing that involve :
	i) Static Binding					( )	
	ii) Dynamic Binding					( )	

	2. The methodology should support  the following kinds of polymorphism 
:
	i) Inclusion						( )	
	ii) Operational						( )	
	iii) Parametric						( )	

	3. The methodology should include the following modes of communication 
	i) Synchronous						( )	
	ii) Asynchronous					( )
	
	note : Synchronous is where the sender suspends execution till the 
	receiver processes the message and asynchronous is where the sender
	 continues processing.


2.3	Process
	1. The methodology should prescribe steps / guidelines for identifying 
:
	i) Semantic (Abstract) classes				( )	
	ii) Attributes 						( )	
	iii) Methods						( )	
	iv) Allocating attributes and methods to classes	( )	

	2. The methodology should specify guidelines for identifying the  
	following relationships :
	i) Generalization					( )	
	ii) Aggregation						( )
	iii) Association					( )
	iv) Cardinalities					( )

	3). The methodology should be able to specify dynamic behaviors 
	through the following :
	i) Message connection					( )
	ii) Instance connection					( )
	iii) Object interaction diagrams			( )
	iv) State machine					( )
	v) Event and state generalization			( )	
	vi) Interactions within the state			( )
	vii) Timing  diagrams					( )	
	viii) Formalization of abnormal behavior		( )	


	4). The methodology should prescribe guidelines  to identify and decomp
ose :
	i) Structural complexity				( )	
	ii) Dynamic complexity					( )

2.4	Design features

	1. The methodology should prescribe guidelines for the following :
	i) Specifying  system architecture			( )	
	ii) Specifying and integrating interface classes for
	human interaction					( )	
	iii) Specifying and allocating tasks / processes to processors	( )
	
	iv) Specifying and integrating classes for 
	database management					( )	
	v) Data structures and pseudo code for 
	the application classes					( )
	vi) Refinement of overall analysis and design in 
	scope of all the new classes added			( )
		
	2. The methodology should prescribe OOSE features regarding :
	i) Release planning					( )
	ii) Work products ( deliverables) review		( )	
	iii) Incremental development				( )
	
2.5 	Representation

2.5.1	Static Views
	
	1. Class and Object					( )	
	2. Attributes						( )
	3. Methods						( )
	4. Generalization					( )
	5. Aggregation						( )	
	6. Cardinalities					( )

2.5.2	Dynamic views
	
	1. Instance connection					( )	
	2. Visibility						( )
	3. Message connection					( )
	4. Control / timing					( )	
	5. Concurrency						( )
	6. Object interaction diagrams				( )
	7. State charts						( )
	8. Nested states					( )

2.5.3	Constraints
	
	1. On structure 					( )
	2. On behavior						( )	

2.5.4	Complexity

	1. Static structure					( )	
	2. Dynamic behavior					( )

2.6	Miscellaneous 
	
	The methodology should :
	
	1. Be Scaleable 					( )
	2. Have semantic and syntactic definitions  for all notations	( )
	
	3. Use same notations for analysis and design		( )	
	4. Provide deliverables at every stage			( )
	5. Have case tool support for graphical layout		( )
	6. Have case tool support for
		simulation / code generation			( )	
	7. Check for extensibility				( )
	8. Check degree of coupling and cohesion		( )
	9. Check for consistency				( )
	10. Checks for completeness				( ) 
	11. Prescribe performance evaluation			( )	
	12. Prescribe non-graphical specifications  for entities
	discovered at all stages				( )	
	
3.0 	Comments and suggestions


							

			


		

					




======================================================================= 57 ===
Date:    8 Sep 94 07:09:24 GMT
From:    dls@gwd.dsto.gov.au (David Silver)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

grp@dmu.ac.uk (Graham Perkins) writes:

>In article <34ac8g$rlc@library.erc.clarkson.edu> satish@sun.mcs.clarkson.edu (
Satish Thatte) writes:
>>
>>Richard, perhaps you can post some examples where a C++ program
>>*requires* casting that a corresponding Eiffel program avoids
>>by some mechanism *other than* assignment attempt or covariance in
>>subclasses (which in a way are the same thing).
>>I am not saying such examples don't exist, but having heard this
>>argument going on for a long time, I still haven't seen any examples
>>that pinpoint the superiority of Eiffel typing over C++ in a way that
>>is not subsumed by RTTI features in forthcoming versions of C++.
>>
>class LIST[T]
>feature
>head : T
>tail : like Current
>put( x:T ) is
>  do tail := clone( Current )
>     head := x
>  end
>empty : BOOLEAN is
>  do Result := void( tail )
>  end
>end
>class ORDERED_LIST[ T->COMPARABLE ]
>inherit LIST[T] rename put as cons
>                end
>        LIST[T] redefine put
>                end
>feature

>put( x:T ) is
>  do if empty then cons( x )
>     elsif x < head 
>           then cons( x )
>           else tail.put( x )
>     end
>  end
>end

>Here, the use of type anchoring allows me to define a recursive
>data type (list = head:T plus tail:like Current) which I can
>also derive more recursive data types from.  You try writing
>the above scheme in C++ without using any casts.  I'll let
>you off with a non-generic solution, since using templates
>AND inheritance in the same C++ data structure leads to a
>horrible, unreadable mess.

OK, I'll bite.


#ifndef LIST_H
#define LIST_H

#include <stdio.h>

// C++ standard includes a "bool" type (finally) coming soon!
typedef int bool; 

template <class T>
class LIST {
protected:
  T       *item;
  LIST<T> *tail;
  
  virtual LIST<T> *clone() const { return new LIST<T>(item,tail); }
  LIST( T* it, LIST<T> *next ) { tail = next; item = it; }

public:
  LIST()                    { tail = NULL;    item = NULL; }
  virtual void put( T& it ) { tail = clone(); item = &it; }
  bool empty() const        { return tail == NULL; }

  T       *getItem() const { return item; }
  LIST<T> *getTail() const { return tail; } 
};

template <class X>
class ORDERED_LIST : public LIST<X> {
protected:
  LIST<X> *clone() const { return new ORDERED_LIST<X>(item,tail); }
  ORDERED_LIST( X* it, LIST<X> *next ) { item = it; tail = next; }

public:
  ORDERED_LIST() : LIST<X>() {}
  virtual void put( X& it );
};

template <class X>
void ORDERED_LIST<X>::put( X& it )
{
  if (empty() || it < *item)
    LIST<X>::put( it );
  else 
    tail->put( it );
}

#endif


I've tested it.  It works.
It's longer than the eiffel version, because eiffel does a few extra
things for you that C++ doesn't, and you'll notice that I have 
cheated, subtly.  The ORDERED_LIST<> is still chained together
with LIST<> pointers, which means that it would be necessary to use
a cast in derived classes to call methods of derived classes on
elements in the tail of the list.

Now, just because I managed to meet your challenge this time doesn't
mean that eiffel isn't a "better" language.  I have a feeling it is,
although I haven't had much incentive (or time) to switch yet.  
Probably it is better than C++ more for different reasons than this,
though.

-- David



======================================================================= 58 ===
Date:    8 Sep 1994 00:37:04 GMT
From:    satish@sun.mcs.clarkson.edu (Satish Thatte)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

>From article <1994Sep6.130943.19162@merlin.hgc.edu>, by jcm@hgc.edu (James McK
im):
> In article <34ac8g$rlc@library.erc.clarkson.edu> satish@sun.mcs.clarkson.edu 
(Satish Thatte) writes:
>>
>>Richard, perhaps you can post some examples where a C++ program
>>*requires* casting that a corresponding Eiffel program avoids
>>by some mechanism *other than* assignment attempt or covariance in
>>subclasses (which in a way are the same thing).
> 
> Hmmm... If we travel back in time a few years we might find the following
> analagous request.
> 
>   "Please show me an example in language X that "requires" a "go to"
>   which the corresponding code in language Y avoids by some mechanism
>   other than an "if..then" or "while..do" (which in a way are the same
>   thing).

Not fair!  See below.

> People who use Eiffel are willing to trade off a certain amount of potentiall
y
> dangerous low level flexibility for safety and high level expressibility.

There is no more safety in assignment attempt and covariance than in
dynamic casting using RTTI.  High level expressibility, maybe, but
the extent to which these features are profitably used (especially
covariance) does not seem to warrant the additional headache of
global checking, etc., which Eiffel is forced to do.

Any comments on the *fragility* of a type system that requires
global flow analysis, anyone?  Especially if you have used this a lot?

Satish


======================================================================= 59 ===
Date:    8 Sep 1994 16:53:07 +0100
From:    tom@smart.bo.open.de (Thomas Neumann)
Subject: SRC 3.3 for NeXT now available

Precompiled binaries of SRC Modula-3 release-3.3 are now
available for NeXTSTEP 3.2 on m68k machines. You may get
them by anonymous ftp from

	ftp.vlsi.polymtl.ca:/pub/m3/next/


The directory holds the following files:


next-m68k.boot.tar.gz	- This is boot-NEXT.tar.gz from release-3.3,
			  modified so that it actually works.

next-m68k.libm3.tar.gz	- This is libm3.tar.gz from release-3.3,
			  modified so that it works on NeXT machines.

next-m68k.diffs.tar.gz	- This are the patches relative to the stock
			  release-3.3 distribution from DEC.
			  It includes a step-by-step description how
			  to apply the patches and boot the compiler.

next-m68k.bin.tar.gz	- Executables and compiled libm3.
			  Unpack and you are ready to go.
			  (Installs under /usr/local/...)


Thanks to Michel Dagenais <dagenais@vlsi.polymtl.ca> for providing me
the necessary disk space on his ftp server, and to DEC SRC for a
wonderful software product.

bye -- Thomas



======================================================================= 60 ===
Date:    08 Sep 1994 20:34:11 GMT
From:    connolly@ulua.hal.com (Dan Connolly)
Subject: Performance of M3 on Intell boxes (Linux, Chicago)


I have wondered about the "weight" of the M3 runtime, and after
some experience with it, I'm a little concerned.

When I start an M3 application on my linux box, the machine whirrs and
spins for a bit -- swapping in the shard libs, I guess. And then once
the application is running, it pauses every once-in-a-while to show me
the star-trek cursor and garbage collect.

I noticed a couple things in the Linux release notes:

	* the exception handling code is based on setjmp/longjmp,
	rather than the more optimal stack-walking strategy.

		-- is this likely to impact performance noticeably?

		-- is the Intel stack sufficiently "self-describing"
		   to allow for the more optimal solution? Would someone
		   with experience in this area make a WAGuess at how
		   much work it would be to implement the stack-walking
		   stuff on the intell platform? If it's a reasonable
		   chunk of work, I'm willing to give it a go.

	* the garbage collection isn't synchronized with the virtual
	  memory system. Same two questions:

		-- is this likely to impact performance noticeably?

		-- Would someone with experience guestimate the amount
		   of work to make the appropriate enhancements?


Finally, for some serious speculating: Is anybody working on targeting
M3 applications on Chicago-class boxes? Say 486/66mhz 8mb ram, SVGA
video... regular "Computer City" boxes by the time next summer comes
around? My guess is that Tresle and VBTkit would be a very time
consuming port, but the stuff apart from the GUI libraries, while it
might be tricky, should be doable by then.

Dan
-- 
Daniel W. Connolly        "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project   (512) 834-9962 x5010
<connolly@hal.com>                   http://www.hal.com/%7Econnolly/index.html


======================================================================= 61 ===
Date:    8 Sep 94 09:39:41
From:    doug@monet.ads.com (Doug Morgan)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

In article <1994Sep7.170247.21058@rcmcon.com> rmartin@rcmcon.com (Robert Martin
) writes:
>>grp@dmu.ac.uk (Graham Perkins) writes:
>[presents a challenge, Translate this Eiffel code into C++ without Casts]
>>|class LIST[T]
>[code elided]
>tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

>>Well, a typesafe C++ solution without casts is given
>>below; 

>[code elided]
>I think this particular bit of language war has illustrated the
>salient principle of all language wars: 

>	  "The only valid critic of a language,
>	  is an expert in that language."

>Corrollary:

>	  "If you don't code in it *alot*, then don't complain about it."

Interesting principles, but, in this instance, of questionable
appropriateness.  Although Thomas Breuel asserted that his code is a
"typesafe C++ solution", it actually sidesteps the main point of the
original challenge and therefore fails to be a "solution" in any
sense.  (As it is a major anomaly for Thomas to miss hitting any point
dead-on and correctly, invoking the above principles probably seemed
justified.)

The core of Graham's challenge is the compiler-typechecked member
datum (attribute feature) called tail.  tail is of class LIST for LIST
objects and of class ORDERED_LIST for ORDERED_LIST objects.  Eiffel
compilers don't use casts and are supposed to do conservative
system-validity checks for potential violations of the invariants of
the tail object engendered by use of features provided by a correctly
written class.  (Thomas already essentially noted that the invariants
for this LIST cannot be those normally associated with lists, but that
is irrelevant to the anchoring issue.)  The C++ version (reasonably)
replaces the tail attribute in the List with a member function:

List tail()

However, the main point is sidestepped in neglecting to define the
corresponding:

OrderedList tail()

in the OrderedList class.  Defining OrderedList::tail() requires using
and possibly introducing a typeunsafe construct: either the
OrderedList(List) constructor (which can easily be used to construct
an invariants-violating unordered OrderedList), a cast, or some other
combination of constructors and casts that equally well may be "type
checked" by the compiler, but won't guarantee that a resulting
OrderedList is indeed ordered.

The point is that Eiffel compilers/environments allow explicit
covariance and catch errors that C++ compilers are not required to
catch (when C++ users implicitly invoke covariance).  However, someone
could probably write a C++ lint that found the existence and maximum
depth down the class lattice of implicit covariance and then did a
system-level validity check at that depth, it's just not in the spec.
Also, Eiffel could stop a perfectly valid program from executing
because its checking is conservative.

Although, Graham Perkins' original challenge/critique of C++ is
logically valid (well, "cast" should really be replaced with
"typeunsafe construct"), its significance to C++ users is less clear.
I don't recall having ever made a strictly system-level validity error
and I'd guess the odds of misusing OrderedList tail() and its
associated typeunsafe implementations would usually be small.  OK,
maybe the principles aren't so strange.

Doug
--------------------------------------------------------------------
Doug Morgan, doug@ads.com, (415) 960-7444
Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
1500 Plymouth St., Mountain View, CA 94043-1230
--------------------------------------------------------------------


======================================================================= 62 ===
Date:    8 Sep 1994 15:57:39 -0400
From:    hendrik@CAM.ORG (Hendrik Boom)
Subject: Re: DEC's Modula 3

Simon Johnston (skj@oasis.icl.co.uk) wrote:
: atverm@ecp541.ecn.nl wrote:
: : In  <778611866.AA07139@dialis.hacktic.nl>  geert@dialis.hacktic.nl (Geert B
osch) writes:
: : | I just ftp-ed Modula-3 from gatekeeper.dec.com and I am wondering if anyb
ody
: : | has tips about setting it up. My ultimate wish would be to compile Modula
-3
: : | from within an OS/2 environment. Does anybody have experience in doing th
is?
: : |  
: : I wish you good luck, you'd be the first to succeed. If you're serious
: : I advise you to use the EMX 0.8h GCC environment to compile the beast.
: : You'll need a fair amount of Unix and C knowledge. I gather you've
: : taken the Linux port as a starting point? 
: : I once had the same plans as you, but I really don't have the time to
: : do it. I remember reading some message of another brave person about
: : two months ago who reported he got quake to work and he posted the

: I am that 'brave' person, I got quake working, and produced some OS2 template
: files which appear to work with the EMX 0.8hpl9 environment. The main problem
 
: with this was that the OS2 command line cannot take all those file names on
: the link/lib command name. The answer was to produce a response file for the
: librarian and pass it on the command line, for the link phase produce a lib
: first and then link the lib.

: : diffs needed for it. I didn't hear from it any more. If you make progress,
: : I am very much interested and would like to be kept informed, and I'm sure

: I have had to stop work on this as my *real* work demanded the time and disk
: space I was using. If I get back to it I will of course let the group know.

: : much others are because there have been quite some requests for an OS/2
: : port in the recent year!

: Thanks for remembering the post, noone else seemed to have noticed the post
: go by, I thought I was all alone out here!

I'm another brave person attempting it, planning a cross-port from Linux.
I'm on the verge of installing Linux as third OS on my OS/2 machine;
i.e., my machine is currently having a much larger hard disk installed...

	hendrik@cam.org


======================================================================= 63 ===
Date:    9 Sep 1994 18:01:47 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Performance of M3 on Intell boxes (Linux, Chicago)

In article <CONNOLLY.94Sep8153413@ulua.hal.com>, connolly@ulua.hal.com (Dan Con
nolly) writes:
> I noticed a couple things in the Linux release notes:
> 	* the exception handling code is based on setjmp/longjmp,
> 	rather than the more optimal stack-walking strategy.
> 		-- is this likely to impact performance noticeably?

It's probably not terrible on an x86 box.  Every entry to a TRY-EXCEPT
statement (and a few bizarre TRY-FINALLY stmts) will call setjmp.
Since the jmp buffer is only 8 words, it can't(?) take too long to
fill it.

> 		-- is the Intel stack sufficiently "self-describing"
> 		   to allow for the more optimal solution?

I don't know.

> 	* the garbage collection isn't synchronized with the virtual
> 	  memory system. Same two questions:
> 		-- is this likely to impact performance noticeably?

Yes.  The star-trek cursor appears during the stop-and-copy collections.
With the VM synchronization you get incremental and generational
collections.  The pauses would be invisible.

> 		-- Would someone with experience guestimate the amount
> 		   of work to make the appropriate enhancements?

It's not much work:
  - It must be possible to protect and unprotect data pages,
    and the signal handler for memory access violations must be able
    to determine the offending address and resume from the
    signal.  See runtime/src/{DS3100,SPARC}/RTHeapDep.[im]3.

  - The system calls need wrappers that validate their arguments
    before making the call.  See runtime/src/{DS3100,SPARC}/RTHeapDepC.c.

> Finally, for some serious speculating: Is anybody working on targeting
> M3 applications on Chicago-class boxes?

Yes, we're working a port of the system to Chicago.  No, I don't know
when it will be ready for release.

  - Bill Kalsow


======================================================================= 64 ===
Date:    09 Sep 1994 22:47:56 GMT
From:    connolly@ulua.hal.com (Dan Connolly)
Subject: mprotect() support in Linux kernel?


I'm interested in enhancing the Linux port of Modula 3 to use
incremental/generational garbage collection. This requires support for
the mprotect() library routine, or its equivalent.

However, it appears that mprotect() is not supported under Linux:

In linux/mm/mmap.c, I see:
230  asmlinkage int sys_mprotect(unsigned long addr, size_t len, unsigned long 
prot)
231  {
232          return -EINVAL; /* Not implemented yet */
233  }

mprotect() is in /usr/include/sys/mman.h, but there's no linux man page
(that I can find) for mprotect.

In the Kernel Hackers guide at
http://sunsite.unc.edu/mdw/LDP/khg/section2.7.1.html
I see:

	Minor alterations are needed in some places (tests for process
	memory limits comes to mind) to provide support for programmer
	defined segments.


So I guess for now, I'm out of luck. I'm willing to hack the modula-3
runtime, but it would take me a while to ramp up on the Linux kernel
memory management.

Have I found the most recent info? Is there a more recent version of
the kernel that supports mprotect()? Is anyone working on support for
this? Is there a different library function that would serve my needs?

Thanks.

Dan


In article <34q7ub$6k4@src-news.pa.dec.com> kalsow@src.dec.com (Bill Kalsow) wr
ites:

   From: kalsow@src.dec.com (Bill Kalsow)
   Newsgroups: comp.lang.modula3
   Date: 9 Sep 1994 18:01:47 GMT
   Organization: DEC Systems Research Center

   In article <CONNOLLY.94Sep8153413@ulua.hal.com>, connolly@ulua.hal.com (Dan 
Connolly) writes:
   > 	* the garbage collection isn't synchronized with the virtual
   > 	  memory system. Same two questions:
   > 		-- is this likely to impact performance noticeably?

   Yes.  The star-trek cursor appears during the stop-and-copy collections.
   With the VM synchronization you get incremental and generational
   collections.  The pauses would be invisible.

   > 		-- Would someone with experience guestimate the amount
   > 		   of work to make the appropriate enhancements?

   It's not much work:
     - It must be possible to protect and unprotect data pages,
       and the signal handler for memory access violations must be able
       to determine the offending address and resume from the
       signal.  See runtime/src/{DS3100,SPARC}/RTHeapDep.[im]3.

     - The system calls need wrappers that validate their arguments
       before making the call.  See runtime/src/{DS3100,SPARC}/RTHeapDepC.c.

The source code he refers to is available at:

	http://www.research.digital.com/SRC/m3sources/html/runtime/src/SPARC/RT
HeapDep.m3

-- 
Daniel W. Connolly        "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project   (512) 834-9962 x5010
<connolly@hal.com>                   http://www.hal.com/%7Econnolly/index.html


======================================================================= 65 ===
Date:    Fri, 9 Sep 1994 17:28:39 GMT
From:    jjb@watson.ibm.com (John Barton)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

In article <DOUG.94Sep8093941@monet.ads.com>, doug@monet.ads.com (Doug Morgan) 
writes:
|> In article <1994Sep7.170247.21058@rcmcon.com> rmartin@rcmcon.com (Robert Mar
tin) writes:
|> >>grp@dmu.ac.uk (Graham Perkins) writes:
|> >[presents a challenge, Translate this Eiffel code into C++ without Casts]
|> >>|class LIST[T]
|> >[code elided]
|> >tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
|> 
|> >>Well, a typesafe C++ solution without casts is given
|> >>below; 
[...stuff deleted]
|> 
|> Interesting principles, but, in this instance, of questionable
|> appropriateness.  Although Thomas Breuel asserted that his code is a
|> "typesafe C++ solution", it actually sidesteps the main point of the
|> original challenge and therefore fails to be a "solution" in any
|> sense.  (As it is a major anomaly for Thomas to miss hitting any point
|> dead-on and correctly, invoking the above principles probably seemed
|> justified.)
|> 
|> The core of Graham's challenge is the compiler-typechecked member
|> datum (attribute feature) called tail.  tail is of class LIST for LIST
|> objects and of class ORDERED_LIST for ORDERED_LIST objects.  Eiffel
|> compilers don't use casts and are supposed to do conservative
|> system-validity checks for potential violations of the invariants of
|> the tail object engendered by use of features provided by a correctly
|> written class.  (Thomas already essentially noted that the invariants
|> for this LIST cannot be those normally associated with lists, but that
|> is irrelevant to the anchoring issue.)  The C++ version (reasonably)
|> replaces the tail attribute in the List with a member function:
|> 
|> List tail()
|> 
|> However, the main point is sidestepped in neglecting to define the
|> corresponding:
|> 
|> OrderedList tail()
|> 
|> in the OrderedList class.  Defining OrderedList::tail() requires using
|> and possibly introducing a typeunsafe construct: either the
|> OrderedList(List) constructor (which can easily be used to construct
|> an invariants-violating unordered OrderedList), a cast, or some other
|> combination of constructors and casts that equally well may be "type
|> checked" by the compiler, but won't guarantee that a resulting
|> OrderedList is indeed ordered.

   Below I modified the C++ version to introduce a ListCategory<List, T>
that defines a tail() member returning an object of type List.  This
construct is exactly covariant because each ListCategory class derives
from the template and substitutes itself for "List", eg
ListCategory< OrderedList<T>, T> and the return types in the ListCategory
are of the self type, eg OrderedList<T> in this case.

   We call this construct a "function-structure category" because it
expresses the relation between functions in a category of classes. In 
the example below I left "data" as member data, but I would look for 
a design that used a function call here instead.  

|> 
|> The point is that Eiffel compilers/environments allow explicit
|> covariance and catch errors that C++ compilers are not required to
|> catch (when C++ users implicitly invoke covariance).  However, someone
|> could probably write a C++ lint ...
  
   Not necessary; I find that you can put as much---or as little---type
checking into C++ as you like.  Doesn't make it better or worse, its
just that way.

[...stuff deleted ]

-- 
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598



typedef int bool;
void assert(void*);

template <class T>
struct Cons {
    T head;
    Cons<T> *tail;
    Cons(T head,Cons<T> *tail):head(head),tail(tail) {}
};

template<class List, class EltT>
struct ListCategory {
   Cons<EltT>* data;
   EltT head()  { assert(data); return data->head;}
   List          tail()  { assert(data); return List(data->tail); }
   bool          empty() {return data==0;}
};

template<class List, class EltT>
List ListCategory<List,EltT>::tail() { assert(data); return List(data->tail); }

template <class T>
struct List 
  : ListCategory< List<T>, T> {
    
    List(){ data=0; }
    List(Cons<T> *dataN) { data = dataN;}

    void insert(T x) {data = new Cons<T>(x,data);}
};


template <class T>
struct OrderedList : ListCategory< OrderedList<T>, T> {
    OrderedList() {}
    OrderedList(Cons<T> *dataN) { data = dataN;}
    OrderedList<T>& operator=(OrderedList<T> & list) {data = list.data; return 
*this;}

   OrderedList(List<T> list){ data = list.data; }
    OrderedList<T>& operator=(List<T> &list) {data = list.data; return *this;}

    void insert(T x) {
	if(!data || data->head >= x) {
	    data = new Cons<T>(x,data);
	    return;
	} 
	Cons<T> *p = data;
	while(p->tail) {
	    if(p->tail->head >= x) {
		p->tail = new Cons<T>(x,p->tail);
		return;
	    }
	    p = p->tail;
	}
	p->tail = new Cons<T>(x,p->tail);
    }
};

int main() {
  OrderedList<int> ol;
  return 0;
}



======================================================================= 66 ===
Date:    Fri, 9 Sep 1994 19:17:36 GMT
From:    bcrwhims@undergrad.math.uwaterloo.ca (Carsten)
Subject: Re: Performance of M3 on Intell boxes (Linux, Chicago)

In article <34q7ub$6k4@src-news.pa.dec.com>,
Bill Kalsow <kalsow@src.dec.com> wrote:
|  In article <CONNOLLY.94Sep8153413@ulua.hal.com>, connolly@ulua.hal.com (Dan 
Connolly) writes:
|  > I noticed a couple things in the Linux release notes:
|  > 	* the exception handling code is based on setjmp/longjmp,
|  > 	rather than the more optimal stack-walking strategy.
|  > 		-- is this likely to impact performance noticeably?
|  
|  It's probably not terrible on an x86 box.  Every entry to a TRY-EXCEPT
|  statement (and a few bizarre TRY-FINALLY stmts) will call setjmp.
|  Since the jmp buffer is only 8 words, it can't(?) take too long to
|  fill it.
|  
|  > 		-- is the Intel stack sufficiently "self-describing"
|  > 		   to allow for the more optimal solution?
|  
|  I don't know.
|  
|  > 	* the garbage collection isn't synchronized with the virtual
|  > 	  memory system. Same two questions:
|  > 		-- is this likely to impact performance noticeably?
|  
|  Yes.  The star-trek cursor appears during the stop-and-copy collections.
|  With the VM synchronization you get incremental and generational
|  collections.  The pauses would be invisible.
|  
|  > 		-- Would someone with experience guestimate the amount
|  > 		   of work to make the appropriate enhancements?
|  
|  It's not much work:
|    - It must be possible to protect and unprotect data pages,
|      and the signal handler for memory access violations must be able
|      to determine the offending address and resume from the
|      signal.  See runtime/src/{DS3100,SPARC}/RTHeapDep.[im]3.
|  
|    - The system calls need wrappers that validate their arguments
|      before making the call.  See runtime/src/{DS3100,SPARC}/RTHeapDepC.c.
|  
|  > Finally, for some serious speculating: Is anybody working on targeting
|  > M3 applications on Chicago-class boxes?
|  
|  Yes, we're working a port of the system to Chicago.  No, I don't know
|  when it will be ready for release.
|  
|    - Bill Kalsow

Well, considering the number of OS/2 installations out there (5mil+),
and the number of Chicago installations (o, <200,000 beta), why not do
OS/2 first?
-- 
-------------------------------------------------------------------
  Carsten Whimster                         EDM/2 Associate Editor
  bcrwhims@cayley.uwaterloo.ca        EDM/2 Book Review columnist
---- Author of POVPanel ------ SRX600 ------- TEAM OS/2 -----------


======================================================================= 67 ===
Date:    Thu, 8 Sep 1994 17:46:00 GMT
From:    franka@parcplace.com (Frank Adrian)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <EMERY.94Sep1140421@goldfinger.mitre.org> emery@goldfinger.mitre.org
 (David Emery) writes:
>> This isn't an issue if dynamic typing is also available, but I still
>>don't see how static typing can possibly _enhance_ creativity.
>
>Do you believe in abstraction?  Do you believe in automating the
>details and bookkeeping?  
>
>Static type checking (whether in the language, such as Ada, or in some
>related tool, such as lint for C) helps creativity by allowing the
>programmer to concentrate on the big issues, and using the tools to
>automate checking of the small issues.  

Excuse me?  I fail to see the connection with static typing and abstraction.

I have seen many fine abstractions presented in dynamically-typed languages -
see Ableson and Sussman's "Structure and Interpretation of Computer Programs",
for some simple examples.  The only thing abstraction means is to present a
common interface to a capability without regards how this capability is carried
out.  This says ABSOLUTELY NOTHING about how references to this interface are
checked - statically, dynamically, or at all.

In fact, most static type systems I am familiar with lull programmers into a
false sense of security because their type system depends on a lexicographic
signature rather than a well-defined LOGICAL set of inariant attributes that
all members of a different class share.  Although Eiffel's pre- and post-
conditions are a step in the right direction, most languages that call them-
selves "strongly typed" are not.

Most studies show that dynamically-typed programming systems still allow a much
more productive programmer.  I think you overestimate both the amount of help
a statically-typed system actually provides in producing a correct program
(especially when the check is just on the language's shallow syntactic structur
e
and not on the deeper logical structure) AND the amount of help a programmer
actually NEEDS.

If you want to show me a language that allows me to write first-order predicate
logic statements as invariants that are used to check types I will be happily
disuaded from my points above.  To put it in a simpler perspective (for the
linguistically challenged out there who only know C++ :-), as soon as you show
me that I cannot overload the + operator to perform a - operation, I will know
that your type system IS actually strong.  Until then, you are living in a
fool's paradise.
-- 
Frank A. Adrian                   /|\         "A Mbit here, a Gbit there
franka@parcplace.com             / | \        and pretty soon you're talking
ParcPlace Systems, Inc.         /  |  \       about real bandwidth..."
Portland                       /   |   \                           -- me


======================================================================= 68 ===
Date:    10 Sep 1994 02:19:12 GMT
From:    tmb@arolla.idiap.ch (Thomas M. Breuel)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

In article <DOUG.94Sep8093941@monet.ads.com> doug@monet.ads.com (Doug Morgan) w
rites:
|Although Thomas Breuel asserted that his code is a
|"typesafe C++ solution", it actually sidesteps the main point of the
|original challenge and therefore fails to be a "solution" in any
|sense.

I don't think it does miss the point (see below).

|The core of Graham's challenge is the compiler-typechecked member
|datum (attribute feature) called tail.  tail is of class LIST for LIST
|objects and of class ORDERED_LIST for ORDERED_LIST objects.

There are (at least) four different semantics that you may want to
use for the relationship between LIST and ORDERED_LIST, and all
four can be implemented easily and without casts in C++:

(1) allow List and OrderedList to be used interchangeably, enforcing
    class invariants

	Solution: provide conversion functions that ensure the
	class invariants; in particular, replace the constructor
	for OrderedList by:

	OrderedList::OrderedList(List<T> &source) {
		data = sort(source.data);
	}

(2) allow List and OrderedList to be used interchangeably, guaranteeing
    class invariants through dynamic typing

	Solution: use RTTI or a manual implementation

	OrderedList::OrderedList(List<T> &source) {
		if(!source.is_ordered()) RUNTIME_TYPE_ERROR;
		data = copy(source.data);
	}

(3) allow List and OrderedList to be used interchangeably without
    guaranteeing class invariants:

	Solution: use the code as given; that is, the constructor
	doesn't do any checking:

	OrderedList::OrderedList(List<T> &source) {
		data = source.data;
	}

(4) don't allow List and OrderedList to be used interchangeably;
    just reuse part of the implementation of List

	Solution: there are many possible approaches, including:

	(a) manual message forwarding

	(b) message forwarding with operator->

	(c) templates

        (d) inheritance with redefinition of the return type
	    in the derived class (I believe the draft ANSI C++
	    standard allows this; this is most closely
	    analogous to the Eiffel solution, but I think
	    it's the least desirable solution)

None of these possibilities require unsafe casts for their
implementation in C++ (or any casts, for that matter).  All of them
allow full reuse of the functionality defined with the List<T> type.

Now, my initial thought was that Graham's Eiffel code implemented (3),
since ORDERED_LIST inherits from LIST in his code.  That's why I gave
the implementation that I did, pointing out clearly that I considered
this a flaw.

On re-reading the section on system-validity in the Eiffel book, I'm
actually not quite sure what his code does (my only reference on
Eiffel; unfortunately, Graham didn't tell us in words what he wanted
his code to do); it seems like it is either reduces to case (4), or it
reduces to case (3), or it requires runtime type checking, or it is
useless (because system validity checks would never let you invoke
method "tail" on an object of type LIST).  Does anyone care to
explain?

|Although, Graham Perkins' original challenge/critique of C++ is
|logically valid (well, "cast" should really be replaced with
|"typeunsafe construct"), its significance to C++ users is less clear.

Whichever of the four behaviors he wants, he can get without casts or
unsafe constructs.  If the Eiffel code does something different from
these four possibilities, please let me know and I'll try to cook up a
C++ version of it.

|I don't recall having ever made a strictly system-level validity error
|and I'd guess the odds of misusing OrderedList tail() and its
|associated typeunsafe implementations would usually be small.  OK,
|maybe the principles aren't so strange.

I don't think you can make a system-level validity error in C++
without explicitly using an unsafe operation (*).  System validity
checking in Eiffel seems to be necessary because of the possibility of
incompatible redefinitions in subclasses (types or hiding).  Case (3)
above doesn't qualify as a "system level validity error", since the
dangerous conversion behavior is explicitly implemented by user code;
something analogous can be done in any language, including Eiffel.

In any case, I think the reason why you haven't come across this
"problem" in C++ is that, as we have seen above, there are numerous
other ways of achieving the same kind of polymorphism and reuse that
do not involve inheritance and the use of "like" and "clone".  You
probably have always simply designed your C++ libraries and classes
accordingly.

				Thomas.

(*) You can make virtual functions "private" in derived classes and
still access them through the base class in C++; however, this is
simply a different definition of what "hiding" means.  Compilers should
probably warn about such cases, though.

The original Eiffel code (Graham's challenge):

|class LIST[T]
|feature
|head : T
|tail : like Current
|put( x:T ) is
|  do tail := clone( Current ) 
|     head := x
|  end
|empty : BOOLEAN is
|  do Result := void( tail )
|  end
|end
|
|class ORDERED_LIST[ T->COMPARABLE ]
|inherit LIST[T] rename put as cons
|                end
|        LIST[T] redefine put
|                end
|feature
|
|put( x:T ) is
|  do if empty then cons( x )
|     elsif x < head 
|           then cons( x )
|           else tail.put( x )
|     end
|  end
|end
|

My original solution:

|template <class T>
|struct Cons {
|    T head;
|    Cons *tail;
|    Cons(T head,Cons *tail):head(head),tail(tail) {}
|};
|
|template <class T>
|struct List {
|    Cons<T> *data;
|    
|    List():data(0) {}
|    List(Cons<T> *data):data(data) {}
|
|    void insert(T x) {data = new Cons<T>(x,data);}
|    bool empty() {return data==0;}
|    T head() {assert(data); return data->head;}
|    List tail() {assert(data); return List(data->tail);}
|};
|
|template <class T>
|struct OrderedList:List<T> {
|    OrderedList() {}
|    OrderedList(Cons<T> *data):List<T>(data) {}
|    OrderedList &operator=(OrderedList<T> &list) {data = list.data; return *th
is;}
|
|    OrderedList(List<T> list):List<T>(list.data) {}
|    OrderedList &operator=(List<T> &list) {data = list.data; return *this;}
|
|    void insert(T x) {
|	if(!data || data->head >= x) {
|	    data = new Cons<T>(x,data);
|	    return;
|	} 
|	Cons<T> *p = data;
|	while(p->tail) {
|	    if(p->tail->head >= x) {
|		p->tail = new Cons<T>(x,p->tail);
|		return;
|	    }
|	    p = p->tail;
|	}
|	p->tail = new Cons<T>(x,p->tail);
|    }
|};


======================================================================= 69 ===
Date:    10 Sep 1994 02:00:15 GMT
From:    goldt@math.tu-berlin.de (Sven Goldt)
Subject: Re: mprotect() support in Linux kernel?

Dan Connolly (connolly@ulua.hal.com) wrote:

: I'm interested in enhancing the Linux port of Modula 3 to use
: incremental/generational garbage collection. This requires support for
: the mprotect() library routine, or its equivalent.

: However, it appears that mprotect() is not supported under Linux:

It is implemented in newer kernels. Look at the Linux Programmer's Guide.

--
*****************************************************************************
*    # THE MOST IMPORTANT FINANCIAL QUESTION IS:  Where is the money ? #    *
*****************************************************************************


======================================================================= 70 ===
Date:    10 Sep 1994 13:18:19 GMT
From:    agulbra@nvg.unit.no (Arnt Gulbrandsen)
Subject: Re: mprotect() support in Linux kernel?

In article <34r3vf$3g9@brachio.zrz.tu-berlin.de>,
Sven Goldt <goldt@math.tu-berlin.de> wrote:
>Dan Connolly (connolly@ulua.hal.com) wrote:
>
>: I'm interested in enhancing the Linux port of Modula 3 to use
>: incremental/generational garbage collection. This requires support for
>: the mprotect() library routine, or its equivalent.
>
>: However, it appears that mprotect() is not supported under Linux:
>
>It is implemented in newer kernels. Look at the Linux Programmer's Guide.

Partly implemented, according to Linus.  He added it about 1.1.36-8.

--Arnt


======================================================================= 71 ===
Date:    10 Sep 1994 11:59:29 GMT
From:    brister@jolt.mpx.com.au (James Brister)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

Richard Bunbury (bunbury@vienna.eiffel.com) wrote:

[ a whole pile of crap about C++'s new 'casts' (really type-saftey mechanisms) 
]

Here we go again. "My language is better than yours." And from a vendor
no less.  Sounds to me like a little panic setting in. C++ is putting
in the type-safety machanisms to make it more appealing and the fringe
languages will become even more so.

James (Modula-3 rules, but language wars suck).


======================================================================= 72 ===
Date:    Sat, 10 Sep 1994 21:27:26 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

franka@parcplace.com (Frank Adrian) writes:

>Most studies show that dynamically-typed programming systems still
>allow a much more productive programmer.  

Which studies are these?  Are they controlled experiments?  Who
sponsors them?  Can you give us some citings?

>I think you overestimate
>both the amount of help a statically-typed system actually provides
>in producing a correct program (especially when the check is just on
>the language's shallow syntactic structure and not on the deeper
>logical structure) AND the amount of help a programmer actually
>NEEDS.

That programmers need an awful lot of help is not in dispute.  They
do.  If we could all write our programs correctly the first time, then
maybe we wouldn't need any help.

The cost of a bug increases geometrically with time.  Early in
analysis and design, bugs are cheap to fix.  During testing they are
more expensive by a factor of K.  During beta by K^2 and after release
K^3, if not more.

Static typed language find certain kinds of bugs in very early phases.
The cost of saving those bugs is significant.  

>If you want to show me a language that allows me to write first-order
>predicate logic statements as invariants that are used to check types
>I will be happily disuaded from my points above.  To put it in a
>simpler perspective (for the linguistically challenged out there who
>only know C++ :-), as soon as you show me that I cannot overload the
>+ operator to perform a - operation, I will know that your type
>system IS actually strong.  Until then, you are living in a fool's
>paradise. 

I find it difficult to believe that any serious C++ programmer would
consider his language to be fully type safe.  I find it difficult to
believe that any C++ programmer considers himself to be living in any
kind of paradise at all.  The most compelling reason for choosing C++
is the aknowledgement that software engineering is closer to Hell than
Paradise and that C++ is pragmatic enough to deal with "hellish"
problems.



-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 73 ===
Date:    12 Sep 1994 12:01:28 GMT
From:    anderse@dna.lth.se (Anders Edenbrandt)
Subject: Problems with SRC Modula-3 v. 3.3

I have installed SRC Modula-3 version 3.3, on SunOS 4.1
as well as on Solaris, and I have installed the fixes mentioned
in "bugs and patches", but I still have some questions/problems:

  1. On SunOS 4.1, nothing works unless I run with @M3novm.
     Is this what I should expect? (I thought that the VM problem
     had been fixed ...)

  2. M3gdb, the debugger, has lots of problems, most of which
     I have seen reported here a long time ago. Is anybody
     working on fixing this? At SRC or anywhere else?

  3. What about the VM protection parts for Solaris? Has this
     been done somewhere?


Anders Edenbrandt
Dept. of Comp. Sci.
Lund University
Lund, Sweden


======================================================================= 74 ===
Date:    12 Sep 1994 14:29:41 GMT
From:    preece@urbana.mcd.mot.com (Scott E. Preece)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

n-reply-to: rmartin@rcmcon.com's message of Sat, 10 Sep 1994 21:27:26 GMT
Xref: courier.urbana.mcd.mot.com comp.software-eng:22141 comp.object:19259 comp
.lang.eiffel:5808 comp.lang.smalltalk:14298 comp.lang.modula3:2813 comp.lang.ob
jective-c:2964

In article <1994Sep10.212726.2087@rcmcon.com> rmartin@rcmcon.com (Robert Martin
) writes:

|   The cost of a bug increases geometrically with time.  Early in
|   analysis and design, bugs are cheap to fix.  During testing they are
|   more expensive by a factor of K.  During beta by K^2 and after release
|   K^3, if not more.
|
|   Static typed language find certain kinds of bugs in very early phases.
|   The cost of saving those bugs is significant.  
---

Yes, static typing allows you to find a specific class of defects early
in the process.  However, most dynamic type checking would find most of
those same problems equally earely in the process.  In my experience,
the enormous bulk of the type errors I hit are trivia - typos and
mistakes in changing a variable from one type to another in some places
but not in others.  Virtually all of them would have been caught by
run-time checks the first time I tried to run the program (the
equivalent of their being caught at the first compile).  Virtually all
of them could have been caught by a code analyzer with a practical level
of effort.  The "hard" type errors I've encountered have mostly been in
places where static type checking wouldn't have helped - in places where
externally provided memory images had to be turned into internally
usable types or where other explicit conversions had to be done and were
botched.

Frankly, I find the "this interface will reliably signal an error if
called with the wrong type" promise of dynamic typing more believable than
the "the language makes it impossible to pass the wrong type to an
interface" promise of static typing...

scott
--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
phone:	217-384-8589			  fax:	217-384-8550
internet mail:	preece@urbana.mcd.mot.com


======================================================================= 75 ===
Date:    12 Sep 94 09:12:22
From:    doug@monet.ads.com (Doug Morgan)
Subject: Re: Real C++ programmers don't use casts [was Re: Static vs Dynamic Ty
ping]

In article <TMB.94Sep10041912@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M. B
reuel) writes:
|In article <DOUG.94Sep8093941@monet.ads.com> doug@monet.ads.com (Doug Morgan) 
writes:
||Although Thomas Breuel asserted that his code is a
||"typesafe C++ solution", it actually sidesteps the main point of the
||original challenge and therefore fails to be a "solution" in any
||sense.
|
|I don't think it does miss the point (see below).
|
||The core of Graham's challenge is the compiler-typechecked member
||datum (attribute feature) called tail.  tail is of class LIST for LIST
||objects and of class ORDERED_LIST for ORDERED_LIST objects.
|
|There are (at least) four different semantics that you may want to
|use for the relationship between LIST and ORDERED_LIST, and all
|four can be implemented easily and without casts in C++:
|
|(1) allow List and OrderedList to be used interchangeably, enforcing
|    class invariants
|
|	   Solution: provide conversion functions that ensure the
|	   class invariants; in particular, replace the constructor
|	   for OrderedList by:
|
|	   OrderedList::OrderedList(List<T> &source) {
|		   data = sort(source.data);
|	   }

No.  If you also have a ReverseOrderedList, they will swap orderings
of the data out from underneath each other.  Further, perhaps LIST
required that only put() could modify its current ordering?

|(2) allow List and OrderedList to be used interchangeably, guaranteeing
|    class invariants through dynamic typing
|
|	   Solution: use RTTI or a manual implementation
|
|	   OrderedList::OrderedList(List<T> &source) {
|		   if(!source.is_ordered()) RUNTIME_TYPE_ERROR;
|		   data = copy(source.data);
|	   }

No.  Run-time, not compile-time, checked.

|(3) allow List and OrderedList to be used interchangeably without
|    guaranteeing class invariants:
|
|	   Solution: use the code as given; that is, the constructor
|	   doesn't do any checking:
|
|	   OrderedList::OrderedList(List<T> &source) {
|		   data = source.data;
|	   }

No.  OrderedLists then aren't necessarily ordered.

|(4) don't allow List and OrderedList to be used interchangeably;
|    just reuse part of the implementation of List
|
|	   Solution: there are many possible approaches, including:
|
|	   (a) manual message forwarding
|
|	   (b) message forwarding with operator->
|
|	   (c) templates
|
|	   (d) inheritance with redefinition of the return type
|	       in the derived class (I believe the draft ANSI C++
|	       standard allows this; this is most closely
|	       analogous to the Eiffel solution, but I think
|	       it's the least desirable solution)

No.  The Eiffel solution does allow an ORDERED_LIST to be used in some
places where a LIST is declared.

|None of these possibilities require unsafe casts for their
|implementation in C++ (or any casts, for that matter).

Yes, but as none of these possibilities actually does or allows what
the Eiffel implementation does, they still don't address what I think
is the core issue.

Actually, I think that most applications could do better to not use
covariance and instead improve the structure of a class lattice (like
Barton did).  However, I also think that sometimes that restructuring
can be difficult to retrofit or can introduce new classes that
sometimes seem to do little more than add unnecessary bulk.  Eiffel
give a capability for safely getting around a "proper" restructuring.
The capability certainly seems interesting, whether it is good, I'm
not so sure.

|  All of them
|allow full reuse of the functionality defined with the List<T> type.

Well, they do allow *some* reuse.

|Now, my initial thought was that Graham's Eiffel code implemented (3),
|since ORDERED_LIST inherits from LIST in his code.  That's why I gave
|the implementation that I did, pointing out clearly that I considered
|this a flaw.

I agree that if LIST means what everyone usually thinks "list" means,
then having ORDERED_LIST inherit from LIST was a flaw (and would have
been detected the first time the example was run with invariant
checking added to the implementation).  However, if LIST is something
a bit less structured (more like a bag, but just called "LIST"), the
classes are logically consistent.  Maybe I shouldn't be so lenient,
but since "good" examples could easily be generated (just rename LIST
to be
UNSPECIFIED_ORDER_LISTY_THING_WITH_SUBCLASSES_THAT_COULD_SPECIFY_ORDER),
I don't think this flaw is significant.

|On re-reading the section on system-validity in the Eiffel book, I'm
|actually not quite sure what his code does (my only reference on
|Eiffel; unfortunately, Graham didn't tell us in words what he wanted
|his code to do); it seems like it is either reduces to case (4), or it
|reduces to case (3), or it requires runtime type checking, or it is
|useless (because system validity checks would never let you invoke
|method "tail" on an object of type LIST).  Does anyone care to
|explain?

See other messages.  Essentially, redefine the reader and writer to a
tail variable with refined return type and argument type and do it
with compiler-checked typesafety.

|...
||I don't recall having ever made a strictly system-level validity error
||and I'd guess the odds of misusing OrderedList tail() and its
||associated typeunsafe implementations would usually be small.  OK,
||maybe the principles aren't so strange.
|
|I don't think you can make a system-level validity error in C++
|without explicitly using an unsafe operation (*).

Right.  I have made such unsafe operations (casts!, heavens) and
didn't screw up (maybe).

|System validity
|checking in Eiffel seems to be necessary because of the possibility of
|incompatible redefinitions in subclasses (types or hiding).

Redefinition of non-virtual member functions gives exactly the same
possibilities to C++.  No wonder there are some strong suggestions, to
never redefine an inherited nonvirtual function (Item 37 in Meyer's
excellent book).  BTW, this rule was just made to be broken and
sometimes should be for the "best" design.

|...
|In any case, I think the reason why you haven't come across this
|"problem" in C++ is that, as we have seen above, there are numerous
|other ways of achieving the same kind of polymorphism and reuse that
|do not involve inheritance and the use of "like" and "clone".  You
|probably have always simply designed your C++ libraries and classes
|accordingly.

That's mostly it.  When I do use covariance, I am extra careful.

Doug


======================================================================= 76 ===
Date:    12 Sep 1994 13:21:20 GMT
From:    haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible)
Subject: Re: mprotect() support in Linux kernel?

Sven Goldt <goldt@math.tu-berlin.de> wrote:
>
>: However, it appears that mprotect() is not supported under Linux:
>
> It is implemented in newer kernels.

mprotect() still needs the following three patches to work properly.

The first one ensures that the reference count of an mmap'ed file is
decremented when adjacent vm_areas are merged (because it is incremented
when a vm_area is splitted). The second and third one provide proper
management of the vm_area_struct list.


                    Bruno Haible
                    haible@ma2s2.mathematik.uni-karlsruhe.de


diff -r -c3 linux-1.1.48/mm/mmap.c linux/mm/mmap.c
*** linux-1.1.48/mm/mmap.c	Sun Aug 14 15:40:56 1994
--- linux/mm/mmap.c	Tue Aug 23 11:11:52 1994
***************
*** 424,429 ****
--- 432,444 ----
  		 */
  		prev->vm_end = mpnt->vm_end;
  		prev->vm_next = mpnt->vm_next;
+ 		if (mpnt->vm_ops && mpnt->vm_ops->close) {
+ 			mpnt->vm_offset += mpnt->vm_end - mpnt->vm_start;
+ 			mpnt->vm_start = mpnt->vm_end;
+ 			mpnt->vm_ops->close(mpnt);
+ 		}
+ 		if (mpnt->vm_inode)
+ 			mpnt->vm_inode->i_count--;
  		kfree_s(mpnt, sizeof(*mpnt));
  		mpnt = prev;
  	}
diff -r -c3 linux-1.1.48/mm/mprotect.c linux/mm/mprotect.c
*** linux-1.1.48/mm/mprotect.c	Sun Aug 14 15:40:56 1994
--- linux/mm/mprotect.c	Sun Aug 14 02:24:34 1994
***************
*** 107,123 ****
  	unsigned long start, unsigned long end,
  	int newflags, int prot)
  {
! 	int error;
! 	unsigned long tmpflags, tmpprot;
  
! 	tmpflags = vma->vm_flags;
! 	tmpprot = vma->vm_page_prot;
  	vma->vm_flags = newflags;
  	vma->vm_page_prot = prot;
! 	error = mprotect_fixup_end(vma, end, tmpflags, tmpprot);
! 	if (!error)
! 		error = mprotect_fixup_start(vma, start, tmpflags, tmpprot);
! 	return error;
  }
  
  static int mprotect_fixup(struct vm_area_struct * vma, 
--- 111,146 ----
  	unsigned long start, unsigned long end,
  	int newflags, int prot)
  {
! 	struct vm_area_struct * left, * right;
  
! 	left = (struct vm_area_struct *) kmalloc(sizeof(struct vm_area_struct),
 GFP_KERNEL);
! 	if (!left)
! 		return -ENOMEM;
! 	right = (struct vm_area_struct *) kmalloc(sizeof(struct vm_area_struct)
, GFP_KERNEL);
! 	if (!right) {
! 		kfree(left);
! 		return -ENOMEM;
! 	}
! 	*left = *vma;
! 	*right = *vma;
! 	left->vm_end = start;
! 	vma->vm_start = start;
! 	vma->vm_end = end;
! 	right->vm_start = end;
! 	vma->vm_offset += vma->vm_start - left->vm_start;
! 	right->vm_offset += right->vm_start - left->vm_start;
  	vma->vm_flags = newflags;
  	vma->vm_page_prot = prot;
! 	if (vma->vm_inode)
! 		vma->vm_inode->i_count += 2;
! 	if (vma->vm_ops && vma->vm_ops->dup) {
! 		vma->vm_ops->dup(left);
! 		vma->vm_ops->dup(right);
! 	}
! 	insert_vm_struct(current, left);
! 	insert_vm_struct(current, right);
! 	merge_segments(current->mm->mmap);
! 	return 0;
  }
  
  static int mprotect_fixup(struct vm_area_struct * vma, 
***************
*** 155,161 ****
  
  asmlinkage int sys_mprotect(unsigned long start, size_t len, unsigned long pr
ot)
  {
! 	unsigned long end;
  	struct vm_area_struct * vma;
  
  	if (start & ~PAGE_MASK)
--- 178,184 ----
  
  asmlinkage int sys_mprotect(unsigned long start, size_t len, unsigned long pr
ot)
  {
! 	unsigned long end, tmp;
  	struct vm_area_struct * vma;
  
  	if (start & ~PAGE_MASK)
***************
*** 188,199 ****
  		if (vma->vm_end >= end)
  			return mprotect_fixup(vma, start, end, newflags);
  
! 		error = mprotect_fixup(vma, start, vma->vm_end, newflags);
  		if (error)
  			return error;
! 		start = vma->vm_end;
! 		vma = vma->vm_next;
! 		if (!vma || vma->vm_start != start)
! 			return -EFAULT;
  	}
  }
--- 211,225 ----
  		if (vma->vm_end >= end)
  			return mprotect_fixup(vma, start, end, newflags);
  
! 		tmp = vma->vm_end;
! 		error = mprotect_fixup(vma, start, tmp, newflags);
  		if (error)
  			return error;
! 		start = tmp;
! 		if (vma->vm_end <= start) {
! 			vma = vma->vm_next;
! 			if (!vma || vma->vm_start != start)
! 				return -EFAULT;
! 		}
  	}
  }



======================================================================= 77 ===
Date:    Mon, 12 Sep 1994 22:26:11 GMT
From:    charles.herrick@amd.com
Subject: Crossposting ButtHeads, keep this thread out of c.l.smalltalk (was: Re
al C++ programmers don't use casts [was Re: Static vs Dynamic Typing]

In article <DOUG.94Sep12091222@monet.ads.com> doug@monet.ads.com (Doug Morgan) 
 
writes:
> In article <TMB.94Sep10041912@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M.
  
Breuel) writes:
> |In article <DOUG.94Sep8093941@monet.ads.com> doug@monet.ads.com (Doug  
Morgan) writes:

bunch of stuff about C++ Lorena-Bobbitized mercilessly.

Kindly think to yourself, if I were a Smalltalk programmer, would I 
want to read this stuff?

Hint: no.
--
personal opinions


======================================================================= 78 ===
Date:    13 Sep 1994 03:38:50 GMT
From:    rwh@cs.cmu.edu (Robert Harper)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

I'd like to point out a fallacy that appears to pervade this
discussion: it is simply not the case that dynamic and static typing
are of equivalent expressive power.  The discussants appear to be
arguing whether one or the other catches errors earlier or more
effectively or is more efficient or whatever, losing track of the fact
that static typing is strictly more expressive than dynamic typing in
that with a decent type system you can enforce invariants statically
that are in no way checkable at run time.  For example, one cannot tell
by the bit pattern whether the value in a variable represents a "set"
or a "time of day" or a "favorite color of the author of the program". 
Nor can one check at run-time properties of, say, functions that can be
enforced by a static type discipline.

To stave off the obvious flames, it is of course obvious that the
static discipline, if it is to be decidable, must provide only
sufficient conditions to ensure that properties such as those discussed
are true, and consequently rule out cases where the properties obtain
but the proof cannot be expressed in the type system to hand.  Bear in
mind, however, that the possibility exists, at least in principle, for
bringing to bear arbitrary mechanical checking procedures for proving
that invariants hold, limited only by the willingness of the programmer
to instruct the compiler why an invariant must hold.  No such option is
open in the dynamic case.

Bob Harper


======================================================================= 79 ===
Date:    Tue, 13 Sep 1994 06:43:43 GMT
From:    rmartin@rcmcon.com (Robert Martin)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

preece@urbana.mcd.mot.com (Scott E. Preece) writes:

>n-reply-to: rmartin@rcmcon.com's message of Sat, 10 Sep 1994 21:27:26 GMT
>Xref: courier.urbana.mcd.mot.com comp.software-eng:22141 comp.object:19259 com
p.lang.eiffel:5808 comp.lang.smalltalk:14298 comp.lang.modula3:2813 comp.lang.o
bjective-c:2964


>Yes, static typing allows you to find a specific class of defects early
>in the process.  However, most dynamic type checking would find most of
>those same problems equally earely in the process. 

This is quite contrary to my experience.

>Frankly, I find the "this interface will reliably signal an error if
>called with the wrong type" promise of dynamic typing more believable than
>the "the language makes it impossible to pass the wrong type to an
>interface" promise of static typing...

I don't.


-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


======================================================================= 80 ===
Date:    13 Sep 1994 11:38:20 GMT
From:    borchert@thales.mathematik.uni-ulm.de (Andreas Borchert)
Subject: Joint Modular Languages Conference

=============================================================================
                     Joint Modular Languages Conference
                        "Modula-2, Oberon & Friends"
                          September 28th-30th, 1994
                              University of Ulm
                                 Ulm, Germany
=============================================================================


Conference Sessions   September 28th-30th, 1994:
================================================

->>Keynote: The History of Modula-2, Prof. N. Wirth, ETH Zuerich
-  Application & Education
-  Large Software Systems
-  Realtime Programming
-  Distributed Systems
-  From Modula-2 to Oberon
-  Object-oriented Development using BETA & Eiffel
-  Development Tools and Techniques
-  Implementation and Porting Projects
-  Language Design
-  Compiler Issues
-  Programming Models
-  Formal Methods and Theory


Tutorials September   26th-27th, 1994:
======================================
-  C++ Tutorial, Sean Smith, University of Southampton
-  Oberon Tutorial, Hanspeter Moessenboeck, University of Linz


**************************
Information & Registration
**************************

JMLC Conference Secretary
Verteilte Systeme, Informatik
Universitaet Ulm
Oberer Eselsberg O-27

D-89069 ULM, Germany

Telephone:  ++49 (731) 502-41 40
Telefax:    ++49 (731) 502-41 42
E-mail: vsoffice@informatik.uni-ulm.de


For accomodation in a hotel please contact the tourist information in Ulm.

Tourist Information                 Telephone: ++49 (0) 731/161-2830
Im Stadthaus                        Telefax: ++49 (0) 731/161-1641
Muensterplatz

D-89073 Ulm, Germany


You can also get some informations via ftp or WWW.

For information about Ulm:

If you have access to WWW try the URLs:
http://www.informatik.uni-ulm.de/index.eng.html
http://www.informatik.uni-ulm.de/uni-ulm/uni-lageplan.eng.html

or FTP to:
hermes.informatik.uni-ulm.de:/pub/jmlc/Way-to-Ulm.[gif,jpeg,ps]
URL: ftp://hermes.informatik.uni-ulm.de/pub/jmlc

For hotel booking:

If you have access to WWW try the URL:
http://www.informatik.uni-ulm.de/fakultaet/abteilungen/vs/jmlc/HotelBooking.ps

or FTP to:
hermes.informatik.uni-ulm.de:/pub/jmlc/HotelBooking.ps



****************
Conference Theme
****************

The decisions on programming languages, tools and environments are of
crucial importance for the success of most scientific and commercial
data processing organisations. These decisions must take into account
local tradition but must also be based on broad and thoroughly
researched perspectives of current programming languages. Modular and
object-oriented languages will typically speed-up the process of
program development, stimulate reuse of existing code and simplify
maintenance or documentation of software systems. In practice,
however, commercially viable languages differ substantially with
respect to their implementation volume, programming performance and
fields of application.

The Joint Modular Languages Conference 1994 in Ulm provides an
opportunity for data processing professionals, programmers, teachers
and researchers to become aware of alternative and more recent
developments in the field of modular and object-oriented languages.
Relevant topics will be presented from both theoretical and practical
perspectives and adequate time is allocated for discussions. We
cordially invite professional programmers from all language
communities together with Pascal, Modula-2 and Oberon programmers to
join the conference and to share our and their experiences.


***********************
Preconference Tutorials
***********************

Three tutorials will introduce software engineers from one programming
community to at least one alternative language environment (C++, and Oberon).
Each tutorial is a self contained course and discusses key concepts such as
modularity, type consistency, classes, inheritance, and dynamic binding from
a language specific point of view. The tutorials comprise 4 to 6 lecture
hours and are augmented by laboratory exercises.

We reserve the right to limit the number of participants  for each
course. All lecturers are experienced university teachers and language
implementors, guaranteeing a high level of expertise and teaching
efficiency. They will be available for in depth questions throughout
the conference. The conference secretariat will gladly send you a
detailed description of all three courses.


------------------------------------------------------------------
C++ Tutorial                  Monday, September 26, 1994 9.00 a.m.
------------------------------------------------------------------
Lecturer: Sean Smith, University of Southampton

     History and rationale of C++
     Inheritance in C++
     Polymorphism Classes in C++
     C++ and the future
     Worked examples


------------------------------------------------------------------
Oberon Tutorial              Tuesday, September 27, 1994 8.30 a.m.
------------------------------------------------------------------
Lecturer: Hanspeter Moessenboeck, University of Linz

     The Oberon language
     The Oberon environment
     Common techniques
     Oberon-2 amendments
     Object-oriented programming in Oberon-2
     Writing extensible software
     Examples, case studies
     Extensive laboratory exercises


********************
Conference Programme
********************

***************   Wednesday, September 28, 1994  *****************

------------------------------------------------------------------
09:00 - 10:15   From Modula-2 to Oberon, P. Schulthess
------------------------------------------------------------------

      Welcome Address
      
->>   Keynote: The History of Modula-2
      N. Wirth, ETH Zuerich

      Process Visualisation with Oberon System 3 and Gadgets
      E. Templ, A. Stritzinger, G. Pomberger
      
      
------------------------------------------------------------------
10:45 - 12:15   Programming Language Design, H. Moessenboeck
------------------------------------------------------------------

      Restricted Multiple Inheritance
      A.E. Nedorya, E.V. Tarasov, A.D. Hapugin

      Sequential and Parallel Exception Handling in Modula-3*:
      A Unifying Semantics Specification
      E.A. Heinz
      
      A Class Mechanism Supporting Subtype-check
      L. Xuedong, Z. Guoliang


Afternoon track 1:
------------------------------------------------------------------
13:30 - 15:00   Formal Methods and Theory, J. Farre
------------------------------------------------------------------

     Object Design with Formal Classes
     P. Andre, D. Chiorean, J.C. Royer

     A Semantic Framework for Understanding the Behavior of Modules 
     and Classes in Programming Languages
     M.H. Dodani, K.S. Gan

     Teaching a Systematic Method of Program Development
     C. Pronk, P.G. Kluit


------------------------------------------------------------------
15:30 - 17:00   Compiler Issues, A. Borchert
------------------------------------------------------------------

     Dynamic Polymorphism: An Ada-Based Approach
     J. Shen, G. Cormack, D. Duggan

     Compiler Optimizations Should Pay for Themselves
     M. Franz

     Building an Optimizing Compiler for Oberon:
     Implications on Programming Language Design
     M.M. Brandis


Afternoon track 2:
------------------------------------------------------------------
13:30 - 15:00   Development Tools and Techniques, A. Corradi
------------------------------------------------------------------

     Post Mortem Debugger for Oberon
     M. Hof

     Using Oberon to Design a Hierachy of Extensible Device Drivers
     P.J. Muller
     
     STUDIO: A Modular, Compiled, Actor-Oriented Language, Based upon
     a Multitask Runtime System
     A. Hadjadji, L. Frecon
     
------------------------------------------------------------------
15:30 - 17:00   Distributed Systems, P. Moylan
------------------------------------------------------------------

     Object-Oriented Distributed Programming in the Oberon-PVM Environment
     E. Bugnion, M. Gitsels, B.A. Sanders
     
     Design of a Distributed Oberon System
     S. Traub
     
     Adding Parallel and Persistent Sets to Modula-3
     L. Boeszoermenyi

------------------------------------------------------------------
17:05 - 18:00 Modula-2 Standardisation Panel, H. Klaeren
------------------------------------------------------------------
     M. Woodman (Convenor WG 13) and Panel Members

------------------------------------------------------------------
19:00 - 20:30   Welcome Reception
------------------------------------------------------------------



***************   Thursday, September 29, 1994   *****************

------------------------------------------------------------------
09:00 - 10:15   O-O Development using BETA & Eiffel, J. Gutknecht
------------------------------------------------------------------

     Part Objects in the BETA Programming Language
     B. Moller-Pedersen
     
     Model-View-Controller Classes in Eiffel
     M. Skipper

------------------------------------------------------------------
10:45 - 12:15   Programming Models, G. Pomberger
------------------------------------------------------------------

     An Object-Oriented Functional Logic Language for the Oberon System
     P. Dykstra
     
     Modular Inheritance of Objects through Mixin-Methods
     C. Lucas, P. Steyaert

     Combining Different Implementations of Types in a Program
     X. Franch

------------------------------------------------------------------
13:30 - 15:00   Application and Education, F. Schweiggert
------------------------------------------------------------------

     Modelling and Developing DSP Algorithms in C++
     J. Middleton, M. Al-Akaidi, P. Urwin 

     An Oberon-Based Implementation Tool 
     J. Lampe

     Making the Transition from ADTs to Objects in Undergraduate
     Software Engineering: A CASE-Based Approach
     A.J. Peralta

------------------------------------------------------------------
15:30 - 17:00   Realtime Programming, J. Cooling
------------------------------------------------------------------

     A Distributed Real-Time Architecture in Oberon-2
     B. Kirk, L. Nigro
     
     Writing Real-Time Applications in Modula-2
     P.J. Moylan

     Timing as a Programming-In-The-Large Issue
     L. Nigro, F. Tisato

------------------------------------------------------------------
17:05 - 18:00   Oberon Standardisation Panel, B. Kirk
------------------------------------------------------------------

------------------------------------------------------------------
20:00 - 23:00   Conference Banquet
------------------------------------------------------------------



***************    Friday, September 30, 1994    *****************

------------------------------------------------------------------
09:00 - 10:15   Oberon and beyond, M. Al-Akaidi
------------------------------------------------------------------

     Oberon -- Perspectives of Evolution
     J. Gutknecht

     Towards End-User Objects: The Gadgets User Interface System 
     J.L. Marais 

------------------------------------------------------------------
10:45 - 12:15   Large Software Systems, L. Nigro 
------------------------------------------------------------------

     A New Approach to Modularization of Large Object-Oriented
     Systems
     A. Belkhelladi, B. Lazzerini, F. Marcelloni
     
     How to Structure Parallel Applications: Nested Local Aggregates
     A. Corradi, L. Leonardi, F. Zambonelli
     
     Capability Based Protection in a Persistent Object-Based
     Programming Language
     M. Hollins, J. Rosenberg, M. Hitchens
     
------------------------------------------------------------------
13:30 - 15:00   Implementation and Porting Projects, St. Collins 
------------------------------------------------------------------

     Native Oberon on the PC Compatible (ISA) Platform
     F. Arickx, J. Broeckhove, T. Van den Eede, L. Vinck
     
     Alpha AXP/Open VMS (Modula|Oberon)-2 Compiler Project
     G. Dotzel
     
     Bringing the Oberon Language to the Macintosh 
     J. Gesswein, R. Ondrus, O. Schirpf



******************
Product Exhibition
******************

Tools for application development, software systems and books will be
demonstrated during the conference.


*******************
Companion Programme
*******************

Ulm is a city with a rich history and many resources. First mentioned
in 854, it has attractions such as the gothic Cathedral with the
world's highest spire, the historic Fishermen's Quarter, the
picturesque Town Hall, and the Danube river where it is still blue.
Other facets of Ulm include the giant federal fortress built around
1850, truck and bus factories, industrial research centers, and the
University with a world famous medical faculty. You will be able to
discover the treasures of Ulm on a guided tour. We will show you the
place where the flight of Albrecht Berblinger, one of the first
aviators, failed in 1811. Another tour will take you to a romantic
little town and the natural beauties surrounding Ulm, above all the
Blautopf, end point and climax of a system of underground rivers,
hundreds of kilometers long. Another highlight will be the boat tour
on the Danube river with striking views of the medieval city.

We will try to share with you the beauty and culture of Ulm and make
your time in Ulm worth remembering.

------------------------------------------------------------------
Wednesday, September 28, 1994
------------------------------------------------------------------

10:00 - 12:30   Tour of Ulm -- historical city and Gothic cathedral
14:30 - 16:00   Visit of baroque style library hall and Wiblingen
                Monastery

------------------------------------------------------------------
Thursday, September 29, 1994
------------------------------------------------------------------

09:00 - 15:00   Daytour to the Blautopf spring, prehistoric museum
                and sites

------------------------------------------------------------------
Friday, September 30, 1994
------------------------------------------------------------------

10:00 - 12:00   Boat tour on the Danube
14:00 - 16:00   Visiting the modern art sculptures on campus,
                tour of the science park and research institutes


*******************
Programme Committee
*******************

Andreas Borchert       University of Ulm, Germany
Antonio Corradi        University of Bologna, Italy
Brian Kirk             Robinson Associates, UK
Franz Schweiggert      University of Ulm, Germany
Gregor Snelting        University of Braunschweig, Germany 
Guenther Dotzel        ModulaWare, Germany
Gustav Pomberger       University of Linz, Austria
Hanspeter Moessenboeck University of Linz, Austria
Herbert Klaeren        University of Tuebingen, Germany
Jacques Farre          University of Nice, France
Jim Cooling            University of Loughborough, UK
John Gough             Queensland University of Technology, Australia
Juerg Gutknecht        ETH Zuerich, Switzerland 
Juergen Uhl            IBM, Germany
Libero Nigro           University of Calabria, Italy 
Marjan Spegel          Stefan Institute, Slovenia
Marwan M. Al-Akaidi    De Montfort University, UK
Peter Schulthess       University of Ulm, Germany
Peter Moylan           University of Newcastle, Australia
Randy Bush             PSG, USA
Steven Collins         Real Time Associates, UK
Wolfgang Hanika        Daimler Benz, Germany
Wolfram Lippe          University of Muenster, Germany


********************
Organizing Committee
********************

Peter Schulthess       Chairman, University of Ulm, Germany 
Alfred Lupper          OC Director, University of Ulm, Germany
Franz Schweiggert      University of Ulm, Germany 
Marwan Al-Akaidi       De Montfort University, UK 
Andreas Borchert       University of Ulm, Germany
Jim Cooling            University of Loughboruough, UK


********************
In Co-operation with
********************

Gesellschaft fuer Informatik e.V., Fachgruppe 2.1.3, 2.1.4
Schweizer Informatiker Gesellschaft, Fachgruppe Oberon
British Computer Society, Modular Languages SIG
Daimler Benz AG, Forschungszentrum Ulm
NC-Gesellschaft fuer neue Technologien
Forschungsinstitut fuer angewandte Wissensverarbeitung, Ulm
IBM Deutschland, Entwicklungs GmbH


----------------------------------- Cut here ---------------------------------

******************************************************************************
                                Registration Form
******************************************************************************

Yes, I want to join the Joint Modular Languages Conference in Ulm.


Name:

Name on Badge:

Affiliation:

Mailing Address:

Postal Code:

City:

Country:

Daytime Phone Number:

Fax Number:

E-mail Address:


[ ] Do not include my mailing address on meeting attendee lists.


Please mark [X] the sessions you want to attend and calculate the
total amount.

==================================================================
| Tutorials   |    Regular    |   Authors and   |    Students**  |
|             |               |   SIG Members*  |                |
------------------------------------------------------------------
| C++         |  [ ]  DM 220  |  [ ]  DM 220    |  [ ]  DM 220   |
------------------------------------------------------------------
| Oberon      |  [ ]  DM 220  |  [ ]  DM 220    |  [ ]  DM 220   |
==================================================================
| Conference  |  [ ]  DM 360  |  [ ]  DM 320    |  [ ]  DM  50   |
==================================================================
| Banquet     |  [ ]  DM  60  |  [ ]  DM  60    |  [ ]  DM  60   |
==================================================================
| Total       |       DM      |       DM        |       DM       |
==================================================================


*)   Members of involved GI, SI, and BCS SIGs should indicate their
     affiliation number.
   
**)  Full time students are asked to present their original student
     card with picture at the conference registration desk. Student
     price does not include conference proceedings.

==================================================================
| Companion Programme          |           all persons           |
==================================================================
| Wednesday                    |          [ ]  DM  20            |
------------------------------------------------------------------
| Thursday                     |          [ ]  DM  40            |
------------------------------------------------------------------
| Friday                       |          [ ]  DM  20            |
==================================================================
| Total                        |               DM                |
==================================================================


------------------------------------------------------------------
| Total Conference, Tutorials, |               DM                | 
|       Banquet                |                                 |
------------------------------------------------------------------
| Total Companion Programme    |               DM                |
==================================================================
| Total Amount                 |               DM                |
==================================================================


Method of Payment:

Payable to: JMLC Conference 1994, University of Ulm

[ ] Transfer to: ULMV DE 66002 Illertisser Bank
    Sorting Code of Bank (BLZ): 731 915 00
    Account No.:                702 505 005

[ ] Cheque enclosed

[ ] Visa                         [ ] Diners Club    
[ ] American Express             [ ] MasterCard/EuroCard

Card Number:                     Expiration Date:


Cardholder Name                  Signature:


----------------------------------- Cut here ---------------------------------


Please send registration via surface mail to

    JMLC Conference Secretary
    Verteilte Systeme, Informatik
    Universitaet Ulm
    Oberer Eselsberg O-27

    D-89069 ULM, Germany

or by fax to:
    
    ++49 (731) 502-41 42


---------------------------------------------------------
Alfred Lupper, Computer Science Dept.,           -------
University of Ulm, D-89069 Ulm, Germany           - o -
Phone: ++49 731 502 4139 FAX: ++49 731 502 4142    ---
E-Mail: lupper@informatik.uni-ulm.de                -
----------------------------------------------------
Note: Visit the Joint Modular Languages Conference
      Date:     28th-30th September 94
      Location: University of Ulm, Germany
----------------------------------------------------


-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-89069 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de


======================================================================= 81 ===
Date:    13 Sep 1994 17:56:10 GMT
From:    rlk@rational.com (Bob Kitzberger)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

Scott E. Preece (preece@urbana.mcd.mot.com) wrote:
: Yes, static typing allows you to find a specific class of defects early
: in the process.  However, most dynamic type checking would find most of
: those same problems equally earely in the process.  In my experience,
: the enormous bulk of the type errors I hit are trivia - typos and
: mistakes in changing a variable from one type to another in some places
: but not in others.  Virtually all of them would have been caught by
: run-time checks the first time I tried to run the program (the
: equivalent of their being caught at the first compile).

So, how about those bugs that static typing would have caught yet
were not exercised at run time, and therefore not caught?  Are
they lying in wait for 100% coverage testing?

	.Bob.

--
Bob Kitzberger				Rational Software Corporation
     "Though the boys throw stones at frogs in sport, yet the frogs 
       do not die in sport but in earnest."      - Plutarch


======================================================================= 82 ===
Date:    13 Sep 1994 19:50:49 GMT
From:    ram+@cs.cmu.edu (Rob MacLachlan)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <3536sa$5se@cantaloupe.srv.cs.cmu.edu>,
Robert Harper <rwh@cs.cmu.edu> wrote:
>I'd like to point out a fallacy that appears to pervade this
>discussion: it is simply not the case that dynamic and static typing
>are of equivalent expressive power.

Actually, the falsity of this equivalence seems to be the only thing that
everyone agrees on.

>losing track of the fact that static typing is strictly more expressive than
>dynamic typing [...] can enforce invariants statically that are in no way
>checkable at run time.

This may be true, but it is also true (as you obliquely say later on) that
dynamic type systems can signal the violation of invariants that are in no way
checkable at compile time, for example in Common Lisp:
    (the nil (do-I-halt?))

This expression asserts that this call to the do-I-halt? function never returns
(NIL is Common Lisp's bottom type.)  It is easy to construct type systems for
which static checking is not computable.  The question is what advantages (if
any) derive from the use of "dynamic" type systems which guarantee to detect
errors during execution.

I think that a great deal of the disagreement over type systems stems from
differing meanings of the term "type".  I get the impression that for some
people "dynamic type" is an oxymoron, since for them the whole point of types
is to enable static analysis.

>For example, one cannot tell by the bit pattern whether the value in a
>variable represents a "set" or a "time of day" or a "favorite color of the
>author of the program".

This is the reason that dynamic type systems always add extra bits to each
object.  This results in a potential efficiency penalty, but no loss of power.

>[...] the static discipline, if it is to be decidable, must provide only
>sufficient conditions [... cannot] rule out cases where the properties obtain
>but the proof cannot be expressed in the type system to hand. [...]  however,
>that the possibility exists, at least in principle, for bringing to bear
>arbitrary mechanical checking procedures for proving that invariants hold,
>limited only by the willingness of the programmer to instruct the compiler why
>an invariant must hold.  No such option is open in the dynamic case.

This touches on my favorite fallacy in this discussion, which is that dynamic
and static typing are mutually exclusive.  Static systems can be augmented with
dynamic rules without giving up their ability to prove that statically typed
program portions contain no static type errors.  

I very much approve of the idea of the language implementation and programmer
engaging in a dialog about the type-correctness of the program, but I don't
believe that programmers must be forced to prove type-correctness before
executing the first line of code.

This is not an argument from "principle": real widely used dynamic
language implementations such CMU Common Lisp do static type checking.  The key
difference between the normal "static checking" and the approach taken in CMU
CL is that:
 1] Compile-time type warnings are not fatal; the program can still be executed
    until the erroneous portion is reached, and
 2] Compile-time type warnings are only given then the compiler can prove that
    a particular portion of the program can *never* be executed without a type
    error.

In the "static typing" approach, any compile-time type error is fatal, and
type errors are signalled whenever the compiler can't prove that type errors
will *always* be avoided.

Obviously, the "static" always-safe rule can make stronger runtime guarantees
than the no-proven-error rule, but the pragmatic concerns of other contributors
to this thread are significantly helped by static checking for provable errors.
For example, if interfaces are typed as strongly as possible, then
static interface-mismatch errors will generally be caught.

  Rob MacLachlan


======================================================================= 83 ===
Date:    13 Sep 1994 20:48:35 GMT
From:    connolly@ulua.hal.com (Dan Connolly)
Subject: efficient M3 runtime for LINUX: RTHeapDepC.c?


I'm working on enhancing the modula-3 port of LINUX to synchronize the
garbage collector heap with the virtual memory subsystem.

I started with linux 1.0.9 and the M3 binary distribution for LINUX
by Michel Dagenais <dagenais@vlsi.polymtl.ca> at:

	ftp://ftp.vlsi.polymtl.ca/pub/m3/linux/

I upgraded from linux 1.0.9 to 1.1.18 without incident -- for
unrelated reasons.

But even simple M3 programs like 'plaid' would stop to garbage
collect. I asked if this had something to do with the fact that VM =
FALSE in LINUX/RTHeapDep.i3, and Bill Kaslow said yes, that's exactly
the problem. He said that nobody has yet done the work to get the
memory protection stuff to work with the garbage collector under LINUX.

So I'm going to give it a try.

The first obstacle was that mprotect() is not included in the 1.1.18
version of the linux kernel. So I have upgraded to 1.1.45. The patches
supplied by Bruno Haible <haible@ma2s2.mathematik.uni-karlsruhe.de>
in <351kkg$g5n@nz12.rz.uni-karlsruhe.de>, when applied to the 1.1.45
source, would not build. So I assume that they are patches to an earlier
version of the kernel, and that the issue has been resolved by the 1.1.45
kernel.

	*** How can I test that mprotect() actually works? ***

I doubt that little 20-line C test programs will test it sufficiently.
Anyway...

Now I'm deep in the bowels of libm3/src/runtime/LINUX, trying to make
it look more like libm3/src/runtime/SPARC and/or
libm3/src/runtime/DS3100.

I thought the tricky part was going to be in RTHeapDep.m3, but I discovered
a whole new ball of wax in RTHeapDepC.c . The comments there
[thank god for the comments in the M3 code. How do the linux guys
get by without comments? Some form of telepathy that I'm not aware of?]
say:


/* This file implements wrappers for almost all LINUX 1.1.45 system calls
   that take pointers as arguments.  These wrappers allow the system
   calls to take arguments that might point to the traced heap, which
   may be VM-protected in the LINUX implementation of the collector.
   The wrappers read and write the referents of all pointers about to
   passed to the system call, which ensures that the pages are not
   protected when the call is made.

   Each wrapper is a critical section, with RTou__inCritical non-zero,
   so that another thread cannot cause the pages to become reprotected
   before the system call is performed.

   A few system calls are not handled here, or are handled only
   partially.  This restricts the system calls that can be made from
   Modula-3, or from libraries that are passed pointers into the
   Modula-3 traced heap.  These system calls are:
	....
*/


The SPARC version of RTHeapDepC.c yields zillions of compile errors
on LINUX. gcc is picky, and you have to get this stuff right, I guess.

How did you come up with the list of syscalls that need wrappers?
How did you distinguish them from the ones like wait, wait3, ...?
   (Some calls in Section 2, including wait, wait3, sigvec,
   sigprocmask, and sigsuspend, are already wrappers for other system
   calls; it is not necessary to reimplement them here.)


Anyway... I suppose I can plot through most of this eventually, but
it looks tedous and error-prone.

I'm making slow progress, but any help would be appreciated.

Dan
-- 
Daniel W. Connolly        "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project   (512) 834-9962 x5010
<connolly@hal.com>                   http://www.hal.com/%7Econnolly/index.html


======================================================================= 84 ===
Date:    14 Sep 94 13:07:54
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: Pickles and Libraries


Amer brings up a good point that it would be nice if one could pickle
references to all reasonable data types, especially ones in the
library.

I think there is a problem with branding in presence of generics.
Specifically, how do you brand the generic type Table.Default?  Two
fixes are needed:

- change the language to support not only literal brands but constant
  brands. This was mentioned on this forum a while ago and happens to
  be the it is the way the SRC compiler works.

- get a constant TEXT representation for the name of the type of the
  instantiation of the generic, so that you can brand it in the
  generated code. In general, you want to parameterize the brand by
  all the parameters of the generic module.

One workaround that you can do right now is to expect each parameter
to the generic modules to include CONST name: TEXT, so that the
generic module can use this name to generate the tag for the
instantiated type. Enforcing this for Table.ig means adding extra
requirements on all parameters of Table.

By the way, at least some non-generic parts of libm3 do use explicit
brands. See for example, TextF.m3. 

For now, you can register picklers to write out and read in the table
correctly. It is a pain, but it should work. 

-- Farshad

--
Farshad Nayeri
nayeri@gte.com


======================================================================= 85 ===
Date:    14 Sep 1994 14:42:25 GMT
From:    diwan@cs.umass.edu (Amer Diwan)
Subject: Pickles and Libraries

I have found Pickles to be a great tool.  And I think the libraries
distributed with SRC Modula-3 3.x are also great.  But I do have one
complaint.  Pickles may not work correctly if implicitly branded types are
being pickled.  The exported data structures in the libraries (e.g., sorted
tables) are revealed with implicit brands.  Thus, if my "graph" has references
to library data structures, then I may not be able to pickle the graph.  Is
there any reason against doing explicitly branding in the libraries?  Perhaps
a prefix should be reserved at least for the standard libraries so that their
brands don't conflict with user defined types.
    Amer
--

------------------------------------------------------------------------------
Amer Diwan                                    Department of Computer Science
Object Systems Lab                            University of Massachusetts   
diwan@cs.umass.edu                            Amherst, MA 01003
(413) 545-0256


======================================================================= 86 ===
Date:    Thu, 15 Sep 1994 00:45:36 GMT
From:    kers@hplb.hpl.hp.com (Chris Dollin)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

rwh@cs.cmu.edu (Robert Harper) writes:

   Adding extra tag bits does not preclude "spoofing", ie creation of an
   object that appears to be a value of an abstract type, but for which
   the key invariants fail to hold.  eg, marking 23 as a SET.  You can
   check that the value is tagged SET but it doesn't mean anything.

A rather weak argument; that an implementation of Set in a statically
typed language passes all the static type checks doesn't mean that it
actually implements Set (eg I might simply have forgotten to eliminate
duplicates). If there's a difference here it needs amplifying.

[Also, the dynamically typed languages I have used provide no operations
to let users mark objects with types as they please, eg, marking 23 as
a Set. (Well, actually they *do*, with flashing red warnings that This
Is Dangerous And Can Break Your Code. I'd need convincing that statically
typed languages don't also have such loopholes provided.)]
--

Regards,    | ``"I can't suit myself," said Weinbaum, a little petulantly.
Kers.       | "I work for the Government".'' - Blish, "The Quincunx of Time".


======================================================================= 87 ===
Date:    14 Sep 1994 15:17:34 GMT
From:    werner@cs.sun.ac.za (Werner Fouche )
Subject: M3 for embedded systems programming!

Has anyone concidered the pros and cons of using M3 for programming
embedded systems? Better still, does anybody have experience in programming
embedded systems in M3. The only downside I can think of is the fairly
large run-time (garbage collecter, thread manager, exception handling code)
that must be supported. I have written a micro-kernel in Modula-2 and
found its non-existent run-time environment to be a blessing. Using Modula-3
for the same purpose would of course require that one get its run-time
environment to work on the bare hardware, before you can start writing
kernel code! How much of an effort would that be? Does embedded systems
not require a stripped-down version of the Modula-3 run-time, say
a simple garbage collecter (supporting only reference counting), no
support for threads (a kernel usually creates its own abstraction
for threads), exception handling will be useful so I think one should leave
that in. 

What do YOU think??

Werner


======================================================================= 88 ===
Date:    14 Sep 1994 14:28:12 GMT
From:    rwh@cs.cmu.edu (Robert Harper)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

> This may be true, but it is also true (as you obliquely say later on) that
> dynamic type systems can signal the violation of invariants that are in no > 
way checkable at compile time, for example in Common Lisp:
>
>    (the nil (do-I-halt?))
>

This does not constitute a _check_ for halting (obviously) because it
does no always return.

Adding extra tag bits does not preclude "spoofing", ie creation of an
object that appears to be a value of an abstract type, but for which
the key invariants fail to hold.  eg, marking 23 as a SET.  You can
check that the value is tagged SET but it doesn't mean anything.

Static type systems cannot be "augmented with dynamic checks" because
you cannot check the properties of interest dynamically.

Moreover, so-called dynamic typing compromises run-time representations
and precludes important optimizations that cannot be performed unless
you have a global program analyzer.  (Hence no separate compilation.) 
And, of course, the analyzer is a form of static type system.


Bob Harper


======================================================================= 89 ===
Date:    14 Sep 1994 16:39:28 GMT
From:    klon@wildsau.idv.uni-linz.ac.at (Oliver Hable)
Subject: GRAPHICAL LIBRARY FOR MODULA

ALL WHO WANNA HAVE A GRAPHICAL LIBRARY FOR TS MODULA 2.x / 3.x 
SHOULD TRY XVGA_V1
ITS ON GARBO.UWASA.FI OR MAIL TO:
    KLON@WILDSAU.IDV.UNI-LINZ.AC.AT



======================================================================= 90 ===
Date:    14 Sep 1994 20:12:29 GMT
From:    ram+@cs.cmu.edu (Rob MacLachlan)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <35719s$7tv@cantaloupe.srv.cs.cmu.edu>,
Robert Harper <rwh@cs.cmu.edu> wrote:

>>    (the nil (do-I-halt?))
>
>This does not constitute a _check_ for halting (obviously) because it
>does no always return.

Well, if "checking" by your definition only applies to decidable problems,
then I can see how you can argue that by definition static type checking is
the only possibility.  Language implementors often refer to "array bounds
checks" and other automatic run-time assertions as "checks".

>Adding extra tag bits does not preclude "spoofing", [...] eg, marking 23 as a
>SET.  You can check that the value is tagged SET but it doesn't mean
>anything.

As others have noted, this is simply not true.  In type-safe dynamic languages
such as Lisp and Smalltalk, the type tags are meta-information which can be
examined but never arbitrarily modified.

>Static type systems cannot be "augmented with dynamic checks" because
>you cannot check the properties of interest dynamically.

I don't deny that there may be non-local "properties of interest" which can't
be checked dynamically.  I claim that neither dynamic nor static typing is
formally more powerful than the other.  Which is "better" rests on real-world
considerations such as human factors, development processes and market demand.
In some situations, a combination of the two may be "best".

>Moreover, SO-CALLED DYNAMIC TYPING[caps RAM] compromises run-time
>representations 

I gather you are in the camp who considers "dynamic typing" an oxymoron.  You
are correct that the size, complexity and restrictive invariants of run-time
representations cause real efficiency problems in completely dynamically typed
languages (such as Lisp.)  A major part of this thread discusses hybrid
languages such as Objective-C where dynamic typing doesn't affect crucial
primitives such as arithmetic.

>and precludes important optimizations that cannot be performed unless
>you have a global program analyzer.  (Hence no separate compilation.) 

I'm guessing that you are referring to not being able to choose good
representations for values based on their types.  But this ignores three
crucial concepts which have been exploited in real dynamic language
implementations:
 1] Dynamic languages such as Common Lisp have type declarations which allow
    program fragments to be statically typed.
 2] Statistical observations about types can be nearly as good as guarantees
    about types.  For example, the strictly dynamic language Self uses
    heuristics and profiling information to pick off the probable cases and
    generate good code for them.
 3] Separate compilation is a very fuzzy concept primarily defined by the
    historical interface to file-based linkers.  Lisp, Smalltalk, Self, and
    other fully dynamic languages don't use conventional linkers.  Because of
    this, these languages do a much better job of achieving the primary goal
    of separate compilation, namely quick recompilation of incremental
    changes.

>And, of course, the analyzer is a form of static type system.

Yes, that's pretty obvious.  That's why I as a dynamic language implementor am
interested in static type systems.  The difference between using a static type
system and having a "static language" is that in a static language programs
can't be run until they have been written in a way which allows the compiler
to prove type-correctness.  

During early and ill-defined stages of development, many programmers have
found dynamic languages very useful because they don't force the programmer to
worry about rare boundary conditions.  Dynamic languages usually allow
programs to be run when they contain references to procedures that haven't
even been written yet, allowing the functional backbone of a program to be
tested and refined without filling in peripheral details.

  Rob MacLachlan


======================================================================= 91 ===
Date:    15 Sep 94 07:35:14
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Threads and heavyweight forks


I suspect it is the alarm. I think you have two choices:

1. Disable alarms by hand.
2. Use the Process interface from the OS package of Libm3, which takes
   care of everything for you, I think.  This would also make your
   program more portable, but it would mean taking the plunge and
   upgrading to 3.x.

Here is a message that Bill Kalsow sent a summer student of ours when
he was getting a similar problem with Unix.System (Thanks Bill!). The
code may be a little stale to work with version 2.11 but you get the
idea. I believe this is a subset of what os/POSIX/PosixProcess.m3
does, so you may want to look at the Modula-3 3.x archives or the
Interface Police document for more information.  (Michel, can we add
this question to the FAQ?)

Incidently, how is it going with using Motif 1.2 with Modula-3? Have
you converted the .h files? Just wondering...

-- Farshad

--- cut here ----

From: kalsow@src.dec.com
To: s9205@gte.com (Rohit Gupta)
Cc: m3-request@Pa.dec.com, rgupta@gte.com, fn00@gte.com, kalsow@Pa.dec.com
Subject: Re: System commands from within Modula-3 programs 
Date: Thu, 16 Jul 92 09:51:12 -0700

When your first thread is forked, the thread runtime starts the
virtual timer signal to trigger thread preemption.  Trestle forks
threads so the timer is started.  Cstdlib.system does a Unix fork of
your shell.  That new shell inherits the active virtual timer,
but is unprepared to handle it.

The fix is to disable the virtual timer before calling Cstdlib.system
and then re-enable it when it returns.  Note that your trestle
application will be unresponsive during the time that the timer
(and hence thread preemption) is disabled.

Here's some prototype code:

    (* Disable the timer BEFORE forking. *)
    VAR nit := Utime.struct_itimerval {
                   it_interval := Utime.struct_timeval {0, 0},
                   it_value    := Utime.struct_timeval {0, 0}}; 
    BEGIN
      IF Utime.setitimer (Utime.ITIMER_VIRTUAL, nit, oit) = -1 THEN
        Gripe (-1, "Couldn't disable virtual timer.");
      END; 
    END;

    TRY

      ...... call Cstdlib.system ....

    FINALLY
      VAR nit: Utime.struct_itimerval; BEGIN
        IF Utime.setitimer (Utime.ITIMER_VIRTUAL, oit, nit) # 0 THEN
          Gripe (-1, "Couldn't re-enable virtual timer."); END; END;
    END

 - Bill Kalsow

--
Farshad Nayeri
nayeri@gte.com


======================================================================= 92 ===
Date:    Wed, 14 Sep 94 18:46:31 PDT
From:    frode@toaster.SFSU.EDU (Frode Odegard)
Subject: Re: M3 for embedded systems programming!

I am trying to get a client in Europe to consider Modula-3 for embedded
systems.  Their main problem is actually the lack of commercial support
for Modula-3; I'm trying to do something about this, but it's a catch-22:
they won't be entierly comfortable unlesss other people are also paying us
to do a commercially supported system, and nobody wants to be first. :-)
[Currently the client does all their sw development in Modula-2.]

What processors are you interested in?

Frode Odegard

Odegard Labs, Inc.
(usually frode@odegard.com)



======================================================================= 93 ===
Date:    Wed, 14 Sep 1994 22:00:59 GMT
From:    george@bcstec.ca.boeing.com (Harry G. George)
Subject: Threads and heavyweight forks



I am stuck on a thread problem. This application
works when I do not use threads, but with threads
I get (apparently) a spurious timer alarm.  

---background---
I am running Modula-3 2.11 on sun0s 4.1.3.  I have
an X11R5/Motif 1.2 application in which I run two threads:
  Xthread does X stuff
  GAthread runs a genetic algorithm

At one point, Xthread is waiting for a Signal from
GAthread.  In GAthread, I am trying to kick off another 
application (which will eventually talk to my app
via an EditRes-like protocol).  I try to start the app
using a normal (heavyweight) Unix.fork and
Unix.execv.  The "other" app starts to run for a while,
and then dies.  The precise timing seems random.  By
doing a Unix.system("trace otherapp"), I found that the
last line was 
  recfrom(3, sh: 883 Virtual time alarm

[NOTICE: no closing paren or = <result>]
Then I get kicked back to the parent process.

I am guessing that this alarm is an artefact of the
thread scheduler still running in the parent process.
I would like to clean it up in the child process before
doing the exec (just as one closes file descriptors).
I don't see how.

---questions---
1. Anyone already doing this (doing a process fork
from inside a thread)? From an X app, to run another X app?

2. Is the alarm the culprit?

3. Is there a way to clean up the alarm so my
"other app" can proceed normally?

4. Any other hints???
-------------
Thanks in advance,


-- 
Disclaimer:  Any opinions expressed herein are my own and
             not those of The Boeing Company.
Contact:     Harry George, BCAG Advanced Software Technology  
Phone:       (206) 237-6915  Org: 6-6541  M-S: 6H-WT


======================================================================= 94 ===
Date:    14 Sep 94 23:24:40
From:    reddy@cs.uiuc.edu (Uday S. Reddy)
Subject: Final CFP: State in Programming Languages


                         Call for Papers

	        The Second ACM SIGPLAN Workshop on 
	       STATE in Programming Languages (SIPL)

                            Jan 22, 1995
                           San Francisco
                  Held in conjunction with POPL '95

Programming languages have been state-based since their inception.
After a period of relative unpopularity, when research focused on
declarative languages, interest in the treatment of state has been
renewed.  Research is increasingly devoted to finding a symbiotic
relationship between the semantic foundations of declarative languages
and the pragmatic handling of state in more conventional languages.
This workshop brings together researchers from various areas,
interested in the common issues of state manipulation in high-level
programming languages.

The first workshop in this series (SIPL '93) was held in Copenhagen in
conjunction with FPCA '93.  The proceedings are available as a Yale
technical report YALEU/DCS/RR-968.  A special issue of the Journal of
Lisp and Symbolic Computation is being published as a follow-up to 
SIPL '93. 

Submissions are invited for the second workshop to be held in
conjunction with POPL '95 in San Francisco.

The workshop addresses the fundamental issues of expressing,
manipulating, and reasoning about state in high-level programming
languages.  The range of topics includes operational and denotational
models of state, assignment and references, semantics of object-
oriented programming, calculi of state and methods to reason about
state.  Novel methods for expressing and controlling state-
manipulation such as linear type systems, effect systems, and monads
are also of interest.  Formal presentations of results, research in
progress, tutorials, and topical discussions are among the possible
venues for interaction.

Program Committee:

  Stephen Brookes, Carnegie-Mellon University
  Kim Bruce, Williams College
  John Launchbury, Glasgow University and Oregon Graduate Institute
  Ian Mason, Stanford University
  Peter O'Hearn, Syracuse University
  Andrew Pitts, Cambridge University
  Uday Reddy, University of Illinois (Chair)
  Mads Tofte, University of Copenhagen

POPL General Chair: 
  Ron Cytron, Washington University

Submission:

We solicit submissions on original research not submitted or published
elsewhere.  Authors should submit 8 copies of a detailed summary not
to exceed 5000 words (approximately 10 pages) to the program chair by
Sep 30, 1994.  The cover page should include a return postal address
and an electronic mail address (if possible).  Please follow the same
guidelines as for writing summaries for the POPL conference.  These
are available by anonymous FTP from directories
	ftp.cs.cmu.edu:/user/petel/popl95
and
	cs.uiuc.edu:/pub/reddy/sipl	
This information may also be accessed via Mosaic/WWW at
	http://vesuvius.cs.uiuc.edu:8080/sipl/index.html

Authors will be notified of acceptance of their paper by Nov 15, 1994.
Final versions of accepted papers are due on Dec 22, 1995.  Accepted
papers will appear in a technical report to be distributed at the
workshop.

Correspondence should be sent to:

	Prof. Uday Reddy
	SIPL '95
	Department of Computer Science
	University of Illinois 
	1304 W. Springfield Avenue
	Urbana, IL 61801
	U.S.A.

E-mail: sipl@cs.uiuc.edu



--
Uday Reddy
Department of Computer Science
University of Illinois
1304 West Springfield Avenue
Urbana, IL 61801.
tel: (217) 333-3412
fax: (217) 333-3501
email: reddy@cs.uiuc.edu


======================================================================= 95 ===
Date:    15 Sep 1994 15:42:10 GMT
From:    adiwan@cs.cmu.edu (Amer Diwan)
Subject: M3build and recompilation

I have  4 modules such that they are linearly related such that each
module has a concrete revelation for a type that is a subtype of a
type in the previous module.
           M1.T <: M2.T <: M3.T <: M4.T

The problem is that when I change one of the modules, m3build
recompiles the other modules as well and says "new opaque info: recompiling".
This is just a performance consideration and is thus inacceptable in the quick
modify-compile-test cycle that I am operating under.  Is there a way
to disable this recompilation?


======================================================================= 96 ===
Date:    16 Sep 1994 14:59:24 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: M3build and recompilation

In article <359q0i$2dv@cantaloupe.srv.cs.cmu.edu>, adiwan@cs.cmu.edu (Amer Diwa
n) writes:
> The problem is that when I change one of the modules, m3build
> recompiles the other modules as well and says "new opaque info: recompiling".
> This is just a performance consideration and is thus inacceptable in the quic
k
> modify-compile-test cycle that I am operating under.  Is there a way
> to disable this recompilation?

Yes, add

   m3_option ("-once")

to your m3makefile.

  - Bill Kalsow



======================================================================= 97 ===
Date:    Fri, 16 Sep 1994 20:48:40 GMT
From:    ckingsto@undergrad.math.uwaterloo.ca (Craig Andrew Kingston)
Subject: Re: SOLICITATION: Call for organized M3 port to OS/2

In article <Cw74C0.6qn@news.hawaii.edu>,
 <ckingsto@undergrad.math.uwaterloo.ca> wrote:
>Submitted by:   Craig Kingston (ckingsto@undergrad.math.uwaterloo.ca)
>Source:         Craig Kingston (ckingsto@undergrad.math.uwaterloo.ca)
>Date received:  1994 September 15
>Date posted:    1994 September 15
>------------------------------------------------------------------------------
-
>I have seen plenty of people saying they tried to / are / or hope
>to port M3 to OS/2, but there doesn't seem to be any results as of
>yet.
>
>So I am calling for people who
>  - are already attempting a port
>  - have attempted a port and have advice/code to share with us
>  - are experienced in porting software to offer advice
>  - people who feel they have special skills to contribute
>    (i.e. documenting, testing, low level coding, etc)
>  - has some interest and wishes to see if they can help.
>
>Send Mail to myself           
> CRAIG KINGSTON
> ckingsto@undergrad.math.uwaterloo.ca
>
>Don't worry about how much time you have available until a schedule
>is set, if you are short of time we may just use you for consultation
>of you can help out when you get extra time - I suspect this could take
>some time - not sure what is involved as of yet!
>
>Please include in your letter your skills, experience (even if none),
>and the amount of time you have available (so I can get an idea of how
>many human/hours per skill are available).  Also please include any other\
>important information (like how/when to contact you).
>
>and from there we shall orgainize a plan of attack on the compiler.

reposted (not sure if first post was successful)


======================================================================= 98 ===
Date:    Fri, 16 Sep 1994 16:45:16 GMT
From:    Bob Hathaway <rjh@geodesic.com>
Subject: Comp.Object FAQ Version 1.0.6 (9-15) Announcement

[The comp.object FAQ is now at zaphod.uchicago.edu:/pub/CompObj6.faq[.Z].
 The automated server should post to comp.object and the answers newsgroups
 soon.]

Archive-name: object-faq/announce
Last-Modified: 9/15/94
Version: 1.0.6

This announces the September version 1.0.6 of the Comp.Object FAQ - just in
time for my birthday!  It has many updates and corrections and has several
very up-to-date appendices on object-oriented methodologies and systems.
While a new section on miscellaneous commercial systems and libraries is
still in the works for completeness, this document may very well comprise
the latest and most up-to-date collection of object-oriented systems and
terms in the world today!  There is also a potential upcoming merge with the
new C++ Libraries FAQ.

I will try to update the FAQ monthly with system entries and information from
the net.  I have a new TQM system in place which should proceed from the
old Level 1 to Level 5 in no time - not hard for a one man job.  *Many*
thanks to the patience of those sending system updates and corrections,
my new system should provide fast acknowledgement, inclusion (within a few
weeks) and tracking, and 6 sigma quality should provide essentially defect
free performance for the FAQ.

Sending comments, suggestions, additions, updates, corrections, and new
system and site entries is strongly encouraged and should be directed to
the author at rjh@geodesic.com.

The FAQ is posted to the comp.object, comp.answers and news.answers newsgroups
and is available via anonymous ftp from zaphod.uchicago.edu and rtfm.mit.edu,
although new versions may take a short period of time to be installed.

Anonymous FTP Sites and Hypertext Server:
  anonymous@zaphod.uchicago.edu:/pub/CompObj6.faq(.Z) (128.135.72.61)
  anonymous@rtfm.mit.edu:/pub/usenet/comp.object/*_Part_*
  http://cui_www.unige.ch/OSG/FAQ/OO-FAQ/index.html

Mail Server:  (See also section 1.24)
  mail mail-server@rtfm.mit.edu
  Subject:
  send usenet/comp.object/*

Zaphod is preferred over rtfm for anonymous ftp retrieval, as it provides a
single file.  Rtfm contains the FAQ as posted.

To use the hypertext system, see APPENDIX E, entries 27.

Again, a short period of time may be required to retrieve the latest version
from anonymous ftp, allowing the posted version to propagate and get out as
quickly as possible.

Thank you to the many people who have contributed their time and effort to
help this document spread the word about object-oriented technology and
available systems!  It is hoped it will be most useful in that endeavor.

Best Regards!
bob


======================================================================= 99 ===
Date:    19 Sep 1994 00:02:16 GMT
From:    vbidarko@tatung3.cs.ttu.edu (Vinod Bidarkoppa)
Subject: OBJECT ANALYSIS AND DESIGN

NOTE :
This is for people who are involved directly or indirectly with
Object oriented software development. Please fill up the required information
and mail it to vbidarko@cs.ttu.edu.
Students and faculty are also welcome to reply.

Thanks in advance.

***************************************************************************




Questionnaire  on  requirements of  Object Oriented Analysis and Design Methodo
logy

INTRODUCTION

	This survey is to obtain information from the real world 
regarding the requirements of OOAD methodology. This is a part of 
masters thesis research in the Computer Science department at the 
Texas Tech University.
All the information will remain anonymous. The information from the
 questionnaires will be used to specify a set of practical requirements
 for an OOAD and also to evaluate the existing methodologies based on this.
	Completed questionnaires may be sent by post  or e-mail to:

	Vinod Bidarkoppa
	Department of Computer Science
	Texas Tech University
	Mail Stop 3104
	Lubbock, TX 79409

 E-mail : vbidarko@cs.ttu.edu
	  bed85@ttacs1.ttu.edu

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-----------------------

1. GENERAL INFORMATION

1.1	Organization 
	
	a) Name  :	
	b) Address :
	c) City :
	d) State :
	
1.2	Area(s) of Company business   ( Mention areas which use OO  )

	

	
1.3 	Personal Information
	a) Name :
	b) Your role in the organization :

1.4 	OO Methodologies used at present  in your organization
	 ( e.g. Booch, Coad and Yourdon, Shlaer and Mellor,OMT, Wirfs-Brock) an
d
 	in which projects / applications.
 	e.g.  G. Booch (1994 ed.)	Realtime Process Control

	
	
	
2.	METHODOLOGY REQUIREMENTS
	( Please rate  one of the categories from A to E.
	 ( A= Extremely Important,  B= Important, C= Not so important,
	  D= Unimportant, E= No comment)

2.1	Structural Concepts
2.1.1	Degree of  OO support
	1. The methodology should support the usual
	meaning of the terms object (instance) and class.	( )
 	
	2. The class should be described in terms
	of its distinct parts: an interface and body.		( )	
		
		
	3. Encapsulation and information hiding
	should be supported by the methodology			( )	
		
	4. The methodology should support metaclasses		( )

2.1.2	Relationships

	1. The methodology should support  :
	i) Single inheritance					( )	
	ii) Multiple inheritance				( )
	iii) Aggregation (container )				( )
	iv) Associative						( )
	v) The associative relationships should include cardinalities	( )

	2. The methodology should include / distinguish
	subclassing ( inheritance implementation with 
	redefinition and / or restriction as well as addition ) 
	and subtyping ( just addition).				( )

2.2 	Behavioral Concepts

2.2.1	Instances

	1. The methodology should provide facility for 
	dynamically creating and destroying objects.		( )

	2. The methodology should support
	i) Notion of object state.				( )
	ii) Export Control / Visibility  e.g. Private, Protected, Public
	( )	
	iii) Persistent Objects					( )	
	iv) Concurrent objects					( )
	v) Embedded Objects					( )	
	vi) Active ( instances executing in parallel) and passive
	(executing in serial with others) instances		( )	

2.2.2	Messages or events

	1. The methodology should facilitate message passing that involve :
	i) Static Binding					( )	
	ii) Dynamic Binding					( )	

	2. The methodology should support  the following kinds of polymorphism 
:
	i) Inclusion						( )	
	ii) Operational						( )	
	iii) Parametric						( )	

	3. The methodology should include the following modes of communication 
	i) Synchronous						( )	
	ii) Asynchronous					( )
	
	note : Synchronous is where the sender suspends execution till the 
	receiver processes the message and asynchronous is where the sender
	 continues processing.


2.3	Process
	1. The methodology should prescribe steps / guidelines for identifying 
:
	i) Semantic (Abstract) classes				( )	
	ii) Attributes 						( )	
	iii) Methods						( )	
	iv) Allocating attributes and methods to classes	( )	

	2. The methodology should specify guidelines for identifying the  
	following relationships :
	i) Generalization					( )	
	ii) Aggregation						( )
	iii) Association					( )
	iv) Cardinalities					( )

	3). The methodology should be able to specify dynamic behaviors 
	through the following :
	i) Message connection					( )
	ii) Instance connection					( )
	iii) Object interaction diagrams			( )
	iv) State machine					( )
	v) Event and state generalization			( )	
	vi) Interactions within the state			( )
	vii) Timing  diagrams					( )	
	viii) Formalization of abnormal behavior		( )	


	4). The methodology should prescribe guidelines  to identify and decomp
ose :
	i) Structural complexity				( )	
	ii) Dynamic complexity					( )

2.4	Design features

	1. The methodology should prescribe guidelines for the following :
	i) Specifying  system architecture			( )	
	ii) Specifying and integrating interface classes for
	human interaction					( )	
	iii) Specifying and allocating tasks / processes to processors	( )
	
	iv) Specifying and integrating classes for 
	database management					( )	
	v) Data structures and pseudo code for 
	the application classes					( )
	vi) Refinement of overall analysis and design in 
	scope of all the new classes added			( )
		
	2. The methodology should prescribe OOSE features regarding :
	i) Release planning					( )
	ii) Work products ( deliverables) review		( )	
	iii) Incremental development				( )
	
2.5 	Representation

2.5.1	Static Views
	
	1. Class and Object					( )	
	2. Attributes						( )
	3. Methods						( )
	4. Generalization					( )
	5. Aggregation						( )	
	6. Cardinalities					( )

2.5.2	Dynamic views
	
	1. Instance connection					( )	
	2. Visibility						( )
	3. Message connection					( )
	4. Control / timing					( )	
	5. Concurrency						( )
	6. Object interaction diagrams				( )
	7. State charts						( )
	8. Nested states					( )

2.5.3	Constraints
	
	1. On structure 					( )
	2. On behavior						( )	

2.5.4	Complexity

	1. Static structure					( )	
	2. Dynamic behavior					( )

2.6	Miscellaneous 
	
	The methodology should :
	
	1. Be Scaleable 					( )
	2. Have semantic and syntactic definitions  for all notations	( )
	
	3. Use same notations for analysis and design		( )	
	4. Provide deliverables at every stage			( )
	5. Have case tool support for graphical layout		( )
	6. Have case tool support for
		simulation / code generation			( )	
	7. Check for extensibility				( )
	8. Check degree of coupling and cohesion		( )
	9. Check for consistency				( )
	10. Checks for completeness				( ) 
	11. Prescribe performance evaluation			( )	
	12. Prescribe non-graphical specifications  for entities
	discovered at all stages				( )	
	
3.0 	Comments and suggestions


							

			


		

					





======================================================================= 100 ===
Date:    Mon, 19 Sep 1994 18:19:46 GMT
From:    "Steven D. Majewski" <sdm7g@Virginia.EDU>
Subject: SRC Modula-3 BOOT builds on AIX, but not libm3



I was able to build the BOOT-IBMR2 on AIX 3.2.4, 
but when I unpacked libm3 and tried to build it, 
( 'cd m3lib; m3build -v -V' ) I get this error:

[ ... lots of quake lines deleted ... ] 
| quake: reading  "/lv1/users/sdm7g/m3/boot-IBMR2/libm3/src/perftool/POSIX/m3ma
kefile"
| quake: reading  "/lv1/users/sdm7g/m3/boot-IBMR2/libm3/src/pqueue/m3makefile"
| quake: reading  "/lv1/users/sdm7g/m3/boot-IBMR2/libm3/src/pqueue/pqueue.tmpl"
| m3 -w1 -why -g -times -a libm3.a -F/tmp/qkFNDWIF1AAA 
|
|
| ***
| *** runtime error:
| ***    Segmentation violation - possible attempt to dereference NIL
| ***
|
|
|  seconds  #times  operation
|      NaN          other
| ---------------------------------------------------
|      NaN          TOTAL
|
| bsh: 31253 Abort - core dumped
| *** error code 134 (ignored)


Any clues ? 

Has anyone built SRC Modula-3 on AIX lately ? 

Because of the rather peculiar way the compiler installs, it's 
pretty hard to get a clue when something goes wrong. Once you've
bootstrapped the compiler, your out of the familiar world of 
'make' and 'cc', and into 'm3build' and 'quake' and 'm3'. I can't
even tell if _in_fact_, the compiler build was successful: no
error messages, but I can't even build the simple HelloWorld
program until the library is built! 

- clueless in Modula-3 land, 

- Steve Majewski       (804-982-0831)      <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics



======================================================================= 101 ===
Date:    Wed, 21 Sep 1994 20:01:02 GMT
From:    003495h@dragon.acadiau.ca (Mohamed Ali Hussien)
Subject: Niklaus Wirth


I have to write something about Niklaus Wirth(creator/inventor of
Pascal/Modula2) for one of my computer courses.

Could anyone out there e-mail me an autobiography of him or anything
about him?

Or maybe point out to me a gopher/ftp site where I can get hold of
such info.

Any help will be greatly appreciated !

Thanks in advance ....


-- 
Mohamed Ali Hussien
003495h@dragon.acadiau.ca
"If all else fail, read the instructions ..." --- Cann's Axiom.
			                          MURPHY'S COMPUTER LAW


======================================================================= 102 ===
Date:    22 Sep 1994 20:02:33 GMT
From:    rolf@gundog.lbl.gov (rolf ebert)
Subject: Re: M3 for embedded systems programming!


If you consider M3 for embedded systems, how about Ada? It has the
expressive power of m3 and also the syntax is very close. Both languages
have Pascal as an ancestor. You don't have automatic garbage collection
in Ada, though. With Ada94, the new standard, you get hooks where you
can easily add your own memory manager.


There are quite a few compiler vendors out there with specially targeted
compilers for embedded systems. In some critical application areas you
can also get a customized run-time (e.g. without tasks (aka threads))


mail me if you need more information.

	Rolf


P.S. Please this message was not intended to start another firework over
languages.


======================================================================= 103 ===
Date:    27 Sep 1994 16:18:12 GMT
From:    adiwan@cs.cmu.edu (Amer Diwan)
Subject: Debugging on DECStations

It seems that conditional breakpoints do not work while debugging M3
with m3gdb on DECStations.  When a conditional breakpoint is reached,
the debugger stops regardless of the condition being satisfied and in
the info to the breakpoint, the condition is "Invalid expression".  
Are there any tricks to setting conditional breakpoints?  
Since news has been very unreliable on the machines I normally use, I
would appreciate an email response to this.
Thanks.
    Amer


======================================================================= 104 ===
Date:    29 Sep 1994 14:41:04 GMT
From:    kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS)
Subject: Re: MODULA-3 being used

spencer@ERA.COM (Spencer Allain) writes:

> I'm hoping that the lack of bandwidth going through this newsgroup isn't due
> to little or no use, but that there aren't as many obscure problems that have
> to be addressed to the net for a solution.

Mostly the latter, I think.  The language and its libraries are simple
enough to preclude the sort of endless "what are the semantics of this
syntax?"  questions one gets with C++.  Certainly those of us porting
the M3 system have questions, but we generally take them up directly
with the authors of the code.

----
Sam Kendall
Sun Microsystems Laboratories BOS


======================================================================= 105 ===
Date:    Thu, 29 Sep 1994 12:56:24 GMT
From:    dkenny@actrix.gen.nz (Des Kenny)
Subject: Re: Information on teaching OO and Reuse (redux)

In article <36b346$50p@uqcspe.cs.uq.oz.au>,
Teaching OO Group <too@cs.uq.oz.au> wrote:
> 
> The following is a rough summary of the responses to my request for informati
on
> on teaching OO and Reuse. The list is undoubtedly not exhaustive, but it's al
l 
> of the relevant responses I received.
> 
> The list is categorised by languages used in no particular order.
> 
> If anyone would like any more information, please let me know.
> 
> Regards,
> 
> Tim Mansfield
> 
> Teaching Object Orientation Group                     Dept of Computer Scienc
e
>                                                       University of Queenslan
d
> Ph: +61 (0)7 365 2956                                 St Lucia 4072
> email: too@cs.uq.oz.au                                Australia
> 
> ------------------------------------
> 
> Smalltalk
> ---------
> Carleton (first years) 
> Uni of Colorado 
> Monash, Caulfield (postgrad) 
> 
> Eiffel
> ------
> QUT (third year) 
> UTS (first year) 
> Monash, Peninsula 
> Rochester Inst of Tech  (moved to C++ at the end of first year)
  University of Auckland, New Zealand
  Central Institute of Technology, New Zealand
  Victoria University, New Zealand ( evaluating Eiffel for teaching OOT )
  Canterbury University, New Zealand ( evaluating Eiffel for teaching OOT )
  Otago University, New Zealand ( evaluating Eiffel for teaching OOT )
> 
> C++
> ---
> Hamilton College, NY (whole course) 
> 
> Ada-83
> ------
> SUNY Plattsburgh (whole course) 
> Swinburne ?
> 
> Beta
> ----
> Uni of Dortmund (first year, first semester)
> 
> 
> ML
> --
> Uni of Dortmund (first year, 2nd semester after Beta) 
> 
> Mod3
> ----
> ecole polytechnique de montreal (final year) 
> 
> Turbo Pascal
> ------------
> Brown University, Rhode Island (first year) 
> 
> 




======================================================================= 106 ===
Date:    29 Sep 1994 17:11:11 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: MODULA-3 being used


In article <KENDALL.94Sep29104104@pot.East.Sun.COM> kendall@pot.East.Sun.COM (S
am Kendall - Sun Microsystems Labs BOS) writes:

   spencer@ERA.COM (Spencer Allain) writes:

   > I'm hoping that the lack of bandwidth going through this newsgroup isn't d
ue
   > to little or no use, but that there aren't as many obscure problems that h
ave
   > to be addressed to the net for a solution.

> Mostly the latter, I think.  The language and its libraries are
> simple enough to preclude the sort of endless "what are the
> semantics of this syntax?"  questions one gets with C++.

I generally agree with Sam here.  We have been using SRC Modula-3 for
more than two years now and we are very happy with it.  Also, I find
that there are fewer religious wars here. I imagine if Modula-3 were
more popular, this newsgroup would also get its share of religious
wars.

However, I agree with Spencer that it would be nice to see a post or
two in a week...  (Bill, can you please add some obscure features to
the next M3 release, so that we have something to discuss? :-)

If you are going to be at OOPSLA'94, I recommend that you look into
attending either the Modula-3 Tutorial, or the Modula-3 users group
meeting (to be announced here shortly). Also, Modula-3 FAQ and the
Mosaic Home page should give a good introduction of what is available
currently. See

  http://www.research.digital.com/SRC/modula-3/html/home.html.

Please do let us know what you intend to do with Modula-3: commercial
software development, prototyping or research software, etc.

-- Farshad
--
Farshad Nayeri
nayeri@gte.com


======================================================================= 107 ===
Date:    Thu, 29 Sep 1994 13:21:04 GMT
From:    spencer@ERA.COM (Spencer Allain)
Subject: MODULA-3 being used

I have just recently been following this newsgroup because, we weren't
subscribed to it before I requested its addition, and was hoping that there
would be more discussions going on.  I'm not even sure if anyone is using
MODULA-3 for any serious large products.

I'm currently using C++ for my projects, simply because that is what I have
to use.  I was weened on MODULA-2 (actually BASIC->FORTRAN->MODULA-2) and
still miss it.  I was hoping that there would be some discussion on how
MODULA-3's style of Object Oriented design compared to C++ or Eiffel, and
why some things were better and/or worse.

I'm a strong advocate for garbage collection, and was wondering how good
it is for MODULA-3.  A bulk of my time is spent tracing down memory leaks
that cause obscure problems in other (sometimes unrelated) parts of the
code, usually stuff that I didn't write but seemed to work fine, until all
of its functionality was attempted to be used.

I'm hoping that the lack of bandwidth going through this newsgroup isn't due
to little or no use, but that there aren't as many obscure problems that have
to be addressed to the net for a solution.

						-Spencer Allain
						Engineering Research Associates


======================================================================= 108 ===
Date:    29 Sep 1994 16:03:25 GMT
From:    gall@infosys.tuwien.ac.at (Harald Gall)
Subject: Installation problems on SPARC

Dear M3-Experts!

I have some problems with installing
m3 on a SPARC (SunOS 4.1.3).

After having configured the necessary files I start m3boot and
get the following:

<...>
ar: filename RTTypeRecSort_i.o truncated to RTTypeRecSort_i
ar: ...                        
<...>
ld: Undefined symbol
    __lib_version
*** error code 2
<...>

What am I doing wrong? I changed the make to the gnumake, but still
things go wrong. Any comments or hints are welcome!

Thanks in advance,
Harald Gall

------------------------------------------------------------------------------
  ___  ______________		Harald Gall, Inst.f. Informationssysteme 184-1
 /_| | \   \    \    \		Vienna University of Technology
 |_ _|__\___\____\____\		A-1040 Wien, Argentinierstr. 8/184-1, Austria 
  ()-----()     ()()()		email: gall@infosys.tuwien.ac.at
                                       Harald.Gall@infosys.tuwien.ac.at
                                       H.Gall@infosys.tuwien.ac.at
				Phone: +43 1 58801 4412 (Fax: +43 1 505 84 53)
------------------------------------------------------------------------------



======================================================================= 109 ===
Date:    29 Sep 1994 14:51:40 GMT
From:    hoodt@postoffice.manassas.ibm.com (Thomas Hood 913-4501)
Subject: Re: Information on teaching OO and Reuse (redux)

In article <36b346$50p@uqcspe.cs.uq.oz.au>, too@cs.uq.oz.au ( Teaching OO Group
) writes:
<snip>
|> 
|> Ada-83
|> ------
|> SUNY Plattsburgh (whole course) 
|> Swinburne ?
|> 
You can add Briar Cliff College in Sioux City IA.  I passed the baton
in 1992, but we were teaching two years of SE and OO (such as it is :-)
with Ada 83.
<snip>

-- 

Thomas Hood
hoodt@lfs.loral.com
-- Ada grunt since 1985
-- Member Team Ada since 1994
-- Member Team Human since 1965
--
-- My opinions are not those of my employers, and if they were I'd probably
-- reject them out of hand and form new ones.


======================================================================= 110 ===
Date:    30 Sep 1994 13:55:12 GMT
From:    fraser@hare.EuroPARC.Xerox.COM (Quentin Stafford-Fraser)
Subject: Sun RPC interface

I have hacked a version of Marvin Theimer & David Nichols' m3rpc 
package which now builds under M3 3.3. For those who don't know, this
provides an M3 interface to Sun RPC and an appropriate stub generator.
My changes have been limited to updating calls which changed in the 
v2 - v3 transition and writing some m3makefiles.

If anyone would like a copy, let me know. I have done only the most 
basic testing on it so far.

-- 
 ----------------------------------------------------------------------
                       Quentin Stafford-Fraser
           http://pelican.cl.cam.ac.uk/people/qs101/me.html
            
 Cambridge University Computer Lab        Rank Xerox Cambridge EuroPARC
 qs101@cl.cam.ac.uk                           fraser@europarc.xerox.com
 Tel: +44 223 334411                                Tel: +44 223 341521
 Fax: +44 223 334679                                Fax: +44 223 341510
 ----------------------------------------------------------------------



======================================================================= 111 ===
Date:    Fri, 30 Sep 1994 09:44:19 GMT
From:    freeman@coolidge.coolidge.grenoble.xerox.fr (Steve Freeman)
Subject: Re: MODULA-3 being used

In article <SPENCER.94Sep29092104@moe.ERA.COM> spencer@ERA.COM (Spencer Allain)
 writes:

> I'm currently using C++ for my projects, simply because that is what I have
> to use.  I was weened on MODULA-2 (actually BASIC->FORTRAN->MODULA-2) and
> still miss it.  I was hoping that there would be some discussion on how
> MODULA-3's style of Object Oriented design compared to C++ or Eiffel, and
> why some things were better and/or worse.
> 
> I'm a strong advocate for garbage collection, and was wondering how good
> it is for MODULA-3.  A bulk of my time is spent tracing down memory leaks
> that cause obscure problems in other (sometimes unrelated) parts of the
> code, usually stuff that I didn't write but seemed to work fine, until all
> of its functionality was attempted to be used.
> 
I've recently been exiled to C++ (for external reasons) from M3 and 
miss it dreadfully. I now have to spend lots of time doing things like
tracking news and deletes and writing run-time type stuff, etc, etc,
which I used to rely on the language for. One excellent example is the 
issue of module initialisation; it simply isn't hard in M3 because you
IMPORT, rather than include interfaces, so the compiler/linker can
figure out an initialisation sequence, and each implementation file
has an initial block which you can rely on to set things up.
One of the more depressing aspects of C++ is that most of the books 
include long lists of "gotchas" of which you have to be aware to survive. 

You might miss is multiple inheritance which, if I remember 
rightly, exercised this newsgroup a while ago, but either it's not as 
necessary as some people think or the M3 type system is so nice (or both) 
that I never really needed it. The other thing you might miss is the
preprocessor; the M3 style is more to use different implementation files
and link according to your needs. The M3 libraries are pretty substantial
and seem to manage quite well with this scheme.

If you have the chance, I'd strongly recommend getting away from C++.

steve

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Steve Freeman, Research Scientist, Rank Xerox France.

Surface:  Rank Xerox Research Centre,
          6, chemin de Maupertuis, 38240 Meylan, France.
Internet: steve.freeman@xerox.fr
Phone:    +33 76 61 50 21
Fax:      +33 76 61 50 99


but wotthehel wotthehel
toujours gai
  -- mehitabel the cat


======================================================================= 112 ===
Date:    30 Sep 1994 03:18:29 GMT
From:    norman@flaubert.bellcore.com (Norman Ramsey)
Subject: Re: MODULA-3 being used

In article <SPENCER.94Sep29092104@moe.era.com>,
Spencer Allain <spencer@ERA.COM> wrote:
>I have just recently been following this newsgroup because, we weren't
>subscribed to it before I requested its addition, and was hoping that there
>would be more discussions going on.  I'm not even sure if anyone is using
>MODULA-3 for any serious large products.

There are a number of serious efforts going on.  I believe Michel
Dagenais makes some effort to list them in the FAQ.

> I was hoping that there would be some discussion on how
>MODULA-3's style of Object Oriented design compared to C++ or Eiffel, and
>why some things were better and/or worse.

We seem to stay relatively free of that sort of religious war.  M3 has
safety, garbage collection, exceptions, and threads.  There's a good
UI toolkit with builder and a good implementation of network objects.
I (and others) find those things more important than the details of
the particular object model.

>I'm a strong advocate for garbage collection, and was wondering how good
>it is for MODULA-3.

There's a reasonable stop-and-copy collector on all platforms.  Some
platforms support a more incremental collector that synchronizes with
the mutator by using VM protection primitives.

>I'm hoping that the lack of bandwidth going through this newsgroup isn't due
>to little or no use, but that there aren't as many obscure problems that have
>to be addressed to the net for a solution.

Most problems arise when a new version of the SRC copmiler becomes
available and people have difficulty porting it to different
platforms.  The rest of the time we're all busy getting work done :-)

Norman


======================================================================= 113 ===
Date:    Fri, 30 Sep 1994 21:27:03 GMT
From:    bwbecker@dragon.uwaterloo.ca (Byron Weber Becker)
Subject: m3build orientation needed

I'm trying to orient myself to v. 3.3  (m3build in
particular) after using v. 2.11 for a while.  

1. Are there non-trivial examples of m3makefiles
   that are easy to access.  The person who installed
   m3 on my machine didn't leave the compiler source as a 
   possible set of examples. 

2. How does m3build/quake interact with:
   a. a source code control system like RCS
   b. building non-M3 parts of the system (compiling
      lex and yacc, for instance)

3. I often including targets to test code in the
   same makefile that builds the program.  How do
   the rest of you handle testing?  Do you have
   a separate makefile, or do it with m3build?

   I guess the big question behind 2 and 3 is whether
   m3build is viewed as a general purpose tool similar
   to make or whether it is just for building the M3
   portion of the program.

4. I need coaching on appropriate/recommended directory
   structures.  For instance, I have 2 programs that
   use a common set of modules.  I have set up the
   directories:

   software/
      program_a/
         src/
            m3makefile -- uses an override to find the
                          common_code library
      program_b/
         src/
            m3makefile
      common_code/
         src/
            m3makefile -- creates a library

   Are there better ways to do this?  

5. How do I use the variable WDROOT to set "conventional
   location of the user's personal package library"?

Any pointers and advice would be very appreciated.

=====
Byron Weber Becker                               (519) 888-4567 x4661
Computer Science Lecturer/Advisor        bwbecker@dragon.uwaterloo.ca
University of Waterloo


======================================================================= 114 ===
Date:    30 Sep 94 15:45:39
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: MODULA-3 being used

In article <KENDALL.94Sep29104104@pot.East.Sun.COM> kendall@pot.East.Sun.COM (S
am Kendall - Sun Microsystems Labs BOS) writes:

   spencer@ERA.COM (Spencer Allain) writes:

   > I'm hoping that the lack of bandwidth going through this newsgroup isn't d
ue
   > to little or no use, but that there aren't as many obscure problems that h
ave
   > to be addressed to the net for a solution.

   Mostly the latter, I think.  The language and its libraries are simple
   enough to preclude the sort of endless "what are the semantics of this
   syntax?"  questions one gets with C++.  Certainly those of us porting
   the M3 system have questions, but we generally take them up directly
   with the authors of the code.

The language was kept simple by design, there are several well designed
and documented libraries and there are no differences practically
from one platform to the other. Furthermore you will not get stuck
with dangling pointers, corrupted memory and core dumps. This
probably tends to keep traffic down. Perhaps the FAQ helps a bit
too :-).

Of course when a new release will come out, traffic will increase for
a while.
--

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029



