• Brian Bober (136/136) Feb 03 2002 I am a developer for Mozilla. Although I don't necessarily represent the
• Brian Bober (14/150) Feb 03 2002 : exists as an operator obviously.
• Brian Bober (23/159) Feb 03 2002 Heheh, the ideas just coming.
• Pavel Minayev (61/144) Feb 04 2002 Some COM support is already there.
• Brian Bober (47/158) Feb 20 2002 implement
• Pavel Minayev (36/84) Feb 20 2002 script

"Brian Bober" <netdemonz yahoo.com> writes:

I am a developer for Mozilla. Although I don't necessarily represent the
Mozilla community or Netscape, I would like to
give some comments on the D language. I would also like to get involved on
the development.
First of all, I would like to mention that I like what you have so far, and
it goes along with lots of the ideas I had
for starting a new language.

I have read so far some of the newsgroup messages, and also glanced over
your site. I will be looking more closely at
it in time to come and talking more. Later on, hopefully we can implement
the features of COM. I also want to discuss
the fact that I believe this language should be scriptable and compilable.
Not only that, but your compilable code
should be able to run as a script. I also want to see perl's parsing
abilities in this. Also, I believe there should be
some GUI libraries that come standard, possibly implementing Mozilla's XUL.
Mozilla is creating a very nice XP development system
that people can use (and they are using in their browser) and together with
D (especially if scriptable) would make
a killer combination. Much of the user-interface for Mozilla is defined in
XML and javascript. If D were both scriptable
and compilable, the javascript could be replaced by D. Also, D could be used
on web pages. The c++ code for Mozilla
is written using something called XPCOM - which is a cross-platform version
of COM. It would be nice if D had a built-in
COM system and abstracted it nicely to take out a lot of the ugliness.

I believe dropping explicit reference types is a bad idea. The reason for
this is that C is a strong typed language and
that's what makes it the most popular language. I don't want to see any loss
in strong typing from C to D and I believe
most would agree. Therefore, its my opinion that they should be kept and the
idea given by by Ivan on using " " is very
nice. Especially since it removes the ambiguity between memory address and
reference.
int myfunction(myclass val)
{

}

void someotherfunc(void)
{
 myclass val;
 //Did you want to pass by reference or use the copy constructor?
 myfunction(val);
}


Please make sure that templates don't create code bloat. Multiple templates
using different types should not add more

code to the program.

Besides operator overloading, it would be nice if you could define new
operator types such as:
a = a newoperator b;
I haven't figured out yet exactly how you would define them, but there could
be some kind of operator definition

language for defining how it should appear in the code. Perhaps:

newoperator ( REGEXP )
{
 //Code

}

The new operators would override the old ones such as + or - etc.


I personally think that its kind of silly that people use:

char
unsigned char
long
long long
....

as computers get more bits per word lenght, this because more and more
crazy.

How about we simplify integer types by defining a data type called bit?

First, let me talk about number systems...

It should be possible to use any base you want. For instance:

6x10 would be 10 in base 6 (6 decimal)
16x10 would be 16 decimal

0x would still signify hex, as there can be no base 0
1x would be binary

Also, you should be able to do:
1h hex
1o octal
1b binary

bit; //unsigned 1 bit
bit[2]; //unsigned 2 bits
bit[3]; //etc
signed bit; //unsigned 1 bit
signed bit[2]; //unsigned 2 bit
signed bit[3]; //etc

People can then call them whatever the heck they want by typedef them.
Making an array of bits,
though - means you have to convert it in order to access a single byte or
group thereof. There should
also be a "b" available to signify you are meaning a bit. bool is just
another word for bit, but it
can't be put into array notation.

Bits will be stored as normal characters and will be mapped to bit-wise
operators. There is no limit on the number
of bits you can use, but if you use something, say 4096 bits, and the
processor is only a 64 bit word length, it will

take a lot of c++ long long to represent this and lots of calculation for
math, etc. Therefore, its probably wise to

use the least number of bits possible. Most likely, using common amounts of
bits like 8, 16, 32, 64, etc will be the

fastest.

for instance:

typedef bit[8] byte;
byte mybyte;
bit mybits1 = 0b;
bit[2] mybits2 = 10b;
bit[5] mybits5 = 3x10;
mybit = ~mybit;
(bit[5])(((bit)mybyte)[2]) = mybits5; //Yuck! More on this later!
((bit)mybyte)[7]) = mybits1;
(bit[2])mybyte) = mybits2;

//Result: [ mybits1 | mybits5 | mybits2 ] = 10010010

equivalent c++:

unsigned char mybyte;
unsigned char mybits1 = 0; //Notice - only the first bit is usable unless
you do a cast
unsigned char mybits2 = 2;
unsigned char mybits5 = 4;
mybits1 = ~mybits1;
mybyte = mybyte | (mybits5<<2);
mybyte = mybyte | (mybits1<<7);
mybyte = mybyte | mybits2;


Now, you might say the second batch looked more intuitive than the first.
But I have already
thought about that and came up with a solution.

First, there would be a special [ to , from] array operator.

byte a[5];
byte b[5];
a[0,3] = b[1,4]; //Same as a memcpy of a's bytes 0-3 => b's 1-4

Also, there would be a bit operator to mean convert to bits. It is the
colon,
which isn't used in c++.

a:[1,4] Bits 1-4
a: = bit 1
a:[5] = bit 5

Therefore, that unweildly line above:

(bit[5])(((bit)mybyte)[2]) = mybits5;

would simply be:
mybyte:[2,6]=mybits5; //mybits5 is equiv to mybits5:[0,4]

"Brian Bober" <netdemonz yahoo.com> writes:

: exists as an operator obviously.
What I meant was :[] and :[,] and just plane : after a variable. Sorry :-)

"Brian Bober" <netdemonz yahoo.com> wrote in message
news:a3l4om$jh3$1 digitaldaemon.com...
 I am a developer for Mozilla. Although I don't necessarily represent the
 Mozilla community or Netscape, I would like to
 give some comments on the D language. I would also like to get involved on
 the development.
 First of all, I would like to mention that I like what you have so far,

and
 it goes along with lots of the ideas I had
 for starting a new language.

 I have read so far some of the newsgroup messages, and also glanced over
 your site. I will be looking more closely at
 it in time to come and talking more. Later on, hopefully we can implement
 the features of COM. I also want to discuss
 the fact that I believe this language should be scriptable and compilable.
 Not only that, but your compilable code
 should be able to run as a script. I also want to see perl's parsing
 abilities in this. Also, I believe there should be
 some GUI libraries that come standard, possibly implementing Mozilla's

XUL.
 Mozilla is creating a very nice XP development system
 that people can use (and they are using in their browser) and together

with
 D (especially if scriptable) would make
 a killer combination. Much of the user-interface for Mozilla is defined in
 XML and javascript. If D were both scriptable
 and compilable, the javascript could be replaced by D. Also, D could be

used
 on web pages. The c++ code for Mozilla
 is written using something called XPCOM - which is a cross-platform

version
 of COM. It would be nice if D had a built-in
 COM system and abstracted it nicely to take out a lot of the ugliness.

 I believe dropping explicit reference types is a bad idea. The reason for
 this is that C is a strong typed language and
 that's what makes it the most popular language. I don't want to see any

loss
 in strong typing from C to D and I believe
 most would agree. Therefore, its my opinion that they should be kept and

the
 idea given by by Ivan on using " " is very
 nice. Especially since it removes the ambiguity between memory address and
 reference.
 int myfunction(myclass val)
 {

 }

 void someotherfunc(void)
 {
  myclass val;
  //Did you want to pass by reference or use the copy constructor?
  myfunction(val);
 }


 Please make sure that templates don't create code bloat. Multiple

templates
 using different types should not add more

 code to the program.

 Besides operator overloading, it would be nice if you could define new
 operator types such as:
 a = a newoperator b;
 I haven't figured out yet exactly how you would define them, but there

could
 be some kind of operator definition

 language for defining how it should appear in the code. Perhaps:

 newoperator ( REGEXP )
 {
  //Code

 }

 The new operators would override the old ones such as + or - etc.


 I personally think that its kind of silly that people use:

 char
 unsigned char
 long
 long long
 ....

 as computers get more bits per word lenght, this because more and more
 crazy.

 How about we simplify integer types by defining a data type called bit?

 First, let me talk about number systems...

 It should be possible to use any base you want. For instance:

 6x10 would be 10 in base 6 (6 decimal)
 16x10 would be 16 decimal

 0x would still signify hex, as there can be no base 0
 1x would be binary

 Also, you should be able to do:
 1h hex
 1o octal
 1b binary

 bit; //unsigned 1 bit
 bit[2]; //unsigned 2 bits
 bit[3]; //etc
 signed bit; //unsigned 1 bit
 signed bit[2]; //unsigned 2 bit
 signed bit[3]; //etc

 People can then call them whatever the heck they want by typedef them.
 Making an array of bits,
 though - means you have to convert it in order to access a single byte or
 group thereof. There should
 also be a "b" available to signify you are meaning a bit. bool is just
 another word for bit, but it
 can't be put into array notation.

 Bits will be stored as normal characters and will be mapped to bit-wise
 operators. There is no limit on the number
 of bits you can use, but if you use something, say 4096 bits, and the
 processor is only a 64 bit word length, it will

 take a lot of c++ long long to represent this and lots of calculation for
 math, etc. Therefore, its probably wise to

 use the least number of bits possible. Most likely, using common amounts

of
 bits like 8, 16, 32, 64, etc will be the

 fastest.

 for instance:

 typedef bit[8] byte;
 byte mybyte;
 bit mybits1 = 0b;
 bit[2] mybits2 = 10b;
 bit[5] mybits5 = 3x10;
 mybit = ~mybit;
 (bit[5])(((bit)mybyte)[2]) = mybits5; //Yuck! More on this later!
 ((bit)mybyte)[7]) = mybits1;
 (bit[2])mybyte) = mybits2;

 //Result: [ mybits1 | mybits5 | mybits2 ] = 10010010

 equivalent c++:

 unsigned char mybyte;
 unsigned char mybits1 = 0; //Notice - only the first bit is usable unless
 you do a cast
 unsigned char mybits2 = 2;
 unsigned char mybits5 = 4;
 mybits1 = ~mybits1;
 mybyte = mybyte | (mybits5<<2);
 mybyte = mybyte | (mybits1<<7);
 mybyte = mybyte | mybits2;


 Now, you might say the second batch looked more intuitive than the first.
 But I have already
 thought about that and came up with a solution.

 First, there would be a special [ to , from] array operator.

 byte a[5];
 byte b[5];
 a[0,3] = b[1,4]; //Same as a memcpy of a's bytes 0-3 => b's 1-4

 Also, there would be a bit operator to mean convert to bits. It is the
 colon,
 which isn't used in c++.

 a:[1,4] Bits 1-4
 a: = bit 1
 a:[5] = bit 5

 Therefore, that unweildly line above:

 (bit[5])(((bit)mybyte)[2]) = mybits5;

 would simply be:
 mybyte:[2,6]=mybits5; //mybits5 is equiv to mybits5:[0,4]

"Brian Bober" <netdemonz yahoo.com> writes:

Heheh, the ideas just coming.

To add to that [,] operator. I also thought about making it capable of doing
multiple selections of array members - like this:
bit[8][20] a;
a[1,5;6;9,14] = a[6;9,14;1,5];     //Switch some bytes around

Which also made me think that , might not be a good idea because it looks
similar to ;
Therefore, [-,] might be better.
bit[8][20] a;
a[1-5,6,9-14] = a[6,9-14,1-5];

a:[1-5,6,9-14] = a:[6,9-14,1-5];    //Switch some bits around

"Brian Bober" <netdemonz yahoo.com> wrote in message
news:a3l4om$jh3$1 digitaldaemon.com...
 I am a developer for Mozilla. Although I don't necessarily represent the
 Mozilla community or Netscape, I would like to
 give some comments on the D language. I would also like to get involved on
 the development.
 First of all, I would like to mention that I like what you have so far,

and
 it goes along with lots of the ideas I had
 for starting a new language.

 I have read so far some of the newsgroup messages, and also glanced over
 your site. I will be looking more closely at
 it in time to come and talking more. Later on, hopefully we can implement
 the features of COM. I also want to discuss
 the fact that I believe this language should be scriptable and compilable.
 Not only that, but your compilable code
 should be able to run as a script. I also want to see perl's parsing
 abilities in this. Also, I believe there should be
 some GUI libraries that come standard, possibly implementing Mozilla's

XUL.
 Mozilla is creating a very nice XP development system
 that people can use (and they are using in their browser) and together

with
 D (especially if scriptable) would make
 a killer combination. Much of the user-interface for Mozilla is defined in
 XML and javascript. If D were both scriptable
 and compilable, the javascript could be replaced by D. Also, D could be

used
 on web pages. The c++ code for Mozilla
 is written using something called XPCOM - which is a cross-platform

version
 of COM. It would be nice if D had a built-in
 COM system and abstracted it nicely to take out a lot of the ugliness.

 I believe dropping explicit reference types is a bad idea. The reason for
 this is that C is a strong typed language and
 that's what makes it the most popular language. I don't want to see any

loss
 in strong typing from C to D and I believe
 most would agree. Therefore, its my opinion that they should be kept and

the
 idea given by by Ivan on using " " is very
 nice. Especially since it removes the ambiguity between memory address and
 reference.
 int myfunction(myclass val)
 {

 }

 void someotherfunc(void)
 {
  myclass val;
  //Did you want to pass by reference or use the copy constructor?
  myfunction(val);
 }


 Please make sure that templates don't create code bloat. Multiple

templates
 using different types should not add more

 code to the program.

 Besides operator overloading, it would be nice if you could define new
 operator types such as:
 a = a newoperator b;
 I haven't figured out yet exactly how you would define them, but there

could
 be some kind of operator definition

 language for defining how it should appear in the code. Perhaps:

 newoperator ( REGEXP )
 {
  //Code

 }

 The new operators would override the old ones such as + or - etc.


 I personally think that its kind of silly that people use:

 char
 unsigned char
 long
 long long
 ....

 as computers get more bits per word lenght, this because more and more
 crazy.

 How about we simplify integer types by defining a data type called bit?

 First, let me talk about number systems...

 It should be possible to use any base you want. For instance:

 6x10 would be 10 in base 6 (6 decimal)
 16x10 would be 16 decimal

 0x would still signify hex, as there can be no base 0
 1x would be binary

 Also, you should be able to do:
 1h hex
 1o octal
 1b binary

 bit; //unsigned 1 bit
 bit[2]; //unsigned 2 bits
 bit[3]; //etc
 signed bit; //unsigned 1 bit
 signed bit[2]; //unsigned 2 bit
 signed bit[3]; //etc

 People can then call them whatever the heck they want by typedef them.
 Making an array of bits,
 though - means you have to convert it in order to access a single byte or
 group thereof. There should
 also be a "b" available to signify you are meaning a bit. bool is just
 another word for bit, but it
 can't be put into array notation.

 Bits will be stored as normal characters and will be mapped to bit-wise
 operators. There is no limit on the number
 of bits you can use, but if you use something, say 4096 bits, and the
 processor is only a 64 bit word length, it will

 take a lot of c++ long long to represent this and lots of calculation for
 math, etc. Therefore, its probably wise to

 use the least number of bits possible. Most likely, using common amounts

of
 bits like 8, 16, 32, 64, etc will be the

 fastest.

 for instance:

 typedef bit[8] byte;
 byte mybyte;
 bit mybits1 = 0b;
 bit[2] mybits2 = 10b;
 bit[5] mybits5 = 3x10;
 mybit = ~mybit;
 (bit[5])(((bit)mybyte)[2]) = mybits5; //Yuck! More on this later!
 ((bit)mybyte)[7]) = mybits1;
 (bit[2])mybyte) = mybits2;

 //Result: [ mybits1 | mybits5 | mybits2 ] = 10010010

 equivalent c++:

 unsigned char mybyte;
 unsigned char mybits1 = 0; //Notice - only the first bit is usable unless
 you do a cast
 unsigned char mybits2 = 2;
 unsigned char mybits5 = 4;
 mybits1 = ~mybits1;
 mybyte = mybyte | (mybits5<<2);
 mybyte = mybyte | (mybits1<<7);
 mybyte = mybyte | mybits2;


 Now, you might say the second batch looked more intuitive than the first.
 But I have already
 thought about that and came up with a solution.

 First, there would be a special [ to , from] array operator.

 byte a[5];
 byte b[5];
 a[0,3] = b[1,4]; //Same as a memcpy of a's bytes 0-3 => b's 1-4

 Also, there would be a bit operator to mean convert to bits. It is the
 colon,
 which isn't used in c++.

 a:[1,4] Bits 1-4
 a: = bit 1
 a:[5] = bit 5

 Therefore, that unweildly line above:

 (bit[5])(((bit)mybyte)[2]) = mybits5;

 would simply be:
 mybyte:[2,6]=mybits5; //mybits5 is equiv to mybits5:[0,4]

"Pavel Minayev" <evilone omen.ru> writes:

"Brian Bober" <netdemonz yahoo.com> wrote in message
news:a3l4om$jh3$1 digitaldaemon.com...

 it in time to come and talking more. Later on, hopefully we can implement
 the features of COM. I also want to discuss

Some COM support is already there.

 the fact that I believe this language should be scriptable and compilable.

D is a language specification. It doesn't claim that implementation
must be a compiler. One could make a bytecode VM, or even a straight
script interpreter. Wanna try? =)

 Not only that, but your compilable code
 should be able to run as a script. I also want to see perl's parsing

What do you mean?

 abilities in this. Also, I believe there should be
 some GUI libraries that come standard, possibly implementing Mozilla's

XUL.
 Mozilla is creating a very nice XP development system
 that people can use (and they are using in their browser) and together

with
 D (especially if scriptable) would make
 a killer combination. Much of the user-interface for Mozilla is defined in
 XML and javascript. If D were both scriptable
 and compilable, the javascript could be replaced by D. Also, D could be

used

Not much sence. First of all, Mozilla GUI library is not so "standard".
It would be better to add support for GTK, then. BTW a native Win32 GUI
library is in progress, and it is going fine.

Also, D by itself is not the best choice for scripting. But a
language could be derived from it - DScript or something like that.

 I believe dropping explicit reference types is a bad idea. The reason for
 this is that C is a strong typed language and
 that's what makes it the most popular language. I don't want to see any

loss
 in strong typing from C to D and I believe
 most would agree. Therefore, its my opinion that they should be kept and

the
 idea given by by Ivan on using " " is very
 nice. Especially since it removes the ambiguity between memory address and
 reference.
 int myfunction(myclass val)
 {

 }

 void someotherfunc(void)
 {
  myclass val;
  //Did you want to pass by reference or use the copy constructor?

There are NO copy constructors in D, and objects NEVER get passed
by value...

  myfunction(val);
 }

D has pointers and in/out arguments. References aren't really needed
any longer, although they can be used to reduce code size sometimes.

 Please make sure that templates don't create code bloat. Multiple

templates
 using different types should not add more

 code to the program.

Why??? Suppose a template container, instantiated for ints and
floats. Any arithmetic operation on these, while looking the
same in the source, will produce absolutely different machine
opcodes. So separate implementation is required. This can be
optimized, for those cases where implementations match, of course.

 Besides operator overloading, it would be nice if you could define new
 operator types such as:
 a = a newoperator b;
 I haven't figured out yet exactly how you would define them, but there

could
 be some kind of operator definition
 language for defining how it should appear in the code. Perhaps:

 newoperator ( REGEXP )
 {
  //Code

 }

 The new operators would override the old ones such as + or - etc.

Since there is no operator overloading in D at all (for now?), this
is something I'm even afraid to ask for. I'd be happy if we get
operator overloading at least for built-in ones...

 I personally think that its kind of silly that people use:

 char
 unsigned char
 long
 long long
 ....

You might have meant char, uchar, int and long? =)

 as computers get more bits per word lenght, this because more and more
 crazy.

 How about we simplify integer types by defining a data type called bit?

Already discussed, and, I believe, declined.

 First, let me talk about number systems...

 It should be possible to use any base you want. For instance:

 6x10 would be 10 in base 6 (6 decimal)
 16x10 would be 16 decimal

How do you think it'd get parsed? Currently, all non-decimal numbers
start with 0. So the lexer sees 0 and it knows that following it is
an octal number or a letter "x", followed by hex number - simple and
fast. With your suggestion, it all gets more complicated. What for?
Do you use ternary numbers in your programs frequently? Binary, octal
and hex numbers give us pretty much everything. If really needed,
a simple function could be defined to convert numbers from other
systems:

    extended number(char[] n, int base);
    ...
    int i = number("1120211", 3);

 0x would still signify hex, as there can be no base 0
 1x would be binary
 Also, you should be able to do:
 1h hex
 1o octal
 1b binary

Binary is already 0b...

 bit; //unsigned 1 bit

The bit data type is present in D. It practically replaces C++ bool.

 bit[2]; //unsigned 2 bits
 bit[3]; //etc
 signed bit; //unsigned 1 bit
 signed bit[2]; //unsigned 2 bit
 signed bit[3]; //etc

In D, bit[] is an _array_ of bits.
Also, D doesn't use the signed/unsigned keywords.

 People can then call them whatever the heck they want by typedef them.
 Making an array of bits,
 though - means you have to convert it in order to access a single byte or
 group thereof. There should
 also be a "b" available to signify you are meaning a bit. bool is just
 another word for bit, but it
 can't be put into array notation.

...
 Now, you might say the second batch looked more intuitive than the first.
 But I have already
 thought about that and came up with a solution.

 First, there would be a special [ to , from] array operator.

 byte a[5];
 byte b[5];
 a[0,3] = b[1,4]; //Same as a memcpy of a's bytes 0-3 => b's 1-4

There is such form:

    a[0..4] = b[1..5];

Note that ranges are end-exclusive.

Now about this bit system. It seems too complicated to me.
Processors work with 2^n-byte words anyhow, so we only need
8-bit, 16-bit, 32-bit... etc intergers. D has 64-bit one,
long. I doubt anything greater than 128-bit (int128?) will be
needed in nearest 50 years =), since capacity grows
logarithmically. If you need to access separate bits of an
integer, you can use bitwise operators and shifts. It isn't
a frequent operation in everyday coding, anyhow, especially
if you deal with more or less high-level APIs.

"Brian Bober" <netdemonz yahoo.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:a3lk3o$sf3$1 digitaldaemon.com...
 "Brian Bober" <netdemonz yahoo.com> wrote in message
 news:a3l4om$jh3$1 digitaldaemon.com...

 it in time to come and talking more. Later on, hopefully we can


implement
 the features of COM. I also want to discuss

 Some COM support is already there.

 the fact that I believe this language should be scriptable and


compilable.
 D is a language specification. It doesn't claim that implementation
 must be a compiler. One could make a bytecode VM, or even a straight
 script interpreter. Wanna try? =)

 Not only that, but your compilable code
 should be able to run as a script. I also want to see perl's parsing

 What do you mean?

I mean using the same source tree, you should be able to run it as a script
or compile it (as long as you don't have any compile-time dependancies).

 abilities in this. Also, I believe there should be
 some GUI libraries that come standard, possibly implementing Mozilla's

 XUL.
 Mozilla is creating a very nice XP development system
 that people can use (and they are using in their browser) and together

 with
 D (especially if scriptable) would make
 a killer combination. Much of the user-interface for Mozilla is defined


in
 XML and javascript. If D were both scriptable
 and compilable, the javascript could be replaced by D. Also, D could be

 used

 Not much sence. First of all, Mozilla GUI library is not so "standard".
 It would be better to add support for GTK, then. BTW a native Win32 GUI
 library is in progress, and it is going fine.

 Also, D by itself is not the best choice for scripting. But a
 language could be derived from it - DScript or something like that.

I refuse to believe D couldn't be a powerful scripting language if it was
done right. Perl uses object oriented code and so does javascript. What are
the reasons
D wouldn't make a good scripting language? I would really like to see
scripting and compiled code use the same language in the future. I'm sure it
could be done - just might take a little ingenuity. For instance... Maybe
you could cache the parses on files that are unchaged.

 I believe dropping explicit reference types is a bad idea. The reason


for
 this is that C is a strong typed language and
 that's what makes it the most popular language. I don't want to see any

 loss
 in strong typing from C to D and I believe
 most would agree. Therefore, its my opinion that they should be kept and

 the
 idea given by by Ivan on using " " is very
 nice. Especially since it removes the ambiguity between memory address


and
 reference.
 int myfunction(myclass val)
 {

 }

 void someotherfunc(void)
 {
  myclass val;
  //Did you want to pass by reference or use the copy constructor?

 There are NO copy constructors in D, and objects NEVER get passed
 by value...

Why? That would bloat memory on code that has a lot of of char equivalents
being passed.
This is exactly what I'm saying. Passing only by reference is a BAD idea.
This means that you affect the passed variable in
a new function and have to explicitly copy it, which is a pain in the neck.

  myfunction(val);
 }

 D has pointers and in/out arguments. References aren't really needed
 any longer, although they can be used to reduce code size sometimes.

 Please make sure that templates don't create code bloat. Multiple

 templates
 using different types should not add more

 code to the program.

 Why??? Suppose a template container, instantiated for ints and
 floats. Any arithmetic operation on these, while looking the
 same in the source, will produce absolutely different machine
 opcodes. So separate implementation is required. This can be
 optimized, for those cases where implementations match, of course.

That is not true. Templates can be converted to classes containing pointers.



template<class t>
class myclass
{
     t data;
}

turned into:

class myclass
{
    void * data
}

myclass<int> a;
myclass<float> b;
Use the same class.

a.data=1;

is really:
a->data=1;

 Besides operator overloading, it would be nice if you could define new
 operator types such as:
 a = a newoperator b;
 I haven't figured out yet exactly how you would define them, but there

 could
 be some kind of operator definition
 language for defining how it should appear in the code. Perhaps:

 newoperator ( REGEXP )
 {
  //Code

 }

 The new operators would override the old ones such as + or - etc.

 Since there is no operator overloading in D at all (for now?), this
 is something I'm even afraid to ask for. I'd be happy if we get
 operator overloading at least for built-in ones...

I agree. But why not kill two birds with one stone :-)

 I personally think that its kind of silly that people use:

 char
 unsigned char
 long
 long long
 ....

 You might have meant char, uchar, int and long? =)

nope, I meant unsigned char. uchar is not an ansi data type afaik.

 as computers get more bits per word lenght, this because more and more
 crazy.

 How about we simplify integer types by defining a data type called bit?

 Already discussed, and, I believe, declined.

 First, let me talk about number systems...

 It should be possible to use any base you want. For instance:

 6x10 would be 10 in base 6 (6 decimal)
 16x10 would be 16 decimal

 How do you think it'd get parsed? Currently, all non-decimal numbers
 start with 0. So the lexer sees 0 and it knows that following it is
 an octal number or a letter "x", followed by hex number - simple and
 fast. With your suggestion, it all gets more complicated. What for?
 Do you use ternary numbers in your programs frequently? Binary, octal
 and hex numbers give us pretty much everything. If really needed,
 a simple function could be defined to convert numbers from other
 systems:

Perhaps then 0x6x10 :-)
Why ask why. We shouldn't question why someone would need a base 4 number.
We should just add the ability so they don't have to suffer. It all boils
down to the Y2K thing which started because engineers made bad assumptions.
What about base 200? Base 500?

     extended number(char[] n, int base);
     ...
     int i = number("1120211", 3);

Which wastes run-time and memory.


I'm going to provide a follow-up on my bit request.

"Pavel Minayev" <evilone omen.ru> writes:

"Brian Bober" <netdemonz yahoo.com> wrote in message
news:a50shm$18ag$1 digitaldaemon.com...

 I mean using the same source tree, you should be able to run it as a

script
 or compile it (as long as you don't have any compile-time dependancies).

I don't see why this isn't possible. There are ANSI C interpreters out
there, why not a D one? Once again, it's just the matter of somebody
to write it...

 I refuse to believe D couldn't be a powerful scripting language if it was
 done right. Perl uses object oriented code and so does javascript. What

are
 the reasons
 D wouldn't make a good scripting language? I would really like to see
 scripting and compiled code use the same language in the future. I'm sure

it
 could be done - just might take a little ingenuity. For instance... Maybe
 you could cache the parses on files that are unchaged.

I don't see any reason for the scripting language to be strongly typed,
for example. There would be virtually no difference between short and int,
float and double, etc... also pointers, are they really needed for
scripting? Interfaces?..


 There are NO copy constructors in D, and objects NEVER get passed
 by value...

 Why? That would bloat memory on code that has a lot of of char equivalents
 being passed.

By "objects" I mean instances of classes. Simple types are byval
by default. Of course you may use in/out/inout to do whatever you need...

Also, what's "char equivalents"?

 Why??? Suppose a template container, instantiated for ints and
 floats. Any arithmetic operation on these, while looking the
 same in the source, will produce absolutely different machine
 opcodes. So separate implementation is required. This can be
 optimized, for those cases where implementations match, of course.

 That is not true. Templates can be converted to classes containing

pointers.
 template<class t>
 class myclass
 {
      t data;
 }

 turned into:

 class myclass
 {
     void * data
 }

 myclass<int> a;
 myclass<float> b;
 Use the same class.

 a.data=1;

 is really:
 a->data=1;

...and then you lose speed because of all that implicit
pointers dereferencing. If you really need those pointers, you
can state this explicitly.


 Since there is no operator overloading in D at all (for now?), this
 is something I'm even afraid to ask for. I'd be happy if we get
 operator overloading at least for built-in ones...

 I agree. But why not kill two birds with one stone :-)

'Cause it has to be a very heavy stone then. And since it's Walter
who'd have to carry it... it's up for him to decide.

 You might have meant char, uchar, int and long? =)

 nope, I meant unsigned char. uchar is not an ansi data type afaik.

In D, there is no unsigned char. There is uchar.

 Perhaps then 0x6x10 :-)
 Why ask why. We shouldn't question why someone would need a base 4 number.
 We should just add the ability so they don't have to suffer. It all boils
 down to the Y2K thing which started because engineers made bad

assumptions.
 What about base 200? Base 500?

If we (Walter, actually! =)) start adding everything that _might_ be needed,
we get a huge, bloated language - like Perl or some BASICs. That's what
modules are for. Instead of putting _everything_ into the language, write
a module (which then probably becomes part of the standard lib) that does
the thing.

     int i = number("1120211", 3);

 Which wastes run-time and memory.

Right. So does function-based screen I/O. Then why not make it a built-in
feature, like BASIC's PRINT? And file I/O then. And maybe regexps?..

Also, functions like that are usually processed by the compiler itself,
effectively inlined or even replaced by a constant if necessary. Of
course, this is implementation-defined... anyhow, your program will
work correctly anyhow, faster here, slower there. For fast number-crunching,
there are specialized tools. And how often do you need 13-based numbers
in your everyday generic programming?