On Friday, 4 July 2014 at 17:05:16 UTC, Walter Bright wrote:
> On 7/4/2014 3:38 AM, Don wrote:
>> What is "the longest type supported by the native hardware"? I don't know what
>> that means, and I don't think it even makes sense.
>
> Most of the time, it is quite clear.
>
>
>> For example, Sparc has 128-bit quads, but they only have partial support.
>> Effectively. they are emulated. Why on earth would you want to use an emulated
>> type on some machines, but not on others?
>
> Emulation is not native support.
>
>
>> Perhaps the intention was "the largest precision you can get for free, without
>> sacrificing speed" then that's not clearly defined. On x86-32, that was indeed
>> 80 bits. But on other systems it doesn't have an obvious answer.
>> On x86-64 it's not that simple. Nor on PPC or Sparc.
>
> Yes, there is some degree of subjectivity on some platforms. I don't see a good reason for hamstringing the compiler dev with legalese for Platform X with legalese that isn't quite the right thing to do for X.
>
> I think the intention of the spec is clear, and the compiler implementor can be relied on to exercise good judgement.

Who are these "compiler implementers"? Are you actually suggesting that, for example, ldc and gdc would seperately decide

On 7/4/2014 10:42 AM, John Colvin wrote:
> Who are these "compiler implementers"?

Whoever decides to implement D for a particular platform.


> Are you actually suggesting that, for example, ldc and gdc would seperately decide

I am confident they will exercise good judgement in making their implementation of D as useful as practical.

On Friday, 4 July 2014 at 12:59:41 UTC, bearophile wrote:
>> If the D maintainers don't care about reaching a stable state, at the expense of scope and features,
>
> Don't be silly, D devs care a lot about reaching stability, fixing bugs, etc.

But not to the extent that they are willing to limit the scope and features to get there in reasonable time for D2 (say 10 months), so the feature set is expanding and the scope of the standard library is too big for a stable mature library that is easy to use to be feasible as far as I can tell. Dart is going down the same path. It affects adoption, which in turn affects the eco system. Basically Dart pushed their commercial adoption two years into the future by not commiting to stable platform support, claming that they only support "evergreen browsers", whatever that means. Which pretty much lets Google, Apple and Microsoft define platform stability.

I'm not trying to be pushy or silly. I just want to know if the most probable path for an alternative system development language is a fork or spinning up a new project.

Evolutionary development is great when there is great uncertainty and you need prototyping, but then you need to focus on getting to something that is tight, uniform, portable (future proof) and feasible with the available resources.

A good starting point would be to get down to locking down the specs in a coherent and platform agnostic manner, then plan for making a mature toolset to support it. The D spec should be clear on what IEEE 754 compliance actually means and relate it to all probable scenarios. That would be a very useful exercise in decision making.

On 7/4/2014 12:07 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> The D spec should be clear on what IEEE 754 compliance actually
> means and relate it to all probable scenarios.

I'm curious how that would affect anyone currently using dmd/gdc/ldc in getting professional work done.

On Friday, 4 July 2014 at 19:53:11 UTC, Walter Bright wrote:
> I'm curious how that would affect anyone currently using dmd/gdc/ldc in getting professional work done.

It doesn't affect them since they are on x86 (until they want to use co-processor auto-vectorization). As far as I can tell, also Intel CPUs such as Phi are faster if you skip on IEEE754 conformance for denormal numbers. So I think this is a trend, backed empirically by CPUs by IBM, ARM and Intel.

The most important factor is that it does affect the credibility of the spec. The spec is the vision that people either embrace or reject. For those devs who aren't happy with status quo having a credible spec that the team is committed to is important, because it says what outcome they can expect if they start contributing. There is very little incentive to contribute if you think that the current D incarnation is insufficient, unless the team specs out what D is to become.

If you can commit to a spec for D2 that is final, then you can also plan for when D2 is done.

On 7/4/2014 1:13 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> If you can commit to a spec for D2 that is final, then you can also plan for
> when D2 is done.

There's no such thing as done for a working language. C++, for example, is constantly in flux. Every release by every vendor alters which parts of the standard and draft standard it supports. Furthermore, the C/C++ Standards don't have much to say about how floating point works - how is that of any help in writing professional, stable fp code?

Do we want to make the spec better? Yes.

Does that impair professional use of D now? No.

Do we accept pull requests on the spec to make it better? Yes.

Have you contributed to any pull requests to improve the spec?

Please, contribute to the things you care about, instead of suggesting in the n.g. that others should do it. That would be far more helpful.

On Friday, 4 July 2014 at 20:28:36 UTC, Walter Bright wrote:
> There's no such thing as done for a working language. C++, for example, is constantly in flux. Every release by every vendor alters which parts of the standard and draft standard it supports.

And no sane devs rely on those experimental parts unless g++ or clang commits themselves to them. The C++ standard specs out things in advance at intervals specified in years, not weeks.

> Furthermore, the C/C++ Standards don't have much to say about how floating point works - how is that of any help in writing professional, stable fp code?

You know that you are on your own and cannot make assumptions about conformance, and address it with code (like ifdefs).

> Do we want to make the spec better? Yes.

Not make the spec better or bring it up to date with the implementation. Spec out the language so people know what the missing bits are.

> Please, contribute to the things you care about, instead of suggesting in the n.g. that others should do it. That would be far more helpful.

That would imply a fork. And yes, I think that might be the most likely outcome that someone forks it.

I don't believe in language design by a comittee. I think the language designers should spec out their vision. Let the community point out the flaws. Go back to the drawing board. Do some rounds. Then commit to it.

I think that would attract more contribution to the core language development.

I am interested in contributing code to make a good spec come to life, not to add noise to an endless contractual metamorphosis that never will lead to anything consistent and coherent.

On 7/4/2014 1:41 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 4 July 2014 at 20:28:36 UTC, Walter Bright wrote:
>> There's no such thing as done for a working language. C++, for example, is
>> constantly in flux. Every release by every vendor alters which parts of the
>> standard and draft standard it supports.
>
> And no sane devs rely on those experimental parts unless g++ or clang commits
> themselves to them. The C++ standard specs out things in advance at intervals
> specified in years, not weeks.

As I said, C++ vendors often implement things far in advance of spec approval, they do it piecemeal, and different vendors do things in different orders. C++ evangelists are constantly rewriting what C++ "best practices" are. To characterize all this churn as "stablility" is awfully charitable.


>> Furthermore, the C/C++ Standards don't have much to say about how floating
>> point works - how is that of any help in writing professional, stable fp code?
> You know that you are on your own and cannot make assumptions about conformance,
> and address it with code (like ifdefs).

Uh-huh. And how much professional code have you seen that had #ifdef's for Vax fp in it? IBM fp? Future CPUs that don't exist yet? How many developers have access to a Vax to test their #ifdef's on?

Next, consider how much C++ code breaks when ported from 32 to 64 bits. It's most of it, even mine, and I know what I'm doing. What you're implying is saying that when a spec says "implementation defined" then voila! the code is portable!


>> Do we want to make the spec better? Yes.
> Not make the spec better or bring it up to date with the implementation. Spec
> out the language so people know what the missing bits are.

Please contribute to those areas of the spec you feel need improvement. Non-specific statements like "bring it up to date" are not helpful.


>> Please, contribute to the things you care about, instead of suggesting in the
>> n.g. that others should do it. That would be far more helpful.
> That would imply a fork. And yes, I think that might be the most likely outcome
> that someone forks it.

A pull request does not imply a fork.


> I don't believe in language design by a comittee.

The only alternative is you believe I need to do all the work. This is not possible. I am not superman, nor am I expert at everything.

Sadly, this also implies that there are no computer languages you believe in. You set an impossible standard. How can you possibly say you prefer C++, a classic design by committee language?


> I think the language designers
> should spec out their vision. Let the community point out the flaws. Go back to
> the drawing board. Do some rounds. Then commit to it.
>
> I think that would attract more contribution to the core language development.

I'm asking you to contribute. These posts do not accomplish anything. Exhorting me to do more (I already work on D 24/7) cannot work.


> I am interested in contributing code to make a good spec come to life, not to
> add noise to an endless contractual metamorphosis that never will lead to
> anything consistent and coherent.

Nothing will improve if you and others remain on the sidelines. Get out in front and make what you want to happen, happen.

On Friday, 4 July 2014 at 21:08:27 UTC, Walter Bright wrote:
> rewriting what C++ "best practices" are. To characterize all this churn as "stablility" is awfully charitable.

Pfft, a lot of performance C++ code is roughly in 1998 land without exceptions and rtti.

> Uh-huh. And how much professional code have you seen that had #ifdef's for Vax fp in it? IBM fp? Future CPUs that don't exist yet? How many developers have access to a Vax to test their #ifdef's on?

It is not uncommon for portable DSP code to have ifdefs. It is not uncommon to have ifdefs for extracting the mantissa etc. Heck, even for uints you might need ifdefs, to account for whether you have wrapping uints or not in phase counters. (wrapping over 31 bits or 32 bits)

Considering that denormal numbers being flushed to zero is non-standard and not uncommon, it would be wise to somehow support it with version{}, so you can specify what assumptions a particular function make. That way you might get "not implemented" as a  compile time error when porting to a new platform.

> What you're implying is saying that when a spec says "implementation defined" then voila! the code is portable!

No, it says "voila! the code is not portable" and then you can inject your own guards that might prevent it from compiling on nonconforming platforms and let you know what you need to look at.

> Sadly, this also implies that there are no computer languages you believe in. You set an impossible standard. How can you possibly say you prefer C++, a classic design by committee language?

I don't prefer it. I think it sucks, but it is the only viable choice if you want to create a scalable game or virtual world server. And since C++ is the crappy shit it is, you usually have to build a language on top of it to keep the server stable and modifiable and stay sane. A key benefit of a tighter version of D would be to avoid that extra layer IMO.

> I'm asking you to contribute. These posts do not accomplish anything. Exhorting me to do more (I already work on D 24/7) cannot work.

Maybe you and Andrei could consider having other people do the stuff you don't have to do, but that other people can take care of? Because I think you and Andrei are the only ones who can spec out the changes that would make D a clean delightful language to use and get acceptance for it in the community.

The alternative is to fork it, cut down on features, clean up the syntax for DSL purposes, rip out the GC and add transactional memory support. I think the current process is too slow for outsiders to get D to production level in the domains where speed and stability truly matters.

On Thu, 3 Jul 2014 14:01:23 -0700
Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I'm fine with real varying from platform to platform depending on what makes sense for that platform, but I think that it should be clear what real is generally supposed to be (e.g. the largest floating point type that the hardware supports), but unless it's _guaranteed_ that real be the same as long double, I would strongly argue in favor of having an alias for long double rather than using real directly (much as it will likely be an alias to real in most cases). We already do that with c_long.

Here: https://github.com/D-Programming-Language/druntime/pull/863

- Jonathan M Davis