Here are a few more comments on D:


1. The "->" operator is unnecessary, and IMHO should be discarded. Replace all uses of it with "." (dot). "->" was necessary in the very early days of C, when the type system was incomplete. Today it is unnecessary.


Furthermore, it is an inconvenience in many situations, at least in C. I have encountered many times where, for example, a structure was declared statically, and then for some reason, was changed to be dynamically allocated.  In principle, all that should be required to do this is to change the declaration "aStruct x" to "aStruct *x," and add the allocation code. However, this also requires changing all occurrences of "x.name" to "x->name." This is not just a minor nuisance - it inhibits refactoring and experimentation and code reuse. The distinction between structure-dereference and pointer-dereference serves no useful purpose, IMHO, and should be discarded.


2. IMHO, a major flaw in C, and its successors, is the absence of nested functions. People who have never worked in languages that support them always belittle them, but IMHO they are extremely valuable tools. Obviously, like any tool, they can be abused, but when used effectively they can greatly simplify and clarify code. Nested functions are simply about scope. By providing a tool for managing scope more effectively, they can often eliminate the need for some global variables, or long, awkward parameter sequences and they can replace uses of macros that are often used as stand-ins for nested functions. They can eliminate a lot of code duplication that occurs in C simply because there is no convenient tool for encapsulating such code.


There is no significant difficulty in compiling nested functions. An early paper on C claimed that the reason C does not have nested functions is that it does not support compiling onto the stack. This was, of course, nonsense. Nested functions are compiled exactly the same way other functions are compiled. Nesting only affects scope. Nested functions can only be called from the function in which they are nested, or other functions nested later in the same function, and nested functions can access variables that are declared before them in the function(s) in which they are nested. (Such uses can be viewed as a form of the "global variable" problem, but because of the limited scope, the concern is far less serious.)


3. IMHO, the "asm" statement should be eliminated from the language definition. A language standard of this sort, intended for widespread use, should not define such a machine- and environment-specific feature. Obviously any specific compiler could support it as an extension, but it should not be part of the pure language definition.

Peter Curran wrote:

> Here are a few more comments on D:
>
> 1. The "->" operator is unnecessary, and IMHO should be discarded. Replace all uses of it with "." (dot). "->" was necessary in the very early days of C, when the type system was incomplete. Today it is unnecessary.

Amen.

> 2. IMHO, a major flaw in C, and its successors, is the absence of nested functions.

Personally, I like this idea.  Just today I was coding something like:

bool func(char *string)
{
    if(special_condition)
        return algorithm(string);

    char *cur;
    for(cur = string; *cur != '\0'; cur++)
        if(algorithm(string))
            return true;

   return false;
};

I had to put algorithm() in a separate function...it would have made a lot of sense for it to just be defined *inside* the current function.

> 3. IMHO, the "asm" statement should be eliminated from the language definition. A language standard of this sort, intended for widespread use, should not define such a machine- and environment-specific feature. Obviously any specific compiler could support it as an extension, but it should not be part of the pure language definition.

Not sure what to think here.  My first thought is that asm *should* be part of the language, or it will not be useful for very low-level stuff like kernels and such...but maybe asm code should be relegated to special "asm modules" or some such.

"Peter Curran" <pcurran@acm.gov> wrote in message news:3B857C48.64D774DB@acm.gov...
> Here are a few more comments on D:
> 1. The "->" operator is unnecessary, and IMHO should be discarded.
> Replace all uses of it with "." (dot). "->" was necessary in the very
> early days of C, when the type system was incomplete. Today it is
> unnecessary.

I agree. It's on its way out.


> 2. IMHO, a major flaw in C, and its successors, is the absence of nested functions. People who have never worked in languages that support them always belittle them, but IMHO they are extremely valuable tools. Obviously, like any tool, they can be abused, but when used effectively they can greatly simplify and clarify code. Nested functions are simply about scope. By providing a tool for managing scope more effectively, they can often eliminate the need for some global variables, or long, awkward parameter sequences and they can replace uses of macros that are often used as stand-ins for nested functions. They can eliminate a lot of code duplication that occurs in C simply because there is no convenient tool for encapsulating such code.

I like nested functions too, and the reason they're not in the language is simply time.



> 3. IMHO, the "asm" statement should be eliminated from the language definition. A language standard of this sort, intended for widespread use, should not define such a machine- and environment-specific feature. Obviously any specific compiler could support it as an extension, but it should not be part of the pure language definition.

Using asm is obviously inherently non-portable, but since D is for systems apps, those apps will need asm from time to time. I specified the form it should take primarilly because I detest the way it's done in gcc.

I'll put a fuller answer to this in the FAQ.

> > 3. IMHO, the "asm" statement should be eliminated from the language definition. A language standard of this sort, intended for widespread use, should not define such a machine- and environment-specific feature. Obviously any specific compiler could support it as an extension, but it should not be part of the pure language definition.
>
> Using asm is obviously inherently non-portable, but since D is for systems apps, those apps will need asm from time to time. I specified the form it should take primarilly because I detest the way it's done in gcc.
>
> I'll put a fuller answer to this in the FAQ.

This would eliminate the #define brackets:

asm(x86) {
}

asm(ppc) {
}

asm(sparc) {
}

You could then keep your asm blurbs together in the same file, and emit the right code based on the target hw.

Jim

Peter Curran wrote:
> 2. IMHO, a major flaw in C, and its successors, is the absence of nested
> functions. [...snip...] Nested functions are simply
> about scope. By providing a tool for managing scope more effectively,
> they can often eliminate the need for some global variables, or long,
> awkward parameter sequences and they can replace uses of macros that are
> often used as stand-ins for nested functions. They can eliminate a lot
> of code duplication that occurs in C simply because there is no
> convenient tool for encapsulating such code.

In C++, the class takes on this kind of encapsulation duty. Not to say whether one or the other is better, but C++ programmers are likely to be more comfortable doing it way they're doing it now.

Of course, member functions which call other member functions as helpers are using the exact same logical concept as nested functions, just in a different shape.

> 3. IMHO, the "asm" statement should be eliminated from the language definition. A language standard of this sort, intended for widespread use, should not define such a machine- and environment-specific feature. Obviously any specific compiler could support it as an extension, but it should not be part of the pure language definition.

Not even to the point of reserving the keyword "asm" and suggesting a semantic for asm blocks? That seems to me to be taking purity a little too far.

-RB

Jim Eberle wrote in message <9m48up$1t4$1@digitaldaemon.com>...
>This would eliminate the #define brackets:
>asm(x86) {
>}
>
>asm(ppc) {
>}
>
>asm(sparc) {
>}
>
>You could then keep your asm blurbs together in the same file, and emit the right code based on the target hw.


That is an interesting idea!

> Using asm is obviously inherently non-portable,

What?
X86 assembly is more portable than C :-)

It will run in:
Windows
Linux
Solaris
Be
FreeBSD

And ALL SYSTEMS that use an X86 processor! This includes even the Macintosh with its emulator.


ASSEMBLY LIVES!
:-)

Just a little thought, I've used both inline asm and external asm, I have to say I think external asm with linkage is preferable.

I assume the reasoning for inline asm is speed, but on very small routines this may actually cause a slowdown.  All registers used must be pushed only the stack and then popped, people have no idea about what the compiler has been doing such as instruction pairing, using inline asm forces the compiler to abandon any optimisation it may have been doing.  You effectively lose the benefits of 'inlining' in which case why not make it a function call and write an external asm function thats linked in anyway.

I have a feeling allowing inline asm may lead to an equivalent horrible mightmare of #ifdefs we have today.

Just a few thoughts.

"Walter" <walter@digitalmars.com> wrote in message news:9m4rfe$1d5c$3@digitaldaemon.com...
>
>
> Jim Eberle wrote in message <9m48up$1t4$1@digitaldaemon.com>...
> >This would eliminate the #define brackets:
> >asm(x86) {
> >}
> >
> >asm(ppc) {
> >}
> >
> >asm(sparc) {
> >}
> >
> >You could then keep your asm blurbs together in the same file, and emit
the
> >right code based on the target hw.
>
>
> That is an interesting idea!
>
>

Wrong, depends on what flavour of x86

i386, i486, pentium, pentiumII pentiumIII athlon cyrix etc

There are even subtle differences between 486s and pentiums RTDSC register
for instance,
Even if the processors share the same instruction set the way you optimise
for them may be different, instruction pairing for pipelines etc.

The Pentium has extra instructions than a 486.

These days processors are so complex and compilers so advanced you have to 'really'  know what you are doing to beat the compiler unless you want to access processor specific functions, (SSE for the Pentium III for example).

"jacob navia" <jacob@jacob.remcomp.fr> wrote in message news:9m5cff$1o6g$1@digitaldaemon.com...
>
> > Using asm is obviously inherently non-portable,
>
> What?
> X86 assembly is more portable than C :-)
>
> It will run in:
> Windows
> Linux
> Solaris
> Be
> FreeBSD
>
> And ALL SYSTEMS that use an X86 processor! This includes even the
Macintosh
> with its emulator.
>
>
> ASSEMBLY LIVES!
> :-)
>
>
>
>
>

Nathan Matthews a écrit :
> 
> Just a little thought, I've used both inline asm and external asm, I have to say I think external asm with linkage is preferable.
> 
> I assume the reasoning for inline asm is speed, but on very small routines this may actually cause a slowdown.  All registers used must be pushed only the stack and then popped, people have no idea about what the compiler has

That's not true for gcc, where you just give the register type that you want to use and gcc manage to find a good register.

> been doing such as instruction pairing, using inline asm forces the compiler to abandon any optimisation it may have been doing.  You effectively lose the benefits of 'inlining' in which case why not make it a function call and write an external asm function thats linked in anyway.
> 
> I have a feeling allowing inline asm may lead to an equivalent horrible mightmare of #ifdefs we have today.
> 
> Just a few thoughts.
> 
> "Walter" <walter@digitalmars.com> wrote in message news:9m4rfe$1d5c$3@digitaldaemon.com...
> >
> >
> > Jim Eberle wrote in message <9m48up$1t4$1@digitaldaemon.com>...
> > >This would eliminate the #define brackets:
> > >asm(x86) {
> > >}
> > >
> > >asm(ppc) {
> > >}
> > >
> > >asm(sparc) {
> > >}
> > >
> > >You could then keep your asm blurbs together in the same file, and emit
> the
> > >right code based on the target hw.
> >
> >
> > That is an interesting idea!
> >
> >