On 15/08/2005, at 9:11 PM, John Allain wrote:
I'm more
than happy to hear why others think BLISS is so bad.
Similarly, not knowing either case, I would be interested in hearing
why BLISS is good.
OK, from my viewpoint (based a lot on BLISS-10 but I've done BLISS-32
programming as well).
Good features (IMHO)
1) No GOTO - probably the first systems programming language to be
designed without one.
2) Generated good code - considerable emphasis was made to ensuring
that BLISS-10 could be used to replace assembler.
3) Everything is an lvalue. BLISS uses the "." operator to get the
contents of an lvalue. So what in most other languages would be
written as i := i + 1 becomes i := .i + 1, unless of course you want
to put the address of the location after i into it.
This of course, led to lots of stupid programming errors, my favorite
one (and one that lead to lots of interesting effects) was a bit of
code that read something like
WHILE work EQ 1 DO
lots of code
OD
Of course, given that this code effectively said, while the address
of work is 1 do "lots of code" lead to the optimizer eliminating lots
of dead code and a very small executable :-)
Everything as an lvalue works backwards to the way c does it and
allows you to do really neat stuff with indirect addressing. It makes
call by value and call by reference far more obvious. Combined with
user defined structures (see point 4) this allows very elegant
structure manipulations.
4) User defined structures. You can set up a structure to define data
structures. This is very analogous to c struc.
5) Modules. BLISS was designed from day one to support modules and
all the necessary things to allow them to be linked against each other.
6) Co-routines were part of the language. Of course, I don't think I
ever used this but it's there.
7) Macro processing is built in, not an add-on.
Huw Davies | e-mail: Huw.Davies at kerberos.davies.net.au
Melbourne | "If soccer was meant to be played in the
Australia | air, the sky would be painted green"