Andrei Alexandrescu:
> No, it's exactly the opposite - putting on the table a rotten fish.<

If it's so smelly all people will avoid it quickly, so no harm done :-)


>Big  integer literals can be accommodated as compile-time strings.

Do you mean like this?
BigInt a = "12_345_678_900_345_678_900_000";

If that's what you say, then it's OK. There are more important things to think about.

Bye,
bearophile

bearophile wrote:
> Andrei Alexandrescu:
>> No, it's exactly the opposite - putting on the table a rotten fish.<
> 
> If it's so smelly all people will avoid it quickly, so no harm done :-)
> 
> 
>> Big  integer literals can be accommodated as compile-time strings.
> 
> Do you mean like this?
> BigInt a = "12_345_678_900_345_678_900_000";
> 
> If that's what you say, then it's OK. There are more important things to think about.

Needs to be something like:

BigInt a = bigIntLiteral!"12_345_678_900_345_678_900_000";

Anyway, I think this feature is thoroughly useless. An adage says that the only numeric literals in a program should be 0, 1, and -1. How many big integer literals can you think of right now?

Andrei

Andrei Alexandrescu:
> Anyway, I think this feature is thoroughly useless. An adage says that the only numeric literals in a program should be 0, 1, and -1. How many big integer literals can you think of right now?

OK, let's forget big integer literals for now :-)

I agree that there are bigger fishes to talk about. For example  I may like some things present in Delight, like especially this one (already discussed in the past, of course):
http://delight.sourceforge.net/null.html

Smaller things in Delight:

Good to have:
- An important difference between D and Delight is that a Delight array is considered true if and only if its length is non-zero:

I like:
- Also, D allows null to be used to mean an empty array. In Delight, you can only use [].

Improvements in the imports:
- Import all symbols into our namespace:
import example.utils: *
- Import a module, accessed by its full name:
import dlt.io
void sayHi(dlt.io.Printer p): ...

Bye,
bearophile

Andrei Alexandrescu:
> I think the question that should be asked is: would anyone complain if they were kept? We have bigger rocks to move than that one.

D has small differences, like disallowing 156l (only 156L is allowed). Such small details build up improving the language.

For example I have put a real bug in a Python program of mine because I have written xrange(100000) instead of xrange(1000000). In D I avoid such bug because I always write such numbers as 1_000_000. After that bug I now write in Python like this: xrange(1000*1000) (Python has recently added a peephole optimizer, so that multiplication is now not done at run-time, oh marvel), but that way can't be used for other kind of integer literals. I've asked two times to introduce _ in integer literals in Python too, but at the end Hettinger has answered me that it requires too many changes in the C code and the gain is little because most Python programs don't contain many integer literals (D contains them more often). I don't agree with Hettinger.

Disallowing octal syntax and 5.  .5 can be positive :-)

Bye,
bearophile

On Tue, Jul 7, 2009 at 8:08 PM, bearophile<bearophileHUGS@lycos.com> wrote:
> Nick Sabalausky:
>> why in the world is anyone defending the continued existance of "5." and ".5"?<
>
> I'm for disallowing them; 5.0 ad 0.5 are better.
> Anyone else pro/against this idea?

Totally agree.  They're cruft that just complicate lexical analysis.

> Regarding number literals, I'm also for:
> B) turning the current octal syntax into a syntax error and introducing a safer octal syntax (see Python 3);

Or just drop octal altogether.  Outside of chmod, when is there any legitimate need for it these days?

On 2009-07-07 20:42:00 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

>> Process all the characters from 'a' to 'z' inclusive.
>> 
>> Currently, ('a' .. 'z'+1)
>> 
>> Logically, ('a' .. 'z')
> 
> Do we need a language feature for that?

The two reasons in favor of a language feature are:

1. It might be more readable.
2. It allows ranges to include the *.max value.

The first is obviously just a cosmetic issue, which I don't think is worth it on its own. The second makes it easier to work with an edge case, which I don't think is worth it on its own either. Solving both together is a little more worth it, but enought to warant a language feature, I have some doubths.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Andrei Alexandrescu wrote:
> Anyway, I think this feature is thoroughly useless. An adage says that the only numeric literals in a program should be 0, 1, and -1. How many big integer literals can you think of right now?

The deficit?

Jarrett Billingsley wrote:
> Totally agree.  They're cruft that just complicate lexical analysis.

Not a significant issue, as the code to lex it is done, works, and is readily available.

> Or just drop octal altogether.  Outside of chmod, when is there any
> legitimate need for it these days?

Translating C code to D.

Michel Fortin wrote:
> Solving both together is a little more worth it, but enought to warant a language feature, I have some doubths.

I'm fairly convinced it is not worth a language feature. It looks good in the abstract, but is useless in practice. I write loops every day, and I can't recall ever having a need for it.

Sometimes I run across someone else's code that does:

   for (i = 0; i <= 10; i++)
   {
	... array[i] ...
   }

and I'll always rewrite it as i<11, because the former confuses my brain into creating bugs.

D has a lot of features. We should be parsimonious with new ones in that they should offer a convincing big payoff, not merely a miniscule hypothetical one.

Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message 
>> It's handy when you want to prefix one expression to another, as in:
>>
>>    (foo(), x + 3)
>>
> 
> I guess I'm not familiar with that syntax. What does that do and for what purpose? 

They're called Comma Expressions, and the left operand is evaluated first, its result discarded, then the right operand is evaluated and forms the type and result of the Comma Expression.

It's handy for things like rewriting ++e so it can be used more than once but is only evaluated once:

   (tmp = ++e, tmp)