Conference turris::languages

Good question -- I've always wondered about that, too.  I learned programming
on Burrough's XALGOL (ALGOL plus the best string-handling primitives I've
ever seen outside of something like SCAN or SNOBOL, plus some other extensions).
During my senior year, someone came in and gave a talk about Pascal -- how
wonderful it was, how it was a superset of ALGOL, etc.  When I came to DEC
and found the TOPS-10 system they put me on had Pascal, I gleefully attacked
it and wrote some stuff on the basis of what he had said and some observations.
Aside from a few minor goodies (user-defined types, for example), Pascal
is such a miserably corrupted subset of ALGOL that I was quickly disgusted.
The stupid thing doesn't even have blocks!  

Even Wirth has (supposedly -- I never actually heard him say it) admitted
that Pascal is no good for real programming.  Why the hell is it so popular?

	/dave

Disregarding ALGOL-68 (which is a beautiful language, but seems never to
have gotten a chance), the only "standard" ALGOL is ALGOL-60.  ALGOL-60
is a stunning achievement for its time.  However, compared to Pascal,
it has some major deficiencies:

	(1) Types.  The only data types in ALGOL are INTEGER, REAL, and
	BOOLEAN.  The only data structure is ARRAY.  There are no records,
	no pointers, no enumerated types, no user-defined types, no sets,
	no strings (I know, standard Pascal has a poor excuse for strings
	too), no characters.

	(2) I/O.  Standard Pascal I/O may be simple-minded, but it's simple
	and useful.  Originally, ALGOL didn't have I/O in the standard at
	all.  The I/O that eventually got standardized was complex and not
	nearly as elegant as the rest of the language; and half of the
	implementors who had already implemented their own I/O didn't
	bother to go back and change to the new standard.

	(3) Control structures.  The control structures in ALGOL are
	IF-THEN-ELSE, FOR-DO, WHILE-DO, and SWITCH (an array of labels).
	The WHILE statement is (by modern standards) peculiar -- you
	have to have a control variable, so when you try to do structured
	programming in ALGOL, you frequently end up writing "FOR DUMMY := 0
	WHILE <the real test> DO ...".  SWITCHES are just a slightly prettier
	version of a computed goto -- there is no CASE statement.  And there
	is no REPEAT statement -- a theoretically trivial, but practically
	annoying omission.

	(4) Implementation.  ALGOL was designed "in the abstract", and when
	it came time to implement it, some features were found to be very
	difficult to implement, or impossible to implement efficiently.
	Pascal was clearly designed to be a subset of ALGOL, extended in
	the areas of data typing and control structures, but with all features
	carefully selected for implementability.  All the features in standard
	Pascal can be implemented efficiently with a moderate amount of effort.
	There are no difficult features like the local variables whose size is
	calculated at runtime, or the wonderful, beautiful, bizarre call-by-
	name parameters.

I loved ALGOL, too.  (I think ALGOL-68 is even more beautiful.)  But I believe
that Pascal was a brilliant compromise between features and implementation,
.

	-Neil Faiman

I learned ALGOL, but quickly started using SIMULA instead.

It has several advantages over ALGOL:

    - You can build data types.  SIMULA was designed for simulations
        and has a scheduler and primitives to create several co-processes
        and switch between then.  I did do many simulations in SIMULA,
        but the "class" concept was useful for any program.  It let you
        define object which had their own storage (RECORDs in PASCAL).
        You could also define functions which worked on these objects --
        you could have code for an object which was executed when you
        created the object to take care of initialization. SIMULA was the
        concept which later became SmallTalk.

    - String types are much nicer to use than what ALGOL defines.
        Strings were implemented as a SIMULA class.

    - The I/O is standardized and quite nice.  Because the buffers
        were strings, you could use the nice string routines to manipulate
        the input and output (whenever the operation was not covered by
        any of the I/O operations).

    - It also had a much nicer debugger than what was provided for ALGOL.
        I haven't seen anything better until the current VMS debugger.

						B.J.

re: .2--As is hinted at in .3, ALGOL-60 does define strings.  Unfortunately 
all you can do with them is pass them to other routines.  I learned ALGOL 
on the B5000 in 1963, and I liked it a lot.  I even added a CASE statement 
to the compiler, at the request of Professor Wirth, so he could see if it 
was useful.
    John Sauter

Re .3:

What system was the Algol on?  And the Simula, for that matter.  I am
trying to get a grasp on your comparison of the two debuggers.  (There
was more in SIMDDT than in ALGDDT on the -10, but I don't recall any
earth-shaking features in the SIMDDT).

Re .4:

Maybe it was a reference to an extension over the basic strings in Algol-60.
Those strings don't deserve to be mentioned anywhere but in a trivia
contest, they are so token.
				/AHM/THX

Strings: XALGOL (Burroughs B5700 and B6805) used what they called "pointer
expressions" -- statements like SCAN and REPLACE, with pointer update and
conditional clauses.  These were quite complex (they were described only
very briefly and cryptically in the XALGOL manual -- there was a separate
POINTER expression manual just as large which went into detail) and extremely
powerful.  Certainly there was no resemblance to standard ALGOL-60 strings.
I've never seen any general purpose language with more power string
manipulation.  Of course, the fact that I was one of two people in the college
(and neither were professors) who had the faintest idea of how to use pointers
was probably a strong factor in my fond memories ...

XALGOL also included CASE (although I didn't like the syntax much), WHILE
loops without control variables, and the best macro facilities I've seen
outside of Bliss -- very powerful and comprehensive (and accordingly complex).

The B5700 operating system (MCP) was written in an XALGOL superset, ESPOL;
the time sharing subsystem was in TSPOL (an ESPOL variant), the XALGOL compiler
was written in ESPOL, and everything else was written in XALGOL (the COBOL
compiler even translated COBOL into XALGOL and then compiled it -- luckily
I never had to use COBOL; it weren't fast).  For history freaks, the B5700
was the first computer to use virtual memory (7 years before IBM decided
to "invent" it).

I think I'm rambling off the subject a bit -- oh well, it's Friday afternoon.

	/dave

I used SIMULA under TOPS-10.  The debugger may not be earthshaking,
but there are still many debuggers which can't show you the source
code of the program you are debugging, set conditional breaks,
automatically type out variables on breaks, set the scope of the
debugger to whatever you want, etc.  That became my base for a
good debugger and nothing raised my expectations until the VMS
version 4.0 debugger with screen management.
						B.J.

I, too, loved XALGOL ten years ago.  When I came here, I tried to convert a
bunch of old code to DEC-10 ALGOL.  I ended up tossing most of it - the
fancy string manipulation code was far too useful, and I had heavily used it.
My code came from B6700/B7700 Burroughs machines.  These days, I like
Pascal, when I can get it, or Modula.

   My current CS course at college (Data Structures and Processes) is being
taught using MODULA-2, and I've become reasonably familliar with it lately,
so I might be able to shed some light about it.

   For the most part it's like Pascal.  Here are the real differences I
can think of off the top of my head:

   1) No builtin I/O.
   2) All routines are built as primitives.  For instance, READINT and WRITEINT
      to do I/O with integers.  WRITELN is a procedure which merely prints
      out a blank line.
   3) The compound-statement concept is right out.  All constructs (except
      for REPEAT) which have iterative or conditional code require an
      END statement.
   4) Functions are not functions.  They are 'function procedures'.  The
      the only real differances are that in the function declaration,
      the word "procedure" replaces the word "function" and instead of
      assigning the function-name the value, there is a statement,
      RETURN x, which returns 'x' as the value of the function.
   5) Well defined inter-module interaction.  For each external module,
      there is a "definition module" and an "implementation module."  The
      definition module is the definition of what the calling routines
      may know about the code, and the implementation is just that.  If its
      not defined in the definition, the calling procedure MAY NOT use it.
   6) Case sensitivity (blech.)  Luckily the compiler on the UNIX (blech!)
      systems at school I'm using do not implement the case sensitivity.
   7) Obviously a multi-pass compiler now.  With the old "FORWARD" declarations
      I think the Pascal compiler only needed to execute one pass on the
      code.  Oh, the point.  No more FORWARD declarations.  Any identifier
      (allowing for scope) may be referenced anywhere.
   8) New data type:  CARDINAL.  Its an unsigned integer which is NOT
      compatable with the INTEGER type.  It has all its own I/O routines,
      READCARD, WRITECARD.
   9) I forget the real name for it, but dimensionless arrays in procedures.
      Not dynamic, but the high bounds for an array passed to a procedure
      need not be specified by the procedure.  A builtin function, HIGH
      returns the highest index value.  (Regardless of the original bounds,
      new bounds become [0..high(x)])
   10)New implementation of sets.  I haven't work with it enough yet.
   11)Process type.  Evidently something dealing with concurrent processing
      and multi-tasking modules.
   12)all sorts of other neat stuff I can't remember now.

  Modula-2 is an even more strongly typed language than Pascal is, but I
am becomming more and more accustomed to it.  For direct control of the
registers and stuff, it's not C or BLISS, but it certainly allows a great
deal of control over the working environment and low-level interfacing.

  P.S.  Still no strings.  Matter of fact, by language definition, the
        only string (ARRAY [x..y] OF CHAR) operations allowed are equality
        and assignment.  Pretty soon, you write a string module and tuck 
        it off somewhere for later use.

                                           -MJG

	For those not familiar with Modula-2 but who would like to try it,
there is a VAX Modula X1.0-1 compiler available.  More details can be found
in the Modula notes file in ELUDOM::SYS$NOTES::MODULA.NOT.

	There is a working group of the British Standards Institute currently
looking at standardizing Modula.  They are considering adding a STRING data
type which would be a distinct from but assignment compatible with ARRAY OF
CHAR of the appropriate size.  For the most part Modula is an extension of 
PASCAL with essentially the same syntax and semantics.  Some of the keywords
are different, but there is usually a 1-1 correspondence with the old one from
PASCAL.

	The previous note (9?) indicated that the I/O functions are builtins -
they are not.  They are separately compiled RTL routines for which there
exists a DEFINITION MODULE that defines the interface to the RTL support.
In this respect Wirth has taken the C approach, in that there is NO i/I/O
support in the language AT ALL.

	Modula would be my language of choice if there existed a VAX Modula
product.  I too grew up on ALGOL-60 and then PASCAL; I believe that Modula
is very much superior to either of these for a number of reasons.  I would even
go so far as to say that Modula is what Ada should have been, but then again 
my views on that issue are weel known in the VAX Languages group!

chris.

	An apology is in order.  In the previous note (10) I indicated that 
the person who entered note 9 said that the I/O functions were builtins.  He
did not say that - I misread his comment.  He indicated that they were 
primitives.  I am not sure I would describe them that way either.  All
of the "standard" I/O functions are separatley compiled RTL routines, some of
which were writen in Modula.

sorry,
chris.

    Re .2: the original Algol 60 I/O was an ISO recommendation, not
    a standard, and several years ago was withdrawn. The ISO Algol 60
    standard (based on the "Modified Report on the Algorithmic Language
    Algol 60 ...") defines a fairly simple I/O system, most of which
    is written in Algol 60. I can provide paper copies if required.

    ALGOL is wonderful. I learnt everything in ALGOL68. I've never used it
    commercialy. My life would be complete if I could go back to it.
    I can remember directly implementing a decision table in ALGOL using
    boolean operators. It was wonderful. Surely the bast way to design a 
    language is on paper. It does what you want it to do, then design the
    machine around it. As a basis for learning programming I think nothing
    could beat ALGOL.  All the main concepts are there and they are clear.
    
    Anyway, its dead now so onwards we shall go!
    P.

    Algol68 is a completely different language from Algol60, and has
    suffered greatly from the impression of being a "follow-on" language
    that the name gives.

    I agree that Algol68 is wonderful.  I wish Ada had been designed using
    more of the lessons that were learned from Algol68.  Still, Modula-3
    has adopted some of the neat features from the language.  Algol60
    sucks, although it does have great historical significance in the
    evolution of computer languages.  A VMS implementation of '68 is
    available (and selling in small numbers), so the language isn't quite
    dead (although it's admittedly a little the worse for wear).
    
    John

    I also find Algol68 wonderful and one of the most powerful and
    sophisticated languages ever. This language appeared too early in the
    computer society and this was its main problem. I still think it could
    actually be reactivated with all its power due to the progress of the
    hardware/software. I know quite little about Ada so I cannot compare,
    but for the rest I do not know any language so powerful and complex as
    Algol68 (it was also designed with high performance in mind).
    
    Sorin

    I also liked Algol-68 since it as/was an expressive language, the only
    one I know of except BLISS. High performance - well, the compiler I
    worked with (on a TR440, an old german Telefunken computer) needed
    twice the time of the Pascal compiler for compilation and the generated
    code performed very poor (also twice the time).  What I've read,
    Algol-68 has been as well as PL1 a nightmare to any compiler writer.
    Maybe the most severe drawback of the language has been the Reference
    Manual, one of the follow-up books has been called ``Algol-68 with
    fewer tears'' and that for good reason.  The manual has been written
    recursively, i.e. you had to know the meta-language in which the manual
    was written before you could read the manual, and, of course, the section
    explaining the meta-language used the meta-language to describe the
    meta-language (pretty much meta in here :-).
    
    				Walter
    
    P.S. What I've heard, even F.L.Bauer, one of the inventors of the
    language does not use it any more in his courses (at the T.U. Munich), 
    maybe due to the lack of a compiler.

    One thing I forgot to ask - is there a Algol-68 compiler on the Easynet
    available?
    
    	Walter

    I agree that the first Algol-68 compilers were not too far from
    academic use but the language was so advanced and complex that it
    necessited more time to have some efficient compilers.
    I remember in 76 and 77 I followed at the Brussels Free University
    courses about compiler theory based on an Algol-68 compiler. The
    professor was P.Branquart, one of the compiler's authors and member of
    the Algol-68 group. As I understood Algol-68 was designed to allow high
    optimization also but probably it was so complicated to write an
    initial compiler than no-one arrived to the optimization issues. The
    compiler we had was quite fine but running on an obsolette machine
    (there were surely ulterior versions but I have no more information).
    PL/I is aparently even much more complicated to compile (but IBM was
    there so ..) than Algol-68. Personally I never liked PL/I which I found
    beeing a mixture of features far from the beautiful and powerful
    Algol-68.
    
    Sorin (who's still melancholic about Algol-68)

    Algol 68 isn't a language that's particularly difficult to write a
    compiler for.  I was (peripherally) involved with the porting of
    Algol 68-RS to VMS some years back (this compiler is available from
    System Designers in the UK), and gained a reasonable understanding with
    what such a compiler has to do.  Admittedly, the RS dialect left out a
    couple of the more complex features of the revised-report language
    (parallelism in particular), but even so, the essentials were still
    there.  Also, RS had a proper seperate compilation mechanism,
    supporting cross-module type checking and consistency checking, not
    that dissimilar to the Ada program library, although lacking much of
    Ada's information hiding ability.
    
    The RS front end is completely portable, and does the essentials like
    type analysis and coercions, moving declarations up to the front of
    blocks, resolving scoping conflicts etc.  This produces an intermediate
    language ("Stream Language") that isn't really that far from Algol 68
    in level (except that it's coded for machine-readability rather than for
    human generation), but in which all operations are explicit, and ordered in
    a way that's most natural for code generation.
    
    The back end just generates code from the stream-language.  The VMS
    back-end didn't do very much in the way of optimization (at least not
    when I last saw it), but the resultant code performed reasonably well in
    comparison with code generated by other compilers (maybe because Algol 68
    encourages programmers to concentrate on algorithms, leaving the compiler
    to sort out the details of lower-level stuff, thereby allowing a few common
    code-generation optimizations to have more of an effect than they might
    in lower-level languages?).
    
    Both parts of the compiler are written in Algol 68-RS (actually, a subset
    of RS that doesn't use the heap, making bootstrapping a new compiler
    port easier).
    
    A significant part of the run-time system is written in Algol 68-RS,
    too, and is machine-independent, but even so it was the RTL that was
    the most difficult part of the port (the garbage collector in
    particular).
    
    Overall, an Algol 68 compiler isn't that complicated - the
    orthogonality of the language benefits the compiler-writer almost as
    much as it does the programmer.  Compiler techniques have probably
    advanced significantly since the days of the revised report.  It's
    certainly a far easier language to compile than Ada is.