RE: New language syntax

[Tony@xxxxxxxxxxxx]

Isn't the loathing by some people of upper case keywords simply because of
the time it takes to hold down the CAPS key?

If this is the issue, then any parser should automatically change the case
to CAPS of keywords it comes across - in a sense, this is another compile
time error checking as it therefore highlights where a keyword was used
illegally. I suppose that it would have to ignore keywords when in comments.

Back in the old days, we were using 20MHz systems and thought they were
fast. Today, most of probably have systems running at 500MHz or faster, so
surely we can soak up a bit of this horsepower to make the front end do more
of our checking. Is it possible to sort out indentation automatically -
assuming that, unless nested, the indentation remains constant.

Also, do we have two issues here - one of structuring and manipulating code
(in some folding editor equivalent way) for efficiency, readability and
understanding (as well as catching trivial faults), and one of the actual
language.

Put the two together, and you have (for those who like it) the environment
and the language, but without forcing the environment on the language. And
for those of us who have to cobble together a mish-mash of HTML, CFML, XML,
javascript etc. all within a single "program" we would have a more
productive environment.

To quote from a Dutch guy who I just introduced to Cold Fusion for a
particular job

"I really like working with CF because it works intuitively and allows me to
work using plain text editors in stead of wit the fancy visual development
tools that take too long to learn. It's also surprisingly easy to develop
something with only a few constructs. The CF TAGS are really powerful."

For the curious, the CF TAGS he refers to look like HTML tags (but with
different names) but actually invoke pre-written and tested java. Yes, it is
not as efficient as writing the whole thing in Java, or PERL or whatever,
but in terms of getting an application together, it is highly productive.

For most people, that is what occam did for parallel programming - a simple
construct PAR and so long as you knew what behind the scenes constraints
there were on timeslicing so that you were not time critical, then you did
not have to worry about it and could just express what you wanted the
program to do in the way you thought about it (especially for hardware
engineers, for whom everything happens in parallel). 

My guess is if the environment and the language are suitably complementary,
more people would use the environment and then out of curiosity start
looking at the companion language. This is a backdoor way of spreading a new
language. The "dream" - an efficient environment that reduces progamming
mistakes and a language with formal basis and symantics that is provably
correct.

Tony Gore

email  tony@xxxxxxxxxxxx (alternative if problems tonygore@xxxxxxxxxxxxxx)
tel +44-1278-761001  FAX +44-1278-760006  GSM +44-7768-598570
URL: www.aspen.uk.com
Aspen Enterprises Limited
Registered in England and Wales no. 3055963 Reg.Office Aspen House, Burton
Row, Brent Knoll, Somerset TA9 4BW.  UK



-----Original Message-----
From: jm40@xxxxxxxxx [mailto:jm40@xxxxxxxxx]
Sent: Monday, December 18, 2000 5:45 PM
To: occam-com@xxxxxxxxx
Subject: New language syntax


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.  I think that using
indentation as a delimiter is a good
thing.  It only really upsets people when they don't understand when they
should indent and outdent (I remember being in a large group of students
bitching about occam's indentation).  Experience will teach those people how
to indent properly anyway, so it will simply speed their learning :).  Most
of us probably indent code the same way as occam anyway (i.e. we indent at
the start of a block and outdent at the end).  How many spaces are used,
where the braces go and whether tabs are used seems to be very personal.
Editing other peoples code can be horrible.

I have to agree with Ian Page that maintaining two separate syntaxes would
be a nightmare.
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.

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

The second question is keyword case.  I can understand why it is disliked by
some.  I think (like Adrian) that it is the BASIC connection that makes
people uncomfortable.  We should simply get around this by allowing lower
case keywords.  Using upper-case to distinguish keywords is less necessary
these days because of the widespread use of syntax highlighting editors.  I
always liked the way Peter writes occam by hand, with underlined lower-case
keywords.  Perhaps we could have a graphical folding editor that did that
one day.

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

  IF condition
    process

doesn't seem like a problem to me.  I know that enforcing the TRUE/SKIP is
supposed to make you think about covering all conditions (which is why it
acts like a STOP), but it really is pretty inconvenient to need FIVE lines
of code just to test a condition!  Unfortunately, we need to remember that
IF's can be replicated, so there is something of a syntax clash with my
proposal.  Perhaps we could keep the old style if and rename it RIF or
something...

Jim
--
Jim Moores, Quickstone Systems, UK.
> -----Original Message-----
> From: IanPage99@xxxxxxx [mailto:IanPage99@xxxxxxx]
> Sent: 18 December 2000 12:24
> To: P.H.Welch@xxxxxxxxx; occam-com@xxxxxxxxx
> Subject: Re: Software fault forces Ford recall
>
>
> In a message dated 12/18/00 12:00:19 GMT Standard Time,
> P.H.Welch@xxxxxxxxx
> writes:
>
> > I suggest that both concrete syntaxes (syntaces?) be
> allowed.  We could
> >  have a flag to the compiler to say which one to expect -
> or maybe that
> >  could be deduced fairly quickly and automatically?
>
> Peter,
>
> Please don't underestimate the problems of having a language
> with two syntaxes (inability to share code, two manuals, two sets
> of training material, etc., etc.)
>
> Also, with the occam experience to focus our hindsight, it should be
> very clear that the problems of introducing *any* new language
> to an uncaring world are truly awesome.
>
> Although it only covers a fraction of the syntax, so not all of the
> occam2 syntax and sematics problems have been addressed, the
> Handel-C language already exists, has many users, and is being
> pushed towards standardisation. If you do go ahead, it would be
> nice, eventually to have just one C-like syntax for occam around!
>
> Whatever your feelings about occam syntax, its ideas are clearly
> right and we have found that users do take readily to the
> C-like syntax
> of our occam-like language. There are now 110+ people employed in
> the company exploiting  Handel-C and some wonderful customer
> validation, so something must be right somewhere.
>
> With the best will in the world towards occam, I have agreed for
> years with Tony Hoare's assertion that "occam really should have
> *been* C"
>
> Prof. Ian Page,
> Founder, Celoxica Plc, (formerly ESL Ltd.)
> 8 Milton Park, Abingdon, Oxfordshire OX14 4RT
> www.celoxica.com
>
>