Exotic Programming Ideas, Part 3: Effect Systems • Hacker News Board

Re: Exotic Programming Ideas, Part 3: Effect Systems

#81

Post by AaronFriel » Mon, Nov 23, 2020, 8:08 PM UTC

dan-robertson wrote: post #48

AaronFriel wrote: post #43

Earlier quoted context omitted.

In a language and type system where the compiler infers all of the intermediate types, no. The way effect systems are typically added to languages without this level of type system is that the effect "fails". Like making a database call in Python without "with use_database(...):" that provides the database context. In those languages and with those effects, typically the default behavior is the effect's methods are a…

In every language I’ve used where types can be inferred, almost everyone writes down the types of their top level functions (or at least the functions that are exposed to clients). I don’t think this is really a good counter argument. The only ways I know of to reliably make this kind of change (or just about any nontrivial change) to an interface are increasing version numbers and letting clients suffer or having a…

In Haskell, it's the norm I think to do both: let the compiler infer the type and then add the inferred type to the code. This locks in compatibility.

Re: Exotic Programming Ideas, Part 3: Effect Systems

#82

Post by the_benno » Mon, Nov 23, 2020, 9:47 PM UTC

no_wizard wrote: post #50

lalaithion wrote: post #25

Earlier quoted context omitted.

The "what color is my function" problem is insurmountable in Javascript, because the runtime does not allow you to call an async function from a non-async one. However, most effects aren't like this. If you say "this function needs randomness" then you can create a pure PRNG and call the function with the PRNG providing randomness. If you say "this function needs logging" you can tell it to log to a string and parse/…

I think the reactive/rx/observer patter might be an acceptable solution around the what color is my function problem and it tends to be very popular with the functional programming wing of the JS community from what I’ve seen. Never understood why the browser didn’t ship a full access to something like an EventEmitter. Since you can dispatch events on window document DOM elements etc seems like being able to subscrib…

We built an effect system to enforce thread safety in Rx-based android apps a few years ago and published a paper on it at ASE, if you're interested: plv.colorado.edu/benno/ase18.pdf

the idea should generalize to whatever thread-pool/effect constraints you want to express, but the paper and implementation are focused on keeping UI effects on the android main thread.

Re: Exotic Programming Ideas, Part 3: Effect Systems

#83

Post by valenterry » Tue, Nov 24, 2020, 12:10 AM UTC

atennapel wrote: post #77

valenterry wrote: post #60

Earlier quoted context omitted.

It only implements the first part, not the more difficult one of composing different kind of effects. Scala has a library for the difficult part, but I don't think it was very successful: https://github.com/atnos-org/eff

There's also effekt for Scala: https://github.com/b-studios/scala-effekt though it does not seem to be maintained.

Yes - I think we can conclude that these techniques are both too complicated and not ergonomic enough as of now. If that does not work in Scala, it will work even less in Kotlin (where many people go when they find Scala too complex).

Re: Exotic Programming Ideas, Part 3: Effect Systems

#84

Post by patrec » Tue, Nov 24, 2020, 12:16 AM UTC

mpweiher wrote: post #31

akiselev wrote: post #29

Earlier quoted context omitted.

I think in theory they’re orthogonal but in practice the two go together. It’s all fine and dandy when you’ve got a restricted set of battle tested macros from a single library interacting in real world code, but it rapidly breaks down when you’ve got application authors of various skill sets all contributing their own macros because the dare not touch the ones that came before. Macro hygiene provides the equivalent…

And maybe Macros aren't the right kind of metaprogramming mechanism...

Why not?

Re: Exotic Programming Ideas, Part 3: Effect Systems

#85

Post by The_rationalist » Tue, Nov 24, 2020, 1:03 AM UTC

skybrian wrote: post #6

I expect that, as with any other type system extension, the more granular your effects are, the more likely you are to run into a “what color is my function” problem. If you have a public API that declares certain effects, you’re stuck with those unless you break backward compatibility. In a practical system, when writing a library and especially an abstract interface, you’d want to be careful what you promise and de…

Arrow Fx manage to be in a way colorless by obscoleting the need of Applicative, monad, etc https://arrow-kt.io/docs/fx/polymorphism/

Re: Exotic Programming Ideas, Part 3: Effect Systems

#86

Post by ledauphin » Tue, Nov 24, 2020, 1:18 AM UTC

jiggawatts wrote: post #68

skybrian wrote: post #6

I expect that, as with any other type system extension, the more granular your effects are, the more likely you are to run into a “what color is my function” problem. If you have a public API that declares certain effects, you’re stuck with those unless you break backward compatibility. In a practical system, when writing a library and especially an abstract interface, you’d want to be careful what you promise and de…

A lot of people are saying that function coloring is essentially an unsolved problem, and this is true . However, coloring of individual functions is not strictly speaking necessary. Think of the classic "zlib" style C libraries. Often they can't assume anything about the target platform, even basic stuff like memory allocation or I/O, because there's such a huge variety compilers, standard libraries, and restriction…

I think this (allowing some form of default for backwards compatibility) is a underrated point.

The common modern example being async functions, I would say it's actually quite surprising that JavaScript can't seem to provide the sane default behavior of "block this non-async function until the async function it calls returns a value".

The reason it can't is simply that it chooses not to provide a runtime with a true threading model - blocking a non-async function means literally blocking the entire runtime. But there's a possible world in which a "colored" (async) function could be used directly in a synchronous function using an escape hatch provided by the runtime, and then async functions would no longer be colored in the same way.

Re: Exotic Programming Ideas, Part 3: Effect Systems

#87

Post by The_rationalist » Tue, Nov 24, 2020, 1:19 AM UTC

klodolph wrote: post #46

There's some interesting research and ideas here, but it does seem like monads "ate everything for lunch" back in the late 1990s and 2000s when it comes to encoding effects, probably because monads are a bit more ergonomic (which seems like a weird thing to say, given the reputation monads have for being abstract nonsense). So effect systems didn't get as much research as everyone was interested in monads, and now th…

Arrow Fx make monads obscoletes, see the table https://arrow-kt.io/docs/fx/polymorphism/

Re: Exotic Programming Ideas, Part 3: Effect Systems

#88

Post by klodolph » Tue, Nov 24, 2020, 1:29 PM UTC

The_rationalist wrote: post #87

klodolph wrote: post #46

There's some interesting research and ideas here, but it does seem like monads "ate everything for lunch" back in the late 1990s and 2000s when it comes to encoding effects, probably because monads are a bit more ergonomic (which seems like a weird thing to say, given the reputation monads have for being abstract nonsense). So effect systems didn't get as much research as everyone was interested in monads, and now th…

Arrow Fx make monads obscoletes, see the table https://arrow-kt.io/docs/fx/polymorphism/

The page you linked to describes monads. It sounds like you’re not describing something that makes monads obsolete, but merely a DSL for Kotlin that makes it easier to use monads. Haskell doesn't need that, because monads are already part of the core syntax of the language.

Re: Exotic Programming Ideas, Part 3: Effect Systems

#89

Post by The_rationalist » Tue, Nov 24, 2020, 4:09 PM UTC

klodolph wrote: post #88

The_rationalist wrote: post #87

Earlier quoted context omitted.

Arrow Fx make monads obscoletes, see the table https://arrow-kt.io/docs/fx/polymorphism/

The page you linked to describes monads. It sounds like you’re not describing something that makes monads obsolete, but merely a DSL for Kotlin that makes it easier to use monads. Haskell doesn't need that, because monads are already part of the core syntax of the language.

You clearly didn't read the table that compare the verbosity and cognitive overhead of the Haskell way vs the fx way

Re: Exotic Programming Ideas, Part 3: Effect Systems

#90

Post by kazinator » Tue, Nov 24, 2020, 6:24 PM UTC

patrec wrote: post #74

kazinator wrote: post #64

Earlier quoted context omitted.

The hygiene problem has multiple aspects. One issue is that the user's code can bind identifiers which the macro expansion expects to be predefined. In a Lisp-1, we have to worry about this: (let ((list ...)) (mac ...)) ;; expansion of mac wants to call (list ...) Since the macro is not defining anything (its expansion is not introducing a binding for list), the ordinary gensym approach is not applicable. THe problem…

Again this is not fundamentally tied to whether functions and variables share a namespace, in clojure they do and yet your example above does not cause a problem. Watch: Let's start out with a function: user=> (defn enlist [x] (if (list? x) x (list x))) #'user/enlist user=> (let [list 1] (enlist list)) (1) Create a (pointless) equivalent macro: user=> (defmacro enlist' [x] `(let [y# ~x] (if (list? y#) y# (list y#))))…

I'd have to say that a ham-fisted read-time solution which throws important backquote identities under the bus is worse than just coding carefully under the threat of unhygienic macros, and worse than the complexity of hygienic macros.