Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Fabio Labella
@SystemFw

the rules are different in unison.

Yeah, I don't want to derail the discussion, but it's actually interesting. It's midway through full referential transparency and side-effects...

@vinayakpathak to finish the def vs val thing, there is also the issue of passing arguments by name and by value, and the fact that IO can do async and concurrency. Overall I would also recommend to forget about evaluation and think about it as an abstraction
Paul Snively
@paul-snively
That's one kind of annoying thing about Scala. It's strict. Except when it isn't.
Fabio Labella
@SystemFw
you can make the same argument about a lazy lang :P
well, the specular argument
Paul Snively
@paul-snively
seq and ye shall find.
Rob Norris
@tpolecat
I put strictness and stack safety in the same bucket. They're just these ambient nuisances that have no effect on anything as long as you don't care about termination (and who does, right?)
Vinayak Pathak
@vinayakpathak
hmm, I think I was convinced that defs don't give us referential transparency from @joroKr21 's argument already
Rob Norris
@tpolecat
referential transparency is a property of expressions
a def is not an expression
I haven't read the huge scrollback, I should be quiet.
Paul Snively
@paul-snively
I mean... a def that does I/O, or generates a random number, or throws an exception rather than returning a value of its declared type is obviously not referentially transparent, right?
I don't mean to be difficult, but is it really that hard to understand what a "side-effect" is?
Vinayak Pathak
@vinayakpathak
hah, no ofc not, I don't mind hearing different perspectives on the same issue :) @tpolecat
Paul Snively
@paul-snively
Yeah, fair, and my puzzlement is genuine. I'm not trying to be a jerk (that comes naturally)... ;-)
And all of this goes to why writing referentially transparent software in Scala is a royal pain in the ass. Thank you for coming to my TED talk.
Vinayak Pathak
@vinayakpathak
@tpolecat what's the definition of an expression and why's def not one?
Rob Norris
@tpolecat
Can you assign it to a variable?
val x = def ...?
Can you pass it as an argument?
foo(def ...?
Vinayak Pathak
@vinayakpathak
i see hmm
Fabio Labella
@SystemFw
@vinayakpathak def is not enough, def + by name arguments might be
Vinayak Pathak
@vinayakpathak
so what is def then?
Fabio Labella
@SystemFw
but then you realise that that is the same as saying that IO is () => A
Ethan
@esuntag
syntax for defining a method
Vinayak Pathak
@vinayakpathak
@SystemFw yes fair
Fabio Labella
@SystemFw
which I show is not enough in the post
for example you can't do async or concurrency
error handling is weirder
and the api you get is much more limited
Vinayak Pathak
@vinayakpathak
i see i see
so above I asked "what's the minimal thing that would ensure referential transparency"... perhaps () => A is a good candidate?
Fabio Labella
@SystemFw
for synchronous stuff only though
Vinayak Pathak
@vinayakpathak
yeah ok
Fabio Labella
@SystemFw
and without errors
Vinayak Pathak
@vinayakpathak
true
Fabio Labella
@SystemFw
but yeah, at the end of the day you need suspension
because you want to separate evaluation and execution
that being said, this is trying to understand (imho) how IO is implemented
rather than its semantics
Vinayak Pathak
@vinayakpathak
i see
Drew Boardman
@drewboardman
is he saying def is not RT because it's lazy and not memoized?
because I don't see how that follows
Fabio Labella
@SystemFw
no
we're trying to discuss where def is enough to ensure referential transparency, which it isn't
Vinayak Pathak
@vinayakpathak
def + by value is not referentially transparent because you will evaluate the arguments prematurely
Fabio Labella
@SystemFw
exactly
def + by name is, and in that model val is the equivalent of <-
but the whole thing is then easier to understand by considering IO[A] = () => A , which has the limitations outlined above