Conference turris::languages

I have used Simula and like it.  I learned it when I was working for
a professor who did some simulations.  I kept using it because it
was like ALGOL but was much better with string handling and I/O.

The simulation features (even when you don't fool around with "system
time") allows you to create objects which have their own variables
and code to work with the variables.  I would like to learn more
about SmallTalk which is a decendent of Simula.
						B.J.

I have a NOTES file on Summit dedicated to object-oriented software and
Smalltalk.

The lack of a usable implementation of Smalltalk within Digital doesn't
allow for much discussion.

[I'm currently attempting to validate some of the concepts of object-
 oriented systems (in terms of performance, etc.) for our group.  We
 are currently investigating using this style of system building for our
 next set of applications...  ]

- dave

	There's an object-oriented language called XLISP developed by some-
body in DEC (on his own time, I believe).  More details if I can find them...
		<_Jym_>

Re .2:

You should contact someone in the Vaxstation group in MR3.  One of the projects
going on a couple of years ago seemed to be planning to use Smalltalk to
write a lot of software.  I haven't heard anything about it recently, so they
might have given up.

Would someone who knows Simula and Smalltalk like to say anythign about their
similarities and differences?  I read part of an intro article in the Smalltalk
issue of Byte, and more concepts seemed to be renamings of what I have seen
in Simula than completely new inventions.  How much is really different?
(For instance, does thinking and talking about messages and actors get you
something that talking about abstract data types and their exported operations
does not?)
				/AHM/THX

Q:  "Does thinking and talking about messages and actors get you something
that talking about abstract data types and their exported operations does not?"

A:  First, lets rephrase the question, viz: "Is there any real difference
between an object-based approach and abstract data types and their exported
operations, where overloading of operators is allowed?".  The answer is no,
although an object-based approach will assume a simple way to use the same
source operation for several data types, and a weaker data typing facility.

					- Gilbert

re:.3 Available from the toolshed.

sar

Re .0:


Algol-68 has a tremendous reputation for being difficult to implement (or
for requiring incredible overhead at runtime to implement properly).

Does anyone know if this is because of being able to pass procedure
parameters by name to parallel clauses while standing on one foot, or
are there even worse things?

I have been hobbled in my attempts to understand this issue by the fact that
the two textbooks and two journal articles I have all describe different
languages.  And I am not talking about specific implementations, either.
They claim different things about the language.
				/AHM/THX

	I don't know whether this affects run-time overhead, but my 
understanding is that Algol-68 has an extremely complex specialized grammar...

						- Victor -

Learning ALGOL-86 is certainly more difficult than ADA.  From my point
of view,  the big advantage of both languages is that we do not
have compilers around,  so we can discuss them without taking the risk
of being denied by reallity! (:-)

For those who do not known,  there is a DEC SmallTalk implementation
(using a VT-125 and a VAX),  which have the interesting property of
changing a VAX-780 to a single user computer (if you have enough
memory to use it at all).  Waiting for a micro-VAX II to use it.

/jm

Most of the difficulty is caused by the fact that ALGOL 86 hasn't been
designed yet.

THERE ARE ADA COMPILERS AROUND - LET'S DISPELL THIS MYTH! THERE ARE NOW
FOUR VALIDATED IMPLEMENTATIONS - ROLM, WESTERN DIGITAL, NYU, TELESOFT
of which all but the NYU are usable.

/Bevin

Re .8:

I believe that it is true that the grammar used to describe Algol-68
is a major factor in making it difficult to learn from the language
deifnition itself.  One of my professors in college related the story
that he once came in contact with someone who was an acknowledged expert
on the subject, and that when actually put to the test, the expert and
the professor and a coworker together couldn't form the derivation of
a trivial phrase of a program from the grammar in a couple of hours of
work on it.

Algol-68 is (mainly) defined by a 2VWG (2 level van Wijngaarden Grammar).
This is basically a context free grammer which generates a context free
grammar.  This allows you to express rules traditionally relegated to
english semantic descriptions as syntatic productions.  The popular examples
of such rules are "all variables must be defined before being used" and
"no variable may be defined twice in the same block".  A 2VWG is no more
powerful than a context sensitive grammar, though I don't remember if
it is as powerful as one.  However, I don't know of anything about Algol-68
which cannot be expressed readably as the traditional pair of a context
free grammar and english rules.

As a matter of fact, I came up with a trial grammar for Algol-68 on the
basis of those two textbooks while I was in college.  By using regular
expression notation for common constructs such as optional parts, sequences
and lists I was able to put the whole grammar on 4 pages of paper.  The
trouble is that every time I read a new article on Algol-68, I find
some language feature mentioned which is not mentioned elsewhere, or worse,
the same thing described with different syntax.
				/AHM

RE: 1,9
The VAX workstation group gave up on Smalltalk because it is so slow.
Xerox Smalltalk runs on a pseudo machine.  Implementing that p-machine
on a VAX is very slow.  More work on the VAX implementation might gain
a factor of two or three in performance, but at least an order of magnitude
is needed to build an acceptably responsive system.

Xerox's machines (Dorado, Dandilion, Daisy) are designed to run P-code and
their micro-code implements the P-machine.  Dorado performance (3 mips)
is impressive.

Don't expect a reasonable DEC Smalltalk as long as the implementation is
bound to the VAX architecture.  Read about "The Design and Implementation
of VAX/Smalltalk-80" by Stoney Ballard & Steve Shirron in Smalltalk-80
Bits of history, words of advice by Glenn Krasner, 1983 Addison Wesley.

Has anyone heard of a language called BLADE? It is apparently being used
in Shrewsbury for wirting disk diagnostics (?).

Jack

Re Algol-68

This is bar none my personal favorite language - tho' in fairness I 
should say that this is because some 12 years ago I worked on the 
implementation of a compiler for a version called Algol-68R. This ran on 
(multiprocessor) mod-1 minis (a make now obsolete I am afraid).

As I recall the major problem in actual implementation was that array 
slicing, and variable dimension arrays were implemented by using a heap
architecture, and the machines of that time only had hardware 
implementation of a stack architecture.

However in fairness, Algol-68 (like Algol-60 before it) was really 
intended as an algorithm publication language, any actual machine 
implementations being seen as a bonus.

I freely admit that A-68 is a language that never really happened, and 
now probably never will. Someone suggested (I don't recall the note 
number) that ADA is easier to learn than ALGOL-68. This might be true, I 
really don't know; however I have yet to find an algorithmic contstruct 
that I cannot represent in A-68.

	/. Ian .\

PS Algol-68R is a substantial subset of A-68, derived by the (British) 
Ministry of Defense, and originally implemented on ICL mainframes, 
messrs Woodward and Bond.

re: .15--The fact that any algorithmic construct can be represented in 
Algol 68 isn't much praise.  Any algorithm can be coded for a Turing 
machine too, but I'd hate to write an operating system for one.
    John Sauter

Re .14,.15:

I don't think you understand what he meant, John.

Most of the semantic features that have appeared in programming languages
over the years appear in Algol-68 in some form or another.  Pointers to
pointers, dynamic arrays, nested procedures with up-level addressing,
*real* dynamic strings, call-by-(value, reference, name), loops with
all parts optional and having a default, array slicing, multi-tasking
and semaphores, manifest bound constants at runtime, I/O with format
specifications, bit twiddling . . .

All that is in there, and I don't mean you have to write a Turing machine
simulator to use it, either.

When I first read the June 1979 description of Ada, I thought that it had
almost every abstraction, packaging and strong typing feature I had ever
heard of rolled into it.  I had little to complain about.  Algol-68 strikes
off in a different direction, and since it predates a decade of thought
about language design, might be percieved to have a devil-may-care aspect
that makes it difficult to stand up to high standards of type-fascism, and
it is no doubt hard to completely implement efficiently.  But there is much
that is good in it, and it is really tantalizing to look at it and think
"a little subsetting here, a little twist of the semantics there, and we
could really come up with something that is beautiful *and* practical".
				/AHM

Oh, and user overloading of all the predefined operators, too.  *And*
respecification of the operator's priority.  (I figured I'd mention this
since operator overloading is the rage in the Corporate Implementation
Language description).
				/AHM

I realise that this discussion occurred so long agao that only new Noters and
Notary users will ever see this but I've used various Algol-68 compilers while
at University. We used it to teach structured programming and compiler design
together with some other more esoteric courses.

    The compilers I used were the Mod-1 Algol-68R compiler (yes we still used
the Mod-1 up until two years ago!! BTW. did you know that the person 
responsible for the OS on the Mod-1 and his chief programmer aer now working 
for Inmos involved with the design and implementation of the Transputer)

    An implementaion of virtually the whole of Algol-68 (I think) running on
a CDC 7600 and CDC 6400.

    A full version running on a Cray-1B, I didn't see this much, but I seem to
remember that this was some horrific Algol -> Fortran translator, took ages
(comparativly) to compile and micro-seconds to run!

    And finally the sub-set Algol-68R (I think) running on a Pr1me 750. The 
compiler for which set a semaphore when it was in-use to stop more than one
person compiling at once, it brought the system to its knees even then!

Just in case anyone IS reading this, I attended Westfield College, University 
of London which is where the Pr1me and the Mod-1 were. The Cray and CDCs were 
at the Univeristy of London Computing Centre.

Ian.

I went to the University of Bristol in England. A couple of programmers
at the regional computer centre ported an Algol 68 compiler to an ICL
mainframe and then ported it to Multics, although this was incomplete
when I left in 1981. The language was quite popular locally, but some
people were put off by its complexity, and considered it difficult to
fully understand.

Enthusaists would talk in a strange way using a vocabulary where the word
"ref" seemed essential to any phrase :-)

Coincidently, Inmos has its headquarters in Bristol.

    We wrote a complete operating system in Algol68.  Of course that
    was more than 1/8 century ago.  The compiler, Algol68-C, was fast
    and produced good code.  It was written by Steve Bourne (of Bourne
    Shell fame?) and Andy Birrell (who I hear is now wasting his time
    with RPC or some such nonsense /-)).
    
    Algol68 was a landmark language.  It had a formal definition which
    is more than most languages before or since.  I found the language
    easy to learn and use, but then I never read the report.  Reading
    a formal definition to learn a language is a bit like reading the
    source of VMS to find out how to submit a batch job. 
    
    It introduced the idea of orthogonality to language design.  This is
    something which a few recent languages could still take heed of.
    Another important advance was showing what could be done with strong
    typing.  This aspect of language design is still moving forward, for
    an example of the state of the art look at ML. 
    
    Algol68 did not distinguish between expressions and commands.  At
    the time I thought this a neat idea, but subsequent experiments
    with language design and implementation have made me think that
    the BCPL solution is a better one.  In BCPL commands are explicitly
    made into expressions with the VALOF, RESULTIS construct.  
    
    Example:
    
      a := VALOF { command; command; command; RESULTIS b }
    
    I cannot remember if this feature of BCPL ever made it into C.
    
    Of course there were a few mistakes.  The IO system was one of them.
    But the chief problem was that it took so long to get the formal
    definition correct and in a state where it was implementable that the
    language had become a laughing stock.  ADA probably took longer to
    define, but the process was managed better and the DOD bought support
    by making every influential computer science professor a consultant. 
    
    Ah well, back to programming in tacky, ill defined languages
    

Re .21:

>I found the language easy to learn and use, but then I never read the report.

It is alleged to be a killer.  Some professors of mine were visiting
some guy who was supposed to be an expert on it, and they said, "Hey,
let's trace out a tiny production to see how it works".  A few hours
later, they all gave up.

I found a copy of the revised report in the ZK library; maybe I'll attack
it some day.

>      a := VALOF { command; command; command; RESULTIS b }
>    
>    I cannot remember if this feature of BCPL ever made it into C.

Nope.  BTW, RESULTIS is called YIELD in SETL (not that I'm claiming it came
before BCPL).  When I've used this construct in Bliss, I've stuck a
macro named YIELD before the final expression (YIELD is defined to be
the empty sequence of tokens).
				/AHM

    The Report is rather mathematical and rather difficult to follow
    (W-grammars can get that way).  The language is rather nice though.
    
    The only major notion it's missing is some concept of packages,
    modules, whatever.
    
    (BTW it was the same Steve Bourne).
    
    Steveg

    The same Steve Bourne liked Algol so much, that when he wrote the shell
    for UNIX in C, he defined a bunch of macros so that the program looked
    like it was written in Algol.

Algol-10/20 is mostly implemented by a bunch of Macro-10/20 macros that
make the assembler look like Algol.  (And I'm not talking about something
as easy as making C look like Algol - the results of expanding the macros
aren't siphoned off and fed to a high level language processor, they
go right into the assembler).  "IF NEXTSYMB = COLON THEN ...".  It is
really weird, because whenever the macros weren't good enough, the authors
would fall back into assembler in midthought.

Presumably the people would have settled for Bliss-10, if only it had
existed at the time.
				/AHM

    re: .24
    
    Minor nit.  The Bourne Shell is written in an Algol-68 dialect of C.
    I think it had something to do with Bourne having written an Algol-68
    compiler at Cambridge (called Algol-68C). 

    I was the project leader for Algol-10/20 which was implemented in
    1970/1. It was a joint CMU-DEC project, CMU writing the compiler
    and us writing the OTS and library. We decided that Bliss-10 was
    not reliable enough at that time (there was also the problem that
    it required a 128K '10 to run and the largest machine we had in
    house was 64K). The first project to be written in Bliss was the
    optimising DEC-10 FORTRAN compiler, after CMU had overlaid the compiler
    to fit in our machines. At that time we also had to make a decision
    that the product was not distributed in source form as their were
    still KA10s with DECtape system device and 16K.
    
    There were two macro systems used in the DEC-10 Algol-60 compiler.
    As well as IF ... THEN ... ELSE, there was nested re-definition
    of labels TRUE and FALSE. The main module had the opdefs redefined
    to be inverted thus: IF <condition> THEN <do the next instruction>.
    Later, after I left DEC for 5 years, somebody changed it to straight
    MACRO-10 because they couldn't remember what the macros meant.
    
    A few words on Algol 68: I was involved in bootstrapping Algol 68C
    onto the DEC-10, but left before it was finished. Some 4 years ago,
    I was assisting Oxford University to boot RS-Algol 68 to VAX. It
    is the full language with extensions for system programming. MoD
    asked us to project manage it and market it, but marketing didn't
    think we could make it pay. Instead Scicon took it over and market
    it. The W-grammar definition of Algol 68 is not all that difficult
    if you find a good explanation of how it works. Reading Lindsey
    and van der Meulen's "An Introduction to Algol 68" is the best way
    to start - then proceed to the Report.
    
    BTW, some years ago, three of us in the UK (Hill, Wichmann and myself)
    rewrote the Algol 60 standard - it is now an ISO standard. A pity
    I had to agree to flush dynamic own arrays, as only three
    implementations do them - ours, Burroughs and a compiler written
    at Novosibirsk, Siberia. It's the only way I know to do Ackermann's
    function efficiently! We also disallowed/simplified the FOR statement.
    Do you know that it is possible to compute any computable function
    in Algol 60? I have a neat program to calculate the mth prime.