G
Grizlyk
To continue some ideas of message "C++ improvements: core and user
properties, default compiler ".
Hi, boys and girls, what news on Pluke
?
Concerning the C++ improvements.
The proccess hardly move and there are nothing to be proud, but some
things are done.
In spite of the fact, that there are no great interest for the ideas
in the group, i am publishing the snapshort of some parts of current
state of the development, because i myself never did the kind of work
(programming language improvement) befor and the improvements are not
private, so i will not angry if anyone will make it faster and better
than i do.
1. Human-oriented representation of C++ source code.
The original C++ language, divided into two parts (cC++/uC++) must
have representation of source code for each part for human usage.
While considering the representation we can find, that with the user
part (uC++), to support OO design we neeed to have ability to easy
export not only interfaces of code, but implementations - parts of
open source code and copirighted compiled code from one project to
another.
The current C++ way of exporting implementation, inherited from C, is
creation a solid "compilation units", source code of which is hard
linked (often with the help of preprocessor) with development
environment of source project. The linkage is so deep, that often even
just a project itself can not be exported to other compatible machine
without valuable changes of the project, but export a part of the code
into other project is very non-trivial thing.
- The problem here is much more complex source code for C++, than for
C.
The problem is representation of source code. The current way of
abstracion as "some units with interface and implementation" by
"class" or by "compilation unit" is not enough to export
implementation of methods to increase reusage of code. The _effective_
instantiation of OO messages in language with reach low-level
properties requires export implementation of single, separated methods
of class or namespace.
- The problem here is the fundamental problem of "function".
"Function" has "interface" (list of parameters and return value), but
links of the function to other, external resources (resources are not
defined inside the function local scope), have no any "interfaces". I
decided, that the unspecified, unlimited, unchecked access to external
resources makes "function" open in bad reason - inportable.
- The problems of C++ name lookup.
The related question is the fact, the C++, unlike C, has non-boolean
name lookup, in other words, names of C++ can be placed not only in
global or local scope, that is why C++ can not just extend simple
rules of C-style boolean name lookup.
Using the several facts i offer to consider "function" as an
abstraction with pair of interfaces: "front end interface" (ordinary)
and "back end interface" (new). The goal of the rear interface is
- explitely specification of external resources for each function (the
same as now ordinary function explitely specifies own ordinary
interface);
- using types to the kind of specification of externals.
The way to move software from one project to another is "on fly"
substitution of correct type of externals (applying correct type of
back end interface) during insertion code from one project to another.
2. What kind of syntax can be introduced for C++ to express back-end
function interface, to make typed access to external resource?
Any thing can not be infinitly improved by a little inheritance of
original thing, because during the evolution we find a point, where
valuable changes must be done to reach result and the new thing will
be enogh incompatible with original thing.
The all above force me to the idea, that C++ can not be easy improved
into the pair c/u, the source language requires dramatic, important,
valueable and visible changes, to lose all inherited "bad" prorerties
and new language can not be compatible with old C++ (old C++ can be
represented as dialect of new only).
It is not very good news, because any easy improvements of C++ are
much easy to do than invention of quite new language.
The idea of the explicit declaration of externals for each portable
part of code has technical problems, the declarations of external are
hard to be coded, in fact all not explicitly declared names will be
errors.
But with IDE, integrated into language, as uC++ does, the most trivial
way as "hit the problem by own forehead" can be used with success, the
IDE can hide any trivial operations, finds new names from code,
creates records for the names in declaration of back end interface and
user will control the existed records only.
The fact of IDE intergrated into language changes the syntax very
much, in fact the presence of IDE is the similar to presence of
english letters and digits in keyboard.
I am not sure, that function with two interfaces is smart idea and i
have no "complete theory of comparison the two kind of functions with
program design", but some artificial examples looks quite successfull
and now i consider the idea as working.
3. Summary.
All encountered problems of C++ improvements still can not set the
process of improvement into state of separated properties to upgrade,
i still did not find independed "bones" of uC++, from any
improvements.
best regards
properties, default compiler ".
Hi, boys and girls, what news on Pluke
?Concerning the C++ improvements.
The proccess hardly move and there are nothing to be proud, but some
things are done.
In spite of the fact, that there are no great interest for the ideas
in the group, i am publishing the snapshort of some parts of current
state of the development, because i myself never did the kind of work
(programming language improvement) befor and the improvements are not
private, so i will not angry if anyone will make it faster and better
than i do.
1. Human-oriented representation of C++ source code.
The original C++ language, divided into two parts (cC++/uC++) must
have representation of source code for each part for human usage.
While considering the representation we can find, that with the user
part (uC++), to support OO design we neeed to have ability to easy
export not only interfaces of code, but implementations - parts of
open source code and copirighted compiled code from one project to
another.
The current C++ way of exporting implementation, inherited from C, is
creation a solid "compilation units", source code of which is hard
linked (often with the help of preprocessor) with development
environment of source project. The linkage is so deep, that often even
just a project itself can not be exported to other compatible machine
without valuable changes of the project, but export a part of the code
into other project is very non-trivial thing.
- The problem here is much more complex source code for C++, than for
C.
The problem is representation of source code. The current way of
abstracion as "some units with interface and implementation" by
"class" or by "compilation unit" is not enough to export
implementation of methods to increase reusage of code. The _effective_
instantiation of OO messages in language with reach low-level
properties requires export implementation of single, separated methods
of class or namespace.
- The problem here is the fundamental problem of "function".
"Function" has "interface" (list of parameters and return value), but
links of the function to other, external resources (resources are not
defined inside the function local scope), have no any "interfaces". I
decided, that the unspecified, unlimited, unchecked access to external
resources makes "function" open in bad reason - inportable.
- The problems of C++ name lookup.
The related question is the fact, the C++, unlike C, has non-boolean
name lookup, in other words, names of C++ can be placed not only in
global or local scope, that is why C++ can not just extend simple
rules of C-style boolean name lookup.
Using the several facts i offer to consider "function" as an
abstraction with pair of interfaces: "front end interface" (ordinary)
and "back end interface" (new). The goal of the rear interface is
- explitely specification of external resources for each function (the
same as now ordinary function explitely specifies own ordinary
interface);
- using types to the kind of specification of externals.
The way to move software from one project to another is "on fly"
substitution of correct type of externals (applying correct type of
back end interface) during insertion code from one project to another.
2. What kind of syntax can be introduced for C++ to express back-end
function interface, to make typed access to external resource?
Any thing can not be infinitly improved by a little inheritance of
original thing, because during the evolution we find a point, where
valuable changes must be done to reach result and the new thing will
be enogh incompatible with original thing.
The all above force me to the idea, that C++ can not be easy improved
into the pair c/u, the source language requires dramatic, important,
valueable and visible changes, to lose all inherited "bad" prorerties
and new language can not be compatible with old C++ (old C++ can be
represented as dialect of new only).
It is not very good news, because any easy improvements of C++ are
much easy to do than invention of quite new language.
The idea of the explicit declaration of externals for each portable
part of code has technical problems, the declarations of external are
hard to be coded, in fact all not explicitly declared names will be
errors.
But with IDE, integrated into language, as uC++ does, the most trivial
way as "hit the problem by own forehead" can be used with success, the
IDE can hide any trivial operations, finds new names from code,
creates records for the names in declaration of back end interface and
user will control the existed records only.
The fact of IDE intergrated into language changes the syntax very
much, in fact the presence of IDE is the similar to presence of
english letters and digits in keyboard.
I am not sure, that function with two interfaces is smart idea and i
have no "complete theory of comparison the two kind of functions with
program design", but some artificial examples looks quite successfull
and now i consider the idea as working.
3. Summary.
All encountered problems of C++ improvements still can not set the
process of improvement into state of separated properties to upgrade,
i still did not find independed "bones" of uC++, from any
improvements.
best regards