Observations

From:

math-mommy.livejournal.com

Ð¢Ð°Ð¼ ÐµÑÐµ Ð³ÑÐ°ÑÐ¸ÐºÐ° Ð·Ð°Ð¼ÐµÑÐ°ÑÐµÐ»ÑÐ½Ð°Ñ.

From:

ÐÐ°, Ñ ÑÑÐ¾-ÑÐ¾ ÑÐ¶Ðµ Ð¿Ð¾Ð¿ÑÐ¾Ð±Ð¾Ð²Ð°Ð».

From:

vissarion.livejournal.com

From:

4da.livejournal.com

> Instead, developers should seriously consider a completely fundamentalist option as well: embrace pure lazy functional programming with all effects explicitly surfaced in the type system using monads.

ÐÐµ Ð¿Ð¾Ð½ÑÐ» Ð¿Ð¾ÑÐµÐ¼Ñ Ð¾Ð±ÑÐ·Ð°ÑÐµÐ»ÑÐ½Ð¾ Lazy Ð¸ Ð¿Ð¾ÑÐµÐ¼Ñ ÑÑÑÐµÐºÑÑ Ð¾Ð±ÑÐ·Ð°ÑÐµÐ»ÑÐ½Ð¾ Ð´Ð¾Ð»Ð¶Ð½Ñ Ð¾Ð¿Ð¸ÑÑÐ²Ð°ÑÑÑÑ Ð² Ð¼Ð°Ð½Ð°ÑÐºÐ°Ñ.

ÐÐ¾ÑÐ¾Ð¶Ðµ Ð½Ð° ÐºÐ°ÐºÐ¾Ðµ-ÑÐ¾ ÑÐ°Ð½Ð±Ð¾Ð¹ÑÑÐ²Ð¾

Edited Date: 2016-08-17 09:37 pm (UTC)

From:

From:

4da.livejournal.com

https://eb.host.cs.st-andrews.ac.uk/drafts/effects.pdf

One often cited benefit of pure functional programming is that pure code is easier to test and reason about, both formally and informally.
However, real programs have side-effects including state management, exceptions and interactions with the outside world.
Haskell solves this problem using monads to capture details of possibly side-effecting computations â it provides monads for capturing State, I/O, exceptions, non-determinism, libraries for practical purposes such as CGI and parsing, and many others, as well as monad transformers for combining multiple effects.

Unfortunately, useful as monads are, they do not compose very well. Monad transformers can quickly become unwieldy when there are lots of effects to manage, leading to a temptation in larger programs to combine everything into one coarse-grained state and exception monad. In this paper I describe an alternative approach based on handling algebraic effects, implemented in the IDRIS programming language. I show how to describe side effecting computations, how to write programs which compose multiple fine-grained effects, and how, using dependent types, we can use
this approach to reason about states in effectful programs.

Edited Date: 2016-08-17 10:07 pm (UTC)

From:

It's a fact of life that they don't compose, not the defect of monads. Try to compare list of sets and set of lists, for instance.

From:

> Unfortunately, useful as monads are, they do not compose very well.

Monads do not, but effects perfectly do as soon as you get effect rows.

From:

> monad transformers for combining multiple effects.

This is a Haskell problem, not the fundamental one.

doFiles::forall e. Eff (fs::FS, console::CONSOLE|e) Unit
doHttp::forall e. Eff (http::HTTP, console::CONSOLE|e) Unit

doStuff::forall e. Eff (fs::FS, console::CONSOLE, http::HTTP|e) Unit
doFiles <<< doHTTP

You can also handle effect, which means you remove the effect from the row and once you get to the Eff () you can runPure and transform the effectful computation into the pure one. Bingo.

Edited Date: 2016-08-18 06:42 am (UTC)

From:

huzhepidarasa.livejournal.com

Correct me if I'm wrong but Eff looks exactly like the IO monad. Naturally it composes with itself. But it's too coarse.

Edited Date: 2016-08-18 01:32 pm (UTC)

From:

pbl.livejournal.com

More like IO with refinement on top of it, innit? But there are other encodings of effects that do not involve monads and, according to rumour, are composable (for some values thereof). I believe F* featured something like that, they even had Div or somesuch for divergence.

From:

huzhepidarasa.livejournal.com

Yes, parameterized by list (set?) of effects that occurred. I think this should be possible in Haskell too, with some existing or plausible extension. Need to think about it.

From:

pbl.livejournal.com

DataKinds and friends should be enough methinks, at least for a rough approximation of this. Is type inference for this decidable, though? Type checking should be.

From:

Yes, it does. But it is parametrized with either an open or closed row of effects and thus Eff (console::CONSOLE) doesn't compose with Eff (fs::FS). By opening and closing the row and adding and removing effects I can control the composability. This is also not fine-grained enough (esp. with the "inflation of effects" when everybody and their grandmother invents new type of effect which implicitly may include others) but it's much, MUCH, more fine-grained than IO() which is just "some IO" who knows what it does.

From:

Oh. Puzzle solved. Thanks!

From:

tridecahedron.livejournal.com

From:

no more turtles (from livejournal.com)

ÑÐ¿Ð°ÑÐ¸Ð±Ð¾, Ð¾ÑÐµÐ½Ñ Ð¿Ð¾Ð·Ð½Ð°Ð²Ð°ÑÐµÐ»ÑÐ½Ð¾.

From:

From:

From:

From:

From:

From:

From:

From:

Edited Date: 2016-08-18 12:33 am (UTC)

From:

From:

From:

From:

ÐÑÑÐ³Ð¾Ð¹ ÐºÐ¾Ð½ÐµÑÐ½Ð¾, Ð¾Ð´Ð¸Ð½ Scott (https://en.wikipedia.org/wiki/Scott_Meyers), ÑÑÐ¾ÑÐ¾Ð¹ Erik (https://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientist)).

From:

pbl.livejournal.com

Ð Ð²ÐµÐ´Ñ ÐµÑÑÑ ÑÑÐµÑÐ¸Ð¹ (https://en.wikipedia.org/wiki/Bertrand_Meyer).

From:

ÑÑÐ¾Ñ Ð¶Ð°Ð´Ð¸Ð½Ð°

From:

From:

thedeemon.livejournal.com

ÐÐ½ ÑÑÑÑ Ð»Ð¸ Ð½Ðµ Ð¾ÑÐµÑ Ð²ÑÐµÐ³Ð¾ LINQ.

"His 1992 dissertation at the University of Nijmegen offered a mathematical justification for what would later become known as Language Integrated Query (LINQ), the important .NET technology that smoothes out differences in data forms by identifying a common set of operations that work across all data. Meijer's acclaimed work on lightweight code generation, the C# language extension C-Omega, and C# 3.0 and Visual Basic 9, has helped bridge object-oriented, relational, and hierarchical data typesâthe three major contemporary data models that prevail in the industry today."
https://www.microsoft.com/about/technicalrecognition/erik-meijer.aspx

From:

From:

From: