On May 3, 2012, at 9:58 AM, Alex Rønne Petersen wrote:

> On 03-05-2012 17:13, Don Clugston wrote:
>> 
>> 
>> Well, they are also used in druntime, in core.stdc.math
>> 
>> BTW I *hate* that module, I don't know why it exists. Even worse, it
>> seems to be growing -- people are adding more things to it.
>> Practically everything in there has a better implementation in std.math.
> 
> But not quite everything yet. When I tried to pure/nothrow/@safe-ify std.math[special], I eventually stumbled upon code that used core.stdc.math.
> 
> It would definitely be nice if we could completely kill any dependency on that module, so we can actually make proper use of pure/nothrow/@safe, etc.

I've always thought use of core.stdc as an indicator for things that should be added to Phobos.  Really, core.stdc should only be used by apps ported from C to D, not by apps written from scratch in D.

On 03.05.2012 21:08, Sean Kelly wrote:
> On May 3, 2012, at 8:13 AM, Don Clugston wrote:
>
>> On 03/05/12 16:13, Andrei Alexandrescu wrote:
>>>
>>>
>>> Good ones. In fact I even discounted them from this discussion because
>>> I'd already considered them gone. Walter agreed that I don't mention
>>> them in TDPL, with the intent to have them peter out.
>>>
>>> One good step right now would be to remove NCEG operators from the
>>> online documentation. Later on, we'll consider them an accept-invalid
>>> bug :o).
>>
>> Well, they are also used in druntime, in core.stdc.math
>>
>> BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it.
>> Practically everything in there has a better implementation in std.math.
>
> core.stdc.math corresponds to C99's math.h and is there as a part of the standard C interface.  It should only contain the required C99 prototypes, and in some cases functions if the C implementation is a macro.  If there is anything nonstandard in there, I'm not aware of it.

Yes, but why do we have it? We're not C.

Some of the std C functions aren't implemented correctly (especially the FreeBSD long double functions, which are completely wrong). And that shouldn't be D's problem. Even when they are, they're not pure nothrow, and sometimes they have really silly names (I'm looking at you, tgamma() )

Quite absurdly, the DMC gamma function is a port from the D version. Why include it twice??

On Thursday, May 03, 2012 15:30:40 Don Clugston wrote:
> What is this D3 thing ????
> As far as I can tell, 'D3' was invented by newcomers to the forums.

I think that what it comes down to is that there are a variety of people who want features added or changed in D which are either not going to happen anytime soon or will never happen in D2 (especially if they're major breaking changes). So, they figure/hope that we'll have a new revision of the language where we'll be able to make breaking changes and then maybe the changes that they want will make it in then. After all, particularly from the perspective of a newbie, we already had D2 which changed a bunch of stuff from D1, why wouldn't we have D3 later on? And for folks who really want to see changes that aren't going to happen, the idea that we're going to have another major revision of the language which might make the changes that they want sounds really appealing.

I think that Walter and Andrei have made it fairly clear when they've said anything on the subject that there is no intention to make any kind of D3 anytime soon and that if we do, it'll be years from now after D2 is mature and well-established, and it actually makes sense to do a new major revision. But I do think that you're right in that the very idea of a D3 was created by folks in the newsgroup. Walter and the other developers have been focusing on stabilizing D2 as _the_ version of the language, not finishing it up so that they can move onto D3. And the misconceptions about D1 that you've pointed out in the past probably just help contribute to the idea that we'll have a D3 at some point. Maybe we will, maybe we won't, but there's no point in worrying about it for years yet.

- Jonathan M Davis

On May 3, 2012, at 1:11 PM, Don wrote:

> On 03.05.2012 21:08, Sean Kelly wrote:
>> On May 3, 2012, at 8:13 AM, Don Clugston wrote:
>> 
>>> On 03/05/12 16:13, Andrei Alexandrescu wrote:
>>>> 
>>>> 
>>>> Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out.
>>>> 
>>>> One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o).
>>> 
>>> Well, they are also used in druntime, in core.stdc.math
>>> 
>>> BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it.
>>> Practically everything in there has a better implementation in std.math.
>> 
>> core.stdc.math corresponds to C99's math.h and is there as a part of the standard C interface.  It should only contain the required C99 prototypes, and in some cases functions if the C implementation is a macro.  If there is anything nonstandard in there, I'm not aware of it.
> 
> Yes, but why do we have it? We're not C.

Mostly because it was handy to fall back on the C API before Phobos was so well fleshed-out.  Today, I think it mostly exists to ease porting of C apps.

Le 03/05/2012 22:43, Sean Kelly a écrit :
> On May 3, 2012, at 1:11 PM, Don wrote:
>
>> On 03.05.2012 21:08, Sean Kelly wrote:
>>> On May 3, 2012, at 8:13 AM, Don Clugston wrote:
>>>
>>>> On 03/05/12 16:13, Andrei Alexandrescu wrote:
>>>>>
>>>>>
>>>>> Good ones. In fact I even discounted them from this discussion because
>>>>> I'd already considered them gone. Walter agreed that I don't mention
>>>>> them in TDPL, with the intent to have them peter out.
>>>>>
>>>>> One good step right now would be to remove NCEG operators from the
>>>>> online documentation. Later on, we'll consider them an accept-invalid
>>>>> bug :o).
>>>>
>>>> Well, they are also used in druntime, in core.stdc.math
>>>>
>>>> BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it.
>>>> Practically everything in there has a better implementation in std.math.
>>>
>>> core.stdc.math corresponds to C99's math.h and is there as a part of the standard C interface.  It should only contain the required C99 prototypes, and in some cases functions if the C implementation is a macro.  If there is anything nonstandard in there, I'm not aware of it.
>>
>> Yes, but why do we have it? We're not C.
>
> Mostly because it was handy to fall back on the C API before Phobos was so well fleshed-out.  Today, I think it mostly exists to ease porting of C apps.

So they probably belongs to deimos.

On Thursday, May 03, 2012 13:43:11 Sean Kelly wrote:
> On May 3, 2012, at 1:11 PM, Don wrote:
> > On 03.05.2012 21:08, Sean Kelly wrote:
> >> On May 3, 2012, at 8:13 AM, Don Clugston wrote:
> >>> On 03/05/12 16:13, Andrei Alexandrescu wrote:
> >>>> Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out.
> >>>> 
> >>>> One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o).
> >>> 
> >>> Well, they are also used in druntime, in core.stdc.math
> >>> 
> >>> BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. Practically everything in there has a better implementation in std.math.>>
> >> core.stdc.math corresponds to C99's math.h and is there as a part of the standard C interface. It should only contain the required C99 prototypes, and in some cases functions if the C implementation is a macro. If there is anything nonstandard in there, I'm not aware of it.>
> > Yes, but why do we have it? We're not C.
> 
> Mostly because it was handy to fall back on the C API before Phobos was so well fleshed-out. Today, I think it mostly exists to ease porting of C apps.

In principle, having prototypes for the entire standard C library in druntime seems like a good idea to me. In practice though, it could cause problems due to people using the C functions rather than the D functions for some things (e.g. the math functions). If we properly documented them all though, we could then put comments about the correct D function to use to replace each C function which has a D replacement, and then it could actually help people move away from the C functions.

- Jonathan M Davis

On Thursday, 3 May 2012 at 20:36:47 UTC, Jonathan M Davis wrote:
> On Thursday, May 03, 2012 15:30:40 Don Clugston wrote:
>> What is this D3 thing ????
>> As far as I can tell, 'D3' was invented by newcomers to the forums.
>
> I think that what it comes down to is that there are a variety of people who
> want features added or changed in D which are either not going to happen
> anytime soon or will never happen in D2 (especially if they're major breaking
> changes). So, they figure/hope that we'll have a new revision of the language
> where we'll be able to make breaking changes and then maybe the changes that
> they want will make it in then. After all, particularly from the perspective
> of a newbie, we already had D2 which changed a bunch of stuff from D1, why
> wouldn't we have D3 later on? And for folks who really want to see changes
> that aren't going to happen, the idea that we're going to have another major
> revision of the language which might make the changes that they want sounds
> really appealing.
>
> I think that Walter and Andrei have made it fairly clear when they've said
> anything on the subject that there is no intention to make any kind of D3
> anytime soon and that if we do, it'll be years from now after D2 is mature and
> well-established, and it actually makes sense to do a new major revision. But
> I do think that you're right in that the very idea of a D3 was created by
> folks in the newsgroup. Walter and the other developers have been focusing on
> stabilizing D2 as _the_ version of the language, not finishing it up so that
> they can move onto D3. And the misconceptions about D1 that you've pointed out
> in the past probably just help contribute to the idea that we'll have a D3 at
> some point. Maybe we will, maybe we won't, but there's no point in worrying
> about it for years yet.

 If anything, I would consider D3 an ideal, something to work towards. And no it wouldn't be started or really worked on for at 10-15 years after D's mature and at Andrei's goal of having at least a million users. And as stated before, if there [b]IS[/b] going to be a D3 at any point it should have no problem calling D2 code.

 Course thinking of D3 now is kinda like thinking of flying cars and how you want a flying car and you won't buy a car today until it can fly...  Back (in the 50-60's was it?) they thought we would be having a flying car for every family and had these really badly done animations of what they expected to see. I don't see any flying cars outside of Hollywood. Best if we stick in the present and deal with our problems now.

On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote: [[...]
>  If anything, I would consider D3 an ideal, something to work
> towards. And no it wouldn't be started or really worked on for at
> 10-15 years after D's mature and at Andrei's goal of having at least
> a million users. And as stated before, if there [b]IS[/b] going to
> be a D3 at any point it should have no problem calling D2 code.

Do we know (roughly) how many D users are out there right now?


>  Course thinking of D3 now is kinda like thinking of flying cars and
> how you want a flying car and you won't buy a car today until it can
> fly...  Back (in the 50-60's was it?) they thought we would be
> having a flying car for every family and had these really badly done
> animations of what they expected to see. I don't see any flying cars
> outside of Hollywood. Best if we stick in the present and deal with
> our problems now.

There aren't any flying cars in Hollywood either. They're either just artist's concepts (*cough*CGI models*cough*), held up by strings, or just superimposed on an animated background.


T

-- 
It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford

On 5/3/2012 8:13 AM, Don Clugston wrote:
> Well, they are also used in druntime, in core.stdc.math
> BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be
> growing -- people are adding more things to it.

It's there simply because all the Standard C headers should be represented. It should not get anything that is not in Standard C. Ditto for all the other stuff in core.stdc.

It's there to make converting C code to D code easier.

> Practically everything in there has a better implementation in std.math.

Yup. But also note that the only "implementations" in there are things that are done as macros in C's math.h, meaning they're trivial.

On Thursday, 3 May 2012 at 22:29:47 UTC, H. S. Teoh wrote:
> On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote:
> Do we know (roughly) how many D users are out there right now?

 Don't know. Need a poll :) I'm definitely sure we have at least 10 users; beyond that I can only speculate; Maybe 2 to the power of ten or thirteen...

> There aren't any flying cars in Hollywood either. They're either just artist's concepts (*cough*CGI models*cough*), held up by strings, or just superimposed on an animated background.

 Exactly! It's on the 'big screen', meaning smoke and gimmicks, the same as magicians.

 Anyways, focus on the now. D3 may/will come some day, but that's a long ways off. Course if you plan early for certain things that will change it does make going towards it easier with language design, or give you more time to think about faults and fixes.