bug raport - about way of linking in c

[Greg Martin]

W dniu niedziela, 30 września 2012 15:04:08 UTC+2 użytkownik fir napisał:
by the way, I think that do not much simple
person could manage to understand what do I
meant and such comments as above are somewhat
(conference with my pol-eng dictionary here)
gross/coarse/boorish/loutish/vulgar
It is always terrible to read such stuff like-this

"Profesor" Fir, it would seem your English is so poor that you are
unable to express the beauty of your logic to others. However, the logic
expressed in, "i do not see how you see it, and do not understand your
objections, but they are false" could easily be translated as, "If you
don't agree with me then you must be wrong".

This in turn could be seen as either beyond arrogance or quite simply
trolling.

 

[fir]

W dniu niedziela, 30 września 2012 16:44:07 UTC+2 użytkownik GregMartin napisał:

"Profesor" Fir, it would seem your English is so poor that you are

unable to express the beauty of your logic to others. However, the logic

expressed in, "i do not see how you see it, and do not understand your

objections, but they are false" could easily be translated as, "If you

don't agree with me then you must be wrong".



This in turn could be seen as either beyond arrogance or quite simply

trolling.

You two bring it very low, I strongly wouldnt
want to go into it

 

[Thomas Richter]

with my slight change to linker you will
can to link it to your program, if they only
are will not be linked to the same one module
but each lib to to different module

Once again: C doesn't *define* "linking". Linking is not a language
feature, it's - from a C language perspective - an implementation detail
that is shared by many, but not by all implementations.

If you need a feature from the linker, ask your vendor.

Your perspective on what the "C language" is is simply wrong. You
*assume* that C is something particular it actually isn't, and then
complain that something is "wrong" with that. You may have a point in
that namespace management is a problem in C, and you are right with
that, but the language doesn't have it and won't have it. If you need
it, use another language that has definitions of modules. C doesn't.
Java does have modules, modula does, C++ uses namespaces as a similar
concept.

But "linking" is nothing that is even defined by the language specs,
thus there is nothing to change there.

Greetings,
Thomas

 

[Stephen Sprunk]

W dniu niedziela, 30 września 2012 13:20:23 UTC+2 użytkownik Keith Thompson napisał:

This is my own ground of new language related the spirit of c, so
choices and decisions are mine. Would tell you why I think they are
good but these are different lerge topics, not to discuss here in to
much large extent this time.

If you intend to create a new language that is not C, then it is
off-topic in comp.lang.c.

S

 

[Ben Bacarisse]

W dniu niedziela, 30 września 2012 15:04:08 UTC+2 użytkownik fir napisał:

Yes. It was in parentheses but I don't see how that would alter the
meaning very much.

You have not answered my objection that your suggestion (at least one
simple version of it -- I think you have made more than one) means that
the text of a program will no longer determine its meaning. Whilst
other features of C implementations (such as -DMACRO=value flags) also
have this effect, your suggestion (as I understood it at first) has this
effect on a much wider scale.

by the way, I think that do not much simple
person could manage to understand what do I
meant and such comments as above are somewhat
(conference with my pol-eng dictionary here)
gross/coarse/boorish/loutish/vulgar
It is always terrible to read such stuff like-this

I am genuinely sorry that you find my comment on your remark gross,
coarse, boorish, loutish or vulgar. I try very hard to avoid being any
of these things but no doubt I fail on occasion. It was flippant,
certainly, (and that is less than respectful) but I felt it was fitting
because of the tome of some of your other posts.

 

[Ben Bacarisse]

Once again: C doesn't *define* "linking". Linking is not a language
feature, it's - from a C language perspective - an implementation
detail that is shared by many, but not by all implementations.

This is not strictly speaking true. Translation phase 8 is described as
follows:

All external object and function references are resolved. Library
components are linked to satisfy external references to functions and
objects not defined in the current translation. All such translator
output is collected into a program image which contains information
needed for execution in its execution environment.

I agree, though, that this is a very high-level description and it does
not imply that there is anything that need be called "a linker".

However, the new feature could be described in similarly abstract terms,
so I don't think the OP's description of it in terms of a linker
necessarily invalidates it.

But "linking" is nothing that is even defined by the language specs,
thus there is nothing to change there.

I don't think that's true (though it gets a but language lawyer-ish).
What the OP wants from the link phase would violate certain guarantees
that C currently makes. Either that, or it can be seen as a request
that otherwise undefined behaviour (having multiple definitions of
external functions) be defined. Whichever way you look at it, some
change to the standard would be needed.

 

[Kaz Kylheku]

Mainly becouse it is not finished and it
is even far from finished maybe.

It never will be if you insist on replying to every followup to your postings,
even though you're outnumbered N to 1.

 

[Kaz Kylheku]

W dniu niedziela, 30 września 2012 14:35:14 UTC+2 użytkownik Ben Bacarisse napisał:

i wrote that ?

Second best quote.

 

[Stephen Sprunk]

This is no matter of namespace.
...
(One should not cure this by adding namespaces, this is no c spirit
in such things, it would be bad)

.... but reinventing namespaces is exactly what you've done.

Here is your proposed syntax (from another post):

module mian;

reaches module_a;
reaches module_b;
reaches module_c;

void main() {

module_a init(); (*)
module_b init();
module_c init();

module_a run();
module_b run();
module_c run();


}

Here is the same thing done with C++ namespaces:

#include "module_a.h"
#include "module_b.h"
#include "module_c.h"

void main() {
module_a::init();
module_b::init();
module_c::init();

module_a::run();
module_b::run();
module_c::run();
}

Aside from a minor difference in syntax, they're the exact same thing.

Since you refuse to recognize that you've reinvented namespaces, though,
you've done a poor job of it. In particular, the C++ solution (and the
C prefix convention that does roughly the same thing, which I provided
an example of in another reply) does not require any change to linkers
or break billions of lines of existing code, whereas your proposal does.

S

 

[Kaz Kylheku]

This is no matter of namespace.

It is purely a matter of namspace, and nothing else.

The real purpose of it, is that combining
(tryin to link) all modules with all other modulesin c linking process has no reason.

Linking is a name-based concept, and internal versus external linkage define
different namespaces of different sizes and scopes.

 

[Kaz Kylheku]

Aside from a minor difference in syntax, they're the exact same thing.

Since you refuse to recognize that you've reinvented namespaces, though,
you've done a poor job of it.

Refusing to recognize that prefixes on names are de-facto namespaces
is a sign of low intelligence (and therefore, needless to say, unsuitability
for working in language design).

 

[BartC]

Refusing to recognize that prefixes on names are de-facto namespaces
is a sign of low intelligence (and therefore, needless to say,
unsuitability
for working in language design).

Building-in a permanent prefix into a name is not the same as having
namespaces. Otherwise no-one would have bothered inventing them.

There is a considerable advantage to having a full 'name' made up of two or
more parts. We all benefit from 'namespaces' as used in hierarchical file
systems, and from having forenames and surnames!

 

[Greg Martin]

Building-in a permanent prefix into a name is not the same as having
namespaces. Otherwise no-one would have bothered inventing them.

There is a considerable advantage to having a full 'name' made up of two
or more parts. We all benefit from 'namespaces' as used in hierarchical
file systems, and from having forenames and surnames!

There is certainly a difference in programmer effort and ease of
consistency but on the other hand C is lexically scoped and a namespace
doesn't change that. It would just leave it to the compiler to
"decorate" the names, would it not?

 

[Les Cargill]

There is certainly a difference in programmer effort and ease of
consistency but on the other hand C is lexically scoped and a namespace
doesn't change that. It would just leave it to the compiler to
"decorate" the names, would it not?

The only difference is:

Suppose we have:

::ns1::a
::ns1::b
::ns2::c

a can refer to b without qualification. c cannot.

If you do "fake namespaces", you always have to qualify.

 

[fir]

W dniu wtorek, 2 października 2012 15:05:17 UTC+2 użytkownik Stephen Sprunk napisał:

... but reinventing namespaces is exactly what you've done.



Here is your proposed syntax (from another post):












Here is the same thing done with C++ namespaces:



#include "module_a.h"

#include "module_b.h"

#include "module_c.h"



void main() {

module_a::init();

module_b::init();

module_c::init();



module_a::run();

module_b::run();

module_c::run();

}



Aside from a minor difference in syntax, they're the exact same thing.



Since you refuse to recognize that you've reinvented namespaces, though,

you've done a poor job of it. In particular, the C++ solution (and the

C prefix convention that does roughly the same thing, which I provided

an example of in another reply) does not require any change to linkers

or break billions of lines of existing code, whereas your proposal does.

The difference is huge -

If you have namespaces and modules you
have two 'beings' (modules and namespaces)
In my proposal you have only modules - and
you dont need namespaces - its much
simpler

 

[Greg Martin]

W dniu wtorek, 2 października 2012 15:05:17 UTC+2 użytkownik Stephen Sprunk napisał:

The difference is huge -

If you have namespaces and modules you
have two 'beings' (modules and namespaces)
In my proposal you have only modules - and
you dont need namespaces - its much
simpler

So .. if I want to link to the other libraries I will have to know what
modules contain what names if I wish to gain any benefit from your
system? C's success has in large part been due to fact that it is
possible to gain considerable portability of code but if I have to know
the internals of object code I'm linking to that is lost. It's common to
link to objects written in other languages and not even know that is the
case.

Fortunately, it is outside of the purview of the language C to address
issues of code location in object files and this won't be a problem for
the language.

 

[fir]

So .. if I want to link to the other libraries I will have to know what
modules contain what names if I wish to gain any benefit from your
system? C's success has in large part been due to fact that it is
possible to gain considerable portability of code but if I have to know
the internals of object code I'm linking to that is lost. It's common to
link to objects written in other languages and not even know that is the
case.

Fortunately, it is outside of the purview of the language C to address
issues of code location in object files and this won't be a problem for
the language.

The main benefit here is trashing out header
files which i dislike.. (not to much will
change but there should be a way to contain
type definitions in .obj files etc)

I advanced this modular improve system with
some more ideas, but it is not finished yet
and may take even a few years yet (it originate
slowly)

The one more 'fature' i can tell about is
instantiating of modules, If a module is
reached it is like a joined space you have
a door to, its ram is away and you can reach
to it, say

module poland;

reach france;
reach spain;

// poland code here

but if you instantiate module its ram is
contained here, in module you use it


module main;
reaches logging;

uses pixelbuffer,
bit,
int,
float;

void main()
{
float f = 2.0;
bit b = 0;

pixelbuffer buf;



}

int is a module instantiatlized here

But not all questions Ive got resolved
in this place, Im working on it :/ its not so
easy

 

[Keith Thompson]

The main benefit here is trashing out header files which i
dislike.. (not to much will change but there should be a way to
contain type definitions in .obj files etc)

If you eliminate header files, you're making a radical change to the
C language, big enough that I wouldn't even call the new language
"C". It would break every non-trivial C program that's ever been
written. Even C++ didn't do that.

If you add your "modules" feature to the language without eliminating
header files, than you have two separate mechanisms with overlapping
functionality, which will make learning the language that much
more difficult.

You probably have some good ideas, but I don't think they can fit
into C. If you want to proceed with this, I suggest you invent
a new language. You can base it on C as much as you like, but I
advise against calling your new language "C". (The name "D" is
already taken; see <http://dlang.org/>. In fact, D may have some
of the features you like; for example, it uses `import std.stdio;`
rather than `#include <stdio.h>`.)

I also advise you to gain a very strong understanding of C as it's
currently defined if you want to base a new language on it.

[...]

void main()

And in your own language, you can use "void main()" as much as you like.
In C, it's wrong. (That's not *quite* accurate, but it's close enough.)

 

[fir]

W dniu środa, 3 października 2012 23:07:47 UTC+2 użytkownik Keith Thompson napisał:

[...]

The main benefit here is trashing out header files which i

dislike.. (not to much will change but there should be a way to

contain type definitions in .obj files etc)

If you eliminate header files, you're making a radical change to the

C language, big enough that I wouldn't even call the new language

"C". It would break every non-trivial C program that's ever been

written. Even C++ didn't do that.



If you add your "modules" feature to the language without eliminating

header files, than you have two separate mechanisms with overlapping

functionality, which will make learning the language that much

more difficult.



You probably have some good ideas, but I don't think they can fit

into C. If you want to proceed with this, I suggest you invent

a new language. You can base it on C as much as you like, but I

advise against calling your new language "C". (The name "D" is

already taken; see <http://dlang.org/>. In fact, D may have some

of the features you like; for example, it uses `import std.stdio;`

rather than `#include <stdio.h>`.)



I also advise you to gain a very strong understanding of C as it's

currently defined if you want to base a new language on it.



[...]

void main()

And in your own language, you can use "void main()" as much as you like.

In C, it's wrong. (That's not *quite* accurate, but it's close enough.)

I wrote on this before many times in this messages tree

1. local linking i see as a fix to the present c - it will break no line

2. other improvements makes a distinct language I work on almost 10 years (maybe not such many but I forgot when it had begun) I used to call it C2 asa 'codename'

I Said here on about 4 improvements, some
other I am thinking on are also:

1) realloc keyword

int tab[1000];

realloc tab[2000];

- it will make a new dynamic memory paradigm
(or almost) other than both GC and no
malloc/free - like management - labels/handlers
ale never disjoined with ram content here

2) larger structures are passed (in and out) by
hideen adress, return value is always on upper
scope so there are no waste on passing

struct float3 {float x,y,z};

(float3) cross(float3 x, float3 y) //by adr not value
{
return { x.y * y.z - x.z * y.y,
x.z * y.x - x.x * y.z,
x.x * y.y - x.y * y.x} //thru addr fill to ram on upper scope

//...
}

(important - this one is efficient
and handy one, fills holes in present c)

float3 v = cross({1,2,3},{4,5,6});

multple values can be returned

int x,y,z = f();

and such like

3) couple of other ideas

ex 'build in' types
float3 or float4 float8 int4 etc related to sse/avx types, accelerated by sse operations on such
types

 

[fir]

W dniu środa, 3 października 2012 23:07:47 UTC+2 użytkownik Keith Thompson napisał:

advise against calling your new language "C". (The name "D" is
already taken; see <http://dlang.org/>. In fact, D may have some
of the features you like; for example, it uses `import std.stdio;`
rather than `#include <stdio.h>`.)

in my version : as I said

module main;
reaches stdio;

char* main(char* in)
//(or close couse sizes and maybe other info should be sent too)
{

}

I also advise you to gain a very strong understanding of C as it's
currently defined if you want to base a new language on it.

got deep understanding of the thing I call "Spirit Of C"