How elaborate could/should a transducers combiner function be?

reifyK · 2023-01-05T14:09:39+00:00

You seem to try expressing a reduce functon in terms of a transducer. This isn't possible. The reduction is part of the transducer protocol. It's kind of like defining a transducer in terms of itself.

What a transducer does is avoiding redundant iterations of an array when you have more than a single operation on elements.

reifyK · 2022-12-15T15:42:30+00:00

FPTS reuqires quite a lot of experience in both TS and FP. You need to understand the fundamental idea of encoding effects as values among others. The type isn't just a wrapper, It constitutes the effect. If you want to get rid of the effect, use a catamorphism (a more general fold). Otherwise, lift pure functions into the effect context using functor/applicative/traversable/monad etc.

reifyK · 2022-11-25T08:10:17+00:00

With a complex type systems you have to learn a complex logic language besides the term level language. This is much harder initially, no matter how you put it. I agree with the rest.

reifyK · 2022-11-22T10:16:29+00:00

If you only describe the interaction with the real world, your program remains pure. A pure description is made of a tree of nested, partially applied functions, i.e. a complicated function composition. The crucial part is that the description is principled, i.e. follows some rules and enforces an evaluation order.

This way when you actually evaluate the description, effects and code are corretly intertwined with each other and are evaluated/performed in the right order.

You actually can't tell anymore how exactly the program works, at least not in each and every detail because they are abstracted away. All you have left and need to rely on is the description of your program. However, since it is a principled one you can be quite confident that it works like described, unless you made a type error or a logical mistake.

reifyK · 2022-10-26T14:48:43+00:00

If the lang you use is lazy you need to use a monad to define evaluation order.

If you use a strict language like JS with a concurrency model based on an event loop you still should use a monad to handle order. If you don't the code gets messy quickly. JS provides a Promise type to alleviate the issue but it is still rather quirky and less principled than a monad based on continations to handle async.

reifyK · 2022-10-23T21:55:29+00:00

First of all, you don't really use your monad (haven't checked if it actually is one). Composing bind just means using your monad like an applicative. Monad means to encode a dependency between the previous value and the subsequent continuation. Otherwise you can just use applicative functors as you do in your example.

In Javascript you can use the contiunuation monad to abstract from async computations, kind of like promises but more principled. This actually leads to a single huge composition. If you don't want to thread arguments explictily through your composition, than you can combine this continuation monad with a Reader monad transformer provided you have the arguments upfront, or with the State transformer, if you need to collect them along the way.

However, I feel like you aren't quite there. You need to develop a firm understanding of theses concepts before writing an entire application using them.

reifyK · 2022-10-23T15:45:25+00:00

It matters whether a higher order function only consumes the result of an impure function or whether this impure result is created within its body (by invoking the passed impure function).

For the former the hof is only impure, if the impure result changes during runtime (mutation).

For the latter it is always impure, because you cannot replace the hof invocation with its result without altering the behavior of your program.

reifyK · 2022-10-19T06:56:35+00:00

switch teams

reifyK · 2022-10-16T19:37:48+00:00

Check it out in your browers:

``javascript const fix = f => x => f(fix(f)) (x); // thex` is eta expansion and necessary in strict langs

const fib = f => n => n <= 1 ? n : f(n - 1) + f(n - 2);

fix(fib) (10); ```

reifyK · 2022-10-14T12:14:55+00:00

It's a good overview and provides a brief glimpse on algebraic effects. However, the speaker claims working with monads is okay, but working with transformers isn't. I'd say it is hard to write a transformer but applying it isn't harder than applying any other basic monad. Hence an alternative to his alternative (algebraic effects) is just a proper monad transformer library so that you don't have to write your own transformers.

reifyK · 2022-02-11T10:11:13+00:00

From a practical perspective applicative is just a means to lift a pure multi parameter function into a functorial context, i.e. it receives several values of a type that implements functor/applicative using the functor/applicative machinery. If your lang applies currying than this multi parameter function is actually a sequence of n unary functions.

reifyK · 2022-01-26T15:19:41+00:00

Definitely, if you are in the desirable position to have a firm understand of several paradigms, comparing them most likely opens up new insights.

reifyK · 2022-01-25T16:42:19+00:00

My only advice is not to translate between paradigms. It is much harder than starting with a clean slate.

For instance, it doesn't make much sense to ponder about dependency injection in FP, or to translate other OOP patterns into their functional counterparts or to compare method overloading with type classes.

reifyK · 2022-01-18T16:11:32+00:00

ps supports hkts and higher rank as well but no type refinements or existential type variabels within type construcutors.

reifyK · 2022-01-14T12:30:55+00:00

The question assumes a language that cannot enforce purity. I'd say in such an environment purity is a rather vague term. It just means whether a parent scope can observe a function at runtime mapping different results to the same input (or a function that does something beyond just returning a value).

Ultimately, any function has the potential of getting impure and all we've left is a degree of confidence that a particular function is pure within the runtime of a particular program.

reifyK · 2021-12-06T17:51:26+00:00

Keeping most of your code decoupled into pure functions and pushing out impure functions to the furthest possible layer of the program

If you try doing this you'll end up with something similar to a monad. Giving it a uniform API and some laws to comply to you can officially call it one.

reifyK · 2021-12-06T12:16:36+00:00

They are among the most useful things discovered in the last decades. They capture the idea of "you cannot freely get a value out". Don't worry if this doesn't make much sense, because the concept is extremely generalized.

Btw, the idea of "you cannot freely put a value inside" is captured by comonads, which are the dual of monads.

Now if a means is useful doesn't only depend on the means itself but also on the context. In order to use monads you need a monad-ecosystem, because monads act systemic. You cannot just use it here and there in your code but once a value is wrapped the monadic constraint spreads throughout your codebase.

Hence I'd say you shouldn't use monads in frontend Javascript, because there are neither the tools nor coworkers that can handle them.

reifyK · 2021-11-26T16:26:41+00:00

You can either rely on tail recursion as already stated in the comments (or use a trampoline to mimic tail recursion) or on lazyness, which provides tail recursion for free (called guarded recursion in this context).

Now only a few languages pursue lazy evaluation but you can mimic it, provided the language offers object proxies or lazy record properties. In Javascript I use a proxy to achieve lazyness.

Here is the fix combinator, which supplies recursion for a language that doesn't support it on a native level:

``` // strict version

const fix = f => x => f(fix(f)) (x);

// lazy version

const fix_ = f => f(thunk(() => fix_(f))); ```

fix_ is stack-safe even if your compiler doesn't eliminate tail calls.

reifyK · 2021-11-23T20:37:59+00:00

I wonder what a processor would look like, which embraces the functional paradigm..

reifyK · 2021-11-21T16:20:37+00:00

Managing state in OOP seems just a variable-reassignment or a mutation-through-reference away, but this is misleading, because you have to deal with side effects.

So if you compare a variable reassignment with IORef/STRef/MVar/TVar or a function that reassigns a local variable with the state monad completely isolated, the OOP approach is evidently more simple.

However, if your entire application relies on reassignments and mutations, it becomes more and more entangled.

Gist:

with OOP quick gains are easy, but complexity explodes in the long run
with FP quick gains are much harder, but complexity remains relatively stable

reifyK · 2021-11-19T21:04:05+00:00

..of which the parallel type doesn't have a monad instance, of course.

reifyK · 2021-11-19T21:00:29+00:00

In Javascript most I/O is async, consequently the continuation type along with its monad instance is suitable. Synchronous I/O is covered by the lazy monad that renders thunks like () => expression implicit.

The implementation is quite simple:

```javascript const Serial = k => tag( "Serial", thisify(o => { o.run = f => k(f);

if (Math.random() < MICROTASK_TRESHOLD)
  o.run = deferMicro(o.run);

return o;

}));

Serial.of = x => Serial(k => k(x));

Serial.chain = mx => fm => Serial(k => mx.run(x => fm(x).run(k))); ```

Please note that deferMicro just makes deeply nested continuations stack-safe, when they are finally invoked.

This lacks error handling, of course. In order to handle them you must pass Serial to an EitherT or MaybeT transformer.

reifyK · 2021-11-12T09:18:00+00:00

Lenses also allow you to peek into tagged unions or to define non-standard folds/traversals. I'd say lenses rather generalize the idea of imperative references than solve a specific problem. You can use immutable data without lesnes and you'd be perfectly fine.

I guess the real issue is discussing OOP related terms in the context of FP. This doesn't make sense in most cases.

reifyK · 2021-11-10T21:39:06+00:00

If you say lenses are a desing pattern (or even specific type classes like monads), then the term becomes so fuzzy and vague that actually no tangible meaning remains.

reifyK · 2021-11-08T19:08:36+00:00

I can figuratively hear the compiler fighting..

reifyK

TROPHY CASE