Question: How to make library classes work with own runtime implementations?

[aloslider]

I wanted to use System.Console.ReadKey function with it's overload that lets you not to print the read key in console:

public static ConsoleKeyInfo ReadKey(bool intercept)
{
    return ConsolePal.ReadKey(intercept); 
}

However, the built-in trait HasConsole<RT> doesn't have this overload but only one without any arguments:

namespace LanguageExt.Sys
{
    public static class Console<RT> where RT : struct, HasConsole<RT>
    {
        public static Eff<RT, ConsoleKeyInfo> readKey 
        {
           get
           {
        ...

So I thought I need to create all the setup of my new trait, its implementation, static class with functions to work with console, runtime and e.t.c. (by following this wiki page example). I've created all of these, but unforunately I can't use Producer class and other pipe classes and high-order functions like awaiting and yield, because the Producer is constrained on <RT> to implement built-in HasCancel<RT> trait:

static class MyConsole<RT>
    where RT : struct, HasMyConsole<RT>, HasMyCancel<RT>
{
    public static Eff<RT, ConsoleKeyInfo> readKey(bool hideKeys)
        => default(RT)
        .ConsoleEff.Bind(
            (MyConsoleIO e) => 
                e.ReadKey(hideKeys)
                 .Match(
                    new Func<ConsoleKeyInfo, Eff<ConsoleKeyInfo>>(SuccessEff), 
                    () => FailEff<ConsoleKeyInfo>(Error.New("end of stream"))));

    public static Producer<RT, ConsoleKeyInfo, Unit> readKeys(bool hideKeys) => // Error: no conversion from RT to HasCancel<RT>
            from ln in readKey(hideKeys)
            from __ in yield(ln) 
            select unit;        
}

So, if I need to use a Producer class with my own runtime and traits implementations, do I need to use only built-in one like HasCancel<RT>, or there's a way to extend it?

[louthy]

First thing is that you can't have your own HasCancel<RT> unless you extend the original trait/interface. It is the only thing that's built-in to the asynchronous effects (Aff) system, because it's the trait that allows you to cancel an asynchronous process.

The key thing to note is that because the 'traits' are just interfaces, they can be extended through inheritance. I would 'extend' the current console trait and interface:

    public interface ConsoleExtendedIO : ConsoleIO
    {
        public Option<ConsoleKeyInfo> ReadKey(bool hideKeys);
    }

    public interface HasConsoleExtended<RT> : HasConsole<RT>
       where RT : struct, HasCancel<RT>
    {
        Eff<RT, ConsoleExtendedIO> ConsoleExtendedEff { get; }
    }

Then implement your extended console:

    public readonly struct YourExtendedConsoleImplementation : ConsoleExtendedIO 
    {
        public readonly static ConsoleExtendedIO Default =
            new YourExtendedConsoleImplementation();

        public Option<ConsoleKeyInfo> ReadKey(bool hideKeys) =>
            System.Console.ReadKey(hideKeys);

        // ... all the inehrited methods can just call LanguageExt.Sys.Live.ConsoleIO.*
    }

And create an extended console static class:

    public static class ConsoleExtended<RT>
        where RT : struct, HasConsoleExtended<RT>
    {
        public static Eff<RT, ConsoleKeyInfo> readKey(bool hideKeys) =>
            default(RT).ConsoleExtendedEff 
                       .Bind(static e => 
                           e.ReadKey(hideKeys)
                             .Match(Some: SuccessEff<ConsoleKeyInfo>, 
                                    None: () => FailEff<ConsoleKeyInfo>(Error.New("end of stream"))));

    }

Then in your runtime, you can implement HasConsoleExtended:

    public readonly struct Runtime : 
        HasCancel<Runtime>,
        HasConsoleExtended<Runtime>,
        Has...
    {
        public Eff<Runtime, Traits.ConsoleIO> ConsoleEff =>
            SuccessEff(YourExtendedConsoleImplementation.Default);

        public Eff<Runtime, Traits.ConsoleExtendedIO> ConsoleExtendedEff =>
            SuccessEff(YourExtendedConsoleImplementation.Default);
    }

I don't know how far you've got implementing your own runtime, but there's a default one built-in that you can copy and use as a basis for extended.

Then you can use the trait HasExtendedConsole<RT> instead of HasConsole<RT> throughout your code and call.

    ConsoleExtended<RT>.readKey(true)

You don't have to extend ConsoleIO and HasConsole in this way, you could make the 'extended' trait stand-alone: that means you would need to use HasConsole and HasExtendedConsole for each method that uses those capabilities.

You will however have to use the built-in HasCancel either way.