On 09/07/14 15:45, Meta wrote:

> As far as I know, there's no reason we can't add pattern matching to
> switch or final switch or both. There's no ambiguity because right now
> it's not possible to switch on structs or classes. See Kenji's DIP32 for
> syntax for tuples that could be leveraged.

There's no reason why we can add a completely new construct for this either. But it's usually easier to get a new function into Phobos then changing the language.

-- 
/Jacob Carlborg

On 10/07/14 05:59, logicchains wrote:

> It's been implemented in Rust[1] via a macro, and can be implemented in
> Haskell[2] without compiler support, so I'd be surprised if it wasn't
> already possible to implement in D. It wouldn't however be as useful as
> Go's until D gets message passing between fibres.

Another use case for AST macros, which we don't have :(

-- 
/Jacob Carlborg

On Wednesday, 9 July 2014 at 19:47:02 UTC, Walter Bright wrote:
> Yes, I mean transitive, and understand what that implies.

I am positively shocked :)

>> I have started work on porting the CDGC to D2, have compilable version (that was
>> easy thanks to earlier Sean work) but updating implementation to match new
>> druntime and pass tests will take quite some time.
>
> Is CDGC's Luca's earlier work on concurrent GC?

Yes.

>> I'd state it differently: "Marketing fuss about goroutines is the killer feature
>> of Go" :) It does not have any fundamental advantage over existing actor model
>> and I doubt it will matter _that_ much.
>
> Much of the froth about Go is dismissed by serious developers, but they nailed the goroutine thing. It's Go's killer feature.

Who are "they"? I don't know any serious developer who praises goroutines if he was not a CSP fan before. I forsee that it will make no impact for D because we simply don't have resources to advertise it as killing feature (on a same scale Go did).

Well, of course, if someone wants to waste his time on this - no objections from my side :)

>> I don't know where it comes from but non-nullable reference type has ZERO value
>> if it is not the default one.
>
> Making it the default is impossible for D. However,
>
>   class _C { ... }
>   alias NotNull!_C C;
>
> is entirely practical. It's not unlike the common C practice:
>
>   typedef struct S { ... } S;
>
> to bring S out of the tag name space.

You are totally missing the point if you consider this even comparable replacement. Reason why non-nullable types are awesome because you are 100% sure compiler will force you to handle null cases and if program compiles it is guaranteed to be safe in that regard. What you propose makes hardly any difference.

On Thursday, 10 July 2014 at 03:59:15 UTC, logicchains wrote:
> Actually, an important question that should be considered: does D want actor-style concurrency, like Erlang and Akka, or CSP-style concurrency, like Rust, Go and Haskell? Or both? Deciding this would allow efforts to be more focused.

AFAICS D already has actor-style concurrency with vibe.d extensions for std.concurrency so this is an easy choice ;)

On Thursday, 10 July 2014 at 10:43:39 UTC, Dicebot wrote:
> On Thursday, 10 July 2014 at 03:59:15 UTC, logicchains wrote:
>> Actually, an important question that should be considered: does D want actor-style concurrency, like Erlang and Akka, or CSP-style concurrency, like Rust, Go and Haskell? Or both? Deciding this would allow efforts to be more focused.
>
> AFAICS D already has actor-style concurrency with vibe.d extensions for std.concurrency so this is an easy choice ;)

Are there any tutorials or blog posts out there demonstrating how to use this? I think posts along the lines of "This is a CSP/message passing program in Go/Erlang. This is the same program translated into D; look how concise and faster it is!" could attract a lot of interest.

Reading the code in the pull request [1], for instance, makes me wonder how to tell if `spawn()` is spawning a thread or a fibre. Can a tid refer to a fibre? If so, why's it called a thread ID, and how do I tell if a particular tid refers to a thread or fibre? It would be great to have these kinds of questions answered in an easily available reference (for instance, the documentation for std.concurrency, which currently doesn't even mention fibres or vibe.d).

1. https://github.com/D-Programming-Language/phobos/pull/1910

On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
> Are there any tutorials or blog posts out there demonstrating how to use this? I think posts along the lines of "This is a CSP/message passing program in Go/Erlang. This is the same program translated into D; look how concise and faster it is!" could attract a lot of interest.

There are no detailed blog posts and I believe only few developers are really well proficient with this vibe.d functionality. Some relevant docs:

http://vibed.org/api/vibe.core.core/
http://vibed.org/api/vibe.core.concurrency/
http://vibed.org/api/vibe.core.task/

> Reading the code in the pull request [1], for instance, makes me wonder how to tell if `spawn()` is spawning a thread or a fibre. Can a tid refer to a fibre? If so, why's it called a thread ID, and how do I tell if a particular tid refers to a thread or fibre? It would be great to have these kinds of questions answered in an easily available reference (for instance, the documentation for std.concurrency, which currently doesn't even mention fibres or vibe.d).
>
> 1. https://github.com/D-Programming-Language/phobos/pull/1910


Problem is that this is most simple PR to simply add message-passing support for fibers. Adding some advanced schedulers with worker thread pool can be expected to be done on top but.. This small PR has been rotting there for ages with pretty much zero attention but from few interested persons.

I can't blame Sonke or anyone else for not wanting to waste his time on pushing more stuff upstream considering how miserable contribution experience is right now. We can't really expect anything else to improve why it stays that bad - Andrei has mentioned that during his keynote but nothing has been ever done to improve the situation.

On 10/07/14 01:57, H. S. Teoh via Digitalmars-d wrote:

> [...]
> I'm sure there are plenty of holes in this proposal, so destroy away.
> ;-)

You should post this in a new thread.

I'm wondering if a lot more data can be statically allocated. Then passed by reference to functions taking scope parameters. This should be safe since the parameter is guaranteed to outlive the function call.

-- 
/Jacob Carlborg

Dicebot:

> I can't blame Sonke or anyone else for not wanting to waste his time on pushing more stuff upstream considering how miserable contribution experience is right now.

This was one of the causes of the creation of Tango and its fiasco, so better to not repeat that.

Bye,
bearophile

On Thursday, 10 July 2014 at 11:19:26 UTC, Dicebot wrote:
> On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
>> Are there any tutorials or blog posts out there demonstrating how to use this? I think posts along the lines of "This is a CSP/message passing program in Go/Erlang. This is the same program translated into D; look how concise and faster it is!" could attract a lot of interest.
>
> There are no detailed blog posts and I believe only few developers are really well proficient with this vibe.d functionality. Some relevant docs:
>
> http://vibed.org/api/vibe.core.core/
> http://vibed.org/api/vibe.core.concurrency/
> http://vibed.org/api/vibe.core.task/
>
>> Reading the code in the pull request [1], for instance, makes me wonder how to tell if `spawn()` is spawning a thread or a fibre. Can a tid refer to a fibre? If so, why's it called a thread ID, and how do I tell if a particular tid refers to a thread or fibre? It would be great to have these kinds of questions answered in an easily available reference (for instance, the documentation for std.concurrency, which currently doesn't even mention fibres or vibe.d).
>>
>> 1. https://github.com/D-Programming-Language/phobos/pull/1910
>
>
> Problem is that this is most simple PR to simply add message-passing support for fibers. Adding some advanced schedulers with worker thread pool can be expected to be done on top but.. This small PR has been rotting there for ages with pretty much zero attention but from few interested persons.
>
> I can't blame Sonke or anyone else for not wanting to waste his time on pushing more stuff upstream considering how miserable contribution experience is right now. We can't really expect anything else to improve why it stays that bad - Andrei has mentioned that during his keynote but nothing has been ever done to improve the situation.

Scala has also a history of three implementations of actor system, until akka is merged into official support (with Akka's arthur Jonas Bonér becoming CTO of Typesafe).

In vibe.d's case I think first people don't really know that there is a good fiber based actor system already in vibe.d, for that I think it would benefit by separating out to be a standalone library, then add more functionalities like location transparency of actors in akka. Otherwise people would only recognize vibe.d as a networking lib, with no intent to look for actors there.

On Thursday, 10 July 2014 at 12:13:03 UTC, bearophile wrote:
> Dicebot:
>
>> I can't blame Sonke or anyone else for not wanting to waste his time on pushing more stuff upstream considering how miserable contribution experience is right now.
>
> This was one of the causes of the creation of Tango and its fiasco, so better to not repeat that.
>
> Bye,
> bearophile

No one but Walter / Andrei can do anything about it. Right now we are in weird situation when they call for "lieutenants" but are not ready to abandon decision power. It can't possibly work that way. No amount of volunteer effort will help when so many PR stall waiting for resolution comment from one of language "generals".