[continued from previous message]

However, my /aim/ is for my language to be self-contained, and not to
talk to external software except via DLLs.

* Blazing fast compilation speed, can run direct from source

Again, that is implementation (some language features may slow
down compilation, as you know C allow fast comilation).

C also requires that the same header (say windows.h or gtk.h) used in 50 modules needs to be processed 50 times for a full build.

Does not "require". More precisely, you can write header and
program in such a way that compiler will give up and process it
50 times. But in normal cases compiler may process header once,
this just requires more effort from compiler writer.

And, let me mention that Ada has module system that allows using
compiled interfaces. Yet flagship Ada compiler (that is GNAT)
used to compile interfaces multiple times. I am not sure what
is current state of GNAT, but it is part of gcc. C and C++ compilers
in gcc have "precompiled headers" feature, which in typical
cases processes header onece and then uses processed version
of the header file. So maybe GNAT catched up to C.

My M language processes it just once for a normal build (further, such
APIs are typically condensed into a single import module, not 100s of
nested headers). Some of it is by design!

* Module scheme with tidy 'one-time' declaration of each module
* Function reflection (access all functions within the program)
* 64-bit default data types (ie. 'int' is 64 bits, 123 is 64 bits)
* No build system needed

That really depends on needs of your program. Some are complex
and need build system, some are simple and in principle could
be compiled with "no" build system. I still use Makefiles for
simple programs for two reasons:
- typing 'make' is almost as easy as it can get

Ostensibly simple, yes. But it rarely works for me. And internally, it
is complex. Look at what a typical makefile contains with one of a
program headers, which looks like a shopping list - you can't get simpler!

I am trying to keep Makefiles simple and I think they mostly are.
Sometimes I need to to tricky things, but they proably would be
more complex without make.

OTOH, currently many Makefiles are machine generated and contain
a lot of junk, generator is too stupid to know that junk it
produces is not needed. In such cases there usually is real
source which is simpler. But I must admit that I am not fun
of automake (which is responsible for many bloated Makefiles)
and I am limiting my use of autoconf, which I find useful,
but in poplular use may also lead to bloated Makefiles.

Still, you may spend time to write a simple Makefile or
possibly with less effort accept bloated one generated by
a tool. Do not be suprprised that people accept bloat
when it saves them work.

- I want to have record of compiler used/compiler options/
libraries

So do I, but I want to incorporate that into the language. So if a
program uses OpenGL, when it sees this:

importdll opengl =

(followed by imported entities) that tells it it will need opengl.dll.
In more complex cases (mapping of import library to DLL file(s) is not straightforward), it's more explicit:

linkdll opengl # next to module info

This stuff no longer needs to be submitted via command line; that is
old-hat.

Well, I do not like hardwiring into programming language notion
of DLL, in particular since there could be system dependent
differences. And I like possibility of using multiple languages,
in which case Makefile is "neutarl ground".

Or are used to buying ready-meals from supermarkets.

Meals are different thing than programming languages. If you want
to say that _you_ enjoy yor language(s), then I got this. My point
was that you are trying to present your _subjective_ preferences
as something universal.

Yes, and I think I'm right. For example, English breakfast choices are
simple (cereal, toast, eggs, sausages), everybody likes them, kids and adults. But then in the evening you go to a posh restaurant and things
are very different.

I think the same basics exist in programming languages.

I like programming and important part

is that my programs work. So I like featurs that help me to get
working program and dislike ones that cause troubles. IME, the
following cause troubles:

- case insensitivity

I believe this would only cause problems if you already have a
dependence on case-sensitivity, so it's a self-fulfilling problem!

Well, I am matematician. In math 'a' and 'A' are different, I need
a way to represent this in programming language. And true case
insensitivity is tricky once you move beyond English, there are
strange rules in German. IIUC most "case insensitive" systems
are in fact "case folding" (oder ones simply made everthing upper
case). Case folding means information loss, which you apparently
want in programming language, but is frequently not acceptable
outside ("computer speaks in capital letters" could work as
good excuse on 1970, but not now). And given that outside
world cares about letter case (there is a reason that we
separate character codes for small and capital letter, as
opposed to attribute like fonts), case insensitivity causes
trouble when you want close relation to external world.

Create a new language with it, and those problems become minor ones that occur on FFI boundaries, and then not that often.

Simple trouble is when you want to represent math/physics
formula as close as possible to a textbook. It is quite
frequent that formulas use letters differing only in case
as different variables, you can represent such formula
directly in case sensitive langiage, but not in case-insensitive.
You may view this as "FFI" (with the textbook) and say
that this in not often, but it creates ugly irregularities.

- dependence on poorly specified defauls
- out of order definitions

I don't believe this. In C, not having this feature means:

* Requiring function prototypes, sometimes
* Causing problems in self-referential structs (needs struct tags)

Struct tags is C way. You need some tag, but in principle that
could be nameded incomplete type. Yes, this means that _some_
info is out of order, but for me this is not a problem.
I want predictable place for declarations/definition and
mutually dependent stuff normally is placed together.

* Causing problems with circular references in structs (S includes
a pointer to T, and T includes a pointer to S)

- infexible tools that for example insist on creating executable
without option on making linkable object file

Concerning 1-based indexing, IME in more cases it causes trouble
than helps, but usually this is minor issue.

In my compiler sources, about 30% of arrays are zero-based (with the
0-term usually associated with some error or non-set/non-valid index).

I use a lot
line oriented syntax. I can say that it works, simple examples
are easy, but there are unintuitive situations and sometimes troubles.
For example cut and paste works better for traditional syntax.
If there are problems, then beginers may be confused. As one
guy put it: trouble with white space is that one can not see it.

White space (spaces and tabs) is nothing to do with line-oriented.

Hmm, so what you really want? You need some way to express syntax,
you do not want braces, semicolons and equivalents so what?

Of course, one could try "flat" structure like assembler, but
it seems that this is also not what you want.

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)