jackfoxy / dependenttypes Goto Github PK

Description

Releasing on 4.7 makes the library unusable for many projects.

Multi-release targeting is primitive in the current build system, so default to some lower version...4.5?

This discussion robkuz/robkuz.github.io#6 (comment) suggests the LimitedValue technique may be leveraged as an F# language suggestion to implement literals as type parameters. If this were to work out, it could potentially eliminate the need for the config consuming helper function, and open the door to other methods of creating dependent types.

Description

Add Expecto BenchmarkDotNet performance tests https://github.com/haf/expecto#benchmarkdotnet-usage to the test project https://github.com/jackfoxy/DependentTypes/tree/master/tests/DependentTypes.Tests

Think of the results compiled into a documentation page on performance. Submitting such a page with the PR is a bonus.

Because the dependent type depends on the new function of the validator being unit -> 'Pi, it is impossible to have the DependentType creation take in a value that should go to the validator function. In my use case, I have validation that always takes in some form of logger function. I specifically do this because each validation operation within a validator function is wrapped in code quotes and stringified with unquote before logging the error and exiting early with a None.

I wish this could be "fixed" by just implementing a LogSomeDependentType or some such, but apparently you can't pass any parameters to the new() of a type parameter.

'T1 -> 'T2 provides more flexibility for users. Although at the moment I have not thought of a useful dependent type where 'T2 differs from 'T1.

It appears that from the user's perspective there is also not much of a difference in the implementation.

The DependentType type does not support extension methods. In lieu of this limitation, is it better to add all the desirable overloads to TryParse and Parse? Otherwise users will have to devise their own functions.

If extension methods were possible users could perform all sorts of customizations to dependent types.

With my skill set and knowledge I have been unable to unify the two types of dependent type in this project into a single type, with the constraint the SomeDependentType continues to lift option up to SomeDependentType.

The only path I can think of is to make a two entry discriminated union. And since both dependent types expose essentially the same API you would think there must be a way to make this work.

My experience was I would run into issue "A". Correcting for issue "A" I ran into Issue "B"...and back to "A".

I take a broad view of the meaning of "parse", in that any type of object may be parsed for the semantic information it contains, but I recognize this is a minority view.

I recognize others may prefer TryCreate as the basic creation method of DependentTypes.

A useful utility would do one-time code generation creating source to populate all the methods and properties of the underlying type as well as functions from the type's module (if it exists), probably using reflection, for the dependent type. Does not have to be fancy. Does not have to be part of the runtime (although I can imagine it could be, at least to produce generated code as a string), and does not need to be part of the design time either. Of course custom coding may still be required in some cases.

This would make #1 less of an issue.

Example:

module rec RecursiveModule =
  module MyType =
    let createBaseTypeElement (config : ConfigType) (value : T1) =
        ...

    type MyTypeValidatorOrDiscriminator(config) = 
        inherit Pi<ConfigType, T1, BaseType>(config, createBaseTypeElement )

    // insert generated properties and functions here, operating on MyType.Value
    let BaseTypeMethod1 (x : MyType) = ...
    ...

  type MyType = DependentType<MyType.MyTypeValidatorOrDiscriminator, ConfigType, T1, BaseType>

Adding constructors to the dependent types has proved impossible, so far.
Maybe recent or planned F# type system work will make this possible.