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

G

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
 
C

coal

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.

This is a problem with the gnu stuff. In my opinion a lot of
intelligent people have painted themselves into a corner as far as gcc
goes. They keep adding to it in C and it gets to be an even bigger
mess than it was before they started. It needs to be rewritten and I
would use C++ if I were doing it.

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

I'm not sure what you mean with that last item. What will be
very slow?
- 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 -//-

I don't understand that very well, but I will reiterate something that
seems kind of related. In my opinion it would be helpful to split
current C++ compilers into two pieces. The first would output fully
instantiated C++ code and it would be available on-line. The second
would be more like a normal compiler and it would turn the output from
the first step into object code. I think that would require a "whole-
program" assumption, but I don't think that is a problem. If you want
decent optimization you have to be willing to reveal the whole
program.

Brian Wood
Ebenezer Enterprises
www.webebenezer.net
 
M

Matthias Buelow

Grizlyk said:
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.

What do you mean by "mutable results"?

Of course a C++ compiler can be written in C, you can also write one in
assembler or as a Turing Machine program.
 
G

Grizlyk

Mattias said:
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
 
M

Matthias Buelow

Grizlyk said:
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.
Have _you_ done it already?

I don't have to.
 
G

Grizlyk

Matthias said:
What exactly is your question?

Some of my questions in the first message even has word "question".
It sounds more like gibberish to me, sorry.

Alas. OO desing require ask experts of problem domain, even if you think
that this is gibberish for anybody. Anybody, who will answer, must take in
account what is the question about, maybe it is not easy to guess.
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?

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

Matthias Buelow

Grizlyk said:
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.
 
L

LR

Grizlyk said:
Mattias wrote:

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
 
M

Micah Cowan

LR said:
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. :)
 
B

Bo Persson

Micah said:
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_faq.html#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
 
G

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top