«

Le 30/04/12 10:01, Malcolm McLean a écrit :

> We also need a bigger standard library.

Things like hash tables, regular expressions,

directory functions, port access for internet programming, SQL,

and the ability to open a graphics window shouldn't have to rely on 3rd
party libraries.

Well, I am developing just that. And this since almost two years.

The latest message is just a few hours ago. Please take a look.

Thanks

jacob
P.S.

http://code.google.com/p/ccl/

On 04/30/2012 02:33 AM, Robert Wessel wrote:
....
> And if you can't address C's ubiquity, you aren't going to have a
> better language than C.

One of the key features of C that has lead to it's ubiquity is also one
that's been most strongly reviled: the freedom it gives implementors in
implementing the language. The standard deliberately leaves many
features implementation-defined or otherwise unspecified, and in many
cases says that the behavior is undefined. In many cases, it does so
because it was thought that there might be some platforms, now or in the
future, for which requiring a specific behavior would make it
excessively difficult to create a fully conforming implementation of C
with acceptable performance.

What the standard doesn't say about Quality of Implementation (QoI)
allows a low-quality but conforming implementation of C to become
available on virtually every possible platform not long after the
platform itself becomes available. What the standard doesn't say about
specific features allows a high-performance implementation that takes
advantages of specific features of a particular platform, while still
being fully-conforming, to eventually become available.

That is a key factor in C's ubiquity. It's not the only factor - if it
were, then the best C standard would be no C standard, giving
implementors complete freedom of implementation. I programmed in C
before the first standard, I have no desire to go back to that world.
The C standard does mandate support for enough useful features that
people can write useful programs without very frequently exceeding the
limits of what it does guarantee, and that is also important.
--
James Kuyper

Le 30/04/12 13:26, James Kuyper a écrit :
> On 04/30/2012 02:33 AM, Robert Wessel wrote:
> ...
>> And if you can't address C's ubiquity, you aren't going to have a
>> better language than C.
>
> One of the key features of C that has lead to it's ubiquity is also one
> that's been most strongly reviled: the freedom it gives implementors in
> implementing the language. The standard deliberately leaves many
> features implementation-defined or otherwise unspecified, and in many
> cases says that the behavior is undefined. In many cases, it does so
> because it was thought that there might be some platforms, now or in the
> future, for which requiring a specific behavior would make it
> excessively difficult to create a fully conforming implementation of C
> with acceptable performance.
>
[snip]

That doesn't justify taking 20+ years for getting rid of gets() however.

There are obvious WARTS and BUGS in the C standard. asctime() had a
built in buffer overflow in the sample code of the C99 standard.

We have discussed about the trigraphs for years and they are STILL THERE
in the 2011 standard that didn't dare to fix all bugs apparently, they
were busy introducing more problems with their thread specs.



jacob

On 04/30/2012 03:41 AM, wrote:
> On Sunday, April 29, 2012 9:23:08 PM UTC+1, io_x wrote:
>
>> here i not find the google sys for NG
>> so google not support NG?
>
> if you want a proper reply make it clearer what you are asking.

You're talking to io_x; clarity is not an available option.
--
James Kuyper

> If you were given the task to design a replacement for the C programming
> language intended to fix all its problems and shortcomings, what would you
> propopose?

http://xkcd.com/927/

Leo Havmøller.

"BGB" <> wrote in message
news:jnkq43$f66$...
> On 4/29/2012 4:37 PM, BartC wrote:

>> The #include mechanism can be left alone. But for using library
>> functions, there would just be something like:
>>
>> #import bar

> except #import is already used by C++, and is technically different from
> include.

Sorry, I didn't realise this replacement language had to retain
compatibility with C++!

I'm not even sure if it's supposed to be a drop-in replacement for C itself.
(And if not, there was the D language, or the first version of it; recently
it seems to have become nearly as complex as C++).

> <--
> #pragma precompiled_header //compiler hint to use PCH
> #pragma once //compiler hint to only include once
>
> #ifndef MYLIB_H //good old header guard (for everyone else)
> #define MYLIB_H
> ...
> #endif
> -->

But this is exactly the sort of stuff we're trying to tidy up. Just write
#import and let the compiler worry about these things. The efficiency of
reading large numbers of headers is also a compiler issue, and it should
solve that problem, if in fact it is a problem (caching the results of
previous imports of the same module for example; but it should be behind the
scenes).


>>> ability to put "_" in numbers as a separator, as in
>>> "0x0123_4567_89AB_CDEF"
>>
>> At least two or three major versions of C over twenty years, and no-one
>> bothers to add in trivial stuff like this which takes five minutes..
>>
>
> yeah, my language uses this syntax.

(I use "_", "'" and "`" as separators which can also be mixed. I also allow
numeric literals to be split over several lines (as I have to accommodate
big integers too). Also "million", "billion" etc as multipliers.)

> it would be nice in C for making things like 64-bit constants easier to
> read.

Especially when they get around to allowing binary literals.

>>> multi-line strings (like in Lua, Python, and my own language).
>>
>> Doesn't C already have that? You do need to have the portion on each
>> line fully quoted.

> however, with multi-line string literals, I would no longer need a
> separate tool for this, and could just be like:
> char *mylib_bigGlobOfASM=
> """
> ...
> lots of code...
> ...
> lots more code...
> ...
> """;

OK (just making a mental note to add the same feature..). Actually, a
version of #include which reads in the entire file as a string literal could
be useful here (taking care of embedded quotes etc which would anyway no
longer be an issue). That could also allow the compiler to keep the actual
string data on disk until it's necessary to do something with it.

--
Bartc

"Kaz Kylheku" <> wrote in message
news:...
> On 2012-04-29, Rui Maciel <> wrote:
>> If you were given the task to design a replacement for the C programming
>> language intended to fix all its problems and shortcomings, what would
>> you
>> propopose?

> I would strengthen arrays without the disadvantages of making them more
> encapsulated.

What are the disadvantages of an encapsulated array (assuming there are
still regular arrays too)?

> There would a way to define an integral object which indicates
> the size of an array referenced by a pointer:

> double *dynamic : int size;

I recently created a similar feature, I just called it a 'slice', but it is
simply an encapsulated (pointer, length) object. This is handy for passing
to functions (passing a regular array as a slice parameter, the length is
automatically filled in and the caller knows then the size of the array).
But is not suitable for proper dynamic arrays where the language looks after
the memory side.

This opens the way to slicing operations in the language, and works with
char arrays too! (Ie. you get counted strings for free.)

--
Bartc

בת×�ריך יו×� ש×*×™,30 ב×�פריל 2012 09:08:29 UTC+1, מ×�ת jacob navia:
> Le 30/04/12 10:01, Malcolm McLean a écrit :
>
> > We also need a bigger standard library.
>
> Things like hash tables, regular expressions,
>
> directory functions, port access for internet programming, SQL,
>
> and the ability to open a graphics window shouldn't have to rely on 3rd
> party libraries.
>
> Well, I am developing just that. And this since almost two years.
>
> The latest message is just a few hours ago. Please take a look.
>
The issue is that it needs to be accepted as a standard by someone with theweight to make everyone use it.

Anyone can write typedef float[3] vect3; The hard part is getting everyone to use the same typedef for their 3d libraries. You'll always get some pedant who insists on point3 for points and vect3 for directions. And you'll always get someone who legitimately needs double precision, or 16 bit fixed point. But the worst problem is that someone else will write typedef struct {float x; float y; flaot z} vector3; simply because it was never arranged that you would be the person to define the 3 dimensional point type for the entire world.

On 4/30/2012 5:06 AM, BartC wrote:
> "BGB" <> wrote in message
> news:jnkq43$f66$...
>> On 4/29/2012 4:37 PM, BartC wrote:
>
>>> The #include mechanism can be left alone. But for using library
>>> functions, there would just be something like:
>>>
>>> #import bar
>
>> except #import is already used by C++, and is technically different
>> from include.
>
> Sorry, I didn't realise this replacement language had to retain
> compatibility with C++!
>
> I'm not even sure if it's supposed to be a drop-in replacement for C
> itself. (And if not, there was the D language, or the first version of
> it; recently it seems to have become nearly as complex as C++).
>

it depends.

for example, my own language is an entirely different language, but most
of my own "C variants" were more-or-less bidirectionally compatible with
existing C compilers, differing mostly in terms of details and
standards-conformance issues.

for example, a person can use alternate declaration parsing without
necessarily breaking compatibility, but with the cost that there may be
constructions which are no longer valid or held in common.

a person can also largely define syntax extensions in ways which can be
faked via macros as-needed.

....


>> <--
>> #pragma precompiled_header //compiler hint to use PCH
>> #pragma once //compiler hint to only include once
>>
>> #ifndef MYLIB_H //good old header guard (for everyone else)
>> #define MYLIB_H
>> ...
>> #endif
>> -->
>
> But this is exactly the sort of stuff we're trying to tidy up. Just
> write #import and let the compiler worry about these things. The
> efficiency of reading large numbers of headers is also a compiler issue,
> and it should solve that problem, if in fact it is a problem (caching
> the results of previous imports of the same module for example; but it
> should be behind the scenes).
>

I disagree in the sense that I wasn't writing about "tidying up" C, but
rather:
changes to increase flexibility and allow higher-performance compilers.


as-is, the design of the language often makes it necessary to spend
anywhere from 100ms to several seconds compiling each module (and C++ is
IME much worse in these regards), whereas at least allowing for the
possibility of a C compiler that requires, say, under 10ms per module,
would be desirable.

as-is, the bulk of time when compiling C tends to go mostly into:
A, parsing header contents;
B, dealing with parsed header contents.

besides this, declarations are both common and presently fairly
expensive to parse (needing to endlessly look up identifiers to
determine whether or not they are a typedef is both not free regarding
time, and also limits some possibilities regarding the implementation).


admittedly, I am partly also thinking of ideas to revive my "C-based
scripting" effort (eventually), partly by in this case likely compiling
C into a form usable by my BGBScript VM. it should work as nearly every
major C feature is supported by the script VM (yes, including pointers).

a downside would be that performance would be worse, since (among other
things), the script VM currently lacks a functional JIT. however, a
number of recent changes should make it possible to implement a much
simpler JIT, say, by reducing the need for complex type analysis in the
back-end, ...


>
>>>> ability to put "_" in numbers as a separator, as in
>>>> "0x0123_4567_89AB_CDEF"
>>>
>>> At least two or three major versions of C over twenty years, and no-one
>>> bothers to add in trivial stuff like this which takes five minutes..
>>>
>>
>> yeah, my language uses this syntax.
>
> (I use "_", "'" and "`" as separators which can also be mixed. I also
> allow numeric literals to be split over several lines (as I have to
> accommodate big integers too). Also "million", "billion" etc as
> multipliers.)
>

I considered these, but opted for only allowing '_' on the basis that
the others would have potentially created syntax issues.


>> it would be nice in C for making things like 64-bit constants easier
>> to read.
>
> Especially when they get around to allowing binary literals.
>

yep.


>>>> multi-line strings (like in Lua, Python, and my own language).
>>>
>>> Doesn't C already have that? You do need to have the portion on each
>>> line fully quoted.
>
>> however, with multi-line string literals, I would no longer need a
>> separate tool for this, and could just be like:
>> char *mylib_bigGlobOfASM=
>> """
>> ...
>> lots of code...
>> ...
>> lots more code...
>> ...
>> """;
>
> OK (just making a mental note to add the same feature..). Actually, a
> version of #include which reads in the entire file as a string literal
> could be useful here (taking care of embedded quotes etc which would
> anyway no longer be an issue). That could also allow the compiler to
> keep the actual string data on disk until it's necessary to do something
> with it.
>

yes, potentially.

On 04/30/2012 11:22 AM, Malcolm McLean wrote:
....
> The issue is that it needs to be accepted as a standard by someone with the weight to make everyone use it.

No one has that "weight". If it needs to be forced on people - if it
can't gain acceptance except by reason of being mandated by a
sufficiently powerful authority - it can't be good enough to justify
mandating it.