00:21 <endformationage> I have a class which is generic over a type [T: Any #send]. Within, I can use `T` as an argument to another generic type with the same constrait `Any #send`.

00:21 <endformationage> Say I have a third generic type with a constraint [U: Any #read]. Is there a way to use the 'base' type of `T` (sans refcap constraints) to instantiate this third type, which should specialize over the same 'base' type provided for `T`, but be constrianed differently with #read?

00:23 <endformationage> I suspect I cannot think of types in this way (apart from their refcap / constraints).

00:56 <endformationage> A contrived example of my intentions: https://playground.ponylang.org/?gist=6c6fb0969e41d37988d0cc855e734f78

08:15 <vaninwagen> I dont know if that helps you a lot, but #read is not a subset of #send. So with Any #send you can have iso, val or tag while with Any #read you can have ref, val and box

08:15 <vaninwagen> So only in case of val, you can actually create SomeRead

08:15 <vaninwagen> Maybe you can check for that cap with iftype, but im not sure

08:16 <vaninwagen> In general i think what you want to do is not achievable, but i have to think about it some more

08:16 <vaninwagen> tricky case

16:25 <endformationage> vaninwagen: To provide a bit more context. There is a separate process which, using iftype, acts as a translator between these seemingly incompatible constraints. This really only means consuming iso cases into a ref, and passing along the others.

16:26 <endformationage> My challenge I think, is that I need a way of using an even more general type param, which other params could use. Something like:

16:27 <endformationage> [T~, X: (T iso | T val | T tag), Y: (T ref | T val | T tag)]

16:28 <endformationage> Where `T~` means the type, apart from any refcaps, and `X` and `Y` are generic types based on `T~`.

16:29 <endformationage> `T~` would only be able to be used by other generic type parameters.

17:41 <vaninwagen> I totally get your point, but i think this is not possible currently

19:17 <vaninwagen> Maybe it is possible to use a third type param and some intersection magic to achieve what you want endformationage

19:27 <emilbayes> When doing libraries/modules in pony, when is it convention to make something an actor instead of a class, and delegating it to the user to wrap the class in an actor? I'm currently looking at the http server that was extracted from stdlib

19:31 <vaninwagen> emilbayes: do you have a concrete example in mind that puzzles you?

19:32 <emilbayes> vaninwagen: Just the http server for example. Maybe I'm too locked in the thinking that threads are expensive while actors are cheap

19:40 <vaninwagen> I'd say the main reason for chosing an actor is concurrency/parallelism. A pony program is always a bunch of actors interacting in some ways. Classes are usually state inside actors or messages sent between actors.

19:47 <vaninwagen> For the http server one reason might be that it should do something not blocking other operations (handling requests etc.), e.g. it kerps track of all tcp connections in order to close them properly when disposed. This should be an asynchronous task during http serving

19:49 <vaninwagen> So it is most likely a result of how you design your little actor subsystem that is your program (or in case of a library the intended use of that lib in a program)

19:52 <emilbayes> vaninwagen: Ah yeah, and it's that decision of where you cut the concurrency that I was unsure of what best practise is. To me it feels a bit like malloc'ing in C, where you try to push it to the application as much as possible

20:00 <endformationage> vaninwagen: I've come up with a rough pattern to attempt to solve my issue. Unfortuanately it requires duplicating the involved types to split off the isolate functionality. The isolate types will take two type params, the first being `iso` for the sendable part, and the second being `ref` for the internal part.

20:04 <endformationage> That's probably not very clear based on lack of context but, I can see the possibility.

20:07 <endformationage> I don't think any intersect magic would be helpful in my case. But if you do find something that resembles my requested `T~` functionality, it could work.