[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New language syntax

Dear all,

I am so pleased that occam-com has for once become an interesting forum
to be a listener to! I could never develop any enthusiasm for Java.

A few points:

1) Could I encourage posters use the subject line properly? Why on earth
conduct a discussion on syntax under a heading on automotive software?
Only Jim gas got it right and I am using his subject line.

2) Ian Page mentions:
>Tony Hoare's assertion that "occam really should have *been* C"
I don't understand what this is supposed to mean, but do remember life
at INMOS before there was an occam and one of things Tony Hoare did for
us was to propose a language that looked very much like BCPL. C had
not taken over the world in those days! 
3) I agree with Rick that agreeing a new syntax will be much more
difficult than implementing a parser. One thing that I am sure that
David May got right was to keep these matters in his own tight control
and stamp hardly on attempts by others to spend his valuable time in 
discussing their contributions to language design. There may be a few
features that we second class citizens (never been to Warwick
University) eventually got into the language, 
(eg CASE construct, counted array protocol) but not many!

4) It has not been made clear in this forum what is the impetus
for this bout of syntax discussion, but I hope that when we have all
had our say someone of appropriate calibre will shut himself/herself
away and do a single handed job. Any language that is too big for this
to be possible could not be a worthy successor to occam.

5) Finally my personal votes for points that have been discussed:

a) uppercase keywords are a good thing - PHW could have a special
   editor that uses underlined lower-case on the screen only!

b) any syntax, or stylistic convention, that has matching grouping
   brackets at different positions on the line is BAD.

c) curly brackets are too faint/small to be used as statement brackets

d) indentation is a good thing - I like Jim's suggestion on this
   that 2 spaces should not be the only unit allowed.

e) a folding editor is the best way to look at long structured texts

f) any attempt to curry favour with EMACS users will alienate vi users, 

6) In my opinion the worst mistake we made at INMOS in promoting the
Folding editor was cutting off existing programming teams who had an
established tool base from these tools by not making the TDS
representation of occam programs an ordinary text file.
In TDS3 (IMS D700E) I tried to rectify this, but was not allowed
by management to make this a documented feature. The TDS was then
killed and Julian had another battle to get his folding editor into
the toolsets. No wonder occam and folding got a bad name when the
world saw the company that had invented them lacking the confidence
to continue to promote them.
Michael Poole
15 Heather Close, STROUD, GL5 3QY
01453 759557