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]

: 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]
>
>

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]
>
>

"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.

"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.

"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?