Change type synonyms (e.g. Elem, LookUp and Zip) to use data-definitions

[gspia]

Is the use of type required in any of the Elem, LookUp or Zip functions?

In hindsight they should probably have been data.

Do they behave behave similarly with respect to computations? E.g. is there less stuck computations with the data-definition?

The main difference is that data can be partially applied. The other difference is that synonyms are fragile and may lead to more confusing error messages (but that is pure speculation on my part).

This could be elaborated a bit more already in readme.md of the repo: in a way, to be able to partially apply type-level functions changes the game a bit and makes it a way more flexible for the user.

It might be worth to change the Elem, LookUp or Zip functions to use data. In addition to partial applicability, the data-definitions work nicely as a type-level function signatures documenting the functions.

List of type synonyms at List.hs

• Elem
• LookUp
• Zip

The type synonyms at other modules:

• LiftM at Combinators.hs
• (-->) at Utils.hs
• Is at Utils.hs
• Any at Utils.hs
• Else at Utils.hs
• Otherwise at Bool.hs

LiftM is a "direct synonym" of (=<<) which, in turn, uses data. Maybe ok this way?

The functions at Utils.hs operate on Match which is a bit different. The Match has term level constructors which are tied to type-level functions. Is the use of type required here or, could data-definitions help here? What ever the answer is, I'd would much appreciate if the reasoning was part of the comments of these functions.

Any chances of documenting the interplay between the term-level and type-level things in here used for Match???? My intuition says that the term level constructors are used to avoid the potential overlapping instances since now the Eval can select more easily, which to use. But is this so?

The Otherwise is for deprecated Guard construct. Maybe ok this way?

[Lysxia]

Let's do it for Elem, Lookup and Zip. The rest can stay as it is.

The functions at Utils.hs operate on Match which is a bit different. The Match has term level constructors which are tied to type-level functions. Is the use of type required here or, could data-definitions help here? What ever the answer is, I'd would much appreciate if the reasoning was part of the comments of these functions.

Anything you can do with a data kind (like Match), you can also do using an "fcf-like" data declaration for each constructor.

If you use a data kind:

• the constructors need to be prefixed with a quote because they're in a different namespace, but type synonyms can be used as they are here to not have to use that quote;

• compared to the other style, the main trade-off is that (this is a cons) Match is closed, but I'm not sure it's worth to make it extensible, and that (this is a pro) Match is different from every other type, so you get better type errors if you mix a Match and an Exp for example.

[gspia]

I realized I don't know, how to make a second PR at the same time and if there will be possibly some merge conflicts. Is it ok, if I'll do those in the same PR that is still open?

[Lysxia]

You need to create a new branch, that allows you to make another independent PR.

[Lysxia]

Normally it looks like this (but you might have different names and might need to set up remotes first):

git status    # Check that there are no pending changes
git checkout origin/master    # Move to the original state of the repo (in this case, assuming "origin" is the name of the remote for the original repository)
git checkout -b my-new-branch    # Create "my-new-branch" (commonly named after the feature being worked on)

# Do the changes.
git commit ...

git push -u myremote my-new-branch   # Push to my own repository so I can make a PR

[gspia]

ok, hope it works; I changed the functions and added one sentence to readme.

[gspia]

hmm, maybe I should have put the close with hash num into the pr in the beginning. anyhow, I'll close this one as the pr is now merged and closed