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

Re: Exotic Programming Ideas, Part 3: Effect Systems

#91

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

skybrian wrote: post #42

shthrow wrote: post #33

Earlier quoted context omitted.

No, think of it like checked exceptions, you only need to handle the effect _at most once_ before it reaches the top (it's up to you to let it keep getting passed up or handle it immediately), otherwise the compiler will automatically infer the effect types in the layers between.

Okay, so type inference is the vital feature here. It can help in a closed code base. In an open code base, you could inadvertently change a public API, breaking callers that are unknown to you, if the type signature of something public is inferred.

Correct, but that is the same for any kind public API though. However that is slowly starting to change with statically typed APIs like GraphQL and Protocol Buffers. You can imagine a public API that is introspected and can tell the client about deprecation and all that.

Re: Exotic Programming Ideas, Part 3: Effect Systems

#92

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

The_rationalist wrote: post #89

klodolph wrote: post #88

Earlier quoted context omitted.

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

> You clearly didn't read…

Just a word of advice—you’re digging yourself in a hole if you make low-quality, ad-hominem comments like that. Comments of the form “you didn’t read X” are specifically discouraged on HN. Maybe you feel good writing it, but nobody feels good reading it and nobody learns anything.

I took another look at the page you linked and it still looks like syntactic sugar for Monads. It’s still monads. Monads monads monads. Applicative and Functor are generalizations of Monad.

Re: Exotic Programming Ideas, Part 3: Effect Systems

#93

Post by patrec » Tue, Nov 24, 2020, 8:57 PM UTC

kazinator wrote: post #90

patrec wrote: post #74

Earlier quoted context omitted.

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.

What concrete problem do you see with it? [edit: BTW you can quite easily implement common-lisp style backquote in clojure as a macro, because just like scheme clojure does not share common lisp's defect of baking unquoting into the readtable dispatch of backquote; i.e. unquotes outside of backquotes are syntactically valid; '~x -> (unquote x)]

Re: Exotic Programming Ideas, Part 3: Effect Systems

#94

Post by atennapel » Wed, Nov 25, 2020, 10:29 AM UTC

valenterry wrote: post #83

atennapel wrote: post #77

Earlier quoted context omitted.

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).

I think something like algebraic effects can definitely be ergonomic and understandable, but a language definitely has to be designed for it. Algebraic effects are like exceptions in a lot of ways, so I think people will be able to understand them. See Effekt [1] and Koka [2] for languages that are designed with them in mind.

[1] https://effekt-lang.org/ [2] https://koka-lang.github.io/koka/doc/kokaspec.html

Re: Exotic Programming Ideas, Part 3: Effect Systems

#95

Post by Quekid5 » Fri, Nov 27, 2020, 8:11 PM UTC

skybrian wrote: post #63

lambda_obrien wrote: post #57

Earlier quoted context omitted.

Honestly, in the Haskell world, no one really complains about broken APIs, it's actually pretty common for a library to change things in a breaking way. People tend to either use Nix or stack to deal with versioning or they just plan to refactor when they have to. I personally just started with Haskell, but I've switched a small tool from one streaming library to another and it was super easy even though each had a v…

Yes, there are easier and harder ways to deal with api migrations. But even in Haskell, isn't "Cabal hell" a thing? And the type of the standard prelude's head function is wrong but it can never be changed. Dependency migration is the sort of thing that's easy enough in small examples and gets harder as you scale up.

> But even in Haskell, isn't "Cabal hell" a thing?

No. Just use stack + Stackage and you have a huge set of packages which are mutually compatible.

(You can also use cabal-install with a Stackage snapshot, I think. Not sure though. Cabal-install has also improved massively and doesn't really do "global" installation of dependencies, so it'll help a lot... but you may still run into difficulties making different versions of your project's dependencies work together.)