plist is confusing and basically it's an immutable array

I don't see function AList.pairwise, is it called something else?

If it is not there can it be added?

It feels like clist.UpdateTo could also have a simpler overload so for primitive values we can just call

            amodel.SKPoints.UpdateTo(model.SKPoints)

Separately, I wonder if ChangeableValue should have an UpdateTo for symmetry, perhaps where

            amodel.RefreshViewIsRefreshing.UpdateTo(model.RefreshViewIsRefreshing)

is equal to

            if model.RefreshViewIsRefreshing <> amodel.RefreshViewIsRefreshing.Value then 
                amodel.RefreshViewIsRefreshing.Value <- model.RefreshViewIsRefreshing

and with the more sophisticated overload available too

From Discord:

Hey, a question - what's the best way to adaptively generate a range of integers, e.g. I have adaptive values min and max and I want an AList for min .. max?

Feels like we might be missing an AList.init : aval<int> -> (int -> 'T) -> alist<'T>? Possibly also an AList.range of some kind which might be more efficient?

migrate the aset functions from Aardvark.Base

Maybe some existential type using visitors?
Can this be done in fable?

Looking at this code it seems that transaction context might get corrupted in cases where the transaction body throws. I'm not too certain but it seems like the restoration statement should be placed in a finally clause.

port operators (map/collect/etc.)

There is bind2 and bind3 for aval, but not for adaptive collections.

The system uses lots of datastructures like HashMap, HashSet, etc.

Since they need to be part of the public API we cannot make them internal.

My current approach is to leave HashMap, HashSet in the Incremental namespace and expose 'internal' things like CountingHashSet or History in the FSharp.Control.Traceable namespace.

That way users can explicity open and work with it, while still leaving the standard-API relatively clean.

Any suggestions?

the current heuristic for pruning the History is suboptimal and the whole functionality is totally untested.

add IndexList tests that would have revealed the bug i was hunting on the wrong end of my validation tests 😒

should we port MapExt from Aardvark.Base or try to get its functions into FSharp.Core?

If we AVal.force I think we should probably have AList.force, ASet.force etc. for consistency

In our old implementation we had a IMod interface which provided GetValue : AdaptiveToken -> obj.
The reason for that mainly was to allow for heterogenous collections of changeable values in our rendering engine (uniform inputs for shaders, etc.)

I think that adding it would severely reduce the cleanness of the API but we need some way of capturing untyped avals for our rendering engine.

Basically we would need GADTs for representing these existential types but the .NET code simulating that is rather verbose:

type AValVisitor<'r> =
    abstract member Accept<'a> : aval<'a> -> 'r
type AVal =
    abstract member Visit : AValVisitor<'r> -> 'r

This would allow aval to get wrapped into one of these and we could 'extract' the generic Argument later on...

A different approach would be to explicitly 'upcast' to aval<obj> but since .NET doesn't support this we would need to create a new aval and use a mapping function, which really destroys the type-information and blows up the dependency graph.

Any better ideas for solving this problem in a cleaner way?

WeakCallbacks do not work as expected. All callbacks on an AdaptiveObject are hold by the MultiCallbackObject. Weak callbacks are not garbage collected as long as there is either any strong or weak callback alive. This can be demonstrated with the following test:

static void CreateGarbage(IAdaptiveValue<int> foo)
{
    foo.AddWeakMarkingCallback(() => Report.Line("WEAK OUT OF DATE"));
}

static void TestWeakCb()
{
    var myVal = AdaptiveValue.Init(5);
    var map = myVal.Map(x => x * 2);

    var foo = map.AddMarkingCallback(() => Report.Line("OUT OF DATE"));

    for (int i = 0; i < 100; i++)
        CreateGarbage(myMod);

    GC.Collect();
    GC.WaitForFullGCComplete();

    for (int i = 0; i < 1000; i++)
    {
        using (Adaptive.Transact)
        {
            myVal.Value = i;
        }
        Report.Line("GETVALUE: {0}", myVal.GetValue());

        Thread.Sleep(100);
    }
}

All the WeakCallbacks of CreateGarbage will be invoked together with the callback of the main test procedure.

Hi!

Is it possible to get item of alist by index as an aval?

In nonincremental world sets and lists are sequences.
any way to achieve similar behaviour for incrementwl world?

groupBy (f : 'a -> 'g) (set : aset<'a>) : amap<'g, HashSet<'a>>

At the moment I'm using a local utility function:

set |> ASet.map (fun v -> (f(v), v)) |> AMap.ofASet

Our old implementation had a GroupByReader. Would there be benefits implementing something similar? In any case adding grouping convenience utlities might be considered.

Known issues

• WeakReference<'T> not available
• HashSet<'T>/Dictionary<'T1, 'T2> not using hash-equality
• typeof<'T> not working for generics (used by Cache and several other utilities)
• OptimizedClosures.FSharpFunc<_,_,_>.Adapt(...) doesn't work
• Monitor.Enter/Exit
• Interlocked
• Arguments cannot be passed byref
• duplicate interface implementations (IComparable, IComparable<'T>)

add some tests for neighbours, alter, choose2, mapMonotonic, chooseMonotonic, etc.

mostly missing

missing

when overriding Equals the follwing happens:

override x.Equals o =
    match o with
        | :? HashSet<'T> as o -> ...
        | _ -> false

In fable this will cause a warning since it cannot test at runtime whether or not the generic 'T matches.
We currently avoid these warnings by simply unboxing the object, which may cause problems when using heterogenous HashSets/etc.

We could obviously just live with the warning but I tend to miss important things when fable just spams 50 warnings everytime it recompiles.

I'm creating this issue just so we don't forget...

is there any way of tracking outputs that doesn't require weak references?

This issue is to catalog additional derived functions I find myself using. We can leave it open and other people can add them

List.existsA
List.forallA
AMap.find

Sample implementations, please improve:

module List =
   let existsA (f: 'T -> aval<bool>) xs =  AList.existsA f (AList.ofList xs)
   let forallA (f: 'T -> aval<bool>) xs =  AList.forallA f (AList.ofList xs)

module AMap =
    let find f x = AMap.tryFind f x |> AVal.map Option.get  // note should give a better error here

RelevantNodes are destroyed that should still be alive for some reason...

migrate from Aardvark.Base once #12 and #14 are done

add some reasonable number of tests for HashMap / HashSet

Keeping track of missing combinators here

Currently not implemented

• AMap.ofASet
• AList.try(At|Get)
• AMap.tryFind
• AMap.fold(Group|HalfGroup)
• AList.ofAVal
• ASet.sortWith
• AList.toASet
• ASet.ofAList
• AList.sort
• ASet.sort
• ASet.mapToMap
• AMap.keys
• ASet.sortBy
• AList.sortWith
• AList.sortBy

Problem

• when evaluating an AdaptiveObject, it should see one consistent value for each input cell
• consistency between multiple cells could then be achieved using tuples and maps on the tupled cell

Idea

• every transaction colors objects it visits with some ref<Transaction> and (when finished) simply sets the ref to null in O(1)
• every evaluation colors objects it evaluates with ref<EvaluationId> and once finished sets the ref to empty in O(1)
• when visited by a new Transaction/Evaluation we prune all dead colors

Pro

• that way we could identify objects where evaluation collides with a (not yet finished) Transaction and vice-versa.

Con

• many leaking refs in objects (each object needs to hold many of those) and we can only clean them up when visiting the object again
• what to do on collision? since the transaction may have marked a graph partially simply blocking it won't suffice. The only real alternative is to let the transaction continue and retry evaluation when it finished, potentially causing starvation on the evaluation-side.

missing validation for choose/filter/concat/fold/etc.

How should we name things consistently?

I personally like the lower-case names like (aset, amap, etc.) and would go for that one, but I'm open to other ideas.

type aref<'a> = //...
module ARef = // ...

The obvious choice would be AdaptiveRef, but the name is quite long and doesn't really roll off the tongue.

type AdaptiveRef<'a> = // ...
module AdaptiveRef = // ...

Maybe something with Incremental/Inc in it??

type IncRef<'a> = // ...
module IncRef = // ...

Any suggestions?

any way to avoid disposable readers?
if not ensure that disposal gets rid of all unreferenced inputs.

I wanted to try the library and immediately found that the NuGet package has an constraint < 4.7.0 on FSharp.Core. I assumed that wasn't intentional, so I installed it by forcing the FSharp.Core version as == 4.7 on Paket, and the API seems to work fine. I guess the upper bound should be lifted?

maybe migrate from Aardvark.Base or come up with a new one (real numbers like in aardvark.web)

IndexList has IndexOf by Index operation:

/// Tries to find the position for the given Index or -1 if the Index does not exist. O(N)
member x.IndexOf(index : Index) =
    MapExt.tryIndexOf index content |> Option.defaultValue -1

Is its complexity really O(N)? I looked into the implementation and it seems to be a search in a binary tree, therefore having the O(log(N)) complexity, isn't it?

AbstractReader currently takes the monoid operations. But it only needs tempty. Let's minimize this

mapUse<'a, 'b when 'b :> IDisposable> (mapping : 'a -> 'b) (set : aset<'a>) : aset<'b>
mapUse<'a,'b when 'b : equality and 'b :> IDisposable> (mapping : 'a -> 'b) (list : alist<'a>)

Please consider restoring this functionality. Would this be also useful for AVal?

At the moment it is not possible to implement a derived AdaptiveObject in C# since the inline type extension EvaluateAlways cannot be used from a C# environment.

We have discussed the possibility of adding a wrapper base class for C# that exposes this method. Please consider this extension.

I (temporarily) put the PreCompiler code here since it's a lot easier to handle for the moment...
Nonetheless we should think about moving it to its own repo once it's done.

The current compilation-scheme looks like that:

This basically reproduces the functionality of Aardvark.Compiler.DomainTypes which turned out to be quite useful in practice. Nonetheless It would be great to have some comments on that.
Any ideas, old problems that should be solved or other suggestions?
@ThomasOrtner @haraldsteinlechner @aszabo314 @dsyme

Oh and by the way: any naming suggestions? I think Adaptor would be nice, but it's not really self-explanatory...

migrate from Aardvark.Base

Looking at these kind of type definitions:

[<Interface>]
type AdaptiveHashSet<'T> =
    /// is the set constant?
    abstract member IsConstant : bool

    /// the current content of the set as aval.
    abstract member Content : aval<HashSet<'T>>
    
    /// gets a new reader to the set.
    abstract member GetReader : unit -> IHashSetReader<'T>

I'm tempted to propose that we merge AdaptiveMap.fs and ChangeableMap.fs and hide the abstract members behind a signature. This would mean that no one can directly implement these interfaces - but it would also give us a lot of flexibility to change the implementations going forward - adding new members and so on. We can still provide a way to implement the interfaces by providing three function definitions.

Note that F# currently doesn't allow internal abstract members - you can only achieve this by hiding the whole type definition like this:

type AdaptiveHashMap<'Key,'Value> 

type amap<'Key,'Value> = AdaptiveHashMap<'Key,'Value>

I found myself in need of an AList.chooseAdaptive, e,g,

val chooseAdaptive: ('T -> aval<'U option>) -> alist<'T> -> alist<'U>

I expect the same is true for existsAdaptive, mapAdaptive and so on. Some of these may already exist under different names.

check if Object can be removed from exn

AdaptiveObject contains lots of things for historical reasons. Get rid of useless things.

not implemented yet

missing tests for

• amap
• Index
• IndexList
• IndexListDelta

let collect (mapping : 'a -> #seq<'b>) (set : aset<'a>)

We might want to consider restoring this functionality.

At the moment this can be implemented quite easily manually and also always use the best ASet creator (ofSeq/ofArray/ofList). Would a special implementation allow any efficiency improvements or would it just be a convenience?