Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 14 19:14
    Teomik129 starred sanctuary-js/sanctuary
  • May 13 04:14
    GMkonan starred sanctuary-js/sanctuary
  • May 11 22:23
    walkermalling starred sanctuary-js/sanctuary
  • May 08 11:09
  • May 02 13:42
    liufei starred sanctuary-js/sanctuary
  • May 02 11:03
    radeee13 starred sanctuary-js/sanctuary
  • May 02 09:13
    cloud2303 starred sanctuary-js/sanctuary
  • Apr 29 16:53
    dotnetCarpenter closed #102
  • Apr 29 16:53
    dotnetCarpenter commented #102
  • Apr 29 16:30
    dotnetCarpenter commented #50
  • Apr 28 16:54
    dotnetCarpenter commented #50
  • Apr 28 16:18
    dotnetCarpenter commented #50
  • Apr 28 16:00
    dotnetCarpenter commented #50
  • Apr 28 15:07
    dotnetCarpenter commented #50
  • Apr 28 11:44
    Avaq commented #102
  • Apr 28 11:39
    Avaq commented #50
  • Apr 28 11:38
    Avaq commented #50
  • Apr 28 11:14
    dotnetCarpenter commented #50
  • Apr 28 10:59
    Avaq commented #50
  • Apr 28 10:24
    dotnetCarpenter edited #50
Scott Christopher
@scott-christopher
and I have my suspicions that the ChainRec instance for Array can be used to implement a relatively efficient parser ... but that's an idea to explore another day :D
David Chambers
@davidchambers
:)
Irakli Safareli
@safareli
@scott-christopher good catch!
David Chambers
@davidchambers
Welcome to the sanctuary-js team, @safareli. :tada:
Irakli Safareli
@safareli
Thanks for having me 🍓
David Chambers
@davidchambers
Excellent emoji choice.
David Chambers
@davidchambers
I just created a sanctuary tag on Stack Overflow. You may like to subscribe to it. Also, I posted a question: Custom equality semantics for Immutable.js data structures. I'd love to be able to use maps and sets when working with Sanctuary, but for various reasons neither the native types nor the Immutable.js equivalents are currently suitable.
Keith Alexander
@kwijibo
:point_up: September 17, 2016 1:41 PM @scott-christopher are there (more specific) common use cases you could name, to explain it a bit more?
Irakli Safareli
@safareli
other use case is with Free monad, you can do monadic recursion when you are working with Free and as long as your target monad to which you are folding to is ChainRec it will not blow stack
here is test case from Free
Keith Alexander
@kwijibo
Nice
Irakli Safareli
@safareli
for a bit context the Free was not stack safe and for it to be stack safe target monds should have some common interface so that it could depend on it. now we have ChainRec, in purescript it's MonadRec, and Free and other structures could use it for doing safe monadic recursion. if you are interested in that here is a paper about that https://github.com/functorial/stack-safety-for-free/blob/gh-pages/index.markdown
Irakli Safareli
@safareli
Also resently I saw rpominov/static-land#26, I don't quite understand what this runGenerator actually does but using ChainRec it's now stacksafe :D
Keith Alexander
@kwijibo
@safareli interesing thanks
Pavel Meledin
@btbvoy
Hi everyone. Could anybody share a link to open source project which widely uses sanctuary ? I'm interested to see how exactly communication with outside world (like DB, external services) is implemented also interested in the way how error handling is done. Would be awesome if such a project is already used in real production with nodejs for instance. Thanks in advance
David Chambers
@davidchambers
The generate script which builds the Sanctuary website is one example of handling errors with the Either type, @btbvoy. For DB interactions one could use a library such as Fluture. The only large project I'm aware of that makes heavy use of Sanctuary is not open source, but reading this blog post will give you an idea of how I used Ramda and Sanctuary in that project.
Brad Compton (he/him)
@Bradcomp
Is Sanctuary moving towards the prefaced method names per the new FL spec?
David Chambers
@davidchambers
Yes it is, @Bradcomp. I was working on updating #216 last night. I got stuck on the laws after changing sequence to traverse. I think I'll .skip those tests and ask @scott-christopher for assistance. One question is whether Maybe#fantasy-land/map should replace Maybe#map or whether we should have both. What's your opinion on this, Brad?
Pavel Meledin
@btbvoy
@davidchambers thanks David :-)
Irakli Safareli
@safareli
I think as a public API we should also have normal non namespaced functions. so if you have Santuary/Maybe object you could call map on it. But depend on FP interface when Santuary functions are taking some Structure as an argument
David Chambers
@davidchambers
Even though the pull request will also introduce S.map?
Irakli Safareli
@safareli
so if some libraries is taking a object which conforms to FP.Functor interface then the lib will use fantasy-land/map
but if someone is creating that functor object in it's codebase and there is no way for it to receive other one it could use the normal map i think
David Chambers
@davidchambers
That seems reasonable, but I really want to promote the use of functions and function composition rather than methods and method chaining.
Irakli Safareli
@safareli
yes but some prefer calling methods and i think we should make it usable to as much developers as we can
David Chambers
@davidchambers
One thing that is confusing about the current documentation is it doesn't make it clear that the map method only exists for compatibility with R.map – users aren't expected to invoke it directly.
Irakli Safareli
@safareli
and calling method which is not mutation anything and returns other object is basically like calling a pure function with a fancy dot syntax.
David Chambers
@davidchambers
Okay. So long as the description of Maybe#map links to the documentation for S.map I think I can get behind including the aliases.
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.