On 8/29/2018 11:02 AM, Timon Gehr wrote:
> Absolutely. But D only strives to provide such automation in @safe code. For @system code, we need a formal specification of what is allowed. (And it needs to include all things that the GC and language do; no magic.) Note that such a formal specification is a prerequisite for any (possibly language-external) automated verification approaches.

I don't think that @system code is amenable to formal verification. After all, you can do UB in it, and it is the programmer's responsibility to ensure it works.

On 8/29/2018 10:05 AM, Timon Gehr wrote:
> This is a misunderstanding. The __mutable DIP will define the set of allowed program rewrites based on const/immutable/pure. Then code that uses __mutable must remain correct when they are applied. This achieves two things: it clearly defines the semantics of const/immutable/pure and (the possibility of) __mutable will not be an optimization blocker.
> 
> I'll get back to this once I have finished the tuple DIP implementation.

This is good news. I'm looking forward to both of them.

On 8/29/2018 10:50 AM, Timon Gehr wrote:
> D const/immutable is stronger than immutability in Haskell (which is usually _lazy_).

I know Haskell is lazy, but don't see the connection with a weaker immutability guarantee. In any case, isn't immutability a precept of FP?

On Wednesday, 29 August 2018 at 16:38:48 UTC, Ali Çehreli wrote:
> On 08/22/2018 10:20 PM, Nicholas Wilson wrote:
>
>> That reminds me, what happened to our conversation with Ali Çehreli about splitting general [newsgroup/forum] into Technical and less technical?
>
> Even I remember that conversation. :) I don't remember who were involved but as soon as I opened the discussion at the next dinner table, I was discouraged; I think people were against the idea.
>
> Ali

It was You, me, Matthias Lang, Shachar, Liran, Don(?) and maybe some more.

That is a pity, it would be nice to have a list that has a better SNR than general.
Greater industry participation on the technical matters would be a nice thing to have.

On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote:
> On Tuesday, 28 August 2018 at 08:44:26 UTC, Chris wrote:
>>
>> When people choose a programming language, there are several boxes that have to be ticked, like for example:
>>
>> - what's the future of language X? (guarantees, stability)
>> - how easy is it to get going (from "Hello world" to a complete tool chain)
>> - will it run on ARM?
>> - will it be a good choice for the Web (e.g. webasm)?
>> - how good is it at data processing / number grinding
>> - etc.
>>
>
> I don't know if all their claims are 100% true, but let that sink in for a while:
>
> https://julialang.org/.

Julia is great.  I don't see it as a competitor to D but for us one way researchers might access libraries written in D.  One could do quite a lot in it, but I don't much fancy embedding Julia in Excel for example, though you could.  Or doing DevOps in Julia.  Perhaps more of a Matlab substitute.

Look around and you can find people grumpy about any language that's used.
http://www.zverovich.net/2016/05/13/giving-up-on-julia.html

Languages really aren't in a battle to the death with each other.  I find this zero-sum mindset quite peculiar.

On Monday, 27 August 2018 at 20:15:03 UTC, Ali wrote:
> On Monday, 27 August 2018 at 19:51:52 UTC, 12345swordy wrote:
>> On Monday, 27 August 2018 at 18:20:04 UTC, Chris wrote:
>>> Then the D Foundation should work on it.
>> Easier said then done. You can't go around demanding people to build factories without addressing the issues that comes with building factories, such as the big question of how is it going to be payed to be built.
>>
>> -Alex
>
> No one is (and no one should be) demanding anything, hoping maybe..
>
> Walter, wants to build D, and he is doing what he can to continue building it
> Andrei and many others joined him
>
> If we are sharing our opinion, its not coming from any sense of entitlement, we are sharing our opinion, because the builders, provided the platform for us to voice our opinion
>
> And again, because I keep repeating this, if they want more donations, I think talking more about the future plans will help, D currently neither have a larger user base, or an ambitious future plan, it make sense that they are not getting a lot of donations, they are not really making it attractive to donate
>
> I think that most current donors are probably incentivized by negative factors, or negatively motivated, they are probably afraid D's Development will stop or they feel guilty for using the language and not providing much back
>
> I dont think many donors are doing so because they are excited about the future
>
> Nothing seriously wrong about negative motivation, it works, but positive motivation is  off

I donate to the D Foundation via my personal consulting company though it is listed under the name of Symmetry Investments.

I see that I am the second biggest donor after Andrei.  I think I can have more insight into my motivations than you can, and I can say that I am motivated by enthusiasm about commercial benefits and it wouldn't have occurred to me to donate out of fear, as you suggest.  If one makes a mistake I am in a business where the custom is that one fixes the mistake and moves on.  Suppose it were to turn out to have been a  mistake to use D.  Well I have made costlier mistakes then that this year and it's only August.  And, as if happens, I don't think it was a mistake.

So you may think what you wish about the motivations of donors, but I think you might do well to base your views on evidence not imaginings if you wish to be taken seriously :)

On 29.08.2018 21:58, Walter Bright wrote:
> On 8/29/2018 11:02 AM, Timon Gehr wrote:
>> Absolutely. But D only strives to provide such automation in @safe code. For @system code, we need a formal specification of what is allowed. (And it needs to include all things that the GC and language do; no magic.) Note that such a formal specification is a prerequisite for any (possibly language-external) automated verification approaches.
> 
> I don't think that @system code is amenable to formal verification. After all, you can do UB in it, and it is the programmer's responsibility to ensure it works.

If it's amenable to informal verification, it is also amenable to formal verification. Computers can check mathematical proofs, and if the code is proven correct it does not contain UB. This is independent of whether D classifies the code as @safe or @system.

On 08/29/2018 04:01 PM, Walter Bright wrote:
> On 8/29/2018 10:50 AM, Timon Gehr wrote:
>> D const/immutable is stronger than immutability in Haskell (which is usually _lazy_).
> 
> I know Haskell is lazy, but don't see the connection with a weaker immutability guarantee. In any case, isn't immutability a precept of FP?

I think the point is that it disallows less, and permits more, all without breaking immutability.

Ie, lazy immutable *can* be changed, albiet once and only once in a very specific circumstance: When transitioning from uninitialized to initialized. AIUI, D only has this "the immutable is in-scope, but can still be initialized" state within constructors, whereas (it sounds like) Haskell allows it anywhere.

It's like strong-pure vs weak-pure: Both enforce the same purity guarantees, but weak-pure is less restrictive and more expressive.

On 8/25/2018 4:49 PM, Nicholas Wilson wrote:
> Run semantic3 on the constructor independent of the requirement to destruct already constructed objects. If the constructors is nothrow then there is no need to have the destructors run or the eh code at all, because no Exceptions can be thrown (an Error may be thrown but that will kill the program). This is how I intend to fix it after I refactor semantic3.

A function can be made nothrow by:

    try {
       ....
    } catch (Exception e) {
       ... handle it locally ...
    }

Also, your proposal is ignoring the destructors, which is literally what the compiler does now.

On Thursday, 30 August 2018 at 23:03:57 UTC, Walter Bright wrote:
> On 8/25/2018 4:49 PM, Nicholas Wilson wrote:
>> Run semantic3 on the constructor independent of the requirement to destruct already constructed objects. If the constructors is nothrow then there is no need to have the destructors run or the eh code at all, because no Exceptions can be thrown (an Error may be thrown but that will kill the program). This is how I intend to fix it after I refactor semantic3.
>
> A function can be made nothrow by:
>
>     try {
>        ....
>     } catch (Exception e) {
>        ... handle it locally ...
>     }

Then I should have said: no exceptions can propagate, which is the real problem.

> Also, your proposal is ignoring the destructors, which is literally what the compiler does now.

It was implicit in that the throwing case would call the destructors in the event of an exception (otherwise the bug ain't fixed). This formulation is to reduce the amount of breakage, which was the problem last time.

Yes this will break (as in code breakage) @safe ctors calling @system dtors but, such is life. The ctor probably shouldn't be throwing in the first place. I'll probably add -vthrowingctor and -vthrowingdtor as well since this will be a perf hit in the case of a throwing ctor.

Sorry for any confusion.