C++ improvements: core and user properties, default compiler

[Grizlyk]

To continue some ideas of "C++ Archeology: Limits of OO paradigm", i want
to ask about C++ development.

There are C++ compilers, that has been written in old good C. Are C or
pascal perfect languages that can be used to build any powerful OO
language with mutable source representation, as C++ could be? Obviously
no.

Is current C++ can be used to build the OO language? Obviously no, because
unfortunatelly C++ simultaneously is not-trivial for implementation, but
quite limited for users.

I have got a hint, that we can select "core of C++" (that does not mean
the core must be completely compatible with current C++ or its subset) and
use the not-mutable core language to build all concrete-hardware "complete
C++" compilers. The "complete C++" language can be the powerful OO
language with mutable source representation, structured by dialects.

The core language properties must be:
- compiler of the core must be able to be easy implemented by C-like
language
- the core must be very conservative (to resists all possible
improvements)
- the core must be suitable to express complete C++ compiler

The related questions are:
- what kind (enumerated set of properties) of language must we take for
core compiler?
- what set of properties and paradigms (in comparison with current C++)
must be supported by the core language?

The complete language can have "default compiler" - the thing with the
follow properties:
- public source code in terms of "core language"
- very slow, but pure incremental
- very easy to be extended by users with new dialects

The "default compiler" can be represented as:
- front-end translator from any concrete representation of "C++ source" to
concrete unified "internal (not for human using) representation"
- front-end compiler and logical optimiser from "internal representation"
to "code generator source code"
- code generator and hardware optimiser from "code generator source code"
to "compiled representation"
- C++ uints linker from "compiled representation"
- traditional static linker -//-
- C++ dynamic linker -//-
- traditional dynamic linker -//-

The related questions are:
- what (enumerated set of properties) is
- unified "internal (not for human using) representation"
- "code generator source code"
- "compiled representation"

Pure logical optimiser can be impossible to implement, so logical and
hardware optimisers can be implemented as separated, but related to the
concrete hardware pair for each concrete hardware

So, what can you advise about all of these?

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new
--
Message posted using http://www.talkaboutprogramming.com/...comp.lang.c++/
More information at http://www.talkaboutprogramming.com/faq.html

[Grizlyk]

co**@mailvault.com wrote:

>There are C++ compilers, that has been written
in old good C. Are C or pascal perfect
languages that can be used to build any
powerful OO language with mutable source
representation, as C++ could be?
Obviously no.

This is a problem with the gnu stuff.

No, i am not speaking about gnu stuff. Limitations here can be explained
by nature of programming language - nature of supported paradigms.

It is hard to write mutable results in languages, that has no enough
abstraction.

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new
--
Message posted using http://www.talkaboutprogramming.com/...comp.lang.c++/
More information at http://www.talkaboutprogramming.com/faq.html

[Grizlyk]

Mattias wrote:

>What do you mean by "mutable results"?

Read first message of the thread.

By the way, it seems to me, the first message is an example of questions
of OO conceptual level decomposition of the C++ domain and i asked experts
of C++ compilers who can describe the domain.

C++ compiler can be written in C

Have _you_ done it already?

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

--
Message posted using http://www.talkaboutprogramming.com/...comp.lang.c++/
More information at http://www.talkaboutprogramming.com/faq.html

[Matthias Buelow]

Grizlyk wrote:

>What do you mean by "mutable results"?

Read first message of the thread.

I did before responding. The term "mutable result(s)" doesn't appear in
there. What does appear is "mutable source representation" but I have no
idea what this is supposed to mean.
What exactly is your question?

By the way, it seems to me, the first message is an example of questions
of OO conceptual level decomposition of the C++ domain and i asked experts
of C++ compilers who can describe the domain.

It sounds more like gibberish to me, sorry.

>C++ compiler can be written in C

Have _you_ done it already?

I don't have to.

[Matthias Buelow]

Grizlyk wrote:

>>>C++ compiler can be written in C
Have _you_ done it already?

I don't have to.

The "have to" is wrong modal verb maybe? If you say "can be written", you
can prove it by anything, can't you?

The g++ (Gnu) compiler is written in C. Probably some others too.

[LR]

Grizlyk wrote:

Mattias wrote:

>C++ compiler can be written in C

Have _you_ done it already?

I'm sorry, but I don't understand the point of this question. No matter
the language of the compiler, the compiler is compiled too, and runs in
machine language.

And I think that it is well established that any task that can be
performed by a particular Turing complete language can be performed by
any Turing complete language.

Am I mistaken?

Do you think there is some requirement for C++ that requires something
special in the language used to implement it? What in particular?

LR

[Micah Cowan]

LR wrote:

I'm sorry, but I don't understand the point of this question. No matter
the language of the compiler, the compiler is compiled too, and runs in
machine language.

And I think that it is well established that any task that can be
performed by a particular Turing complete language can be performed by
any Turing complete language.

Am I mistaken?

This doesn't take anything away from the point you're making, but it
seemed worth pointing out that this is only true in the context of
Turing machines. C and sed are both Turing-complete; but you can't open
a network socket in sed*. :)

*Ignoring silly things like using the "r" command to open a device file
that opens a network connection, or using sed to drive a program through
a pipe to do so.

Of course, only someone who has neither written nor studied any sort of
compilers could believe that a language such as C would not be capable
of handling a compiler for the complete C++ language.

Grizlyk's arguments would make _somewhat_ more sense if the argument
were whether you could write a program to translate C++ into C programs
with identical functionality, though even there phe'd be wrong. In fact,
I believe Comeau Computing has just such a beast (and, of course, C++
was originally implemented via a compiler-to-C, though the language back
then was not nearly as complex).

If I were planning to write a C++ implementation, writing it in C would
be something I'd strongly consider, in no small part because (old)
standards-conformant C implementations still appear to be more plentiful
than C++ implementations, and because even if I chose to write it in
C++, I might choose to avoid many of the most advantageous pieces of the
C++ Standard Library, as I might not be able to depend on their having
been implemented as optimally as I might wish.

Of course, writing in C++ would have the advantage that I could then
bootstrap my implementation, which is a terrific, "eating your own
dogfood" way to test it. :)

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

[Bo Persson]

Micah Cowan wrote:

LR wrote:

>I'm sorry, but I don't understand the point of this question. No
matter the language of the compiler, the compiler is compiled too,
and runs in machine language.

And I think that it is well established that any task that can be
performed by a particular Turing complete language can be
performed by any Turing complete language.

Am I mistaken?

This doesn't take anything away from the point you're making, but it
seemed worth pointing out that this is only true in the context of
Turing machines. C and sed are both Turing-complete; but you can't
open a network socket in sed*. :)

*Ignoring silly things like using the "r" command to open a device
file that opens a network connection, or using sed to drive a
program through a pipe to do so.

Of course, only someone who has neither written nor studied any
sort of compilers could believe that a language such as C would not
be capable of handling a compiler for the complete C++ language.

Grizlyk's arguments would make _somewhat_ more sense if the argument
were whether you could write a program to translate C++ into C
programs with identical functionality, though even there phe'd be
wrong. In fact, I believe Comeau Computing has just such a beast
(and, of course, C++ was originally implemented via a
compiler-to-C,

Which was, of course, written in C++.

http://www.research.att.com/~bs/bs_f...#bootstrapping

though the language back then was not nearly as
complex).

If I were planning to write a C++ implementation, writing it in C
would be something I'd strongly consider, in no small part because
(old) standards-conformant C implementations still appear to be
more plentiful than C++ implementations, and because even if I
chose to write it in C++, I might choose to avoid many of the most
advantageous pieces of the C++ Standard Library, as I might not be
able to depend on their having been implemented as optimally as I
might wish.

Hey, if you write your own C++ compiler, you will of course have the
best Standard Library implementation as well. Just write that one
first!

>
Of course, writing in C++ would have the advantage that I could then
bootstrap my implementation, which is a terrific, "eating your own
dogfood" way to test it. :)

See! :-)
Bo Persson

[Grizlyk]

Let's return to OP questions. Of course, at last, I will do it myself, but
conditions, selected by me, could be incomplete.

I hope, one can see by the thread why i have written once, that we must
strictly divide C++ and STDLib. This is _really_ different things and the
things have really different experts.

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new
--
Message posted using http://www.talkaboutprogramming.com/...comp.lang.c++/
More information at http://www.talkaboutprogramming.com/faq.html