Walter Bright wrote:

> I was going to call this 1.0 RC1, but I just could not resist adding  [...]

Will there be a "Beta" period, between the current Alphas and Release ?

Just thought it was a bit quick to start announcing Release Candidates
right after the D features had been frozen, but maybe that's just me.

--anders

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ecbodc$1v70$1@digitaldaemon.com...
> Don Clugston wrote:
>> * Together with lambda delegate type inference, it seems that delegates are becoming the central language idiom of D. It's not just an improved C++ any more, I think a whole new programming style is developing.
>
> Inner classes, nested functions, delegates, and closures are all closely related. The only thing missing in D is the full generality of closures; once we have that I think D can do what Lisp does, but with a much more palatable syntax.

I think serious Lispniks would disagree with the above statement (I'm not one of them by the way).



However, I find it really encouraging that you are comparing D with Lisp and obviously gaining some important insights into language design as a result. I was concerned that your goal was to create a better C++, rather than a better LANGUAGE, but this is obviously not the case anymore (if it ever was).



One advantage of Lisp (which is not present in D) is Lisps removal of the artificial boundary between compile time and runtime capabilities.  Put another way, because code and data share a common form in Lisp (the list, which is in fact a form of parse tree), Lisp provides easy access to runtime code generation.



 I'm at a loss as to how a similar capability could be made available in D.
However, if this were possible then I believe you would have created
something truly revolutionary.



D really has become a very interesting language.  Thankyou Walter.



Tony

Melbourne, Australia

 tonys  -  mailbox  at  hotmail.com

Walter Bright wrote:
> I was going to call this 1.0 RC1, but I just could not resist adding the lazy expression evaluation. This adds one of the big capabilities of common lisp.
> 
> http://www.digitalmars.com/d/changelog.html

Is there any chance my post entitled "No way to selectively expose imported symbols using 163" in d.D could be addressed or at least considered before RC1?  It would have a slight impact on the wording describing selective import if so.  Here is a direct link to the post:

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=40811


Sean

Walter Bright wrote:
> I was going to call this 1.0 RC1, but I just could not resist adding the lazy expression evaluation. This adds one of the big capabilities of common lisp.
> 
> http://www.digitalmars.com/d/changelog.html

Nice work!  I'm not sure I understand the advantage offered to the enforcement example however, unless it is in creating the message string (a benefit that was already demonstrated).  Where is the lazy evaluation occurring?


Sean

Walter Bright a écrit :
> I was going to call this 1.0 RC1, but I just could not resist adding the lazy expression evaluation. This adds one of the big capabilities of common lisp.
> 
> http://www.digitalmars.com/d/changelog.html
Nice feature. D seems to be as a good wine : the older it gets, the better it tastes.

And what about const by default ? I may have missed some of the discussion : I thought something related to it would
be decided before 1.0 but don't know anything about such a decision.
( And there is no clue about the fate of the auto keyword : will it be turned into a local or var keyword before 1.0 ? )

Does it means that all these features will be « post 1.0 » ?

Walter Bright wrote:
> I was going to call this 1.0 RC1, but I just could not resist adding the lazy expression evaluation. This adds one of the big capabilities of common lisp.
> 
> http://www.digitalmars.com/d/changelog.html

cool, I like it

given

void foo(char[]);
void foo(char[] delegate());

how do I force the use of  the first?

char[][] fig;
int i = 10;
fig.length = i;


while(i) foo(fig[--i]);	// --i must be evaluated

Tony wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:ecbodc$1v70$1@digitaldaemon.com...
>> Don Clugston wrote:
>>> * Together with lambda delegate type inference, it seems that delegates are becoming the central language idiom of D. It's not just an improved C++ any more, I think a whole new programming style is developing.
>> Inner classes, nested functions, delegates, and closures are all closely related. The only thing missing in D is the full generality of closures; once we have that I think D can do what Lisp does, but with a much more palatable syntax.
> 
> I think serious Lispniks would disagree with the above statement (I'm not one of them by the way).

Of course they would <g>.


> However, I find it really encouraging that you are comparing D with Lisp and obviously gaining some important insights into language design as a result. I was concerned that your goal was to create a better C++, rather than a better LANGUAGE, but this is obviously not the case anymore (if it ever was).

What catches my interest about Lisp are the folks (like Paul Graham) who claim huge productivity gains from it. Despite such, however, Lisp has failed to gain mainstream acceptance. Maybe D could adopt some of the things that make Lisp so productive, and leave behind the stuff that inhibits Lisp from getting traction.

defmac is often trotted out as a big productivity gainer in Lisp, because with it one can define one's own syntax. D's lazy evaluation does the equivalent.

> One advantage of Lisp (which is not present in D) is Lisps removal of the artificial boundary between compile time and runtime capabilities.  Put another way, because code and data share a common form in Lisp (the list, which is in fact a form of parse tree), Lisp provides easy access to runtime code generation.
> 
>  I'm at a loss as to how a similar capability could be made available in D. However, if this were possible then I believe you would have created something truly revolutionary.

I think that would be D 3.0 <g>.

> D really has become a very interesting language.  Thankyou Walter.

You're welcome.

Anders F Björklund wrote:
> Walter Bright wrote:
> 
>> I was going to call this 1.0 RC1, but I just could not resist adding  [...]
> 
> Will there be a "Beta" period, between the current Alphas and Release ?
> Just thought it was a bit quick to start announcing Release Candidates
> right after the D features had been frozen, but maybe that's just me.

I don't think there's a need for a beta period. D's already in heavy use, we know what state it's in.

Sean Kelly wrote:
> Walter Bright wrote:
>> I was going to call this 1.0 RC1, but I just could not resist adding the lazy expression evaluation. This adds one of the big capabilities of common lisp.
>>
>> http://www.digitalmars.com/d/changelog.html
> 
> Is there any chance my post entitled "No way to selectively expose imported symbols using 163" in d.D could be addressed or at least considered before RC1?  It would have a slight impact on the wording describing selective import if so.  Here is a direct link to the post:
> 
> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=40811 

I think that's just a compiler bug, not a design problem.

Sean Kelly wrote:
> Walter Bright wrote:
>> I was going to call this 1.0 RC1, but I just could not resist adding the lazy expression evaluation. This adds one of the big capabilities of common lisp.
>>
>> http://www.digitalmars.com/d/changelog.html
> 
> Nice work!  I'm not sure I understand the advantage offered to the enforcement example however, unless it is in creating the message string (a benefit that was already demonstrated).  Where is the lazy evaluation occurring?

The example has typos in it, but the advantage is to not evaluate the msg (which can be arbitrarily complex) unless an error actually occurs.