MitchAlsup <MitchAlsup@aol.com> writes:
> > (This is one of the things I really do not like about standard UNIX
> > compilation, writing out the code in assembler and then reading
> > it back and parsing it again seems like a waste.)
> It was not a waste when there was only 64KB of memory for your
> application and you wanted to compile files larger than would fit
> in memory.

In fact, the PDP-11 pcc I hacked to add ANSI stuff has two passes _before_
the assember. Basically tokenize and parse into trees, then next pass does
the pattern matching onto the code generation patterns. It gives you
significantly more memory headroom.

Like all search and pattern match solutions, code generation wants to be a
Prolog program. I was going to say that it had the excuse of predating
Prolog, but in fact, it does not. A 16-bit Prolog code generator would be
pretty cool.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On 7/4/2021 4:15 PM, Andy Valencia wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>>> (This is one of the things I really do not like about standard UNIX
>>> compilation, writing out the code in assembler and then reading
>>> it back and parsing it again seems like a waste.)
>> It was not a waste when there was only 64KB of memory for your
>> application and you wanted to compile files larger than would fit
>> in memory.
>
> In fact, the PDP-11 pcc I hacked to add ANSI stuff has two passes _before_
> the assember. Basically tokenize and parse into trees, then next pass does
> the pattern matching onto the code generation patterns. It gives you
> significantly more memory headroom.
>
> Like all search and pattern match solutions, code generation wants to be a
> Prolog program. I was going to say that it had the excuse of predating
> Prolog, but in fact, it does not. A 16-bit Prolog code generator would be
> pretty cool.
>
> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html
>

Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
the Snobol-shaped.

On 7/4/2021 4:56 PM, Thomas Koenig wrote:
> BGB <cr88192@gmail.com> schrieb:
>
>> One doesn't just have literals, but may also have:
>> * any symbols (variable / function name) within the program;
>> * the names of any visible function prototypes, typedefs, ...;
>> * Every signature string for every variable or function;
>> * ...
>
> Any of those should be ASCII, right?
>

Most are ASCII...

Actually, given most symbols are one of:
A..Z
a..z
0..9
_

One could almost justify an "extra-compact" 6-bit encoding.

Say, for example, if one is using tagged pointers, one of the tags could
be interpreted as, say, containing 9x 6-bit chars. In this case, strings
like "strncmp"/"_Complex"/... could be stored without using any
additional memory.

For normal strings, non-ASCII cases are a small minority, but this is a
lot less true of binary data though.

>> So, having a space-efficient representation for string data can be
>> relevant, as can interning any short/recurring strings.
>
> Hmm... ok...
>

If one stores every copy of every string, this costs a lot of extra
memory. Merging them is generally effective.

The main exception is large one-off strings, which are better if not
interned. Similarly, the longer a string is, the less likely it is to
repeat.

>>
>>
>> As noted, in my compiler, inline ASM blobs, and also entire ASM modules
>> (post preprocessor) may also be passed through the IR stage via string
>> literals, as well as some binary data blobs, such as "Resource WAD"
>> lumps, ...
>
> I would think that there is a difference between user strings
> (which may be UTF-8 or whatever) and internal representation of
> variable names. Those are two rather different things, which I
> would probably put in separate code paths.
>

One could do so, but in this case things developed along a path where it
ended up being easier to treat all of these as essentially special cases
of strings at the IL layer.

There are different opcodes for different literal types, but they are
built on top of the same underlying serialization mechanism.

>> Essentially, pretty much the entire front-end of the compiler is fed
>> through something that is essentially comparable to a binary-coded
>> version of PostScript, and stored temporarily as ".ril" (RIL3) files.
>
> Hm, interesting. Is there a particular reason why you use files instead
> passing things through data structures in memory?
>

Memory buffers are used if one is compiling code to a binary directly.
This isn't always the case though, such as with static libraries and
similar.

At some point, there is a need to be able to store partially-compiled
code to files, so that it can be "linked" into a program at some other
point.

When compiling a program, the compiler will fetch the ".ril" files
containing things like the C library and similar, and combine it with
the RIL code from the program currently being compiled.

And, if one is compiling a library, the frontend does its thing and then
the blob of RIL code is stored to a file.

In some sense, RIL is derived from an earlier form of the BGBScript
bytecode (along with the AST format).

Brief history:

Very long ago, I wrote some script-language interpreters...

My first script language was based on Scheme (this was back when I was
in high-school), using a fairly naive interpreter design (recursive
expression rewriting), it kinda sucked... Did partly implement a 3D
engine based around it though, rendering stuff using OpenGL (with a lot
of code copy/pasted from the Quake engine and similar).

I started programming a bit earlier, but most of my code from middle
school and earlier was lost due to an HDD crash.

My second script language (BGBScript, VM-0) was essentially a crappy
JavaScript clone built on top of DOM and a hacked and extended version
of XML-RPC / Jabber-RPC, and its performance was abysmal even vs the
Scheme clone.

Not long after, I rewrote the BGBScript VM (VM-1, or 1.0), partly using
the core of the Scheme VM, but rewriting the front-end. This version
effectively used Scheme as its IR stage, with the parser effectively
rewriting the JS style code into Scheme. For some extra speed (by my
standards at the time), replaced the expression-rewriting backend with a
bytecode interpreter (stack machine based, inspired by PostScript).

Then, getting to BGBCC:
I copy/pasted much of the parser from VM-0, though replacing the
original DOM with my own re-implementation;
And, a lot of the rest of the bytecode compiler parts from VM-1;
I then glued these parts together, and modified the parser to deal with
C (sorta);
And, wrote a backend to translate the stack bytecode to x86 machine code.

I went with the older DOM based parser mostly because I soon noted that
a big drawback of using a Scheme-based AST format was that it was rather
inflexible if compared with XML.

At the time, BGBCC was basically unusable garbage, and I couldn't get
its reliability to anything near what could be considered "acceptable".

I then returned to working on BGBScript, back-porting some of the parts
I had written for BGBCC into BGBScript:
It gained a static typesystem (and a bunch of new syntax "borrowed" from
ActionScript3);
It also switched to a statically-typed VM core;
It also gained a JIT compiler.

I redubbed this new language "BGBScript-1.5", and around the same time I
also wrote a 3D engine I called "BGBTech", which initially started off
trying to be sort of like Quake with a Doom3 inspired renderer, but then
switched over to being a Minecraft clone (while still using a Doom3
inspired renderer).

Some videos for this engine are still on YouTube, eg:
https://www.youtube.com/watch?v=WTrfNAfWV8o

This 3D engine was basically a mix of C and BGBScript.
It suffered from crappy performance, excessive memory usage, and
frequent stalls due to the use of a conservative mark/sweep garbage
collector.

Not long after, I did a ground up rewrite of both the BGBScript VM and
BGBTech, creating BGBScript2 and BGBTech2.

The BGBScript2 VM (BS2) differed partly in that its compiler switched
over to essentially using JSON as its AST format, and aimed mostly to be
a cleaned up and simplified version of what the original BGBScript had
become.

The BGBTech2 engine was also a lot more focused on performance (simpler
renderer, and also got rid of the use of a garbage collector), ...
I also switched mostly from 3D models to sprite graphics.

Example here:
https://www.youtube.com/watch?v=LGB53L7f314

Most of the renderer and similar is written in C, whereas most of the
"game logic" and similar is written in BS2.

Not long after, my first ISA project (BJX1) got started (based on an
extended version of the SuperH / SH-4 ISA).

In this case, I sort of revived BGBCC, and in the process replaced the
DOM clone with an AST format partly derived from the BS2 compiler, but
with an API wrapper to mimic the prior DOM-style API. So, at this point,
it is essentially sort of like JSON pretending to be XML (and RIL3 is
still mostly derived from the original BGBScript-1.0 bytecode).

After not too long, issues with the BJX1 design became pretty obvious,
so I did a partial reboot of the ISA design, which I called BJX2, which
then gained a lot more features (and some amount of cruft).

Similarly, BGBCC also contains a partial re-implementation of
BGBScript2, just targeting BJX2 rather than a VM. This uses mostly the
same code as when compiling C (mostly enables/disables parser features).

Similarly, some amount of BS2 features are exposed in C (in BGBCC) as
language extensions.

Though, my BJX2 project did basically eat up all my time, so I ended up
not doing much more on the BGBTech2 engine after that. Kinda considered
resuming work on it on/off a few times, but never got back around to
working on it.

Well, and also I end up writing significantly more code in C for BJX2
than I do in BS2.

If anything, BS2 in this context can be compared to C++, which I also
tend not to use all that much. Though, I personally consider BS2's
design to be "a lot less evil" than C++.

Ironically, making a compromise between these languages would end up
looking (syntax wise) fairly similar to C#, so it would almost be sort
of like if one could have C# on top of C's memory model.

I made an effort in BS2 to try to limit the presence of "unreasonable"
runtime overheads if compared with C, but doing this (while also
allowing for "high-level" features), is difficult.

Yeah... This is basically my life history up to this point...

Never really did much "professionally" though, it is pretty rare that I
can "actually get a job", and then almost invariably stuff comes along
to causes it to end after not that long (most recently, covid), and then
back to no one wanting to hire me to do anything, so alas...

Ivan Godard <ivan@millcomputing.com> schrieb:

> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
> the Snobol-shaped.

Some people who don't like C++ say that C++ is the perfect tool
for thumb-shaped problems :-)

On 7/4/2021 5:21 PM, MitchAlsup wrote:
> On Sunday, July 4, 2021 at 4:56:41 PM UTC-5, Thomas Koenig wrote:
>> BGB <cr8...@gmail.com> schrieb:
>>> One doesn't just have literals, but may also have:
>>> * any symbols (variable / function name) within the program;
>>> * the names of any visible function prototypes, typedefs, ...;
>>> * Every signature string for every variable or function;
>>> * ...
>> Any of those should be ASCII, right?
>>> So, having a space-efficient representation for string data can be
>>> relevant, as can interning any short/recurring strings.
>> Hmm... ok...
>>>
>>>
>>> As noted, in my compiler, inline ASM blobs, and also entire ASM modules
>>> (post preprocessor) may also be passed through the IR stage via string
>>> literals, as well as some binary data blobs, such as "Resource WAD"
>>> lumps, ...
>> I would think that there is a difference between user strings
>> (which may be UTF-8 or whatever) and internal representation of
>> variable names. Those are two rather different things, which I
>> would probably put in separate code paths.
>>> Essentially, pretty much the entire front-end of the compiler is fed
>>> through something that is essentially comparable to a binary-coded
>>> version of PostScript, and stored temporarily as ".ril" (RIL3) files.
>> Hm, interesting. Is there a particular reason why you use files instead
>> passing things through data structures in memory?
>>
>> (This is one of the things I really do not like about standard UNIX
>> compilation, writing out the code in assembler and then reading
>> it back and parsing it again seems like a waste.)
> <
> It was not a waste when there was only 64KB of memory for your
> application and you wanted to compile files larger than would fit
> in memory.
> <

Yeah.

Getting this low would require a *very* different compiler design from
the one I have.

Decided to leave out a bunch of "going down the rabbit hole" ideas for
how to do a limited-scope redesigns for how to make RIL3 more efficient
for use as an AOT compiler format.

Current front-runner is mostly to move the format partly over to a TLV
package and then "individually wrap" all the structures and variables
and functions and similar, with an offset table to map index numbers to
their corresponding TLV lumps (anyone who knows how the RIFF AVI format
works should have a general idea what I am thinking here).

Would otherwise more or less keep the same basic bytecode design, and
would likely continue building metadata via interpreting bytecode ops, ...

>>> When the final binary is to be compiled, these RIL3 files are
>>> decoded/interpreted, which essentially builds all of the structures used
>>> by the backend (and is also translated into 3AC and basic-blocks via
>>> this interpretation process).
>> OK.
>>> It is possible that RIL3 files could be considered also as input to an
>>> AOT compiler, but the main debate is whether the memory overhead would
>>> be low enough to be "acceptable" (its design would basically depend on
>>> the ability to be able to keep everything in RAM during the AOT
>>> compilation process, though possible workarounds may exist).
>> I can understand that you want your compiler to be able to run on
>> your own hardware, but...
>>> Ideally, one would want the ability to have a single-pass AOT compiler
>>> which can fit in a memory footprint of, say, under 4MB or so, and where
>>> its memory footprint doesn't increase drastically when compiling a
>>> larger or more complex program (ignoring the space needed to store the
>>> intermediate program sections or "object code").
>> ...that seems to be a rather harsh requirement these days. I am
>> all for conserving resources, but I personally would probably
>> rather go for a cross-compilation than trying to fit a compiler
>> into 4MB. (Then again, I work in the gcc framework, where such
>> restrictions do not exists).
>>>
>>>
>>>> The best way is probably to translate to that type on input, do
>>>> all stuff that needs to be done on that simple data type and then
>>>> write it to the desired format on output.
>>>>
>>>
>>> Could be.
>>>
>>> As noted, convert-on-output was how it worked previously, but figured it
>>> needed to be changed given doing it this way led to some ambiguities
>>> regarding the parsing and handling of C string literals.
>>>
>>> Luckily, the literals were already capable of handling arbitrary binary
>>> data, so this part wasn't a huge leap.
>> Including null bytes? That's good design, then.
>>
>> [...]

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Sunday, July 4, 2021 at 4:56:41 PM UTC-5, Thomas Koenig wrote:

>> (This is one of the things I really do not like about standard UNIX
>> compilation, writing out the code in assembler and then reading
>> it back and parsing it again seems like a waste.)
><
> It was not a waste when there was only 64KB of memory for your
> application and you wanted to compile files larger than would fit
> in memory.

At the time, it was a reasonable design decision, although the
original FORTRAN compiler chose a different patth - you could
write out the generated assembler, but the default was to compile
straight to what we now call object code.

With the amount of memory we have now... I do not think that would
be a choice many people would make if designing a new system from
scratch.

Also, this was not done for compilers on mainframe systems, at
least not on OS/360, so another choice was certainly possible
with very limited resources.

On 7/5/2021 12:02 AM, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Sunday, July 4, 2021 at 4:56:41 PM UTC-5, Thomas Koenig wrote:
>
>>> (This is one of the things I really do not like about standard UNIX
>>> compilation, writing out the code in assembler and then reading
>>> it back and parsing it again seems like a waste.)
>> <
>> It was not a waste when there was only 64KB of memory for your
>> application and you wanted to compile files larger than would fit
>> in memory.
>
> At the time, it was a reasonable design decision, although the
> original FORTRAN compiler chose a different patth - you could
> write out the generated assembler, but the default was to compile
> straight to what we now call object code.
>
> With the amount of memory we have now... I do not think that would
> be a choice many people would make if designing a new system from
> scratch.
>
> Also, this was not done for compilers on mainframe systems, at
> least not on OS/360, so another choice was certainly possible
> with very limited resources.
>

I was an expert witness (for Fujitsu) in the IBM vs. Fujitsu trade
secret lawsuit, where Fujitsu stole IBM's system software to go with
Fujitsu's IBM clones. In the case of one of the compilers, Fujitsu
claimed that they had done a clean-sheet re-implementation and didn't
owe penalties for that compiler.

Comparing the IBM and Fujitsu codes, it was clear that (except for one
function where apparently a Fujitsu engineer had cheated and done his
own copy) the Fujitsu code was not a copy and not a simple programmatic
re-edit of the original, although necessarily there were some
organizational similarities because they did the same job.

However, the IBM original was written to run on the S360/30 and had
something like 112 overlays and 65 passes to fit in 64k of memory.
Fujitsu never sold a box with less than a megabyte. Yet I spotted that
the Fujitsu code ... had 112 overlays and 65 passes. Oops.

That was the first and only time I have ever cost a client company a
gigabuck penalty.

In article <sbue5h$et0$1@dont-email.me>, ivan@millcomputing.com (Ivan
Godard) wrote:

> However, the IBM original was written to run on the S360/30 and had
> something like 112 overlays and 65 passes to fit in 64k of memory.
> Fujitsu never sold a box with less than a megabyte. Yet I spotted
> that the Fujitsu code ... had 112 overlays and 65 passes. Oops.

Was that a PL/1 compiler?

John

Ivan Godard <ivan@millcomputing.com> schrieb:

> I was an expert witness (for Fujitsu) in the IBM vs. Fujitsu trade
> secret lawsuit, where Fujitsu stole IBM's system software to go with
> Fujitsu's IBM clones. In the case of one of the compilers, Fujitsu
> claimed that they had done a clean-sheet re-implementation and didn't
> owe penalties for that compiler.

Rather interesting.

> Comparing the IBM and Fujitsu codes, it was clear that (except for one
> function where apparently a Fujitsu engineer had cheated and done his
> own copy) the Fujitsu code was not a copy and not a simple programmatic
> re-edit of the original, although necessarily there were some
> organizational similarities because they did the same job.
>
> However, the IBM original was written to run on the S360/30 and had
> something like 112 overlays and 65 passes to fit in 64k of memory.
> Fujitsu never sold a box with less than a megabyte. Yet I spotted that
> the Fujitsu code ... had 112 overlays and 65 passes. Oops.

If I read

https://btlj.org/data/articles2015/vol3/3_2/3-berkeley-tech-l-j-0241-0266.pdf

correctly, IBM software before 1978 was public domain. That means
that Fujitu could have used that compiler and also modified it.

> That was the first and only time I have ever cost a client company a
> gigabuck penalty.

The sums that I find in the old articles are rather lower than that,
but not everything one reads in articles is correct :-)

I worked on a Fujitsu machine (branded as Siemens), running their
MVS clone. Once the computer center hat switched to an IBM 3090,
all of a sudden most error messages and the documentation became
comprehensible... it as a revelation.

Plus, Fujitsu had labeled all the IEB utilities as JSE for some
unfathomable reason, but IEB also worked.

On 7/4/2021 11:59 PM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>
>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
>> the Snobol-shaped.
>
> Some people who don't like C++ say that C++ is the perfect tool
> for thumb-shaped problems :-)
>

Main problems I have with C++ ATM:
Compiler would be too complicated, don't want to bother with this;
Multiple inheritance needlessly complicates stuff;
Templates needlessly complicate stuff;
The C++ standard library and STL is kinda a trash fire;
...

Too many "features" exist essentially as a way to play whack-a-mole with
the consequences of other features.
If you leave out multiple inheritance and templates, many of the rest of
the language features go "poof" and disappear.

Leaving out templates also eliminates on of the major sources of massive
code bloat and excessive build times.

But what about generic containers?
How about we have some other way of building containers which isn't so
prone to be misused and hose everything?...

But what could such an alternative possibly look like?

How about we have a few types, lets call them 'auto' and 'variant',
which unlike most other types, take on the type of the things that are
passed to them. Similarly, they can be allowed in argument lists and as
a return type, then the function will operate on that type (calling a
function with 'auto' arguments may specialize the function over the
argument types, allowing for any implicit type promotions).

Decided to leave out going into a big long thing about auto and variant
semantics.

Basic idea is that 'auto' does type inference (more or less like how it
already is in C++), and enforces static type checks, but may be allowed
to decay into 'variant' if the compiler decides to do so.

The 'variant' type being like a partially inverted 'auto', which behaves
as if it were dynamically typed by default, but is allowed to use type
inference (so, it may turn into a primitive type if the compiler
determines that the variable only ever holds a single type).

In the case of 'variant', when not type inferred, it will normally exist
as a tagged pointer. The 'variant' type could also be allowed in object
fields, whereas 'auto' would not.

Could maybe also add generics, but limit their semantics, and allow the
compiler an "easy way out" for cases which would otherwise result in
excessive expansion (if stuff "goes sideways", then the compiler may
quietly fall back to using dynamic type-checking instead of specialization).

Well, or go the opposite direction and, instead of having either
generics or templates, just use block macros. "But, this sucks and is
awkward to use!", "That is kinda the point...".

#define FOO_TPL(T) Foo__##T
#define GEN_FOO_TPL(T) \
class FOO_TPL(T) { \
... \
}

GEN_FOO_TPL(int) //Instantiate the 'template'

FOO_TPL(int) someFooInstance; //create object from the 'template'

....

Side note: I have actually done similar to pull off type-specialized
functions in C, just I soon stopped doing this as, as with C++
templates, it can quickly lead to excessive amounts of code bloat.

....

BGB <cr88192@gmail.com> schrieb:
> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>
>>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
>>> the Snobol-shaped.
>>
>> Some people who don't like C++ say that C++ is the perfect tool
>> for thumb-shaped problems :-)
>>
>
> Main problems I have with C++ ATM:
> Compiler would be too complicated, don't want to bother with this;

Certainly correct.

C++ has a way of accumulating features because somebody on the
commitee (usually representing some company) feels that they
need something.

Modules are an example. I attended a talk at a GNU cauldron
where somebody seriously suggested doing a http request to
an oracle as part of the compilation process.

This was to solve the problem of "which file defines which module".
When I asked how the oracle should know, the answer was basically
"not my department".

Everybody agrees that using the whole of C++ for a project is
madness and a sane subset is required, but apparently not two
people agree on what this sane subset should be.

And of course, if you're a compiler writer, you cannot restrict
yourself to a subset of a language.

> Multiple inheritance needlessly complicates stuff;

That was a bad design decision, especially if a class inherits
multiple times from the same base class.

> Templates needlessly complicate stuff;

There, I disagree somewhat. While C++ syntax for templates is
unintelligible (at least for me) and I'm not sure that they made
templates Turing complete on purpose, templates do fullfill a
useful function. You just have to look at the way people use
preprocessors for Fortran to fill that gap.

> The C++ standard library and STL is kinda a trash fire;
> ...
>
> Too many "features" exist essentially as a way to play whack-a-mole with
> the consequences of other features.
> If you leave out multiple inheritance and templates, many of the rest of
> the language features go "poof" and disappear.
>
>
> Leaving out templates also eliminates on of the major sources of massive
> code bloat and excessive build times.
>
> But what about generic containers?
> How about we have some other way of building containers which isn't so
> prone to be misused and hose everything?...

If all you want to do is to have generic containers, you could
so something like (Fortran style)

module all_my_templates
implicit none

template_type a_type, only : real(4), real(8) ! (only those types are valid)
template_type b_type ! No restriction, pass what you want
template_type x_type, only :: real(*) ! Pass all kinds if you want

contains

template subroutine foo(a,b,c)
template_type (a_type), intent(in) :: a
template_type (b_type), intent(out) :: b
template_type (a_type), intent(inout) :: c

! Do stuff with a_type and b_type
end template subroutine

And it is still useful to have more powerful features like
template metaprogramming.

Just assume you want to write n nested loops, with n being
a compile-time constant, for example...

On 7/5/2021 11:48 PM, Thomas Koenig wrote:
> BGB <cr88192@gmail.com> schrieb:
>> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>
>>>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
>>>> the Snobol-shaped.
>>>
>>> Some people who don't like C++ say that C++ is the perfect tool
>>> for thumb-shaped problems :-)
>>>
>>
>> Main problems I have with C++ ATM:
>> Compiler would be too complicated, don't want to bother with this;
>
> Certainly correct.
>
> C++ has a way of accumulating features because somebody on the
> commitee (usually representing some company) feels that they
> need something.
>
> Modules are an example. I attended a talk at a GNU cauldron
> where somebody seriously suggested doing a http request to
> an oracle as part of the compilation process.
>
> This was to solve the problem of "which file defines which module".
> When I asked how the oracle should know, the answer was basically
> "not my department".
>
> Everybody agrees that using the whole of C++ for a project is
> madness and a sane subset is required, but apparently not two
> people agree on what this sane subset should be.
>
> And of course, if you're a compiler writer, you cannot restrict
> yourself to a subset of a language.
>
>> Multiple inheritance needlessly complicates stuff;
>
> That was a bad design decision, especially if a class inherits
> multiple times from the same base class.

Are you acquainted with "virtual base class"es?
https://en.wikipedia.org/wiki/Virtual_inheritance

I heavily use multiple inheritance for behavior mixins.
https://en.wikipedia.org/wiki/Mixin

I rarely find MI for real data to be useful though.

JMO, YMMV.

On 7/6/2021 1:48 AM, Thomas Koenig wrote:
> BGB <cr88192@gmail.com> schrieb:
>> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>
>>>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
>>>> the Snobol-shaped.
>>>
>>> Some people who don't like C++ say that C++ is the perfect tool
>>> for thumb-shaped problems :-)
>>>
>>
>> Main problems I have with C++ ATM:
>> Compiler would be too complicated, don't want to bother with this;
>
> Certainly correct.
>
> C++ has a way of accumulating features because somebody on the
> commitee (usually representing some company) feels that they
> need something.
>
> Modules are an example. I attended a talk at a GNU cauldron
> where somebody seriously suggested doing a http request to
> an oracle as part of the compilation process.
>
> This was to solve the problem of "which file defines which module".
> When I asked how the oracle should know, the answer was basically
> "not my department".
>
> Everybody agrees that using the whole of C++ for a project is
> madness and a sane subset is required, but apparently not two
> people agree on what this sane subset should be.
>
> And of course, if you're a compiler writer, you cannot restrict
> yourself to a subset of a language.
>

Yeah.

I had implemented a subset that was basically "more or less EC++ but
re-adding namespaces".

In practice, very little C++ code actually works on such a subset though.

>> Multiple inheritance needlessly complicates stuff;
>
> That was a bad design decision, especially if a class inherits
> multiple times from the same base class.
>

Yeah. There are workarounds (eg: virtual inheritance), but they fall
into "whack a mole" territory IMO.

Then again, my preferred option is to use interfaces instead, but then
people argue that interfaces are just poor man's MI.

However, interfaces are simpler for a compiler, since every subclass is
essentially just the parent class with more stuff glued onto the end,
and interfaces also glue-on linearly.

With MI it turns into aggregation, which is harder to deal with, and a
bunch more edge cases end up being added (diamond inheritance, ...), ...

>> Templates needlessly complicate stuff;
>
> There, I disagree somewhat. While C++ syntax for templates is
> unintelligible (at least for me) and I'm not sure that they made
> templates Turing complete on purpose, templates do fullfill a
> useful function. You just have to look at the way people use
> preprocessors for Fortran to fill that gap.
>

I am still thinking mostly from the perspective of implementing them in
a compiler, and the effects which misusing them can have on a program.

They actually make some sense from a language POV, possibly too much,
and they are too easy to use, prompting people to overuse them.

>> The C++ standard library and STL is kinda a trash fire;
>> ...
>>
>> Too many "features" exist essentially as a way to play whack-a-mole with
>> the consequences of other features.
>> If you leave out multiple inheritance and templates, many of the rest of
>> the language features go "poof" and disappear.
>>
>>
>> Leaving out templates also eliminates on of the major sources of massive
>> code bloat and excessive build times.
>>
>> But what about generic containers?
>> How about we have some other way of building containers which isn't so
>> prone to be misused and hose everything?...
>
> If all you want to do is to have generic containers, you could
> so something like (Fortran style)
>
>
> module all_my_templates
> implicit none
>
> template_type a_type, only : real(4), real(8) ! (only those types are valid)
> template_type b_type ! No restriction, pass what you want
> template_type x_type, only :: real(*) ! Pass all kinds if you want
>
> contains
>
> template subroutine foo(a,b,c)
> template_type (a_type), intent(in) :: a
> template_type (b_type), intent(out) :: b
> template_type (a_type), intent(inout) :: c
>
> ! Do stuff with a_type and b_type
> end template subroutine
>
> And it is still useful to have more powerful features like
> template metaprogramming.
>
> Just assume you want to write n nested loops, with n being
> a compile-time constant, for example...
>

Generic containers is the main big fuss area for a lot of people over
"we need templates", because manually writing type-specialized code is
"scary and archaic" and many of them seemingly aren't aware that
preprocessor macros are a thing.

Though, one could have a less awkward block macro feature, eg (language
extension):
#defmacro FOO(X)
...
#endmacro

( Functionally analogous to multi-line #define just without the need to
put '\' at the end of each line. )

But, this would make a lot more temptation for "people to actually use
it", which is ultimately a big part of the problem here...

And, then there is also the C11 "_Generic" feature, which falls into the
category of "it exists I guess", not super obvious yet how it would be used.

ATM, what I have is a mix of different versions of the C standard. Still
doesn't fully implement C99, but has random bits of C11, and some of the
proposed features from C23.

Granted, I am more going on an "implement features as they seem useful"
path, rather than necessarily trying to implement the standards in
chronological order.

....

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 7/5/2021 11:48 PM, Thomas Koenig wrote:
>> BGB <cr88192@gmail.com> schrieb:

>>> Multiple inheritance needlessly complicates stuff;
>>
>> That was a bad design decision, especially if a class inherits
>> multiple times from the same base class.
>
> Are you acquainted with "virtual base class"es?
> https://en.wikipedia.org/wiki/Virtual_inheritance

In principle, yes.

>
> I heavily use multiple inheritance for behavior mixins.
> https://en.wikipedia.org/wiki/Mixin
>
> I rarely find MI for real data to be useful though.

I haven't yet found the need for something like that in my own
programs (I am firmly in the "single inheritance only camp", and I
find, for example, that Fortran's object-oriented features enough
for me), but, as you wrote

> JMO, YMMV.

> Then again, my preferred option is to use interfaces instead, but then
> people argue that interfaces are just poor man's MI.

The good thing about inheritance is that it gives you subtyping.
Interfaces give you subtyping but without the bad after taste that you
get from inheritance.

IOW, interfaces are "MI done right".

Stefan

On Mon, 5 Jul 2021 15:39:34 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

>Ivan Godard <ivan@millcomputing.com> schrieb:
>
>> That was the first and only time I have ever cost a client company a
>> gigabuck penalty.
>
>The sums that I find in the old articles are rather lower than that,
>but not everything one reads in articles is correct :-)

Perhaps it was giga-yen.

On Tue, 6 Jul 2021 00:45:57 -0700, Ivan Godard
<ivan@millcomputing.com> wrote:

>I heavily use multiple inheritance for behavior mixins.
>https://en.wikipedia.org/wiki/Mixin
>
>I rarely find MI for real data to be useful though.

Exactly. More often than not what I want is to inherit
/functionality/. Many SI languages provide "interfaces", but far too
often it is necessary to re-implement the interface functionality in
every class that needs it.

C++ has plenty of warts, but its ability to mix in already existing
functionality is very useful.

On Tue, 06 Jul 2021 09:12:51 -0400, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

>> Then again, my preferred option is to use interfaces instead, but then
>> people argue that interfaces are just poor man's MI.
>
>The good thing about inheritance is that it gives you subtyping.
>Interfaces give you subtyping but without the bad after taste that you
>get from inheritance.
>
>IOW, interfaces are "MI done right".

In too many SI languages, interfaces are more annoying than helpful:
far too often with SI the interface functions have to be
re-implemented where in an MI language they would be inheritable.

Mix-ins are useful, but sometimes you really want inheritance.

YMMV.

George Neuner wrote:
> On Mon, 5 Jul 2021 15:39:34 -0000 (UTC), Thomas Koenig
> <tkoenig@netcologne.de> wrote:
>
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>
>>> That was the first and only time I have ever cost a client company a
>>> gigabuck penalty.
>> The sums that I find in the old articles are rather lower than that,
>> but not everything one reads in articles is correct :-)
>
> Perhaps it was giga-yen.

FUJITSU ORDERED TO PAY IBM FOR SOFTWARE SECRETS, 30-Nov-1988
https://www.washingtonpost.com/archive/business/1988/11/30/fujitsu-ordered-to-pay-ibm-for-software-secrets/6f59c2a5-dafe-4dc2-9292-4946106d00c3/

"In total, the arbitrators assessed Fujitsu $833 million in retroactive
fees, but the company has already paid IBM all but $237 million.
Over the remaining nine years of the agreement, however, Fujitsu will
be charged additional fees for use of IBM material according to a
complex payout plan. Total payments could exceed $1 billion over
the life of the agreement."

No mention of Ivan spilling the beans.

On 7/6/2021 11:48 AM, George Neuner wrote:
> On Tue, 06 Jul 2021 09:12:51 -0400, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>
>>> Then again, my preferred option is to use interfaces instead, but then
>>> people argue that interfaces are just poor man's MI.
>>
>> The good thing about inheritance is that it gives you subtyping.
>> Interfaces give you subtyping but without the bad after taste that you
>> get from inheritance.
>>
>> IOW, interfaces are "MI done right".
>
> In too many SI languages, interfaces are more annoying than helpful:
> far too often with SI the interface functions have to be
> re-implemented where in an MI language they would be inheritable.
>
> Mix-ins are useful, but sometimes you really want inheritance.
>

Several of the languages which I am aware of with interfaces also allow
something like:
public interface IFoo {
default void someMethod()
{ ... do something ... }
}

Where, if the class doesn't provide its own someMethod, it is implicitly
added from the interface.

A language could use multiple inheritance but make virtual inheritance
semantics the default, but this "kinda sucks" as there isn't really a
good way to implement it which doesn't carry a performance overhead.

Though, a similar strategy to what would normally be used for
implementing virtual inheritance can also be used to fake MI on top of a
SI object system.

This could be managed by the compiler, or one could be like "meh,
whatever", and have the programmers do it themselves if they want it.

One other possibility is to allow someone to throw a 'delegate' keyword
or similar onto an object field, in which case it will be transparently
used to resolve fields or methods if they were not found within the
containing class.

public class Bar {
int x;
public Bar(int i) { x=i; }
}
public class Bar {
int y;
public Bar(int i) { y=i; }
}

public class Foo {
delegate Bar bar;
delegate Baz baz;
public Foo(int i, int j) {
bar=new Bar(i);
baz=new Baz(j);
}
public int sum { get x+y; }
}

Foo foo = new Foo(3, 4);
int v = foo.sum; //calculates 'foo.bar.x + foo.baz.y'
int x = foo.x; // behaves like 'foo.bar.x'

So, in these cases, when we try to access 'x' or 'y' in the Foo class,
the compiler sees that neither Foo (nor its parent classes) provide
these members, but that it does delegate to another class which does,
and uses the values from these classes instead.

....

On Tuesday, July 6, 2021 at 1:26:13 PM UTC-5, BGB wrote:
> On 7/6/2021 11:48 AM, George Neuner wrote:
> > On Tue, 06 Jul 2021 09:12:51 -0400, Stefan Monnier
> > <mon...@iro.umontreal.ca> wrote:
> >
> >>> Then again, my preferred option is to use interfaces instead, but then
> >>> people argue that interfaces are just poor man's MI.
> >>
> >> The good thing about inheritance is that it gives you subtyping.
> >> Interfaces give you subtyping but without the bad after taste that you
> >> get from inheritance.
> >>
> >> IOW, interfaces are "MI done right".
> >
> > In too many SI languages, interfaces are more annoying than helpful:
> > far too often with SI the interface functions have to be
> > re-implemented where in an MI language they would be inheritable.
> >
> > Mix-ins are useful, but sometimes you really want inheritance.
> >
> Several of the languages which I am aware of with interfaces also allow
> something like:
> public interface IFoo {
> default void someMethod()
> { ... do something ... }
> }
>
> Where, if the class doesn't provide its own someMethod, it is implicitly
> added from the interface.
>
>
> A language could use multiple inheritance but make virtual inheritance
> semantics the default, but this "kinda sucks" as there isn't really a
> good way to implement it which doesn't carry a performance overhead.
>
> Though, a similar strategy to what would normally be used for
> implementing virtual inheritance can also be used to fake MI on top of a
> SI object system.
>
> This could be managed by the compiler, or one could be like "meh,
> whatever", and have the programmers do it themselves if they want it.
>
>
>
> One other possibility is to allow someone to throw a 'delegate' keyword
> or similar onto an object field, in which case it will be transparently
> used to resolve fields or methods if they were not found within the
> containing class.
>
> public class Bar {
> int x;
> public Bar(int i) { x=i; }
> }
> public class Bar {
> int y;
> public Bar(int i) { y=i; }
> }
>
> public class Foo {
> delegate Bar bar;
> delegate Baz baz;
> public Foo(int i, int j) {
> bar=new Bar(i);
> baz=new Baz(j);
> }
> public int sum { get x+y; }
> }
>
> Foo foo = new Foo(3, 4);
> int v = foo.sum; //calculates 'foo.bar.x + foo.baz.y'
> int x = foo.x; // behaves like 'foo.bar.x'
<
Does anyone else get the impression that this is a better description of
entering the C Obfuscation Championship that a means for sane
people to render application programs ?
<
>
> So, in these cases, when we try to access 'x' or 'y' in the Foo class,
> the compiler sees that neither Foo (nor its parent classes) provide
> these members, but that it does delegate to another class which does,
> and uses the values from these classes instead.
>
>
> ...

On 05/07/2021 19:49, BGB wrote:
> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>
>>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
>>> the Snobol-shaped.
>>
>> Some people who don't like C++ say that C++ is the perfect tool
>> for thumb-shaped problems :-)
>>
>
> Main problems I have with C++ ATM:
>   Compiler would be too complicated, don't want to bother with this;

C++ compilers are certainly complicated. It's a big language, and it is
a demanding language for compilers. Parsing is hard, with lots of
conditional keywords, and you need to be happy with heavy inlining or
the results will be hopelessly inefficient.

>   Multiple inheritance needlessly complicates stuff;

I'm not a fan of multiple inheritance myself. In particular, inheriting
data from different places is likely to cause trouble, and multiple
inheritance of classes with virtual methods is very rarely worth the
complication and confusion. CRTP, however, can be really neat (for
compile-time polymorphism). In one project I am working on, I have
templates for GPIO pins, arranged with inheritance:

template <int gpio_bank, int gpio_pin, bool output = false>
class GpioInOut :
public GpioIn<gpio_bank, gpio_pin>,
public GpioOut<gpio_bank, gpio_pin>
....

It works neatly, the source code is clear, it is hard to use incorrectly
as you can't mix up pins or accidentally drive an input-only pin, and
the resulting code is as efficient as possible since the compiler has
all the details of pin numbers, addresses, etc., on hand when compiling
"green_led.on();".

Multiple inheritance is a powerful tool, and is often used very poorly -
but it /can/ be used very well.

>   Templates needlessly complicate stuff;

Templates change the nature of the language significantly. If you still
think of C as being a language where a function in the source code
corresponds precisely to a function in the generated assembly, and you
think of C++ as being like C with extra features, you will not be able
to handle templates. Of course, it is a long time (perhaps three
decades) since C has had complete correspondence in functions - but
often you can pretend it works that way when it is useful.

In C++, however, the move has been towards higher level coding.
Templates generate functions and classes. They let you write more
general code, with a lot more flexibility.

Again, templates are powerful and can be abused, and template coding can
certainly be complicated. (It's got much easier in newer C++
standards.) But to suggest they are "needless" is tantamount to
admitting you really do not understand the language at all.

>   The C++ standard library and STL is kinda a trash fire;

There is plenty to like, and plenty to dislike in the C++ standard
library. It contains a great deal of functionality that few people will
ever need, and that does complicate things. And it suffers from
backwards compatibility (as does the language) - once something is in
the language, or the library, it is hard to remove it even if better
methods have been found.

>   ...
>
> Too many "features" exist essentially as a way to play whack-a-mole with
> the consequences of other features.
> If you leave out multiple inheritance and templates, many of the rest of
> the language features go "poof" and disappear.
>

If you leave out templates, the /language/ goes "poof" and disappears.
All you are left with is C with better structuring and a bit more type
safety - and you are back to copy-and-paste and macros for anything generic.

It's like saying FORTRAN would be simpler without arrays.

(There was an attempt at a C++ subset that simplified and restricted the
language, aimed as resource-limited systems - "Embedded C++". It was a
total and utter failure, and no one used it.)

>
> Leaving out templates also eliminates on of the major sources of massive
> code bloat and excessive build times.
>

Misuse of templates can lead to code bloat, especially with poorer
compilers. Good use of templates makes code smaller as the generality
is handled

> But what about generic containers?
> How about we have some other way of building containers which isn't so
> prone to be misused and hose everything?...
>
>
> But what could such an alternative possibly look like?
>
> How about we have a few types, lets call them 'auto' and 'variant',
> which unlike most other types, take on the type of the things that are
> passed to them. Similarly, they can be allowed in argument lists and as
> a return type, then the function will operate on that type (calling a
> function with 'auto' arguments may specialize the function over the
> argument types, allowing for any implicit type promotions).

Do you mean that instead of having to write something like:

template <typename T>
T add(T x, T y)
{ return x + y;
}

it would be nicer and neater to be able to write :

auto add(auto x, auto y)
{ return x + y;
}

That would let you use a nice general "auto" indicator for the type, and
make specialist functions as needed for the concrete type (or inline the
code as appropriate). Then there would be no need for the somewhat ugly
and verbose template syntax.

It turns out that the C++ designers thought that too, and this is now
valid syntax that means exactly the same as the template version.
(Templates are a lot more flexible, and can have non-type template
parameters, but for cases like this "auto" is a valid alternative syntax.)

On 06/07/2021 08:48, Thomas Koenig wrote:
> BGB <cr88192@gmail.com> schrieb:
>> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>
>>>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
>>>> the Snobol-shaped.
>>>
>>> Some people who don't like C++ say that C++ is the perfect tool
>>> for thumb-shaped problems :-)
>>>
>>
>> Main problems I have with C++ ATM:
>> Compiler would be too complicated, don't want to bother with this;
>
> Certainly correct.
>
> C++ has a way of accumulating features because somebody on the
> commitee (usually representing some company) feels that they
> need something.
>
> Modules are an example. I attended a talk at a GNU cauldron
> where somebody seriously suggested doing a http request to
> an oracle as part of the compilation process.
>
> This was to solve the problem of "which file defines which module".
> When I asked how the oracle should know, the answer was basically
> "not my department".

Modules (or units, or whatever a language wants to call them) are always
difficult if there is not a one-to-one correspondence between module
names and file names. C++ suffers from historical baggage here, going
right back to the early days of C. There really is no good way out of
this while getting the features people want (including being able to
treat existing headers as modules, during transitions to modules). But
to a very large extend, programmers don't care how the details of the
compiler works, as long as it works efficiently and correctly. No one
(except compiler writers and maintainers) cares that many C++ compilers
today are composed of multiple executables, that they generate assembly
rather than object code directly, or how they interact with linkers for
link-time optimisation. No one using a C++ compiler with modules will
care how the right module is found, as long as it /is/ found.

>
> Everybody agrees that using the whole of C++ for a project is
> madness and a sane subset is required, but apparently not two
> people agree on what this sane subset should be.

You can say that about /any/ language. Can you give an example of a C
project that uses all of C's language features? Can you give an example
that uses more than perhaps 5% of the C standard library? Languages and
their libraries cover features that people want and need (and yes,
sometimes the designers make mistakes and include stuff that later turn
out not to be popular). But no one expects any given person to use all
the features - with many features only being useful to a very small
proportion of users.

The bigger the language and library, the greater this effect - but it is
not by any means a C++ effect. Basically, you are complaining that C++
is big.

It's like complaining about the range of shops in a city. Perhaps you
come from a small village, where there are only a dozen shops and
everyone uses them all. But here in the city there are so many - it
would be madness to try to look in them all, but no two city dwellers
can agree on which subset of shops are useful.

>
> And of course, if you're a compiler writer, you cannot restrict
> yourself to a subset of a language.
>

Writing a good compiler is hard. Writing a good compiler for a big,
complex language is even harder - and even more effort. A single person
can perhaps write a passable C compiler with enough dedication - C++ is
far too big for that.

David Brown <david.brown@hesbynett.no> schrieb:
> On 06/07/2021 08:48, Thomas Koenig wrote:
>> BGB <cr88192@gmail.com> schrieb:
>>> On 7/4/2021 11:59 PM, Thomas Koenig wrote:
>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>
>>>>> Prolog is the perfect tool for Prolog-shaped problems. As is Snobol for
>>>>> the Snobol-shaped.
>>>>
>>>> Some people who don't like C++ say that C++ is the perfect tool
>>>> for thumb-shaped problems :-)
>>>>
>>>
>>> Main problems I have with C++ ATM:
>>> Compiler would be too complicated, don't want to bother with this;
>>
>> Certainly correct.
>>
>> C++ has a way of accumulating features because somebody on the
>> commitee (usually representing some company) feels that they
>> need something.
>>
>> Modules are an example. I attended a talk at a GNU cauldron
>> where somebody seriously suggested doing a http request to
>> an oracle as part of the compilation process.
>>
>> This was to solve the problem of "which file defines which module".
>> When I asked how the oracle should know, the answer was basically
>> "not my department".
>
> Modules (or units, or whatever a language wants to call them) are always
> difficult if there is not a one-to-one correspondence between module
> names and file names.

I certainly know that, Fortran also has modules.

The problem is that, when C++ added the new module feature, the
major problems this introduced were well known (including that
modules were a totally different thing from namespaces, and that
a #define outside a module should have an effect inside the used
module).

The fact that this feature was approved anyway points towards
a broken language design process.

>C++ suffers from historical baggage here, going
> right back to the early days of C. There really is no good way out of
> this while getting the features people want (including being able to
> treat existing headers as modules, during transitions to modules). But
> to a very large extend, programmers don't care how the details of the
> compiler works, as long as it works efficiently and correctly.

I would certainly be concerned if the compiler I used suddenly started
making http requrests to god knows where.

> No one
> (except compiler writers and maintainers) cares that many C++ compilers
> today are composed of multiple executables, that they generate assembly
> rather than object code directly, or how they interact with linkers for
> link-time optimisation. No one using a C++ compiler with modules will
> care how the right module is found, as long as it /is/ found.
>
>>
>> Everybody agrees that using the whole of C++ for a project is
>> madness and a sane subset is required, but apparently not two
>> people agree on what this sane subset should be.
>
> You can say that about /any/ language. Can you give an example of a C
> project that uses all of C's language features?

There is no particular reason to restrict the use of C to a subset
of the language, because the language is small enough.

With C++, this is different.

>Can you give an example
> that uses more than perhaps 5% of the C standard library? Languages and
> their libraries cover features that people want and need (and yes,
> sometimes the designers make mistakes and include stuff that later turn
> out not to be popular). But no one expects any given person to use all
> the features - with many features only being useful to a very small
> proportion of users.

That is a big problem.

C.A.R. Hoare of quicksort fame expressed this better than I could ever
hope to do in his "Hints on Programming Language Design":

# Some language designers have replaced the objective of simplicity
# by that of modularity, by which they mean that a programmer who
# cannot understand the whole of his language can get by with a
# limited understanding of only part of it. For programs that work
# as the programmer intended this may be feasible; but if his program
# does not work, and accidentally invokes some feature of the language
# which he does not know, he will get into serious trouble. If he is
# lucky, the implementation will detect his mistake, but he will not
# be able to understand the diagnostic message. Otherwise, he is even
# more helpless. If to the complexity of his language is added the
# complexity of its implementation, the complexity of its operating
# environment, and even the complexity of institutional standards
# for the use of the language, it is not surprising that when faced
# with a complex programming task so many programmers are overwhelmed.

> The bigger the language and library, the greater this effect - but it is
> not by any means a C++ effect. Basically, you are complaining that C++
> is big.

It is big, and it is a piecework of questionable features whose
interactions are poorly understood.

> It's like complaining about the range of shops in a city.

That is a false analogy. The problem is that, in a project, people
a) use features which they do not understand, or b) have to work
with other people's code which uses features they do not understand.

If, by buying from one shop in the city, I would force everybode
else to buy from the same shop, if they wanted it or not, and
if they didn't even know what they were buying and whay, and then would
be forced to check these purchases for defects and return them
to the store accordingly... that would be a bit more apt.

> Perhaps you
> come from a small village, where there are only a dozen shops and
> everyone uses them all. But here in the city there are so many - it
> would be madness to try to look in them all, but no two city dwellers
> can agree on which subset of shops are useful.
>
>
>>
>> And of course, if you're a compiler writer, you cannot restrict
>> yourself to a subset of a language.
>>
>
> Writing a good compiler is hard. Writing a good compiler for a big,
> complex language is even harder - and even more effort. A single person
> can perhaps write a passable C compiler with enough dedication - C++ is
> far too big for that.

That is correct. For Fortran 95, a single person can do it, but
that single person has to be extremely good; so far, only two
people have managed it effectively on their own, Malcolm Cohen
and Andy Vaught. And both of them got around the code generation
bit - Malcolm Cohen (the primary author of NAG's compiler) chose
to compile to C as an intermediate language, and Andy Vaught had
help with the scalarizer and with the glue code to gcc (which is
why g95 stagnated after the fork with gfortran).

In article <sc421l$1r7$1@newsreader4.netcologne.de>,
tkoenig@netcologne.de (Thomas Koenig) wrote:

> I would certainly be concerned if the compiler I used suddenly
> started making http requrests to god knows where.

I'd interpret this as malware in the compiler. After finding out that it
was intentional, my next question would be "How do I tell the difference
between the intended behaviour, and malware that tries to look like that?"
Because much malware /would/ be created.

John