Conference turris::languages

================================================================================
  SPIDER::KEANE                    Languages                  1-OCT-1984 12:52  
  Note #33               -{ New Corporate Language? }-            48 responses  
--------------------------------------------------------------------------------
I don't usually like to fuel the rumor mill but..

I have heard that we will soon have a new designated "corporate
implementation language" to replace Bliss.  Pascal, Ada, and C
were rumored as possible candidates.

Is there any substance to this rumor?

Brian
================================================================================
  LATOUR::AMARTIN                  Languages                  1-OCT-1984 16:06  
  Note #33.1             -{ New Corporate Language? }-                 1 of 48  
--------------------------------------------------------------------------------
Yes, but the selection process hasn't begun.  Read the last paragraph in 27.6.
				/AHM
================================================================================
  XENON::STANSBURY                 Languages                  4-OCT-1984 07:23  
  Note #33.2             -{ New Corporate Language? }-                 2 of 48  
--------------------------------------------------------------------------------
If it is going to be Ada, then there will have to be a lot of educational
programs worked out to teach everyone the language. Both C and Pascal would
require a lot less training.

Is Pascal a serious choice? I would think it doesn't allow one to get down to
the bit-level well enough - like C does. I for one would welcome the stricter
typing of Pascal.

Jack
================================================================================
  VAXUUM::DYER                     Languages                  4-OCT-1984 10:35  
  Note #33.3             -{ New Corporate Language? }-                 3 of 48  
--------------------------------------------------------------------------------
	My vote is (of course) for C.  If you want strict typing, use LINT
or something like that (though we don't have it...)...
	Could Ada run on a Rainbow?

	I know!  We could all use COBOL!!!
		(-: :-)
		<_Jym_>
================================================================================
  XENON::STANSBURY                 Languages                  4-OCT-1984 12:34  
  Note #33.4             -{ New Corporate Language? }-                 4 of 48  
--------------------------------------------------------------------------------
... or BASIC!

:-)
================================================================================
  MOTHER::SAVIGNANO                Languages                  4-OCT-1984 19:03  
  Note #33.5             -{ New Corporate Language? }-                 5 of 48  
--------------------------------------------------------------------------------
Better still VAX LISP, or maybe Prolog.....
================================================================================
  TURTLE::GILBERT                  Languages                  5-OCT-1984 02:05  
  Note #33.6             -{ New Corporate Language? }-                 6 of 48  
--------------------------------------------------------------------------------
Modula.
================================================================================
  ADVAX::A_VESPER                  Languages                  5-OCT-1984 08:47  
  Note #33.7             -{ New Corporate Language? }-                 7 of 48  
--------------------------------------------------------------------------------
APL, of course.  (After all, it's easier to write than BLISS. (Although harder
to read. (And nicer than LISP with all those parenthesis (and such).)))

Andy V
================================================================================
  VAXUUM::DYER                     Languages                  5-OCT-1984 09:17  
  Note #33.8             -{ New Corporate Language? }-                 8 of 48  
--------------------------------------------------------------------------------
	IBM uses APL, but don't they use it for prototypes and use something
else (PL/I?) for programs?
		<_Jym_>
================================================================================
  LATOUR::AMARTIN                  Languages                  6-OCT-1984 09:10  
  Note #33.9             -{ New Corporate Language? }-                 9 of 48  
--------------------------------------------------------------------------------
Re .6:

I hope you meant Useless-2, and not the original Useless.  Useless was
worse than the original Wirthless.
				/AHM
================================================================================
  BABEL::REAGAN                    Languages                  6-OCT-1984 17:03  
  Note #33.10            -{ New Corporate Language? }-                10 of 48  
--------------------------------------------------------------------------------
PASCAL would be a good choice if all the Pascals implement the
same type of extensions that VAX PASCAL has...

		-John
================================================================================
  HARE::GILBERT                    Languages                  7-OCT-1984 19:01  
  Note #33.11            -{ New Corporate Language? }-                11 of 48  
--------------------------------------------------------------------------------
Urp.  Modula-2.
================================================================================
  ORPHAN::BRETT                    Languages                  8-OCT-1984 18:22  
  Note #33.12            -{ New Corporate Language? }-                12 of 48  
--------------------------------------------------------------------------------
I am hesitant to enter this, because this really IS religion!   However, I
think that there had better be a good reason for changing!  The argument that
'no-one else uses BLISS' doesn't convince me, since I learnt it in a couple of
days, and polished my skills over the years without any one else around who
knew the language.

Any replacement language should, in my opinion, have the following support...

	(1) Run-time expressions in arrays bounds and scalar bounds.   Ada is
the only candidate here that shows any sign of being wide spread over the next
ten years.

	(2) Extensive compile-time massaging facilities to construct tables
as well as to do conditional compilation.   Bliss is the only candidate here,
unless extensive use is made of a pre-processor, in which case almost any
structured language will surfice.

	(3) Procedures/Functions as 'types' so that you can have arrays/records
of them.  Bliss only here.  Pascal at least has procedure/function parameters
which Ada does not.

	(4) True multi-tasking support.  Ada is the only candidate again among
those languages that have a chance of wide acceptance.  Modula-2 comes in with
an 50%,  Pascal, C, Bliss et.al. with 0%, in my rating.  This is going to be
increasingly important as we head toward a more distributed set of h/w, and
multi-windowing etc.

	(5) Variant parameter lists. (ie optional parameters, and differing
interpretations of parameter lists).  Bliss pretty good but no checking.  Ada
is probably okay, by the time you combine in-lining with overloading.


Conclusion:

	No available language meets above criteria.  The best hope is a
superset of Ada, or a cramping of our styles and a good set of precompilation
tools targetted to Ada.

	Its not yet worth leaving Bliss.


/Bevin
================================================================================
  LATOUR::RDF                      Languages                  8-OCT-1984 20:43  
  Note #33.13            -{ New Corporate Language? }-                13 of 48  
--------------------------------------------------------------------------------
re VAX PASCAL:  Not bad, but you still have the ever popular...

[EXTERNAL,ASYNCHRONOUS,GREGARIOUS,VOCIFEROUS,PEANUT_STOMPING]
   FUNCTION MTH$RANDOM (VAR seed : INTEGER) : REAL; EXTERN;

:-)

Rick
================================================================================
  EGEV00::SCHERRER                 Languages                 12-OCT-1984 15:37  
  Note #33.14            -{ New Corporate Language? }-                14 of 48  
--------------------------------------------------------------------------------
ADA of course...

Patrick
================================================================================
  ORPHAN::BLICKSTEIN               Languages                 15-OCT-1984 19:57  
  Note #33.15            -{ New Corporate Language? }-                15 of 48  
--------------------------------------------------------------------------------
Gee Bevin, I'd never have thought it would be you who'd be coming out in
favor of PL/I as the corporate language (by indirect advocacy):

>	(1) Run-time expressions in arrays bounds and scalar bounds.   Ada is
>the only candidate here that shows any sign of being wide spread over the next
>ten years.

PL/I (including ours) has had these since before ada was ever conceived.

>	(2) Extensive compile-time massaging facilities to construct tables
>as well as to do conditional compilation.   Bliss is the only candidate here,
>unless extensive use is made of a pre-processor, in which case almost any
>structured language will surfice.

If you can construct tables using the PL/I language, chances are good that
you can construct them using the PL/I preprocessor since it is a fairly
rich subset of the PL/I language.  Besides, BLISS ain't so great at all
kinds of table building.  Ask me about the macro to build the APL overstrike
table sometime.  BLISS fails when tables must be built in anything other
than sequential order.

>	(3) Procedures/Functions as 'types' so that you can have arrays/records
>of them.  Bliss only here.  Pascal at least has procedure/function parameters
>which Ada does not.

PL/I has a Procedure/function datatype (ENTRY VARIABLE).  And unlike ada,
you can pass procedures/functions as parameters.

>	(4) True multi-tasking support.  Ada is the only candidate again among
>those languages that have a chance of wide acceptance.  Modula-2 comes in with
>an 50%,  Pascal, C, Bliss et.al. with 0%, in my rating.  This is going to be
>increasingly important as we head toward a more distributed set of h/w, and
>multi-windowing etc.

Not true.  The next PL/I standard will have a wonderful definition of
PL/I multitasking based on a new idea called block structured critical regions
which allows the compiler to detect violations of protocol.  While it's true
that our VAX compiler doesn't have this yet, it's a good candidate for
the next version and many other PL/Is already have multitasking support.

>	(5) Variant parameter lists. (ie optional parameters, and differing
>interpretations of parameter lists).  Bliss pretty good but no checking.  Ada
>is probably okay, by the time you combine in-lining with overloading.

PL/I does have optional parameters (our implementation).  I'm not sure what
you mean by variant parameter lists.  From what I've read of overloading,
you can keep it.

>Conclusion:
>
>	No available language meets above criteria.  The best hope is a
>superset of Ada, or a cramping of our styles and a good set of precompilation
>tools targetted to Ada.

The first statement of your conclusion is false therefore I reject the
conclusion PL/I has all this.   It's not nearly so hard to learn or use as ada.
And the single most biggest advantage is that our PL/I compiler has one of the
fastest lines per minute performance of all the VAX compilers (I don't think
any ada compiler will ever achieve that).  It is also the champion code
generator of all the currently available VAX compilers.

>	Its not yet worth leaving Bliss.

Agreed.

	db
================================================================================
  TURTLE::GILBERT                  Languages                 15-OCT-1984 20:48  
  Note #33.16            -{ New Corporate Language? }-                16 of 48  
--------------------------------------------------------------------------------
Overloading is really very useful.  However, it requires a typed language,
which Bliss is not.

Most 3GLs have overloaded operators built into the language, but not many allow
syntactically simple constructs for user-defined overloading of functions, fewer
still offer user-defined operators.
================================================================================
  ADVAX::A_VESPER                  Languages                 16-OCT-1984 09:01  
  Note #33.17            -{ New Corporate Language? }-                17 of 48  
--------------------------------------------------------------------------------
Even FORTRAN has overloaded operators -- the lowly "+" can
mean integer addition, floating point addition, convert left argument
to floating point and then do floating point addition, ...


Andy V
================================================================================
  ORPHAN::BRETT                    Languages                 16-OCT-1984 14:01  
  Note #33.18            -{ New Corporate Language? }-                18 of 48  
--------------------------------------------------------------------------------
>>       (1) Run-time expressions in arrays bounds and scalar bounds.   Ada is
>>the only candidate here that shows any sign of being wide spread over the next
>>ten years.
>
>PL/I (including ours) has had these since before ada was ever conceived.
>

PL/I has it on array bounds, but not general scalar bounds, such as


	I : INTEGER range   FUNCTION_CALL .. FUNCTION_CALL;

>>       (2) Extensive compile-time massaging facilities to construct tables
>>as well as to do conditional compilation.   Bliss is the only candidate here,
>>unless extensive use is made of a pre-processor, in which case almost any
>>structured language will surfice.
>
>If you can construct tables using the PL/I language, chances are good that
>you can construct them using the PL/I preprocessor since it is a fairly
>rich subset of the PL/I language.  Besides, BLISS ain't so great at all
>kinds of table building.  Ask me about the macro to build the APL overstrike
>table sometime.  BLISS fails when tables must be built in anything other
>than sequential order.
>

    What I was really hoping to be able to do was construct tables such as
    the following, which is an abstraction of some real code in the Vax Ada
    compiler...  [these can be done, with some difficulty, in PL/I].

	    given prefixes,  "A", "B", and "C"
	    and   postfixes, "X", "Y", and "Z"

	construct the table

	   (A_X,  A_Y,  A_Z,
	    B_X,  B_Y,  B_Z,
	    C_X,  C_Y,  C_Z)

	where these are all literals/constants that have been defined earlier.


    Another abstraction of real code in the Vax Ada compiler is...

	    given postfixes "ALPHA", "BETA", "GAMMA"

	construct the equivalent of the Bliss source...

	    routine RTN_ALPHA is forward;
	    bind routine RTN_BETA  = RTN_ALPHA;
	    bind routine RTN_GAMMA = RTN_ALPHA;
	    routine ALPHA =

		....

	    own LIST_OF_RTNS : vector[long]
		preset(
		    ...
		    [K_ALPHA] = RTN_ALPHA,
		    [K_BETA]  = RTN_BETA,
		    [K_GAMMA] = RTN_GAMMA
		    ...
		    );


    [[Aside:
      I believe that the 'other than sequential order' problem with Bliss
      can usually be avoided with presets.  In the worse case where you
      wish to build several tables at once, it can be hacked together with
      psects, but it is usually possible to build the tables individually
      if you try hard enough - note I am NOT a strong advocate of Bliss's
      pre-processing - I think a lot stuff could be done better and faster
      with preprocessors written in almost any language, including BASIC!
    ]].

>>       (3) Procedures/Functions as 'types' so that you can have arrays/records
>>of them.  Bliss only here.  Pascal at least has procedure/function parameters
>>which Ada does not.
>
>PL/I has a Procedure/function datatype (ENTRY VARIABLE).  And unlike Ada,
>you can pass procedures/functions as parameters.
>

    Great!,

>>       (4) True multi-tasking support.  Ada is the only candidate again among
>>those languages that have a chance of wide acceptance.  Modula-2 comes in with
>>an 50%,  Pascal, C, Bliss et.al. with 0%, in my rating.  This is going to be
>>increasingly important as we head toward a more distributed set of h/w, and
>>multi-windowing etc.
>
>Not true.  The next PL/I standard will have a wonderful definition of
>PL/I multitasking based on a new idea called block structured critical regions
>which allows the compiler to detect violations of protocol.  While it's true
>that our VAX compiler doesn't have this yet, it's a good candidate for
>the next version and many other PL/Is already have multitasking support.
>

    The *next* PL/I standard, but again Great!

>>       (5) Variant parameter lists. (ie optional parameters, and differing
>>interpretations of parameter lists).  Bliss pretty good but no checking.  Ada
>>is probably okay, by the time you combine in-lining with overloading.
>
>PL/I does have optional parameters (our implementation).  I'm not sure what
>you mean by variant parameter lists.  From what I've read of overloading,
>you can keep it.
>

    The biggest complaint about Bliss is "its our implementation", hence to
    say that our PL/I has it isn't ideal, although its pretty good and
    personally I see nothing wrong with adding to languages so that we
    are better at producing s/w than our competitors!

    An example of a variant parameter list would be a function IMAGE which
    can either be called with an INTEGER or a FLOATING value, and in either
    case returns the corresponding character string - much as WRITE in Pascal.

    Overloading is one way of accomplishing this.  Actually people will find
    overloading very easy to learn and VERY convenient to use.  For example,
    say you have a linked list implemented by pointers.  It would be possible
    in Ada to declare an operator

	function "+"(
	    START : PTR_TO_LINKED_ITEM;
	    OFFSET : INTEGER ) return PTR_TO_LINKED_ITEM is
	begin
	    ...
	end;

    More importantly, it is possible to declare...

	function SIN(ANGLE : DEGREES) return F_FLOAT;
	function SIN(ANGLE : RADIANS) return F_FLOAT;
	function SIN(ANGLE : DEGREES) return G_FLOAT;
	function SIN(ANGLE : RADIANS) return G_FLOAT;

    etc.

>>Conclusion:
>>
>>       No available language meets above criteria.  The best hope is a
>>superset of Ada, or a cramping of our styles and a good set of precompilation
>>tools targetted to Ada.
>
>The first statement of your conclusion is false therefore I reject the
>conclusion PL/I has all this.   It's not nearly so hard to learn or use as ada.
>And the single most biggest advantage is that our PL/I compiler has one of the
>fastest lines per minute performance of all the VAX compilers (I don't think
>any ada compiler will ever achieve that).  It is also the champion code
>generator of all the currently available VAX compilers.
>

    PL/I comes closer than I thought, although since I'm not very familiar
    with it that's not too surprising!   The absence of scalar ranges, even
    compile-time-constant scalar ranges, is serious.

Maybe I should add enough criteria to the above list to make it more difficult
for PL/I to score so well!  If so, here's what I think I would add (and would
even admit that I should have included them to start with).


    (1) Strong named typing, as in Pascal/Ada/Modula - including named types

    (2) Functions capable of returning arrays whose bounds are determined by
	the function

    (3) Separate compilation with full checking across units

    (4) Information hiding, such as Ada's private types & packages; or such
	as Modula 2's specification and implementation modules.



In general I think Ada will become the best widespread language for LARGE SCALE
s/w development.  For programs less than 1 man month, it doesn't matter what
you use, and for medium scale stuff PL/I, Bliss, Pascal, Modula 2 all suffice.


/Bevin
================================================================================
  LATOUR::AMARTIN                  Languages                 16-OCT-1984 17:11  
  Note #33.19            -{ New Corporate Language? }-                19 of 48  
--------------------------------------------------------------------------------
Re .12:

One interesting aspect of multi-tasking is that most existing
languages which supports it, use models which don't look like
what our operating systems support.  (Unless you include C/Ultrix;
while C itself doesn't support multi-tasking, it drags in a set of
standard procedures from Unix for it).  What languages which were not
designed at DEC are implemented using the DEC host operating system's
process primitives, instead of having their own custom written scheduler?
Do any Ada or Modula-2 implementations use VMS or Twenex processes?

I have seen overloaded procedures misused to produce very unreadable
code.  A set of packages for lists and their headers had two procedures
named ADD (or something), and it was very unclear whether the invocations
were adding something to the list, or a list element.  And they were not
even overloaded onto binary "+".  I wonder whether this is going to be
a widespread phenominon (and source of bugs).

Re .16:

Actually, Bliss has types, but they only affect the code generated for
the structure reference operator ([,...]).  And of course, you can
overload as many different routines as you want onto that operator. . .
				/AHM
================================================================================
  TURTLE::GILBERT                  Languages                 16-OCT-1984 17:33  
  Note #33.20            -{ New Corporate Language? }-                20 of 48  
--------------------------------------------------------------------------------
module bretts_examples (list(expand)) =
begin

external literal
    a_x, a_y, a_z,
    b_x, b_y, b_z,
    c_x, c_y, c_z;
literal
    k_alpha =	2,
    k_beta =	0,
    k_gamma =	1;

macro
    pre_post_(prefixes, postfixes) = 	post__(postfixes, %remove(prefixes)) %,
    post__(postfixes)[prefix] =		pre__(prefix, %remove(postfixes)) %,
    pre__(prefix)[postfix] =		%name(prefix,'_',postfix) %;

bind
    pre_post_table = uplit( pre_post_( <'A','B','C'>, <'X','Y','Z'> ) );

macro
    rtn_def_(a) =
	forward routine %name('RTN_',a);
	rtn_def__(a,%remaining) %,
    rtn_def__(a)[b] =
	bind %name('RTN_',b) = %name('RTN_',a) %;

rtn_def_('ALPHA','BETA','GAMMA');

routine rtn_alpha = 0;	! This was declared forward

macro
    own_def_(dummy) =
	own LIST_OF_RTNS: vector[%length,long]
	    preset(
	    own_def__(dummy,%remaining)
	    ) %,
    own_def__[a] =
	[%name('K_',a)] = %name('RTN_',a) %;

own_def_('ALPHA','BETA','GAMMA');

end
eludom
================================================================================
  ORPHAN::BLICKSTEIN               Languages                 17-OCT-1984 16:31  
  Note #33.21            -{ New Corporate Language? }-                21 of 48  
--------------------------------------------------------------------------------
PL/I does not have overloading (and I personally hope that it never will).
Instead, the way you accomplish the same thing in PL/I is via ENTRY statements.
ENTRY statements allow a procedure to have more than one entry point and
thus, differently typed parameters.   It's not quite the same as overloading
in that each entry must have a different name but it allows you to do
the same things.

Besides overloading is a strongly-typed language concept.   It's neither
appropriate or desireable for PL/I, which isn't strongly typed.  I personally
do not like strongly typed languages.  The difference to me seems to boil
down to strongly-typed languages are less convienent to use and do less for
you than loosely typed languages.

	db

P.S.  I'm not a PL/I freak.  But I'm driven to response when I hear anything
      implying that ada offers anything new.
================================================================================
  ADVAX::A_VESPER                  Languages                 19-OCT-1984 15:40  
  Note #33.22            -{ New Corporate Language? }-                22 of 48  
--------------------------------------------------------------------------------
I strongly suggest that the DEC standard implementation language
should have DEC supported compilers or cross-compilers for:

    VAX-11 (inc. uVAX)	VMS, ULTRIX
    PDP-11 (inc. T-11)	RSX, RSX-PLUS, P/OS, RT11, RSTS/E
    DECsystem 10  	TOPS10
    DECsystem 20  	TOPS20

    Intel 80186, 8096
    Motorola 68012
    Zilog Z-80

(The last 4 are used inside products.)

Andy V
================================================================================
  BEING::PETTENGILL                Languages                 20-OCT-1984 00:28  
  Note #33.23            -{ New Corporate Language? }-                23 of 48  
--------------------------------------------------------------------------------
Its obvious that if the ADA compiler had been written in C all our problems
would be solved.  Simply recompile it using existing C compilers for each
machine involved and we would have ADA ported to everything from the VAX
to the 68000.  Then everything we write, from terminal firmware to database
systems could be written in ADA without regard for the eventual target
machine.

I'm working on LAT software.  LAT is basically a wire.  This means that
a lot of characters are processed so code performance is very critical.
VERY CRITICAL.  The addition of two instructions reduces the performance
of some parts of the system perhaps 10%.  The code for the critical sections
are written in MACRO-11 and the I-streams are modified to reflect state.
However, much of the system is executed very infrequently and needs to
be in a high level language.

If there is going to be a "corporate" implementaton language, I think it
needs to support linkage specifications at least as powerful as BLISS.
I find BLISS to be marginal in this regard.

BTW, BLISS provides either all the multitasking support you need or none.
I guess it depends on your perspective.  The current multi-threading support
in an internal LAT base level are written in BLISS because that was easier
to describe and evolve in BLISS than in MACRO-11.
================================================================================
  LATOUR::AMARTIN                  Languages                 20-OCT-1984 11:54  
  Note #33.24            -{ New Corporate Language? }-                24 of 48  
--------------------------------------------------------------------------------
Re .23:

It is obvious that if Vax-11 Ada had been written in C (in a portable manner)
that you would be able to generate object code for Vaxes while running the
compiler on anything from the Vax to the 68000.  If writing a compiler in
C magically means that it has a universal code generator, I think we have
got a real edge on the competition.

While I ragged on Bevin about being Vaxocentric wrt the Ada compiler, I
certainly didn't mean to imply that there was no extra cost to making
the Ada compiler generate code for more than one machine, or that the
added work should have been done.

I can remember thinking a couple of years ago that it looked like DEC
was totally ignoring Ada for all of its architectures.  (I didn't know
the people on the project, the schedule, or whether they would make it).
I don't know what the performance of the product will be, (high, I hope),
but at least we can sit back and watch the 3rd party Ada announcements
secure in the knowledge that we have something to offer in competition.
(Have any of the announcements been for systems that will run under VMS,
or were they all Unix?)

Has anyone translated the Whetstone benchmark into Ada yet?
(Snicker)

How about the benchmarks that Mike Powell has been measuring his Modula-2
compiler with?
				/AHM
================================================================================
  ORPHAN::BRETT                    Languages                 20-OCT-1984 21:22  
  Note #33.25            -{ New Corporate Language? }-                25 of 48  
--------------------------------------------------------------------------------
It is unlikely that an Ada compiler running on a machine with less than 2 Mb
of physical memory will EVER run very well.

The VAX-o-centric nature of our current product was built in.  It will cost
$M's to even convert it to another architecture (surprised? not when engineers
cost 115K per year each and our Ada compiler has LOTS of man years in it!)

Yes, we have an 'official' Whetstone benchmark (as published in Ada letters) -
we score just over 1000 WITH FULL RUN TIME CHECKING ENABLED.  (Real snicker!)

What about Mike Powell's bench marks?  Other than they, and no real world
program, use tail recursion?

Seriously though, bench marks are supposed to reflect the real usage of the
individual language.  The Whetstone is a CRUMMY Ada benchmark - any one who uses
that style in Ada deserves to be selected, sliced, and aborted.

Performance and quality was a real goal in our compiler.  It will be interesting
to see how the other compilers turn out.  But at least this IS A VERY PORTABLE
language, and the fact that you use our compiler on VAX, and Microsoft's
(sarcasism) on a Z80, will not stand in your way as much as many other languages
where manufacturers can't resist putting in their own improvements.


/Bevin
================================================================================
  BARTOK::BARABASH                 Languages                 22-OCT-1984 13:25  
  Note #33.26            -{ New Corporate Language? }-                26 of 48  
--------------------------------------------------------------------------------
  If you want to write a transportable compiler for some language X,
  where X is not C, writing it in C is not the correct strategy.

  WRITE IT IN X.  HAVE IT SELF-COMPILE.

  This way, all you have to do to transport the compiler to another
  architecture is first, learn the new target architecture.  Then,
  re-write the compiler's code generator to suit the new architecture.
  Finally, have it self-compile, and bring the object code to the target
  machine.  Once it self-compiles correctly on the target machine, then
  it's fully bootstrapped.

  This beats having to worry about the possible existence of a reasonably
  good C compiler in order to have language X available on the new target
  architecture.

  -- Bill B.
================================================================================
  XENON::STANSBURY                 Languages                 22-OCT-1984 16:36  
  Note #33.27            -{ New Corporate Language? }-                27 of 48  
--------------------------------------------------------------------------------
According to Bill Keating's 24-Sep-1984 memo on "LANGUAGE, TOOL, AND DISPLAY
SYSTEM SOFTWARE STRATEGY", the section on BLISS Product Strategy Summary (page
57) says:

    C. Future Strategy

    Both BLISS compilers are in the maintenance mode. No new
    enhancements are planned.

    During FY85, we will nominate a new First Choice Development
    language for in-house software product development.

I guess that says it all.

Jack
================================================================================
  ALIEN::PETTENGILL                Languages                 22-OCT-1984 21:04  
  Note #33.28            -{ New Corporate Language? }-                28 of 48  
--------------------------------------------------------------------------------
I think that means that some new language gets the kiss of death.

I doubt any significant in-house software development project will find one
language appropriate for the entire project, not to mention all of software
engineering find one language appropriate for all projects.  Today, many
people find BLISS to be a convenient target for many ills.  Tomorrow, some
new language will be missing many critical features that BLISS (or some other
language) has and the solution is simple: tailor the language to the
requirements that seem most appropriate.  In the end, we end up with a language
well suited to our needs, yet 60% of its users will be against it.

Wouldn't we be better off if people just agreed to continue hating BLISS ?
Either that, or choose COBOL; nobody would take that seriously.

Personally I find all this very frustrating.  This is used as an excuse to not
use BLISS.  The alternative: MACRO-11.  And this is for software that should
be transported to the VAX (not VMS nor ULTRIX).  Anyone got macros that allow
MACRO-32 to compile MACRO-11 code into something useful ?
================================================================================
  LATOUR::AMARTIN                  Languages                 23-OCT-1984 09:13  
  Note #33.29            -{ New Corporate Language? }-                29 of 48  
--------------------------------------------------------------------------------
Re .26:

That approach has two potential problems:

1.  X may not be an appropriate language to write compilers in.

2.  As time goes by, the percentage of architectures which do not have
(C, Pascal, Ada, Modula-2; choose one or all) compilers will tend to
decrease.  Indeed, the absence of enough compilers for a machine makes
it a rather boring prospect, and hurts it viability in the general
marketplace.
				/AHM
================================================================================
  BARTOK::BARABASH                 Languages                 24-OCT-1984 13:48  
  Note #33.30            -{ New Corporate Language? }-                30 of 48  
--------------------------------------------------------------------------------
  RE .-1:
	1. You're right.  I shudder to think of writing a compiler in COBOL.
	   But for any candidate for corporate implementation language, if
	   you can't even write a compiler in it, imagine writing an operating
	   system, database management system, or even a debugger in it!

	2. Some examples of computers which first shipped without C,
	   Ada, Pascal, or even Modula-2:

		VAX
		PDP-11
		PDP-10 / -20

	   It's not far-fetched to have a computer with none of your favorite
	   languages on it, and for DEC's corporate implementation language,
	   it had better be implemented transportably and not depend on the
	   existence of a compiler for another language.

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

  Words of advice to the New Corporate Implementation Language Committee:

	1. Beware of people whose arguments boil down to "less is more":
	   they're all lying.  Less is less.

	2. Beware of people who say that it's more natural to do something
	   in one language than in another:  they're all perverts.
	   Programming a computer is an inherently unnatural act.

  -- Bill B.
================================================================================
  REX::MINOW                       Languages                 24-OCT-1984 15:32  
  Note #33.31            -{ New Corporate Language? }-                31 of 48  
--------------------------------------------------------------------------------
Beware, too, of people who say "not invented here."  (Or, to translate
it to DECese) "We'll lock people into our computers and gain a
significant marketing advantage thereby."

Beware, too, of people who say "more is more;", who need language
support for every microcoder's favorite widget.

Beware, too, of languages that don't have significant usage outside
of Dec, and of languages that our customers aren't interested in.


Martin.
================================================================================
  LATOUR::AMARTIN                  Languages                 24-OCT-1984 19:06  
  Note #33.32            -{ New Corporate Language? }-                32 of 48  
--------------------------------------------------------------------------------
The Vax may have shipped without a C compiler, but I'll bet it was the one
of the first things written for it by Bell Labs, which was then an arm of
what was then DEC's largest customer.

As far as the PDP-10 & PDP-11 shipping without Ada goes, I'll bet you'll
agree that Eniac first booted without a Fortran compiler also.
				/AHM
================================================================================
  BEING::PETTENGILL                Languages                 24-OCT-1984 21:20  
  Note #33.33            -{ New Corporate Language? }-                33 of 48  
--------------------------------------------------------------------------------
Martin:

Can you justify why one should beware of a language that doesn't have
signficant usage outside of DEC and of languages that our customers
aren't interested in ?
================================================================================
  REX::MINOW                       Languages                 25-OCT-1984 09:16  
  Note #33.34            -{ New Corporate Language? }-                34 of 48  
--------------------------------------------------------------------------------
re .32: Both the 11/70 and Vax-11/780 ran Bell Unix at fcs, if I recall
my history correctly.

re .33: This is mostly gut feel that we can't force our customers to
follow us wherever we might go; that, when our customers reject one
of our products, there is a lesson to be learned and it is not that
we are so much smarter than they are.  And, that our customers will
eventually get the products they want, if not from us, than from others.

I admit to a strong bias towards C -- I've programmed in essentially
nothing else for about five years now.   My programs and the products
(DECtalk) derived from them have made extensive use of C's transportability.
(The research version of DECtalk ran on an 11/60 running Unix, the first
in-house version ran on RSTS/E and RT11, subsequent development was
on Vax using Vax-11C, the product uses a stand-alone 68000, the follow-on
will probably use a different micro and several of the algorithms used in
DECtalk were taken almost without change from R&D work I did in 78-80.)

The demonstrated portability of C proved to be one of the major reasons
we brought DECtalk to market on time and under budget.

Martin.
================================================================================
  ELUDOM::ARSENAULT                Languages                 25-OCT-1984 11:21  
  Note #33.35            -{ New Corporate Language? }-                35 of 48  
--------------------------------------------------------------------------------
Reply to .34

I think you are implying that our customers rejected BLISS.

As I understand it, this is not true.  Our customers did not reject BLISS,
because DEC never tried to sell BLISS.

mark
================================================================================
  VAXUUM::DYER                     Languages                 25-OCT-1984 13:23  
  Note #33.36            -{ New Corporate Language? }-                36 of 48  
--------------------------------------------------------------------------------
	[RE .35 [RE .35]]:  Yes, but did AT&T try to sell C?  From what I
understand, C just kinda caught on because it was so useful.
	Then again, there *was* a book published, _The_C_Programming_Language_,
which the public could use to learn the language.  Did DEC do the same?
		<_Jym_>
================================================================================
  ORPHAN::BLICKSTEIN               Languages                 25-OCT-1984 13:38  
  Note #33.37            -{ New Corporate Language? }-                37 of 48  
--------------------------------------------------------------------------------
Having worked in the languages group for 5 years, I've never met anyone who
ever proposed that we try to lock people in with languages that aren't avail-
able elsewhere.

The typical view is more conservative.  The general opinion is that
we should offer standard languages with DEC extensions.  The customer locks
himself in only when he uses our extensions.  I believe this is the correct
approach in that it has the following advantages:

1)  We don't preclude migration to DEC (by offering standard languages).

2)  We don't force people into non-portability.  (This is very important
    given our fickleness with architectures and recent experience with
    LCG customers).

3)  We offer advantages to using DEC machines (extensions).

4)  These extensions lock customers into DEC.

	db
================================================================================
  BARTOK::BARABASH                 Languages                 25-OCT-1984 15:31  
  Note #33.38            -{ New Corporate Language? }-                38 of 48  
--------------------------------------------------------------------------------
  RE: .31

  Martin, if Bell Labs followed your advice there would be no C.

  Inventing your own language should probably be considered a last resort,
  but should not be ruled out a priori.

  -- Bill B.
================================================================================
  ADVAX::A_VESPER                  Languages                 25-OCT-1984 15:53  
  Note #33.39            -{ New Corporate Language? }-                39 of 48  
--------------------------------------------------------------------------------
Re .-1:  Martin's word was "Beware", as in "it may bite, so
be careful" not "Don't do it" as in "it's gonna kill you".

There are times when you should invent a new language, but
don't do it just because of NIH or other paranoia.

Andy V
================================================================================
  LATOUR::AMARTIN                  Languages                 26-OCT-1984 11:15  
  Note #33.40            -{ New Corporate Language? }-                40 of 48  
--------------------------------------------------------------------------------
I didn't percieve Martin's posting as an explicit slur on Bliss.  My
eyeballs pop out when I read such things, and I didn't feel them leave
their sockets.  Maybe he was just being too subtle for me.  I can't
complain about pointing out non-optimal aspects of the language, because
"If the shoe fits, wear it".

Bliss was originally done at CMU to implement some experimental software.
Nothing available at the time suited the people doing the work.

C was originally done at Bell Labs to implement some experimental software.
Nothing available at the time suited the people doing the work.

It's not as if the original creators of the languages thought they were
going to conquor the world with them (= zillions of $ worth of software
written in them).  It's sort of like the line from a Dune book that goes
something like "Regardless of how you explain me, I exist".

We can and should make rational decisions about implementation languages,
but that isn't always enough to get them carried out.  And there always
seems to be someone succeeding where others fail while they are busily
flaunting the rules.

C'est la vie.
				/AHM
================================================================================
  ORPHAN::BLICKSTEIN               Languages                 29-OCT-1984 14:51  
  Note #33.41            -{ New Corporate Language? }-                41 of 48  
--------------------------------------------------------------------------------
RE: 18, 21.

I made an incorrect statement.  PL/I, to my great surprise does have
overloading!  (Why not, it has everything else?)   In fact, it's definition of
overloading addresses my biggest objection to ada's overloading in that ada
will allow you to overload a name that you didn't intend to overload.  The PL/I
definition (called GENERIC) forces to declare an overloaded name.  Example:

	DECLARE FUN GENERIC( FUN_FLT WHEN (FLOAT),
		     	     FUN_INT WHEN (FIXED));

I think this is highly preferable to the ada method which has been justly
criticized as being error-prone.  This method makes overloading an explicit
operation which I think is the only acceptable method.

GENERIC is in both the FULL ANSI PL/I standard and IBM (which is not ANSI
standard conforming).

Gee, I'm rapidly convincing myself that PL/I should be the next corporate
language (and I don't even particularly like PL/I) if we're not going to
================================================================================
  LATOUR::AMARTIN                  Languages                 29-OCT-1984 16:15  
  Note #33.42            -{ New Corporate Language? }-                42 of 48  
--------------------------------------------------------------------------------
Re .41.1, .41.2:  (Looks like the file is messed up again)

Is this declaration used in every file or routine which uses the overloaded
function names, or where the functions are defined?

Some C implementations provide a "signal" subroutine which allows you to
specify that user-supplied subroutines be invoked whenever an asynchronous
event occurs.  Some C implementations provide "setjmp" and "longjmp"
subroutines which allow the user to save the SP, PC and ACs at a certain
point, and restore this saved state at a later time.  Taken together, they
provide the primitives for constructing (part?) of the functionality of
the Bliss CHF.  setjmp/longjmp do not have universally agreed-upon semantics,
and a debate about them is ongoing in net.lang.c.

Bliss has better exception handling support, as far as I can see.
				/AHM
================================================================================
  ERLANG::CAMPBELL                 Languages                 30-OCT-1984 20:10  
  Note #33.43            -{ New Corporate Language? }-                43 of 48  
--------------------------------------------------------------------------------
I have had to do perverted things with setjmp/longjmp in order to get
reasonable condition handling in a network transport module I'm writing.
What I *really* want is BLISS-style condition handling (which, by the
way, is stolen pretty much feature-for-feature from Multics).  Using
setjmp/longjmp I can emulate most of it, except for continuable
exceptions.  No way to do that at all (can't be done with signal,
either...)

- Larry Campbell
================================================================================
  ORPHAN::BLICKSTEIN               Languages                 31-OCT-1984 07:51  
  Note #33.44            -{ New Corporate Language? }-                44 of 48  
--------------------------------------------------------------------------------
I made an incorrect statement.  PL/I apparently DOES have overloading!  See
reply 19 to note 37.  So that's one less issue with PL/I.

I'm afraid that all this talk is leading me to the conclusion that if we
are to abandon BLISS that PL/I is the best replacement (believe me, I'm not
a big PL/I fan even if I am the project leader).  Reasons:

	1.  PL/I is robust enough for most applications.
	2.  It meets nearly all of the requirements Bevin outlined.
	3.  It is currently the best code generator of all the currently
	    shipping compilers.
	4.  I believe it has the fastest compilation speed of all our
	    compilers.
	5.  Aside from BLISS, it's the only compiler that comes with a
	    builtin fully functional preprocessor (C really only has
	    conditionals, PL/I allows compile-time programs).
	6.  It is already used very widely internally.
	7.  It is used very widely externally.   Very few professionals have
	    escaped college and work experience without some exposure to it.
	8.  It is the implementation language of many computer manufacturers
	    and system software providers.

Many of the notes so far that have suggested replacements for BLISS have offered
little more reason that "it's my favorite...".  Bevins note is the exception
and it carries more weight because he specifies WHY it should be ada.   I'd
be interested in hearing WHY it should be C, or Pascal or whatever.

By the way, my current opinion is that we should stick with BLISS as the
language of preference.  I still consider it the best for system software
and there is no compelling reason to change.

	db
================================================================================

I made an incorrect statement.  PL/I apparently DOES have overloading!  See
reply 19 to note 37.  So that's one less issue with PL/I.

I'm afraid that all this talk is leading me to the conclusion that if we
are to abandon BLISS that PL/I is the best replacement (believe me, I'm not
a big PL/I fan even if I am the project leader).  Reasons:

	1.  PL/I is robust enough for most applications.
	2.  It meets nearly all of the requirements Bevin outlined.
	3.  It is currently the best code generator of all the currently
	    shipping compilers.
	4.  I believe it has the fastest compilation speed of all our
	    compilers.
	5.  Aside from BLISS, it's the only compiler that comes with a
	    builtin fully functional preprocessor (C really only has
	    conditionals, PL/I allows compile-time programs).
	6.  It is already used very widely internally.
	7.  It is used very widely externally.   Very few professionals have
	    escaped college and work experience without some exposure to it.
	8.  It is the implementation language of many computer manufacturers
	    and system software providers.

Many of the notes so far that have suggested replacements for BLISS have offered
little more reason that "it's my favorite...".  Bevins note is the exception
and it carries more weight because he specifies WHY it should be ada.   I'd
be interested in hearing WHY it should be C, or Pascal or whatever.

By the way, my current opinion is that we should stick with BLISS as the
language of preference.  I still consider it the best for system software
and there is no compelling reason to change.

	db
================================================================================

You can implement continuable signals for Vax-11 C if you have written
all of the routines which call signal yourself.  (If you haven't written the
routines yourself, then someone else must have solved the problem before.)

What you need is a stack of routines which want to gain control of
a particular signal, and a routine of your own to actually be the
routine that gets control on a particular signal.

Where you would have an ENABLE declaration in Bliss, link the address of
the new handler routine into the head of the list.  Where you would
fall out of the scope of an ENABLE declaration, remove the first element
from the head of the list.  Establish a protocol between your own CHF and
the handlers so that you can tell when a handler was not able to take care of
a condition, and is passing the buck to the handler which was enabled before
it (the handler which follows it in the list).

Larry, the odds are that you have done more work with condition handlers
than I have, so are you complaining that the standard composition of signal
and setjmp/longjmp are still not powerful enough?  Is it that you don't
want to write it all yourself?  Where's your community spirit?  There had to
be some long-dead fool was first person to figure out that he couldn't type
out a file on Unix and ended up writing cat.  Now everyone can type out files.
If we are all going to build on the work of others, and you are the first
person to need continuable signals, you are obviously honor bound to
provide this feature for the billions of C programmers that are not yet born.

We'd all just like to say thanks for writing the package, and where can we find
the source files.
				Yours in the Unix philosophy,
				/AHM

Now that I think about it some more, I guess you could implement continuable
signals.  It wouldn't be easy.  It turns out that I was able to live without
them in my current project so I gave up quickly, and only implemented
non-continuable signals.  The details of how I did it are not pretty, and
it took a lot of standing on my head to keep both the C compiler and lint
happy.  If there's genuine interest, I can make the code publicly available
(after removing my comments about Kernighan's and Ritchie's ancestry...)

   C?  Be real.  Might as well just go ahead and program in MACRO.
   PL/I?  I believe I've heard it called the language for people who
          can't decide whether to program in COBOL (yech!) or FORTRAN.
   Pascal?  Nice, but too algorithmic.  Modula-2 might be better.
   Ada?  Might as well use Pascal or Modula-2, and some people may even
         have objections to connections with the DoD.

  Sorry for ruffling feathers.  I'm new to this notesfile, and after reading
through .0, et ceteris, I had an unsuppressable urge to come on out and
be blunt.  I have never seem BLISS, but I know about Digital's apparent
internal affinity(sp?) to the language.  I think you should wait a while
and wait till the dust settles in the big structures language war going
on.  Make that structured language war.  If Digital committed itself to
a new language, there's too big a chance for the one it picks to be one
of the ones lost in the crowd.

"Too algorithmic"?  I'm sure you intended it as a slur on the language, but
tell us, what does it mean?

It reminds me of the Phil Emma quote:

"Same to you and everybody else who looks like Donny Osmond"

Just to get this note started up again ...

Bill Keating sent out another memo this week (dated 3-Dec-1984) that says:

    By year end, I will initiate a process whereby our group will select
    a [preferred development] Language. We will then present our
    recommendations and our rationale to the DEC S/W Community.
    
He goes on to say:

    As the first step in the process, I will outline the goals as I see them
    for the new development language:
    
    1. Machine Architecture independence.
    
    2. Reasonable OS independence.
    
    3. Reasonable (within 10% of Bliss for Systems Software) efficiency.
    
    4. Positive Life Cycle effects on our programming effectiveness.
    
    5. Full required functionality (now, or within 1 year).
    
    6. Full participation in our emerging programming environment.
    
    7. Near Term, within 1 year, availability.

He goes on to say (as 'other thoughts'):

    1. Development Language may superset (subset) existing Language Products.
       This superset (subset) may never be a product. [huh?]
    
    2. A real win, for our strategy, would be an automatic BLISS to New
       Development Language Translator or Conversion Assistant.
    
The rest of the memo says essentially that Bliss will no longer be the
preferred development language, and that any new projects that start up after
a new language is selected must either use the new language or justify why
they did not use it.

In considering all the languages we have as candidates, the only ones I
see being seriously considered are Ada, C, and Pascal. Of these, I would
select Ada.

Jack    

Given Bill Keatings' goals I would also select Ada, but I disagree with one 
of his goals.  He seems to feel that it is bad to be tied to the VAX 
architecture.  What is bad about this?  Ken Olsen seems to feel that
VAX is the one in our "one system" strategy, so what is wrong with being 
tied to it?
    John Sauter

Choosing Ada makes the architectural independence problem interesting - it 
means we may need code generators (an modifications to other parts of the
compiler) within a year - for PDP-11's and for PDP-8's.  There will probably
be viable 68000 and 8086 targetted compilers within a year hosted on VAX/VMS.

/Bevin

  Keating obviously wants Ada to be the new system implementation language.
  I draw this inference from the requirement that there be a translator from
  BLISS to the new language, and the fact that the Ada compiler is currently
  written entirely in BLISS-32.  Not translating the Ada compiler into Ada
  would make it difficult to rehost on new architectures.

  -- Bill B.

I wouldn't worry about the 8, but there's still a lot of programming
being done for 11's and 20's.  Also, it is reasonable to assume
there will be a "new architecture" out within, say, 2 years.

(Rational:  PDP-11 was in house in 1968, Vax in 1976.  That's eight
years.   1984 is eight years further on.  I assume we're late as
usual.)

How much of Ada must be implemented?  All the task stuff?
Not sure I like that: we've had very good luck doing "tiny"
very-task-specific o.s.'s for C for several architectures
and would fear having to find an Ada environment before I
choose my cpu.

Martin.

The Federal Government won't allow partial implementations of Ada.
You gotta take the whole kit'n'kiboodle.
Tom

Thats true, but a static examination of an Ada program can determine whether or
not it uses tasking, and if not there is no reason to include tasking in the
rtl-stuff that you load to run the program.  Ditto for I/O.

Whilest getting Ada tasking working under VMS was a significant issue, we now
have that down pat (apart from cactus stack and debugging issues), and hence it
would probably be fairly easy to port that part of our VAX/VMS rtl even to a 
raw machine.  In fact we are currently moving it to VAXEln.

/Bevin

The Ada standard does permit some subsetting.  The garbage collector, for 
example, is optional, and VAX Ada does not implement it.
    John Sauter

re .10
	Bill, by the same argument, Fortran, Cobol, or Basic could be the
	next corporate development language.

re ?
	It's odd that Bliss is out of the running so soon.

	Also, ADA superset/subset rules don't apply if we use it internally,
	and call it, say, AKA.

	Personal bets: I think it'll be between Modula-II and Ada.

Using AKA, or VAX Charles (in honor of C. Babbage; not our project leader
C. Mitchell), would lose the main advantage - a truely portable implementation
language.


Since my list got lost, here's my attempt to reincarnate the potential wins.


1.  Dynamic bounds for arrays, and dynamic ranges for scalars.
2.  Tasking
3.  Exceptions
4.  Specification and Implementation parts
5.  Separate compilation  (ie. deferring the bodies of nested routines until
	a later compilation)
6.  Generics
7.  Recompilation and compilation automatically organised from sources
8.  Checking - VAX Ada makes a lot more of an effort to optimize these than
	other VAX languages do.
9.  Records with dynamically-bounded-array components (I saw these in a 
	recent spec. I had to review - if the spec. had been in Ada instead
	of Bliss it would have been much clearer what was going on)
10. Overloading
11. Access types with full checking, and its impossible to have an 
	uninitialized one in Ada
12. Optional parameters
13. Portable, even beyond DEC architectures.


Here's the losses.

1.  Ada might not get chosen.  In that case I would rather have Bliss than
    any of the alternatives so far mentioned.

2.  Ada is only a V1 compiler.  Bliss is old and very stable.

3.  Ada will require a great deal of re-education (but then again, learning
    Ada is supposed to add 10% to you salary according to various computer
    magazine surveys :-)

4.  Ada doesn't have Bliss's extensive macro facilities

5.  Nor does it have arrays of routines

6.  Ada's code quality may not be as good, since it is still young



/Bevin

	Would Ada fit on a PDP-11?  A PDP-8?  A Rainbow?

	Another question:  Do we really *need* a corporate language?
The language I choose to use depends a lot on the task I have to do.
Can any one language do all that?  Should we want any one language
to do everything?
		<_Jym_> (Kitchen Sink Buster)

re: .17--The BLISS compiler does not fit on a PDP-11, PDP-8 or Rainbow, yet 
BLISS is the present "corporate language".  (I understand there is a subset 
BLISS compiler on the PDP-11, but it omits some of the features that make 
programs transportable, such as compile-time conditionals.)
    John Sauter

Bevin:
    
Here is your list of the advantages of Ada over Pascal (and other 
structured languages). This note was in the Ada notes file on SPEEDY::. 


	- What are some of the major differences/advantages of Ada
	  over PASCAL ?

	- What are some of the major differences/advantages of Ada
	  over other structured programming languages in general ?


The Ada language was designed for developing multi-person, long-life-time,
programs.  It assumes reasonable technology to add in the creation of
programs (for example syntax-directed editing to cut into the typing burden).
It was not intended for 10 line programs!

An example of this is the way the language deals with I/O.  People comment on
the lack of I/O in the syntax of the language.  There is no need for it, because
(1) the language is powerful enough to express much of the necessary ideas, and
(2) because I/O is not expected to be a large portion of the lines of code of a
program.

With this in mind, here is the major differences/advantages...


(0) IT IS A RESTRICTIVE STANDARD.  IMPLEMENTORS ARE *NOT* FREE TO ADD WHAT
    THEY LIKE.

	This is potentially a HUGE win, if it works.  Because it is the only way
	to enforce portability.  It is true there are nonportable things that an
	implementation can add to the language, but they fall into only a few
	classes and it is VERY easy to write truely portable Ada.  The language
	is powerful enough to not require large numbers of enhancements to make
	it useable.

	Compare this to our current Pascal lineup.  We haven't even got
	consistency across our own line of machines!   Not even just on VAX,
	since VAX Pascal and the ELN Pascal are different in very significant
	ways.


(1) Separate compilation.

	I know VAX Pascal has it, and the Pascal standards committee is working
	on it, but the Ada standard has it now.

	Also separate compilation means more than just programs/modules as in
	VAX Pascal.  It means

	(a) being able to separately compile the body of a nested procedure.
	    This means you can correct the algorithm for the nested procedure
	    without having to recompile all the stuff around it.  Great for
	    development!  Its things like this that will make up for the slower
	    compilation speed.

	    $ ADA

		procedure COMPLEX_ENVIRONMENT is
		    lots-of-declarations
		    procedure SUBPROC is separate;
		begin
		    ...
		end;

	    $ ADA {some time later}

		separate(COMPLEX_ENVIRONMENT)
		procedure SUBROC is
		begin
		    ...
		end;


	(b) It means implementation & specification parts. (Packages and package
	    bodies for example)


	(c) It means elaboration order checks so that you don't use a
	    procedure/function before its had its static environment
	    established.  This is critical in languages like Ada where
	    types can have non-compile-time-constant shapes


(2) Numeric Accuracy and Range constraints

	Not even PL/I lets you say the equivalent of

	    type FLT is digits 6 range -100.0 .. 100.0;

	This lets you write algorithms whose accuracy is assured across
	all implementations, regardless of the underlying h/w.  If the
	implementation can't provide the accuracy you need, it can't compile
	your program.


(3) Non-compile-time-constant types

	S : STRING(1..some_arbitrary-non-constant-expression);

	No more guessing "is this buffer gonna be long enough for the worst
	case?".  No more wasted space.  Allocate exactly the space you need for
	this case.  Get the exact bounds-checking that you want for this case.


(4) Exceptions
(5) Multitasking

	Again, may be coming in Pascal; here in Ada.



(6) Generics

	Generics are like macros, in a way.  But they have the added virtue that
	they fully express exactly the requirements of the algorithm, and only
	have to be debugged once.  The later is because the semantic checks are
	done on the generic, not on the instantiation.

	For example

	    generic
		type SORT_ITEM is limited private;
		type SORT_BOUND is (<>);
		type SORT_ARRAY is array(SORT_BOUND range <>) of SORT_ITEM;
		with function "="(LEFT,RIGHT : SORT_ITEM) return BOOLEAN;
		with function "<"(LEFT,RIGHT : SORT_ITEM) return BOOLEAN;
		with procedure SWAP(LEFT,RIGHT : in out SORT_ITEM);
	    procedure SORT(LIST : in out SORT_ARRAY);

	expresses exactly the requirements of a sort-routine (the body of
	which I have placed at the end of this reply).

	This sort routine can be instantiated with any definition of "<" and
	"=", any type can be sorted, any discrete type can be used for the array
	index.

	So this routine, written just once, provides the algorithm for sorting
	an array of fixed-length-strings indexed by characters, or for sorting
	an array of floating-point indexed by short_short_integer!


(7) Aggregates


(8) Positional and Named notation for parameter-lists and aggregates


(9) Constraints on arrays, records, and pointers

	These let you express restrictions that goes beyond type checking.
	Here, for example, is a symbol table with a thread (NEXT_BUFFER),
	running through it that only passes through BUFFER_OBJECT's.


	    type NAME_TYPE is
		access STRING;

	    type OBJECT_CLASS_TYPE is
		(BUFFER_OBJECT, RANGE_OBJECT, MARK_OBJECT);

	    type OBJECT_TYPE(CLASS : OBJECT_CLASS_TYPE);

	    type OBJECT_POINTER_TYPE is
		access OBJECT_TYPE;

	    subtype BUFFER_OBJECT_POINTER_TYPE is
		OBJECT_POINTER_TYPE(BUFFER_OBJECT);

	    subtype RANGE_OBJECT_POINTER_TYPE is
		OBJECT_POINTER_TYPE(RANGE_OBJECT);

	    type OBJECT_TYPE(CLASS : OBJECT_CLASS_TYPE);
		record
		    NAME : NAME_TYPE;
		    case CLASS is
			when BUFFER_OBJECT =>
			    NEXT_BUFFER : BUFFER_OBJECT_POINTER_TYPE;
			...
		    end case;
		end record;




	- For which major applications development areas would Ada
	  be used preferentially over other programming languages ?

Large programs with long lifetimes, Ada wins hands down.

Applications other than report generation.

I used to argue that it wasn't suitable for operating systems or compilers but
now believe that, with the appropriate optimizations in the code-generator's,
and by use of the 'abuse the machine' features such as unchecked type conversion
etc., that in fact it could be used for these applications!  Furthermore if used
in this way the resulting o/s would be clearly delineated into portable and
non-portable areas.

In short, as the quality of the code generators improves, and the numbers of
experienced programmers increases, I think it could profitably be used for
almost all programming where C, Bliss, Pascal, or Modula-II is being used now.

Only time will tell however...


	- Finally, what is the real reason for having developed
	  another structured language, and its compiler ?

				$  $
			    $$$$$$$$$$$$
			 $$$$$  $  $  $$$$$
			 $$     $  $     $$
			 $$$    $  $
			   $$   $  $
			    $$$ $  $
			      $$$$$$$$$
				$  $ $$$
				$  $   $$
				$  $    $$$
			  $$    $  $     $$
			  $$$$$ $  $   $$$$
			     $$$$$$$$$$$
				$  $


with SYSTEM;
procedure SORT(LIST : in out SORT_ARRAY) is

    type INT is range SYSTEM.MIN_INT .. SYSTEM.MAX_INT;

    function "+"(LEFT : SORT_BOUND; RIGHT : INT) return SORT_BOUND is
    begin
	return SORT_BOUND'val(SORT_BOUND'pos(LEFT) + RIGHT);
    end;  pragma INLINE("+");

    function "-"(LEFT : SORT_BOUND; RIGHT : INT) return SORT_BOUND is
    begin
	return SORT_BOUND'val(SORT_BOUND'pos(LEFT) - RIGHT);
    end;  pragma INLINE("-");

    -- HACK : Avoids compile bug with merely renaming SORT_BOUND'pred/succ
    --
    function PRED(I:SORT_BOUND) return SORT_BOUND is
    begin
	return I - 1;
    end;

    function SUCC(I:SORT_BOUND) return SORT_BOUND is
    begin
	return I + 1;
    end;

begin

    if LIST'length <= INT'(1) then return; end if;                      -- Already sorted.
--  if LIST'length <= INT'(10) then BUBBLE_SORT(LIST); return; end if;  -- Small case

    declare

	-- Partition LIST into
	--
	--      LE_first..LE_first + LE_length
	--      EQ_first..EQ_last
	--      GE_last - GE_length..GE_last
	--
	-- then sort the LE and GE partitions.
	--
	-- This formulation avoids overflows at the ends of the range of
	-- SORT_BOUND.  The point of the EQ_first..EQ_last is to cope with
	-- large numbers of equal values quickly.

	LE_first    : constant SORT_BOUND := LIST'first;
	LE_length   : INT := 0;

	EQ_first    : SORT_BOUND := LIST'first + LIST'length/2;
	EQ_last     : SORT_BOUND := EQ_first;

	GE_length   : INT := 0;
	GE_last     : constant SORT_BOUND := LIST'last;

    begin

	-- Sort three values to get the splitting point to EQ_first.
	--
	declare
	    FIRST       : SORT_ITEM renames LIST(LIST'first);
	    MIDDLE      : SORT_ITEM renames LIST(EQ_first);
	    LAST        : SORT_ITEM renames LIST(LIST'last);
	begin
	    if MIDDLE < FIRST  then SWAP(FIRST,MIDDLE); end if;
	    if LAST   < MIDDLE then SWAP(MIDDLE,LAST);  end if;
	    if MIDDLE < FIRST  then SWAP(FIRST,MIDDLE); end if;
	end;


	-- Build the centre partition
	--
	while
	    LIST'first < EQ_first and then LIST(PRED(EQ_first)) = LIST(EQ_first)
	loop
	    EQ_first := PRED(EQ_first);
	end loop;

	while
	    EQ_last < LIST'last   and then LIST(SUCC(EQ_last))  = LIST(EQ_last)
	loop
	    EQ_last  := SUCC(EQ_last);
	end loop;


	-- Build the LE_ and GE_ partitions
	--
	declare
	    -- Flags that indicate when an end partition reaches EQ_ partition
	    --
	    LE_next : SORT_BOUND := LE_first + LE_length;
	    GE_next : SORT_BOUND := GE_last  - GE_length;

	    LE_DONE : BOOLEAN := (LE_next = EQ_first);
	    GE_DONE : BOOLEAN := (EQ_last = GE_next);
	begin
	    loop
		if not LE_DONE then
		    begin
			while LE_next < EQ_first loop
			    if LIST(EQ_first) < LIST(LE_next) then
				goto LE_NOT_DONE;
			    end if;
			    LE_next := SUCC(LE_next);
			end loop;
			LE_DONE := TRUE;
		    <<LE_NOT_DONE>>
			LE_length := SORT_BOUND'pos(LE_next) - SORT_BOUND'pos(LE_first);
		    end;
		end if;

		if not GE_DONE then
		    begin
			while GE_next > EQ_last loop
			    if LIST(GE_next) < LIST(EQ_first) then
				goto GE_NOT_DONE;
			    end if;
			    GE_next := PRED(GE_next);
			end loop;
			GE_DONE := TRUE;
		    <<GE_NOT_DONE>>
			GE_length := SORT_BOUND'pos(GE_last) - SORT_BOUND'pos(GE_next);
		    end;
		end if;

		exit when LE_DONE and GE_DONE;

		if LE_DONE then

		    if SUCC(EQ_last) /= GE_next then
			SWAP(LIST(SUCC(EQ_last)), LIST(GE_next));
		    end if;

		    SWAP(LIST(EQ_first), LIST(SUCC(EQ_last)));

		    EQ_first := SUCC(EQ_first);
		    EQ_last  := SUCC(EQ_last);

		    LE_length := LE_length + 1;

		elsif GE_DONE then

		    if PRED(EQ_first) /= LE_next then
			SWAP(LIST(PRED(EQ_first)), LIST(LE_next));
		    end if;

		    SWAP(LIST(PRED(EQ_first)), LIST(EQ_last));

		    EQ_first := PRED(EQ_first);
		    EQ_last  := PRED(EQ_last);

		    GE_length := GE_length + 1;

		else

		    SWAP(LIST(LE_next), LIST(GE_next));
		    GE_length := GE_length + 1;
		    LE_length := LE_length + 1;

		end if;

	    end loop;
	end;


	-- Sort the LE_ and GE_ partitions
	--
	if LE_length > 1 then SORT(LIST(LE_first..LE_first+(LE_length-1))); end if;
	if GE_length > 1 then SORT(LIST(GE_last-(GE_length-1)..GE_last));   end if;

    end;

end;

I would like to add another advantage of Ada over BLISS: training of new 
employees. How many new employees (particularly those coming from 
colleges) know BLISS? [I had never heard of it before.] How many of those 
new employees will know Ada? Won't Ada be taught in colleges a LOT more 
than BLISS [is BLISS taught in any colleges?]? I personally don't see new 
employees on the average taking much longer to learn Ada than what it 
would take them to learn BLISS. 

Jack

(from last note)

Besides, I would like that 10% increase in salary! :-)

Jack

  I don't look on training as an advantage for Ada.  DEC already has a rather
  large number of software engineers that know BLISS.  Having to retrain them
  all will be a big expense.  I also don't believe that in the future we will
  only hire software engineers that know Ada -- another big training expense.

  I believe that the decision to replace the DEC corporate implementation
  language should be based on the merits of the replacement language alone.
  The question is:  Is the new language a significant improvement over the
  existing one?

  -- Bill B.

3 out of the last 4 compiler developers hired for Fortran-10/20 already knew
Bliss-10, and one knew Common Bliss.  The exception was the also the only one
who was not a new college hire.  Only two of the four had exposure to Ada.

On page 58 of the '77-'78 CMU Comp. Sci. Research Review there is a black
and white photograph of a Bliss program to convert an integer into
Roman numerals.  It didn't say who got the PhD for the code, though.
				/AHM

The driving force between the "new corporate language" (i.e., the perceived
need for a corporate language) is the proliferation of micro chips.
While we don't care if our code ports to a Nova, some of us need to
transport code to 68000's, Rainbows, PDP-11's and so forth.

It is unclear why the old standard corporate language (Bliss) has apparently
fallen out of favor so easily.  Compilers for it already exist, giving good
code on Vax and Tops-20, and (cross-compiled) for the PDP-11.

Is it really less effort to retrain the entire software-engineering
universe to Ada to avoid retargeting Bliss to 68000's, 8086's, and
the new Dec architecture whatever that may be?  If so, why?

It might also be pointed out that Bliss already generates good code
for a moderatly well-known 32-bit single-chip microprocessor which
will undoubtedly find its way into terminals and other stand-alone
products in a year or so.

If we indeed change our corporate language, than all existing code written
in Bliss is just as orphaned as all the existing PDP-11 macro code
struggling to exist on VMS V4.0 (PRO Toolkit, for example).

The above are Dave Conroy's opinions.  He just wrote a messy, convoluted
data structure (that has different contents for VMS testing and 8086
on-board execution) that could have been hidden entirely in Bliss using
its more elaborate structure capability.  Since C is currently the
only transportable language, he had to spend an extra hour of work
to obtain a much less readable result.

RE: 24.

What makes you say that C is the ONLY portable language?  I've never heard
even the most fanatical UNIX fans make that claim.  What makes you think C
is any more portable than PL/I, FORTRAN, Pascal or APL?

	db

RE: .24

But our BLISS doesn't support 68000's now. Presumably, there will be an
Ada compiler for 68000's soon - from another vendor of course.

Jack

RE: .25

Dave:

I wouldn't say that C is the ONLY portable language. But, I wouldn't say
that it is less portable than PL/I or APL. How many micros have PL/I 
compilers (or would even want them)? Same for APL. Speaking only for myself
and my PDT at home, I do have a C compiler that allows me to transport
programs from this VAX to the PDT. The same goes for FORTRAN and Pascal.
I even had an APL image that would supposedly run on the PDT but I never tried
it.

Jack

What's the advantage of being able to generate code for 68000s, etc., other
than having to address the failure of DEC to respond to the market place in
I/O devices ?  A J-11 should be competative with a 68000 as long as you don't
need to use a Q-bus, and even with a Q-bus if you buy non-DEC gear you can
be very competive with 68000 based systems.

And if DEC produces a new architecture, its hard to beleive that a BLISS to
xxx translator would eliminate the need for a BLISS compiler for the new
architecture.  Can you imagine any project that would get a product currently
written in BLISS running after being run thru a translator ?  Either the code
will be completely uncommented or the comments will be the original BLISS
source.  Any programmer that already knew ADA would have to learn BLISS to
figure out why the ADA code wasn't doing what it was supposed to do.  It would
probably be more efficient to use BLISS programmers who had just learned ADA;
they would have a better understanding of what was going on and would be more
likely to write ADA code that was obvious and less machine specific.

The comment to the effect that the compiler might be a DEC specific version
that wouldn't be sold would certainly apply only to ADA.

One question which perhaps demonstrates my complete ignorance of ADA:

	Can ADA call all of the VMS system services and routines written
	in all of the other VMS compiled languages ?

Certainly one of the major features of VMS is ability to use the language
appropriate to the problem and mix languages within a system with a high
degree of flexibility.  I was just reading something in SIGPLAN to the effect
that a standard call interface would be a big win that didn't reference VMS.
Amazing !?

re: .28--Programs written in Ada can call system services and programs 
written in most (not all) other VMS languages.  The exceptions I know of 
are C and Lisp.  If a program written in C does any I/O then its main 
program must also be written in C, according to the C handbook.  This is a 
failure of C, not of Ada, but it impacts Ada, just as it impacts all other 
VMS languages.  Lisp is even more restrictive: programs written in Lisp can
call programs written in other languages but not the reverse--only Lisp 
programs can call other Lisp programs.  Again this is a failure of Lisp 
which impacts Ada and all other VMS languages.

There are, of course, limitations involving compatible data types which 
limit callability to particular routines, depending on their parameters.
For example, Ada doesn't support the CIT data type, so a subroutine which 
used this data type in one of its parameters couldn't be called from Ada.
    John Sauter

Re .28:

(An outside company which is trying to foist a Bliss-to-C translator on
us would strip the comments off, and leave most variable references with
an undecypherable cast prefixed to them, "just in case").

Re .29:

I doubt that calling C is so restrictive.  Bare user-written subroutines
ought to survive as well on their own as Bliss, I'd think.  I can't say
about the I/O issue, though.
				/AHM

Uhhmmm, yes, the VMS Calling so-called-Standard.  

(1) "This standard does not apply to calls to ... language support routines."
	(Appendix C)

	which means that the RTL went away and used weird conventions for
	things like OTS$POWHH because these were so obviously 'language
	support' routines, and compilers could generate the weird linkages
	required.

	Well, the Ada language DOESN'T HAVE a float**float operator, so
	OTS$POWHH is the first thing the user thinks of calling.  Then he
	discovers we don't support that linkage!

(2) "This standard requires LANGUAGE EXTENSIONS to permit the CALLING program
     to generate some of the argument passing mechanisms EXPECTED by the called
     procedures."

	so why is it that VAX Fortran, VAX PL/I, and others can't call
	VAX Pascal passing dynamic strings?  Because VAX Pascal expects
	CLASS(A) descriptors, and the others are generating CLASS(S).

	VAX Ada solved the same problem (of dynamic bounded strings) by
	adding CLASS(SB) to the calling standard.  Now we can't get called
	by ANYBODY because no other compiler's out there are capable of
	generating CLASS(SB) descriptors.


In short, the VMS Calling Standard is a nice ideal.  I have argued elsewhere
that, in hindsight, it has serious flaws in the standard.  More important is 
we are have acted/are now acting as though it is not important.  Talk about
biting the hand that feeds you.

And no wonder we are looking around for a single development language.


/Bevin

Sorry, I didn't mean that C was the only portable language, but
the only one of the possibilities available to us at the time
we started the project.  The alternative was Fortran (with no
assurances that a Fortran compiler would be available for the 68000).
There are many languages available with reasonable portability,
Cobol, Basic, and Mumps come to mind.

The 11/73 wasn't available at the time we had to decide on a
base-support.  While the code was running in-house on Unix (11/60),
RSTS/E and RT11 (11/23), we didn't doubt that we could work around
the addressing limitations of the 11, but heeded one of Gordon
Bell's laws: "don't do two new things." -- we had risks with
the technology (we have one of the first products using the TI\
signal processor chip) and didn't want to worry about time to market
if the 11/73 was late.

I believe that the problems with calling C from other languages
go away with VMS V4 -- you could ask in the VAXC notesfile on
ELUDOM:: if you're worried.

Don't forget that my needs are very different from most Dec
software developers.  I am building a terminal -- a piece
of hardware -- that just happens to have 128 Kbytes of code in it
and about 10,000 lines of C sourcecode that supports the firmware,
but is only run on VMS (dictionary builders and the like).
Our design strategy has been to debug the linguistics of DECtalk
on VMS and only use the actual board for hardware-specific testing.
We haven't fired up a logic analyser or in-circuit emulator for
a year or so, nor have we linked an ODT module into the 68000.

Oh yes, to put Bliss up on a new architecture should "only" require
rewriting the code generator.  It shouldn't require inventing a
totally new language.

Martin.

> If a program written in C does any I/O then its main program must also be
> written in C, according to the C Handbook.

	I couldn't find this in my copy of "Programming in VAX-11 C", so I
don't know exactly what you're referring to.  I do know that there are three
types of I/O you can use with VAX C:

	    o "Standard" I/O - Though C has no I/O as part of its
	      languaged definition, these functions have evolved
	      and are generally available with any C compiler.  I
	      use them all the time in mixed-language programming,
	      and I haven't had any problems.

	    o Unix I/O - Supplied with VAX C for compatibility with
	      Unix programs.  I don't use these very often, but I
	      suspect that most of their use is with Unix programs
	      which are almost always written in C (so the main pro-
	      gram is written in C, of course).

	    o RMS and QIOs - This is what I usually use.  As should
	      be obvious, there are no problems with mixed-language
	      programming here!

(RMS and QIOs) are presented as seperate things in the "Programming in VAX-11
C" book, but you get the idea.
	Like I said, I've often used Standard I/O from other programs (printf()
is the best function of its genre).  I don't use Unix I/O, but I really can't
say that you need main() to do those, either.  The link maps I get don't show
any dependency...
		<_Jym_>

re: .33
"Programming in VAX-11 C", order number AA-L370A-TE, software version V1.0, 
May 1982.  Page, 76, the first page of chapter 6, library functions.
The library functions are broken down into eight categories, one of which 
is I/O.  The handbook then says "Programs that use these library functions 
must contain a C function named main or a C function with the main_program 
attribute."

I haven't tried the functions to verify that they all fail when used 
without a C main program, but the implication is that if you don't have a C 
main program you shouldn't expect any of the library functions to work.
    John Sauter

	Yup.  That's what it says.  It says you can't use *any* C function
without having a main program written in C.
	I suppose it was true in V1.0, but it's not true now (even pre-V2.0).

	Then again, these functions aren't *really* part of the C language.
You just can't get anything done without them.
	(Actually, that's not true - you can call system functions!)
		<_Jym_>

After reading thru all the notes on our "new corporate language", I'm
puzzled about the genesis of this controversy.  It appears that Bill Keating
(or other management) has decided that it's time to trade in tired, old
BLISS for a new snazzy language.  Nowhere have I seen a clear statement
about what problem we are trying to solve, what criteria will be used to
select the new language, and why BLISS is automatically out-of-the-running.

Ward

[It's worth repeating]

After reading thru all the notes on our "new corporate language", I'm
puzzled about the genesis of this controversy.  It appears that Bill Keating
(or other management) has decided that it's time to trade in tired, old
BLISS for a new snazzy language.  Nowhere have I seen a clear statement
about what problem we are trying to solve, what criteria will be used to
select the new language, and why BLISS is automatically out-of-the-running.


Near as I can tell....  Management has realized that some new architectures
are coming, and that Bliss does not generate code for these new arcitectures.

Silly me. I might have thought it would be possible to fund BLISS to
generate code for these new architectures.

I, too, vote for keeping BLISS.

If a new architecture comes around that becomes a significant product then I
think it would be very easy to justify the need to make the necessary changes to
the BLISS compiler to support it.  One thing that I think many others have
missed is that any other compiler would also have to have changes made to the
code generator for any new architecture that the company develops.  Granted
there are a few compilers (FORTRAN, C, PASCAL, ADA) that should automatically be
transported to any new architecture, but these have not been our implimentation
language and writing a translator form BLISS to any of these would be a major
task. 

Rich

I've heard rumors that certain management folks are reconsidering their
anti-Bliss bias. 

Let's hope it's true. 

In any case, keep those flames coming!

mark

Of course, C, Ada, COBOL, FORTRAN, BASIC, etc., would all be bad choices
for the implementation language if the criterion was whether the compiler
generated code for the architecture, unless the architecture specified
direct interpretion of the language itself.

re .20 (reconsidering anti-Bliss bias)

	I'm glad to hear it.

	Considering the relatively low investment in Bliss (as compared with
	all the software yet to be written), and the relatively low cost of
	implementing or re-working an existing language (again, as compared
	with software developed in that language), the various vying languages
	should be on equal footing, and judged on by their merits, rather than
	on historical circumstances.

P.S.
	The "architecture" argument is just a result of an acerbic wit.

Let me start by saying I'm actually a closet BLISS fan.  It's a pretty
good language, with the best macro facility I've ever seen.

However, BLISS does make some architectural assumptions that are invalid
on certain classes of machines.  The one that springs to mind most readily
is that BLISS assumes that an address will fit inside a BLISS value
(%BPADDR <= %BPVAL).  This is not true on machines like the 8086/8088
family from Intel.  No doubt there are other architectures where this
is also a problem.  Given the way field selectors are defined in BLISS,
I think fixing this problem would be a perversion of the language (not
to mention breaking every BLISS program you tried to port).

Another problem is that BLISS only has one datatype, the BLISS value,
and can do arithmetic only on this datatype.  On 16-bit machines,
it's difficult to build useful programs with BLISS, since you're limited
to 16-bit quantities.  C recognizes this problem, and provides the long
type (32 bits) to compensate.

Notice I haven't even mentioned floating point.

re .43

Then again, its difficult to build useful programs on 16-bit machines
in assembly language, so I don't think that BLISS is the problem.  Of course,
a lot of software has been built for the PDP-11.  I think that the 16-bit
related problems are relatively minor for many applications, especially
those for which PDP-11s are well suited.

Re: .-2 

This is a problem of interpretation.   It just happens that on PDP11, VAX
and DEC10/20 %BPADDR LEQU %BPVAL.  The only thing that removing this
relationship is likely to cause is breaking of programs that assume it.  
Just like most the programs that I write in BLISS assume that a character 
fits in to one addressable unit and will therefore break on a DEC10/20.  As 
I only ever use PDP11 and VAX that's not really a problem.

I really can't see any justification for saying "there will be a Corporate 
Language ... it will not be BLISS".  That's just plain negative.  We have 
tens of thousands of lines of BLISS programs in the corporation.  The 
alternatives suggested are all in some way deficient - in some cases 
seriously so.  I am sure that to support those oddball people who use 
things like 68000, 8086/8088 and the like it would be cheaper to write new 
back ends for BLISS that retrain every person using BLISS.  Trouble is that 
when these were really needed - 2-3 years ago - nothing was done.

On what languages people know, PASCAL is probably the most widely taught 
language today that is block-structured.  C is also fairly widespread but 
tends to fall down on it's having not kept up with the times. ADA I don't 
know anyone who knows it.  My experience is that learning BLISS is easiest 
for someone who knows PASCAL (or ALGOL).

PASCAL, C and ADA all suffer from the one thing I *hate* most - strong 
typing.  People complain that in BLISS it's lack of typing makes it easy to 
program in bugs - I find that you just have to be disciplined to avoid 
this.

Why ONE language.  Every piece of software may well not be amenable to the
chosen language whatever it is, just as BLISS is not always the language of 
choice today.

Also - if you look at the subterfuges used to "avoid" using BLISS in the 
past it's quite clear that BLISS will still be used for the forseeable 
future.

I personally have an aversion to ADA as I do to military things in general. 
Unless there will be a guaranteed salary differential for people who can 
use ADA I will be *extremely* loath to learn anything about it at all, even 
then I'll be reluctant.

I will continue to use BLISS until someone can show that I should do 
otherwise.  Unfortunately at the moment I have gotten stuck with doing 
things on VAXEln, and there the only language is EPASCAL - ugh!!

Jeremy Barker - European Network Engineering - Diagnostics.

re .45:

> Re: .-2
> 
> This is a problem of interpretation.   It just happens that on PDP11, VAX
> and DEC10/20 %BPADDR LEQU %BPVAL.  The only thing that removing this
> relationship is likely to cause is breaking of programs that assume it.
> Just like most the programs that I write in BLISS assume that a character
> fits in to one addressable unit and will therefore break on a DEC10/20.  As
> I only ever use PDP11 and VAX that's not really a problem.

The problem is that addresses are manipulated very often in Bliss,
much more so than in most languages (consider Fortran).  Therefore my
prediction is that any successful implementation of Bliss will have
%BPADDR LEQU %BPVAL. If it takes 24 bits to represent an address, 32
bits will be used for the Bliss Value, even if 16 bits are sufficient
for most arithmetic purposes. 

> I really can't see any justification for saying "there will be a Corporate
> Language ... it will not be BLISS".  

I see two problems here.  Why do we need ONE corporate language?  It
isn't working out that way in practice, so why do we pretend that
there is only one? I suggest a small number of languages (2 or 3) and
give guidelines to help select one.  My choices:  Bliss for things
which will only ever run on Vaxen under VMS or PDP-11's under RSX.  C
for programs which will run on other CPU's such as 68000's, etc.  Any
others for general programming?  (Note that Pascal is not on my list. 
This was not an oversight; I dislike Pascal intensely.) Special
projects will always have their special languages (for example, LISP
for AI work). 

> I am sure that to support those oddball people who use
> things like 68000, 8086/8088 and the like it would be cheaper to write new
> back ends for BLISS that retrain every person using BLISS.  Trouble is that
> when these were really needed - 2-3 years ago - nothing was done.

Unfortunately, there are no backends for Bliss for alternate
processors. What can we do?  (1) Increase pressure on the Tools group
to write these backends and (2) use another language with a compiler
bought from outside (typically not the same quality as DEC-produced
compilers).  Is the Ada group listening?

> On what languages people know, PASCAL is probably the most widely taught
> language today that is block-structured.  C is also fairly widespread but
> tends to fall down on it's having not kept up with the times. ADA I don't
> know anyone who knows it.  My experience is that learning BLISS is easiest
> for someone who knows PASCAL (or ALGOL).

Pascal: Not even Wirth believes that Pascal is a good language for large 
programming projects (that's why he is promoting Modula-2). 

C: How has it not kept up with the times?  Why should it add something
new every two years -- that type of thing just keeps everything in
confusion.  I PREFER a simple, STABLE language.

ADA:  I expect this will become THE language in the future.  How far in
the future I don't know.  I don't know it yet, but I will probably learn
it within a year or so.

> PASCAL, C and ADA all suffer from the one thing I *hate* most - strong
> typing.  People complain that in BLISS it's lack of typing makes it easy to
> program in bugs - I find that you just have to be disciplined to avoid
> this.

C is generally considered to have weak typing because of the automatic
conversion from one type to another.  Pascal and Ada do have strong
typing, but it is a matter of opinion whether or not they 'suffer'
because of it.  The 'discipline' you mention is fine, but why should I 
keep careful manual track of how each variable is used when an 
automated tool can do it for me?

> Also - if you look at the subterfuges used to "avoid" using BLISS in the
> past it's quite clear that BLISS will still be used for the forseeable
> future.

Hmm?  The two halves of your statement seem to contradict each other.
When I look at the 'subterfuges used to avoid using BLISS' I see a
reason why Bliss will be quickly dropped if the 'corporate language'
blessing is removed.  What do you mean? 

Andy V

The VAX PL/I compiler is written in PL/I.  That has proved to be a tremendous
win.  We are both implementers and users of our product.  The knowlege and
breadth of experience with the language and the product that that provides is
priceless. 

It's my hope that the advantages of using your own compiler to develop your
compiler are considered sufficient justification for not using the corporate
implementation language.

(I am obviously ignoring the problems introduced when you are using a
bootstrapping technique for V1.  That's a secondary issue.)

	db

With the risk of putting my words in somebody else's note, I would interpret
that the fact of "subterfuges to avoid using BLISS" in favor of other
languages when BLISS is the de facto corporate language constitute an
existence proof of similar subterfuges to avoid using a new language in
favor of BLISS by those of us who prefer BLISS.

I happen to be a strong partisan of strong typing;  I find that just dumb
errors like getting the order of arguments to a routine wrong account
for 50% of the bugs I write, and a strongly-typed language prevents these
bugs from ever getting into running code.

Note also that, while C is "weakly" typed, if you use lint you can think
of it as quite strongly typed.  After having used lint for a couple of
months, I would never (willingly) go back to naked C.  And the nice thing
about lint is that it's optional;  if you just hacking a tiny program
together and don't care about portability or cleanliness, you needn't
use lint;  but on your big projects, that you'd like to keep portable,
and especially on hard-to-debug code like the Unix kernel, lint is a real
lifesaver.

Now, if Modula-2 ever gets a real I/O system, it'd be a contender (Mike
Powell's Modula-2 is REALLY nice, but of course all the nice features
exist only in his compiler, so your code isn't portable...)

RE: .-1

The lint that I used did nothing about checking parameters, variables,
etc. across modules. It only checked the consistencies in one module.

Jack

By the way, over here on the CREF project, we plan on providing a LINT-type
of tool, which will do sanity checking across modules and across languages
for VMS-supported languages.

This is a medium-term proposal, so don't get to excited. 

mark

Current lint (on Ultrix-32) does a good job of cross-module checking.
Invoke it as
	lint	file1.c file2.c ...
d
^oops

Martin.

Well, it looks like this discussion went for a while and then fizzled out
with no real answer - will there be a new corporate language.

One of the reasons that I started tracking this file is to try to come to
grips with what language I would like to learn next (and why).  As an aspiring
young software specialist, just celebrating my 1 year anniversary with DEC
today, I'm still trying to decide my future with the company.  One outside
thought running around in the back of my mind is that one day I might want
to be a part of corporate software engineering.  To accomplish this, I would
want to try to learn "the corporate language", hince the interest in finding
out what that will be.

At any rate, I'm glad this file exists, and thanks for the exchange of info.

Jim
(not a new noter, but new to this file)

Well, one large group is going to be extending VAXeln Pascal, and using that.

A smaller project chose C over Modula-2 and the extended Pascal.

The mainstream of the corporation participated in the initial requirements
for the extended Pascal, but I don't see it being adopted across the board.
				/AHM