Open paluh opened 3 years ago
Sure!
After a discussion on purescript-beginners channel it seems that this can be implemented by coercing into VariantRep
and back (unvariant
is not an option and this is not a folding like in the case of the Record
). Could you please tell me if you think that this can be acceptable implementation?
I'm not very familiar with VariantRep, but I don't think it should be a problem.
I was talking bullshit. Prefixing Variant
is also a fold (as suggested by Nate).
I've this prototype (not ready for a PR) but I wonder if this polymorphic row in the result is a real problem:
I think that we should get "closed row" back. What is your opinion?
Why should the polymorphic row be a problem? Do you have a case where this breaks? At a quick glance it looks pretty similar to the record solution
Why should the polymorphic row be a problem? Do you have a case where this breaks?
I think that "opening" a Row of a Variant
/ Record
can be seen as problem (the input row are closed) because we don't have an easy way to apply another generic transformation to it - like in this example we need a type annotation:
https://github.com/paluh/purescript-record-prefix/blob/master/src/Data/Variant/Prefix.purs#L50
Mm right, this is pretty annoying.
I just checked and it's not the case for the record implementation which has a an additional Row.Lacks
constraint. I'm not sure if this would help, but have you tried using it?
I had Lacks
constraint in my initial version. It doesn't change the output unfortunately... It seems that I have to calculate the output Row
type and inject values into the final variant. I'm afraid that it is going to complicate the implementation a bit ;-)
I could do this with typelevel-eval
easily... but I'm not sure if we want to bring such a dependency here. Could you please tell me what do you think?
So this is a version which uses typeleve-eval to precompute resulting row type:
As you can see it doesn't require intermediate annotations but is a bit more complicated - we use here folding on the type level:
ToRow <<< FoldrWithIndex (UnprefixStep pre) NilExpr <<< FromRow
I should probably make clear distinction between these two folds strategies (one purely on type level using typlevel-eval and second on the value level using heterogeneous) used by the module by commenting them properly.
I think it's a good approach. Despite what's written in the readme, this library never had any pretence of being fast or efficient (which could be done via FFI I guess), so I don't see any problem in adding an extra dependency.
I wonder If this library should change name after this merge
I think it's a good approach.
Cool! I'm going to rebase all these commits so they form a single one so I can provide a nice PR.
Despite what's written in the readme, this library never had any pretence of being fast or efficient (which could be done via FFI I guess), so I don't see any problem in adding an extra dependency.
I don't think that this typelevel computation is going to impact runtime performance. I'm not sure how JS looks like exactly regarding the hfoldWithIndex
but it folds into a single Variant.case_ # Variant.on ... # Variant.on ....
expression so I think it will be OK ;-)
I wonder If this library should change name after this merge
prefix-rows
sounds too "type-level" I think... prefix
alone sounds to abstract... "Naming is the hardest problem..." :-P
Great and thank you! :) Could you also please add a couple of simple tests and expand the readme?
prefix-row
is too "type-level", but is also the only correct one. Maybe something like `label-prefix"
Could you also please add a couple of simple tests and expand the readme?
Yeah, sure. I want to add support for VariantF
, add tests and extend the README as well. We can also try make the README a part of the test suite like it is done in the case of the purescript-cookbook or in my other libs (like here or here). Could you please tell me what do you think about this idea?
Maybe something like `label-prefix"
label-prefix
or prefix-label
both sounds good I think.
Would you like prefixing helpers for
Variant
andVariantF
to this library? I have working prototype forVariant
so I can provide a PR.