Warren Toomey via COFF wrote in
<aFiUbk1wRWo4uQOZ(a)minnie.tuhs.org>:
|I love C; I think it's a great language. But there are things I wish
|were different in C, and I wish it had less undefined behaviour.
|
|I've been having fun designing a language called 'alic' to do the above.
|I feel proud enough to mention it here. Have a look at the doc which
|compares it to C, if you are interested:
|https://github.com/DoctorWkt/alic/blob/main/docs/overview.md
|
|Rather than talk about alic, reply with what you like/hate about
|your favourite language!
Sequence point stuff; i like alic's
Argument values are evaluated from left to right.
Maze of long argument lists; i like alic's
you can name arguments to a function.
Bit enumerations (i heard ringing newest clang has something).
And extended (bit) enumerations, where a subclass / "superclass
user" wants to reuse bit space in some "upper class bit carrier":
ie, its first value must start after the highest bit/value of
the enum it builds upon. But when to stop? On one-before signed
max, 32-bit / 64-bit? Error on excess.
Exceptions? It was a mess in C++; i had a base exception class
with optional (compile-time) documentation string, and also
debug-only file name and line number info. The doc string was
optionally (compile-time) passed via a translation macro. What a
preprocessor mess! (The sizeof() was always the same. That is
32 byte on 64-bit to init, without language support; i dreamed of
carry-flag set or something, on error. All x86 by then.)
To mention that FreeBSD just recently added (compile-time)
support for descriptive error strings in the kernel, beyond the
usual errno. I would assume this can end up as a tremendous
debugging help for developers, but also users. Too many things
end up as EINVAL, etc. Exceptions could be the better concept.
Finally{} i remember a article series conclusion from German
Linux Magazine, about 20++ years ago.
Btw when i see "array index access is always checked" i am sure
i will add a vector class etc with unchecked access, for the
prevalent (imho) case that i know i will not excess boundaries.
Or at maximum !NDEBUG assertions.
I hate unwanted optimizations. Loops that get unrolled,
non-inline functions that get inlined, code that gets entirely
removed (leading to solutions like explicit_bzero(3)), also the
usual "Who's afraid of a big bad optimizing compiler?" stuff.
On the other hand __attribute__()ing like grazy is also nuts.
I like the ({ block; }) extension of GNU C; i used it for
translations for example, you can inject a block in the right
hand side of an assignment, like 'char const *x = _("xy");'.
It surely can be overused, but that thing can lead to visually
better code, and that i can grasp more easily when iterating it.
alic has {} blocks in for(;;) i had seen. I do not understand
why they all go grazy over lambda's and callable blocks, but such
an easy right hand side block there still not is.
Simply being able to create {} blocks on a right hand side is easy.
Btw i like the difference in between -> and .. But it is ok.
If you then come to indirections like "object ***oppp" you
drifted to the twilight zone anyhow. (Or not.)
For translations the C++ << I/O thing was a terrible misfit.
I like the new-style "{fmt2#config} {fmt1#config}" things ---
good decision to not use va_list etc i think!, but if i would
create a language, providing a random-access array would then
be it, without consumation that is, you know? For example
va_count(), va_arg(u32, IDX). One could get away with va_pop()
or va_shift() if you want a consuming iterator.
Languages possibly should support simple documentation text
blocks that their tools then could dump in some generic format,
yaml alike, or json alike, or whatever. Plain text. You know.
Everybody could take that output and do whatever with it, without
having to write a language-specific parser.
I use doxygen now, it fails for
EXPORT BITENUM(u32,su_idec_state) su_idec(...);
how can it be made clear otherwise what it is, and what exact
integer should be used. It also requires anything to be tagged,
but i often want "fun1;fun2;fun3; DOCU FOR ALL" (or DOCU first).
Around Y2K+ there was a free software string C++ library which did
so, using TeX commands inside the DOC. Output looked good.
I cannot find it on the internet, i think his name was Sauter.
These are absolutely fascinating projects of yours, both,
compiler, and language! How can you all do such great projects,
in my friend nosh and cleanup circles i hardly find time to read
the emails. (But even if not, operating systems, compilers,
languages, .. wow!) Journeys -- i likely will find easier access
than i ever could with Knuth's web writings.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear