scala/scala

Discord is now Scala’s main chat platform. Please join us at https://discord.com/invite/scala

PsyfireX

@PsyfireX

Could you copy a larger code-snippet?

Harrison Houghton

@hrhino

also, that's Java...

Josh

@joshlemer

Also I feel like it's so easy to "sneak in" mutability, if that makes sense. For example:

Seq[(String, Int)](
  "x" -> 1,
  "y" -> 2,
  "z" -> 3,
  "x" -> 2
).foldLeft(Map.empty[String, Int])(_ + _)

In a sense, we're reassigning a value to "x" here, right?

Harrison Houghton

@hrhino

... no? not any more than using updated on a map

Josh

@joshlemer

If you kinda squint at it and pretend that each line is binding to a variable then it's as if we have invented var out of purely functional constructs

PsyfireX

@PsyfireX

I don't get it, how are you assigning anything to "x"

"x" isn't mutable, nor is "x".->(2)

Martijn Hoekstra

@martijnhoekstra

@joshlemer sure, if you consider a Map[String, Int] as the runtime of your programming environment, with the strings as identifiers, updating values in that map can be seen as mutating values pointed to by identifiers

Josh

@joshlemer

Exactly @martijnhoekstra gets it

Martijn Hoekstra

@martijnhoekstra

but that's not scala, that's the Map[String, Int] language

Josh

@joshlemer

so if you aren't careful, mutability can "foam up" from beneath you

or rather, emerge would be the verb

Fabio Labella

@SystemFw

mutability is not a problem, lack of referential transparency is

also, that Map is a common technique to implement environments for closures when doing e.g. an interpreter :)

Josh

@joshlemer

a more flushed out example

sealed trait AssignmentTo 
case class Constant(c: Int) extends AssignmentTo
case class Variable(varName: String) extends AssignmentTo


Seq[(String, AssignmentTo)](
  "x" -> Constant(1),
  "y" -> Constant(2),
  "z" -> Constant(3),

  "uhoh" -> Variable("x"),

  "x" -> Constant(1),

  "uhoh" -> Variable("x")

).foldLeft(Map.empty[String, Int]) { case (acc, (ident, assign)) =>
  val newValue = assign match { 
    case Constant(c) => c
    case Variable(varName) => acc(varName)
  }
  acc + ((ident, newValue))
}

Martijn Hoekstra

@martijnhoekstra

The mutability there is in the interpreted language of AssignmentTo, not in scala

Josh

@joshlemer

like, aside from throwing exceptions, this is as pure as it gets.Yet, it is starting to look a lot like imperative programming

PsyfireX

@PsyfireX

I don't see the mutability

It seems like you're trying to prove a point by starting with "squint very hard"

Amit Prasad

@amitprasad01_twitter

Hi Guys

anyone familiar here of scalamock

Josh

@joshlemer

here we've invented a little world/language/abstraction where identifier can be mutably updated using only purely functional constructs

Amit Prasad

@amitprasad01_twitter

need some urgent help

Josh

@joshlemer

"x" can be assigned values, it can be read and assigned to other values, updated. It's a var

Pierre Marais

@Deeds67

@joshlemer Do you see recursion as mutation then as well?

Josh

@joshlemer

I'm not saying I have any answers or rules, just pointing out that purity maybe is less black and white than it seems?

PsyfireX

@PsyfireX

No, that's not what's happening.

"if you squint really hard 98 + 1 = 100"

Josh

@joshlemer

Unless there's like really a rule for why this is not to be breaking referential transparency

PsyfireX

@PsyfireX

^ that is an incorrect statement relying on ignoring logic/facts in favor of fuzzy logic

Josh

@joshlemer

@PsyfireX I'd like to hear why this is wrong if you wouldn't mind elaborating

PsyfireX

@PsyfireX

What is being mutated in your example?

Josh

@joshlemer

@amitprasad01_twitter I'm not familiar but if you pose specific questions maybe someone will know

@PsyfireX the binding of "x" to 1

Martijn Hoekstra

@martijnhoekstra

@joshlemer I see your exmple, but what you did was show that you can interpret an impure language in a pure interpreter. Just because you can use pure programming to write an interpreter to interpret an impure program doesn't make the interpreter impure.

PsyfireX

@PsyfireX

The binding is never mutated

Josh

@joshlemer

@PsyfireX I apologize, the second appearance of "x" should be "x" -> Constant(12345)

@martijnhoekstra I get that but I'm not sure where you draw the line between what is in our language and what is in the interpreted language

PsyfireX

@PsyfireX

I think you're trying to say that when the accumulator receives the same key twice, that's mutation?

Josh

@joshlemer

yes

PsyfireX

@PsyfireX

The problem with a statment like that is that ... it's not mutatation

Josh

@joshlemer

Looks quite a bit like mutation to me

PsyfireX

@PsyfireX

Would you consider this mutation?

Seq(3) ++ Seq(4)

Josh

@joshlemer

No not typically

I would say almost certainly no

Martijn Hoekstra

@martijnhoekstra

@joshlemer what's in our language is scala - creating a binding like val x = 12345. Your interpreted language is the language with the primitives defined asAssignmentTo, interpreted by the function in the fold -- only when you give AssignmentTothe meaning of being a program, then the mutability shows up.

PsyfireX

@PsyfireX

Would you consider this mutation (from your example)

acc + ((ident, newValue))

Martijn Hoekstra

@martijnhoekstra

but then it's also clear what the dividing line is -- the language of AssignmentTo

Where communities thrive

People

Repo info

Activity