combinator: add S.T

[davidchambers]

In preparation for the upcoming v0.11.0 release I'm updating a rather large project to run against sanctuary-js/sanctuary#master. Now that we're embracing curried functions (#182), combinators seem more useful than ever (and T seems more useful to me than A).

[Avaq]

😃 👍 I was thinking about this addition to Sanctuary yesterday! T is very useful indeed. LGTM!

[rjmk]

Outside of combinators, are we generally for or against providing 2 versions of a function that differ only by an application of flip/C. My guess is against, but I thought I'd double check

[davidchambers]

Outside of combinators, are we generally for or against providing 2 versions of a function that differ only by an application of flip/C.

Against, in general. There are functions—R.contains comes to mind—which I frequently find myself using "flipped". It seems to me we should either support placeholders or provide flipped versions of such functions. I favour the former, though my preference is not strong.

[rjmk]

Any interest in sanctuary-js having some 'extension' libraries? I would personally love a core Sanctuary that was as tiny as possible, with some extra libraries that leveraged the core functions to provide helper functions (in which category I would place both R.contains and the flipped version)

[davidchambers]

Any interest in sanctuary-js having some 'extension' libraries?

Along the lines of sanctuary-int, perhaps?

In general I'm in favour of modularity, but in JavaScript modularity poses some problems. Were we to break Sanctuary into ten small modules, say, one would likely need to import several of these modules in any given file. This is not a problem in and of itself, but what would one name these variables? Having everything attached to S is convenient.

One could, though, provide a pure method for extensibility along these lines:

const sanctuary = require('sanctuary');

const S = sanctuary.create({
  checkTypes: true,
  env: sanctuary.env,
  extensions: [
    require('sanctuary-foo'),
    require('sanctuary-bar'),
    require('sanctuary-baz'),
  ],
});

This would impose a uniqueness constraint on the names of the exported properties of sanctuary, sanctuary-foo, sanctuary-bar, and sanctuary-baz. This is effectively the case already, though it's currently impossible for a naming collision to go unnoticed.

What do you imagine the "tiny core" would include? How might the remaining functions be divided? I imagine sanctuary-types and sanctuary-type-classes are two pieces of the puzzle.

[gilligan]

It has already been merged, but I find the name T somewhat irritating since I am so used to R.T -- but maybe that is just me.

[rjmk]

Yes, that sort of thing.

Starting with your last question

What do you imagine the "tiny core" would include?

Well, casting my over the functions, I would guess

• I, K, A, C, B, S
• flip and the lifts (Good band name)
• pipe
• The Maybe and Either stuff -- or would that live in sanctuary-types?
• All those fns for working with native types that use Maybe or Either
• Array methods
• I haven't thought about using the Alternative, Logic or Classify sections so may be missing stuff there

I think that might be a sensible subset?

This is not a problem in and of itself, but what would one name these variables?

Yes, merging 'function bags' can be a bit of a pain in JS, it's true. If Sanctuary (or, under my scheme, perhaps one of its 'extensions') had a merge and/or mergeAll that could be used.

This would impose a uniqueness constraint on the names of the exported properties of sanctuary, sanctuary-foo, sanctuary-bar, and sanctuary-baz. This is effectively the case already, though it's currently impossible for a naming collision to go unnoticed.

I think ideally some 'Sanctuary extensions' would be developed outside of the aegis of sanctuary-js. People would be free to use whatever method suited them for avoiding name collisions. If it were me I would probably do something like:

var S = merge
  ( require('sanctuary')
  , { string: require('sanctuary-strings')
    , list: require('sanctuary-list')
    , object: require('rjmks-heterodox-sanctuary-objects')
    ...
    }
  )

and then S.string.words('split me up!')

(Though actually I might just destructure the various packages with disambiguation as necessary)

[Avaq]

Here's my ideas on extensions: sanctuary-js/sanctuary-def#74

[davidchambers]

I find the name T somewhat irritating since I am so used to R.T

I'd like to deprecate R.T and R.F. R.always(true) and R.always(false) are descriptive and fairly terse, and these functions are not used commonly enough to justify even terser equivalents. In Sanctuary, of course, we have S.K(true).

The Maybe and Either stuff -- or would that live in sanctuary-types?

I imagine the implementations of S.Maybe and S.Either (and their accompanying type definitions) living in that repository, yes.

Here's my ideas on extensions: sanctuary-js/sanctuary-def#74

Thanks for opening that issue, Aldwin. The thread of a merged pull request (for a humble combinator) is not the ideal forum for such an important discussion.