Bill Cox wrote:

> - alias: Never felt like I needed it in Pascal.

I'm not (directly) a fan of alias.  However, I *am* a fan of typechecked
typedefs.  That is, if you do this:
    typedef uint myTypedef;
then you shouldn't be able to do implicit casts between uint and myTypedef.

In that context, I think alias is necessary because it allows you to create
a non-checked typedef.  Like what I almost always do in my D programs:
    alias bit bool;
or
    alias int s32;
    alias uint u32;
Stuff like that.

> - goto statements: Haven't we won this argument yet?  It's been decades now...

Did you read the link that referred to the Linux argument about goto? Sometimes, judiciously used, goto's are MORE readable than looping syntax. Like if you want to jump into the middle of a while loop, rather than start at the beginning.

> - Assignments in expressions: I accidently type if(a = b) much too often... and when I'm reading code, I often fail to see the assignment.

Right.  D++ should REQUIRE bool's as inputs into if(), for(), while(),
etc...

> - Fall through in case statements: Missing break statements can be ugly bugs to find.

Hear, hear!

> - pointers
>
> I'm a huge speed freak, but I just don't need pointers.  I'm really sick of debugging pointer spaghetti.  I haven't seen a good use of ** types (pointers to pointers) in years.  Ever debug a function that takes a *** argument?  Lots of fun!

I agree that pointers can be misused.  But if you don't use them, then how are you going to interface with C?

> - garbage collection
>
> It's already in D, and that's not going to change, but just to continue the endless debate...
>
> GC is a good solution to a problem that has a better solution.  Speed freaks like me want objects of each class allocated together in memory to make better use of cache (or even more advanced memory layouts).  The compiler should do that automatically.  The compiled code should compact and reclaim memory whenever I ask it to, not whenever it wants.  I just want to write 'new' and 'delete', and get awesomely fast and seg-v free code.  And, I never want to write my own destructors.  Fix the pointers for me.  It requires more from the compiler, and a small addition to the language (to specify which children to recursively delete).  It really does work.  We do this now where I work.

I agree:
The compiler should include mechanisms (weak pointers, perhaps) that allow a
garbage object to be "returned to the pool" rather than deleted.  :Likewise,
you don't want the GC to run just anywhere...but that's already possible
with gc.disable() and gc.enable().  Also, remember that the GC *only runs*
because of a new operator...so if you're so worried about performance in an
area, don't try to allocate memory there!

I disagree:
That GC is fundamentally flawed.  By the "speed freak" argument we all
should abandon new and malloc as well.  Heck, let's go back to assembly and
write our heaps by hand, if that's the kind of speed you want.

The GC can be turned off.  If you don't want it, don't use it.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

D would make an excellent back-end language.  C makes a good back end, but it's really showing its age.  D is more powerful in some ways and safer.

What I would like is for D to also be an excellent front-end language!!  ;)

Sean

"Ilya Minkov" <midiclub@tiscali.de> wrote in message news:b135kt$1u11$1@digitaldaemon.com...
> You're right, flexible code generator is a way to go. This is a common solution for template-like things, as well as implementing new syntactic constructs. This is what i am going to adress. It would also allow writing compilers for other languages, using D as a back end.

Hi, Russ.

Russ Lewis wrote:
> Bill Cox wrote:
> 
> 
>>- alias: Never felt like I needed it in Pascal.
> 
> 
> I'm not (directly) a fan of alias.  However, I *am* a fan of typechecked
> typedefs.  That is, if you do this:
>     typedef uint myTypedef;
> then you shouldn't be able to do implicit casts between uint and myTypedef.
> 
> In that context, I think alias is necessary because it allows you to create
> a non-checked typedef.  Like what I almost always do in my D programs:
>     alias bit bool;
> or
>     alias int s32;
>     alias uint u32;
> Stuff like that.

Yes, that's a nice use for aliases.  I guess I'd miss it if it weren't there.

BTW, your example reminds me that there has been some discussion of variable size int type with proposed syntax like int:32, but I don't think Walter likes the look, or the additional compiler complexity.  How about having the lexer directly recognise int24 as an Bison KINT token, with lval.intVal of 24?  That's how I did it in a fun little compiler I wrote.

>>- goto statements: Haven't we won this argument yet?  It's been decades
>>now...
> 
> 
> Did you read the link that referred to the Linux argument about goto?
> Sometimes, judiciously used, goto's are MORE readable than looping syntax.
> Like if you want to jump into the middle of a while loop, rather than start
> at the beginning.

Jumping into a while loop :-O!  I think I'll just continue to be anal and keep the gotos out.  Actually, a reasonable use of goto's I've seen is in C where you don't have the finally keyword with setjmp/longjmp. Without the goto, you often duplicate a modules clean-up code.  Still, I find life simpler in a group programming environment if you just make concrete rules, like no gotos, and live with them.

>>- Assignments in expressions: I accidently type if(a = b) much too
>>often... and when I'm reading code, I often fail to see the assignment.
> 
> 
> Right.  D++ should REQUIRE bool's as inputs into if(), for(), while(),
> etc...

Definately.

>>- Fall through in case statements: Missing break statements can be ugly
>>bugs to find.
> 
> 
> Hear, hear!
> 
> 
>>- pointers
>>
>>I'm a huge speed freak, but I just don't need pointers.  I'm really sick
>>of debugging pointer spaghetti.  I haven't seen a good use of ** types
>>(pointers to pointers) in years.  Ever debug a function that takes a ***
>>argument?  Lots of fun!
> 
> 
> I agree that pointers can be misused.  But if you don't use them, then how
> are you going to interface with C?

It's hard.  Where I work, we allow pointers to be used in exactly three ways:

1) Interfacing to C libraries (mostly just char *'s)
2) Multiple return values.  D eliminates this one.
3) Function pointers for callback routines.

Under no circumstances to we allow **'s.

All other uses of pointers are hidden under the hood by the database code generators.  Mosly, they just get typedef-ed away, but there really still there.  D does a find job of hiding these pointers automatically.

>>- garbage collection
>>
>>It's already in D, and that's not going to change, but just to continue
>>the endless debate...
>>
>>GC is a good solution to a problem that has a better solution.  Speed
>>freaks like me want objects of each class allocated together in memory
>>to make better use of cache (or even more advanced memory layouts).  The
>>compiler should do that automatically.  The compiled code should compact
>>and reclaim memory whenever I ask it to, not whenever it wants.  I just
>>want to write 'new' and 'delete', and get awesomely fast and seg-v free
>>code.  And, I never want to write my own destructors.  Fix the pointers
>>for me.  It requires more from the compiler, and a small addition to the
>>language (to specify which children to recursively delete).  It really
>>does work.  We do this now where I work.
> 
> 
> I agree:
> The compiler should include mechanisms (weak pointers, perhaps) that allow a
> garbage object to be "returned to the pool" rather than deleted.  :Likewise,
> you don't want the GC to run just anywhere...but that's already possible
> with gc.disable() and gc.enable().  Also, remember that the GC *only runs*
> because of a new operator...so if you're so worried about performance in an
> area, don't try to allocate memory there!

Darn... Thought I'd read everything about D carefully enough.  I missed gc.enable() and gc.dissable().

> I disagree:
> That GC is fundamentally flawed.  By the "speed freak" argument we all
> should abandon new and malloc as well.  Heck, let's go back to assembly and
> write our heaps by hand, if that's the kind of speed you want.
> 
> The GC can be turned off.  If you don't want it, don't use it.

Hmmm... Fair enough.


I have to admit that I was having trouble sleeping and though this post would generate some interesting discussion (which I think it has).  I don't actually expect Walter to delete any features that he's already worked hard to add to D.  These are just some features I might have left out if I had written D.

I kind of wanted to make the point that D is already VERY feature rich, and that it may be leaning a bit on the heavy side.  This discussion group generates new feature requests at least daily.  I hope this adds a bit of a counter-blance to all the feature requests.

Bill Cox

Bill Cox wrote:

> I kind of wanted to make the point that D is already VERY feature rich, and that it may be leaning a bit on the heavy side.  This discussion group generates new feature requests at least daily.  I hope this adds a bit of a counter-blance to all the feature requests.

A very worthwhile goal.  Welcome to the group!

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Ilya Minkov wrote:

> IMO,
> 
> if (a=b) {}
> 
> is a clear bug, i've stumbled over more than a couple of times. And it's not necessarily easy to track down. Likewise:

Definately.  The compilers I use usually warn about that though, and I don't think I've ever made that mistake myself.

> 
> int j;
> for (int i=1; 1<=max; j++) {}
> 
> Well, this is the most stupid example, but it illustrates several things which may actually happen when editing a piece of code a number of times. Well, this example "for" is no use at all and should have no forgiving.

That one is probably an error.  If so, probably not easy to catch or for a compiler to notice.  I had to look at that twice to notice the problem.  It doesn't help that the characters 1, i and l look pretty similar (at least in the font I'm using).

> 
> Basically, "dirty constructs" like this are to issue warnings. If someone does this on purpose, a keyword should exist, like "violate" or "crude", which would simply shut off a warning. This could considerably bloat a semantic analyzer though.
> 
> A keyword is also some typing, and should slowly discourage even the most eager fans of these dirty tricks.
> 
> Some systems use something like a pragma, which shuts all warnings or certain classes of warnings off, and then there usually exists an opposite one to turn them on back again. But IMO this would have no teaching efect, since people would be tempted to turn the warnings off and never turn them on again.
> 

I really hate it when I see some pragma to disable a warning that just includes some magic number.  I have no idea which thing it is trying to disable and have little desire to stop suddenly to go look it up.  I much prefer the long syntax the gnu compiler uses (-fnowhatever) but that can get unwieldy too I guess.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b13tup$2b8s$1@digitaldaemon.com...
> D would make an excellent back-end language.  C makes a good back end, but it's really showing its age.  D is more powerful in some ways and safer.

Several times I considered making D output C code, but there are just a lot of problems making it work (such as no exception handling in C).

I think you misunderstood my point here... I was saying new 5GL's could use D as a backend intermediate language, instead of C or ASM.  ;)  D is feature-rich relative to C, yet still efficient... and safer.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:b49alu$19vu$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b13tup$2b8s$1@digitaldaemon.com...
> > D would make an excellent back-end language.  C makes a good back end,
but
> > it's really showing its age.  D is more powerful in some ways and safer.
>
> Several times I considered making D output C code, but there are just a
lot
> of problems making it work (such as no exception handling in C).

"Ilya Minkov" <midiclub@tiscali.de> wrote in message news:b136sj$1ufm$1@digitaldaemon.com...
> IMO,
>
> if (a=b) {}
>
> is a clear bug, i've stumbled over more than a couple of times. And it's not necessarily easy to track down. Likewise:

D will give you a syntax error on that.

In article <b49alu$19vu$1@digitaldaemon.com>, Walter says...
>
>
>"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b13tup$2b8s$1@digitaldaemon.com...
>> D would make an excellent back-end language.  C makes a good back end, but it's really showing its age.  D is more powerful in some ways and safer.
>
>Several times I considered making D output C code, but there are just a lot of problems making it work (such as no exception handling in C).
>
>
If not making D output C code you can make D output C++ code.

D Rocks!!!
---------------------------------------
http://www.digitalmars.com/d/index.html

"Kublai Kahn" <Kublai_member@pathlink.com> wrote in message news:b4b0h0
> If not making D output C code you can make D output C++ code.

True, but there are more problems there (like no nested functions).

> D Rocks!!!

True. <g>