Discord is now Scala’s main chat platform. Please join us at https://discord.com/invite/scala
head character directly:def balance(chars: List[Char]): Boolean ={
def loop(chars: List[Char], counter: Int) : Boolean = {
chars match {
case Nil => counter == 0
case '(' :: tail => loop(tail, counter + 1)
case ')' :: tail => counter > 0 && loop(tail, counter - 1)
case _ :: tail => loop(tail, counter)
}
}
loop(chars, 0)
}
I would not consider Option/Either an effect. Sometimes Either is used where non-FP people would throw an exception (which would be an effect), but that's the closest connection I can see
@lysium Yeah, and I think this must have been why I somewhat developed a connection between effect and Option/Either
Option and Either an effect per definition
F[A]
val myOpinion = Opinion(None)
side-effect has a very precise definition
effect does not, it's just a convenient term
F[_]
I would not consider Option/Either an effect. Sometimes Either is used where non-FP people would throw an exception (which would be an effect), but that's the closest connection I can see. At the moment, I have a hard time to define 'effect', but I'd describe it as changes that were not part of your functions' arguments or return values, such as the contents of the stdin buffer, some observable memory location, or the continuation of the function call.
you are talking about side-effects here, which has a precise definition: something that breaks referential transparency
SideEffectSuspensStrategyProviderFactoryBeanjust as a sort of Pavlov reaction
@ochrons Thank you for the video! I love the phrase "
F[A]: This is a program in F that computes a value of type A." I think it accurately describes what we think of F[A]: we are actually interested in computing A, but we use the stuff fromF to do that. Now I think I better understand the phrase "F[A] is an effect on A".
The word "effect" has always confused me in any description of FP, I only have a kind of mental model of the type of thing that might be going on when someone says effect, it definitely makes any sentence in it less informative to me :) But that's probably just me
@trepidacious Nope...that makes us two...plenty sure many more like us out there :D
effectdoes not, it's just a convenient term basically used to refer to anF[_]
@SystemFw I have seen context, or computational context used to describe this...will I be right to say that effect is just another way of saying the same thing?
F[_]
4 replies
it goes like this:
- purity is a syntactical property of programs, more precisely defined as referential transparency: replacing an expression for its bound value doesn't change meaning (precise definition)
- side effects are things that break referential transparency (precise definition)
- There's no direct connection between the concepts of IO, State and so on, and side effects. Traditionally, these things are side effectful (break referential transparency), but you can have abstractions that are pure (don't break ref.trans.)
- Due to the above, the term
purely functional programmingis not an oxymoron, it makes perfect sense. - In haskell style pure FP, type constructors and algebras are used to represent "things that would otherwise traditionally be side effects (break ref.trans.)". We call these
F[_]seffectsorcomputational contextsfor brevity. You can see for yourself how this cannot be a precise definition (especially because they could also have kind higher than* -> *, even though most famous algebras like Functor and Monad operate onF[_]
I guess the other thing to add is that purity really matters a lot, it's not pedantry. Referentially transparent expressions respect the substitution model, which means you can use local reasoning only to understand and compose your programs, which is a huge win