Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Pavel Meledin
@btbvoy
@davidchambers What is overhead of using sanctuary instead of "plain" JS in terms of performance ? How well v8 optimize Sanctuary internals?
Irakli Safareli
@safareli
And also namespacing those methods I think is good because for some object we might want to use word map as name of it's property where we are storing some Map object and it's not a function. but as FL methods are namespaced we could have the Map object live in ['map'] and Functor map in ['fantasy-land/map']. so libs which require FL Functor will not care about our Map object. or for example if we want to create more user friendly object maybe we want to call transform to map and andThen to chain. so basically i see FL namespaced methods as the way for libs to interact with each other. but for user who is using some specific implementation of maybe I think there should also be normal non namespaced methods
David Chambers
@davidchambers
Right now the performance with type checking enabled is very bad, @btbvoy. The performance with type checking disabled should be similar to that of Ramda.
Pavel Meledin
@btbvoy
got it, thanks for quick reply :-). Just wondering what could be improved in case of type checking enabled ?
David Chambers
@davidchambers
The main source of slowness is polymorphism. Functions with types such as Integer -> String -> Maybe Integer are fine; it's functions with types such as a -> a which are problematic. This means S.I is one of the slow functions when type checking is enabled!
Hans Krutzer
@hkrutzer
Is there something like https://github.com/megawac/babel-plugin-ramda for Sanctuary?
ok looking at the uglified code maybe it's not necessary
David Chambers
@davidchambers
I don't think so, @hkrutzer. You might like to :+1: #246, though.
Hans Krutzer
@hkrutzer
cheers :) it'll be a while before I can build with tree shaking but at least it'll be possible
Pavel Meledin
@btbvoy
@davidchambers thanks for explanation :-)
Pavel Meledin
@btbvoy
@davidchambers Could you please elaborate also about sanctuary-js's Either and ramda-fantasy's Either. What's the rule one should follow in order to understand which one to pick :-) As I understand sanctuary-js was created first but ramda-fantasy just recently appeared. Are these libraries competitors ? :-)
David Chambers
@davidchambers
I think RF predates Sanctuary, actually. ramda/ramda-fantasy#105 should shed some light on the differences.
RF started as a laboratory for experimentation, and in many respects this is still the case. Sanctuary started as a collection of safe versions of unsafe Ramda functions. The libraries do overlap, but not significantly. Sanctuary overlaps more with Ramda itself.
If you want to use Either or Maybe, Sanctuary should serve you well. If you want Future/Task, I suggest Fluture. If you want IO, Identity, Reader, State, or Tuple, RF should be able to provide it for you.
Pavel Meledin
@btbvoy
Thanks :-) That's the picture which I wanted to see. I'd note that it's a pity that there is no solid integration between all of these libs. That looks like all a common problem for FP approaches in almost all languages without build-in FP support.
David Chambers
@davidchambers
I don't agree with that statement, @btbvoy. The various Fantasy Land -compatible libraries play together nicely. It's great that since Fluture exists, for example, Sanctuary needn't provide its own Future type. Algebraic data types à la carte!
Pavel Meledin
@btbvoy
might be you are right :-) anyway thanks for taking time to answer for questions. Appreciate it
David Chambers
@davidchambers
You're welcome. Keep 'em coming!
Irakli Safareli
@safareli
I have written my point on FL namespaced methods vs non namespaced at origamitower/folktale#39 what you think on that? /cc @davidchambers
David Chambers
@davidchambers
Nice one. I certainly think Folktale should keep the unprefixed method names, since Folktale is closer to Scala than Haskell so using it in an OO manner feels quite natural. I'm not convinced this is right for Sanctuary, though. I'll create a Sanctuary issue a bit later (I'm currently reworking the property tests for FL methods and finally making good progress).
Irakli Safareli
@safareli
OK, lets discuss it in that issue then
Brad Compton (he/him)
@Bradcomp
@davidchambers I almost never use method chaining, preferring instead to use the functions in Ramda. My only concerns are in regards to compatibility. It would be nice to have adoption of the FL namespacing in Ramda and Sanctuary (and others of course) be fairly simultaneous, or else have the old names deprecated but maintained until Ramda gets updated.
David Chambers
@davidchambers
@Bradcomp, your point about migration is a good one. Even if we decide we don't want the method aliases it might be a good idea to keep them around for a while. They could even be undocumented during the transition.
Brad Compton (he/him)
@Bradcomp
Obviously one can always stay on whatever version they have that is working, but it's nice to be able to keep things up to date.
David Chambers
@davidchambers
I agree. It's no fun being stuck on an old version of a package.
Brad Compton (he/him)
@Bradcomp
Looking at #216 now. I like that Sanctuary is going to provide versions of all the FL functions. This would make the backwards compatibility less of an issue, but I still think keeping the deprecated functions for some period would be a good idea.
David Chambers
@davidchambers
Yep, I agree.
David Chambers
@davidchambers
I just removed the ramda dependency! v0.12.0 will depend on sanctuary-def and sanctuary-type-classes but not on ramda.
Irakli Safareli
@safareli
sweet
Brad Compton (he/him)
@Bradcomp
Awesome!

Is it possible using Sanctuary-def to create a TypeRef from a type? For instance

S.get($.FiniteNumber, 'a', {a: Infinity});

Obviously this code doesn't work as it stands because $.FiniteNumber is a type and not a TypeRef.

David Chambers
@davidchambers
Check out #191, @Bradcomp. It's currently blocked, but I'm bringing together the many loose ends so @Avaq will soon be able to update the pull request. We'll then be able to write:
S.get($.FiniteNumber._test, 'a', {a: Infinity});
Brad Compton (he/him)
@Bradcomp
Great! The future for Sanctuary is looking bright!
David Chambers
@davidchambers
It has momentum at the moment. I'm really looking forward to the next release. I'm working on it full-time at the moment, but these things always take longer than expected. I know I'm getting close, though, because I'm working on documentation, doctests, and code style. :)
Brad Compton (he/him)
@Bradcomp
In the meantime, I suppose a getWhere function that will mimic the future get function.
Stefano Vozza
@svozza
@davidchambers wow. nice work!
David Chambers
@davidchambers
For now you could use R.filter after the fact, @Bradcomp:
const R = require('ramda');
const S = require('sanctuary');
const $ = require('sanctuary-def');

//    f :: Any -> Maybe FiniteNumber
const f = S.compose(R.filter($.FiniteNumber._test), S.get(Number, 'a'));

f({a: 42});
// => Just(42)

f({a: Infinity});
// => Nothing()
Thanks, @svozza! Nice to hear from you. :)
Stefano Vozza
@svozza
yeah sorry i've been off the radar for a good while. i have been lurking on the recent PRs though
looking good!
David Chambers
@davidchambers
I didn't mean to make you feel guilty. I'm just pleased to see you around.
Stefano Vozza
@svozza
:D
do we still want to do that mergeStrMaps function? i'm guess it needs a serious rebase
David Chambers
@davidchambers
I think sanctuary-type-classes defines Object#concat. Let me check.
Yes, it does:
        //  Object#concat :: StrMap a ~> StrMap a
        'fantasy-land/concat': function(strMap) {
          var result = {};
          for (var k in this) if (has(k, this)) result[k] = this[k];
          for (k in strMap) if (has(k, strMap)) result[k] = strMap[k];
          return result;
        },
Brad Compton (he/him)
@Bradcomp
Thanks for the help @davidchambers!
David Chambers
@davidchambers
You're welcome. :)
Stefano Vozza
@svozza
ah yes, i like it
David Chambers
@davidchambers
Here you go, @svozza:
const Z = require('sanctuary-type-classes');

Z.concat({x: 1, y: 1}, {y: 2, z: 2});
// => {x: 1, y: 2, z: 2}
Stefano Vozza
@svozza
very nice