Has<T> interface, remove a layer when wrapping IO?

[bmazzarol]

@louthy this is a combined question and idea.

Why are the HasSomething<RT> interfaces required?

I get that it enforces the struct constraint, but that (IMHO) is not required as
Eff and Aff enforce it.

Is the ability to conjure it up using default that essential?

Could we not just create a dead simple interface,

/// <summary>
/// Indicates that a runtime has a given service
/// </summary>
/// <typeparam name="Service">service</typeparam>
public interface Has<out Service>
{
    /// <summary>
    /// Gets a service.
    /// </summary>
    /// <returns>service</returns>
    Service Get();
}

And then create simple static functions to access it?

public static class Service
{
    /// <summary>
    /// Accesses the service from the runtime
    /// </summary>
    /// <typeparam name="RT">runtime</typeparam>
    /// <typeparam name="Service">service to access</typeparam>
    /// <returns>effect using the service</returns>
    [Pure]
    public static Eff<RT, Service> access<RT, Service>() where RT : struct, Has<Service> =>
        EffMaybe<RT, Service>(rt => rt.Get());

    /// <summary>
    /// Uses a service from the runtime returning a T
    /// </summary>
    /// <param name="f">delegate to use the service</param>
    /// <typeparam name="RT">runtime</typeparam>
    /// <typeparam name="Service">service to access</typeparam>
    /// <typeparam name="T">T</typeparam>
    /// <returns>effect using the service returning T</returns>
    [Pure]
    public static Eff<RT, T> access<RT, Service, T>(Func<Service, T> f) where RT : struct, Has<Service> =>
        access<RT, Service>().Map(f);

    /// <summary>
    /// Uses a service from the runtime returning a T
    /// </summary>
    /// <param name="f">delegate to use the service</param>
    /// <typeparam name="RT">runtime</typeparam>
    /// <typeparam name="Service">service to access</typeparam>
    /// <typeparam name="T">T</typeparam>
    /// <returns>effect using the service returning T</returns>
    [Pure]
    public static Eff<RT, T> access<RT, Service, T>(Func<Service, Eff<RT, T>> f) where RT : struct, Has<Service> =>
        access<RT, Service>().Bind(f);

    /// <summary>
    /// Uses a service from the runtime returning a T
    /// </summary>
    /// <param name="f">delegate to use the service</param>
    /// <typeparam name="RT">runtime</typeparam>
    /// <typeparam name="Service">service to access</typeparam>
    /// <typeparam name="T">T</typeparam>
    /// <returns>effect using the service returning T</returns>
    [Pure]
    public static Aff<RT, T> access<RT, Service, T>(Func<Service, Aff<RT, T>> f)
        where RT : struct, Has<Service>, HasCancel<RT> =>
        access<RT, Service>().Bind(f);

    /// <summary>
    /// Uses a service from the runtime returning a T
    /// </summary>
    /// <param name="f">delegate to use the service</param>
    /// <typeparam name="RT">runtime</typeparam>
    /// <typeparam name="Service">service to access</typeparam>
    /// <typeparam name="T">T</typeparam>
    /// <returns>effect using the service returning T</returns>
    [Pure]
    public static Aff<RT, T> access<RT, Service, T>(Func<Service, CancellationToken, Task<T>> f)
        where RT : struct, Has<Service>, HasCancel<RT> =>
        access<RT, Service>().Bind(service => AffMaybe<T>(async token => await f(service, token)));

    /// <summary>
    /// Uses a service from the runtime returning a T
    /// </summary>
    /// <param name="f">delegate to use the service</param>
    /// <typeparam name="RT">runtime</typeparam>
    /// <typeparam name="Service">service to access</typeparam>
    /// <typeparam name="T">T</typeparam>
    /// <returns>effect using the service returning T</returns>
    [Pure]
    public static Eff<RT, T> accessAndDispose<RT, Service, T>(Func<Service, Eff<RT, T>> f)
        where RT : struct, Has<Service> where Service : IDisposable =>
        use(access<RT, Service>(), f);

    /// <summary>
    /// Uses a service from the runtime returning a T
    /// </summary>
    /// <param name="f">delegate to use the service</param>
    /// <typeparam name="RT">runtime</typeparam>
    /// <typeparam name="Service">service to access</typeparam>
    /// <typeparam name="T">T</typeparam>
    /// <returns>effect using the service returning T</returns>
    [Pure]
    public static Aff<RT, T> accessAndDispose<RT, Service, T>(Func<Service, Aff<RT, T>> f)
        where RT : struct, Has<Service>, HasCancel<RT> where Service : IDisposable =>
        use(access<RT, Service>(), f);
}

So the recipe is as follows,

• Create interface to access the IO
• Create static functions to make working with the IO better
• Create live and test implementations of the interface

It would be fantastic if there was a constraint that forced a generic to be an
interface, but apart from that it should work as per the old recipe.

C# will let the runtime struct stack the same interface as many times as required,

public readonly struct LiveRuntime :
    Has<Clock>,
    Has<Seed>,
    Has<Random2>
{
    Clock Has<Clock>.Get() =>
        throw new NotImplementedException();

    Seed Has<Seed>.Get() =>
        throw new NotImplementedException();

    Random2 Has<Random2>.Get() =>
        throw new NotImplementedException();
}

Even using it directly without a static wrapper is not the worst thing in the world (def not the worst code I have written),

public static class Test
{
    public static Eff<RT, string> SomeContrivedTest<RT>() where RT : struct, Has<Clock>, Has<Random2>, Has<Seed> =>
        from dt in Service.access<RT, Clock, DateTimeOffset>(clock => clock.Now())
        from i in Service.access<RT, Random2, int>(random => random.RandomNumber<RT>())
        let nd = dt + i * seconds
        select nd.ToString();
}

Love to hear your thoughts.

[rmbrunet]

Still trying to wrap my head around the runtime (that @louthy kindly explained to me here) and hoping to have an AHA moment in the no so distant future. For now, the jump from Aff<T> to Aff<RT,T> seems like a pretty large one and a simplification -if possible- would be welcomed.

[louthy]

@bmazzarol Believe it or not, I actually have this in a Haskell project I'm working on at MMS

I'd actually forgotten that C# could do qualified inherited names, so that it would be possible to have multiple members in a type with the same argument-lists. I'll keep it in mind once I've done by other refactorings 👍

[bmazzarol]

Thanks @louthy