• bearophile (30/38) Apr 17 2011 I am having some troubles with D newsgroups.

bearophile <bearophileHUGS lycos.com> writes:

I am having some troubles with D newsgroups.
Through Reddit I've found a kind of little online book, 13 HTML pages, about C
and other languages:
http://www-cs-students.stanford.edu/~blynn/c/index.html


Instead, I was enchanted by Eiffel, a language so clean that it’s sterile. I
became a rabid Eiffel zealot, even trying to prove its superiority in a
programming contest. Long time no C. Then during grad school, I ported one of
my pet projects from Eiffel to C. I forget why. Normally I'd mix C and Eiffel
to talk to the graphics library, but perhaps I had tired of writing glue code.
I slowly awoke from a dream, or more accurately, a mild nightmare. My C code
also worked, except it was faster. It was more concise, which in turn made it
easier to maintain. It was... better.<

I think that using higher level languages has trained him to understand and use
some abstractions. Later he's able to implement them in C too.


The pages also link a short article about Fortran, that says:
http://www.ibiblio.org/pub/languages/fortran/ch1-2.html
Fortran 90 allows explicit pointers restricted to point only to variables
declared with the "target" attribute, thus facilitating automatic
optimizations.<
Fortran disallows aliasing of arguments in procedure-call statements (CALL
statements and FUNCTION references), all passed argument lists must have
distinct entries. Fortran disallows also aliasing between COMMON (global)
variables and dummy arguments. These restrictions allows better compiler
optimizations.<


The pages explain why Haskell lazy lists are a very good idea, useful and handy
for many situations. I agree with the author, they are very different from
D/Python lazy ranges.

------------

Some of the things the author desires in an improved C language (I have omitted
several already present in D):

- Multiple return values: After writing the first version of a function, often
I want to have the function return more data, such as an error code or
diagnostic data. I’m forced to add an extra pointer parameter, somehow encode
it into the return value, or define a one-off tuple struct. Multiple return
values would be much simpler.

- Flexible array ranges: Arrays indexed from ranges other than [0..N-1]
sometimes better fit the problem at hand, for example, an array of triangular
numbers. The venerable "Numerical Recipes in C" advocates this hack:
float b[4], *bb = b - 1;
The elements of b can supposedly be referred to as bb[1] through bb[4].
Unfortunately, section 6.5.6 of the C99 standard appears to state the results
are undefined, though it may work for many compilers.
- Reflection: The previous wish is a form of reflection. Full reflection may be
difficult to add to C, but I wonder how far one can go.
- Overflow: I sometimes wish there were a way to detect overflow from basic
arithmetic operations.
- The conventions for symbol visibility should be reversed, that is, public
exposure should be opt-in, not opt-out. Similarly for static versus extern
functions. Bitwise AND and OR should have higher precedence.<


Flexible array ranges: they introduce some extra complexity (when you read some
code you can't just assume an array starts from zero, you have to take a look
at the array type definition or declaration), but in some cases they simplify
the code and maybe make it less bug-prone. You write:

int['a' ... 'z'] arr;
arr['f']++;

Instead of something like:

int[cast(int)'z' - 'a' + 1] arr;
arr['f' - 'a']++;

This feature seems less useful if you are using larger Unicode characters.

Converting to D routines written in older 1-based languages is another usage,
but probably not important enough.


Module symbols visibility: in D with "private" you are to turn module names
(gloabal alias, global variable, global function, global class, template, ecc)
private when you import the module from another one. But indeed it's easy to
forget to add "private" to things you don't want to get imported. Reversing the
situation (and requiring "public" for the names you want to let other modules
see) seems a safer default.

--------------

The last page is about Go language, and it links to a document of comments
about Go (November 2009, not up to date):
http://www.math.bas.bg/bantchev/misc/on-go.html

Some of the things this "on-go" article says about Go, that I partially like:

 i++ is allowed, and ++i is not. Pike says 'the postfix version is more
traditional'.

 Assignments of all kinds, including ++ and --, are statements, not expressions.

 There is no , (comma) operator. (The need for it has been to a great extent
obviated by multiple assignment, but still.)

 Bitwise operator &^, 'bit clear': like & with a (bitwise) negated argument.
Bitwise negation itself is absent

Bye,
bearophile