Re: New language syntax

[A E Lawrence <adrian.lawrence@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

jm40@xxxxxxxxx wrote:
> 
> Hi All,
> 
> I was at one time very keen on introducing a more C-like syntax to occam or
> it's successor, but I've changed my mind a bit. 

Hooray! :-)

> I've never heard anyone complain about indentation in Python, so why not?
> Part of the reason is that Python is not so strict about the type and amount
> of whitespace that you use.  In occam you must indent and outdent by two
> spaces.  In Python it doesn't care how many spaces you use or if they are
> intermixed with tabs.  From occam classes, tabs put in automatically by the
> students favorite text editor are a large source of error.  All the lexical
> analyser should ensure is that the indentation is further in or further out
> than
> the current level.

An excellent idea. But like you, I like two spaces and the resultant
alignment.

> I, for one, will continue to use two spaces for indentation, but it wouldn't
> been too painful to allow for some extra flexibility.

> 
> With regards to program length and so on, we really need to find some way to
> make IF's shorter.  Is it just me or is:
> 
>   IF
>     condition
>       process
>     TRUE
>       SKIP
> 
> just a bit too long winded, when


I forgot that people complain about the wide open fresh clean space of
an occam program. In the days of paper listings, that might have been a
valid objection:
forests and all that.

Some things are complex and need a lot of code. occam encourages a
simple sparse - and thus elegant - style. If code is long, one's
attention is drawn to that. If it is unavoidable, start folding
heavily, if only to make it understandable. Dense impenetrable code is
encouraged by C and friends; unfortunately there are still people who
think it macho to write such stuff. Despite officially deprecating such
things.

I have to say that I really like the longwinded IF: but yes I have
sometimes felt slight irritation about writing several lines for really
trivial things. Time for a fold and fold replication... 

I like the idea that it is just a matter of representing the same tokens
which I think we discussed before. But whatever we do, we *must* have
two-way translation. Partly so we can translate when presented with
horrible syntax and understand what is happening. But also so that the
problems that Ian mentioned of maintaining two lots of documentation do
not arise: automatic translation can take care of that. Of course, we
must choose the C-like syntax to be *so* awful that everyone will turn
to the proper version :-) But then it is already...

So I need to add "long-winded/sparse_and_elegant"" to the list of
objections/strengths.

Adrian
-- 
Dr A E Lawrence