Pollyanna posted:

what

if f(x) is defined as x^2 - x + 1 then no matter what you put in for x you should get the same answer

why the hell would you get a different one???

Pollyanna posted:

what's the difference between functional programming and whatever you end up doing in python?

Symbolic Butt posted:

try thinking about lists in python and how they can be weird if you don't think about mutation

Python code:

l = [4, 1, 7, 0]

print(sorted(l))  # prints [0, 1, 4, 7]
print(l)          # l is still [4, 1, 7, 0]

l.sort()
print(l)  # the sort() method mutates the original list so this prints [0, 1, 4, 7]

so basically this kind of behavior of the sort() method is not a thing in functional programming.

in a way you only get tuples

Pollyanna posted:

well yeah, in that first one you're just printing an array "sorted variable l", rather than making variable l equal to the array "sorted variable l". l.sort() and "l = sort(l)" would accomplish the same thing.

so youre saying that in functional programming, once you've set variable l equal to something, it will always be that, and that "l = sort(l)" would not be a valid command?

General Olloth posted:

instead of being able to do

l.sort()

you would have to do
l = sort(l)

sort would have to take an array and return the sorted array

it wouldn't be a function to call on an array

VanillaKid posted:

no neither of those are functional because they mutate state

VanillaKid posted:

no neither of those are functional because they mutate state

Pollyanna posted:

you can't change l itself? that doesn't seem like too much of a big deal...

Pollyanna posted:

well yeah, in that first one you're just printing an array "sorted variable l", rather than making variable l equal to the array "sorted variable l". l.sort() and "l = sort(l)" would accomplish the same thing.

so youre saying that in functional programming, once you've set variable l equal to something, it will always be that, and that "l = sort(l)" would not be a valid command?

Pollyanna posted:

so the only way to define a sorted version of l is to say:

ls = sort(l)

? you can't change l itself? that doesn't seem like too much of a big deal...

MononcQc posted:

Single assignment owns and hell yes functional programming chat

Pollyanna posted:

lambda is new to me. i havent seen that before.

also in that example, don't the for loop and the lambda do basically the same thing, if i'm reading it correctly?

Pollyanna posted:

lambda is new to me. i havent seen that before.

also in that example, don't the for loop and the lambda do basically the same thing, if i'm reading it correctly?


so the only way to define a sorted version of l is to say:

ls = sort(l)

? you can't change l itself? that doesn't seem like too much of a big deal...

MononcQc posted:

Yes and no. That depends on the language. Immutability and single assignment are not necessarily the same exact thing.

Let's say I have a tree T:

code:

      d
    /   \
   b     g
 /  \   /  \
a    c f    h

Now let's say my code does:

code:

Old = T, % regular assignment
New = Old,
New = insert(e, New)

Now here, in a language like Erlang or Haskell or whatever, you would crash (or not compile) because you're trying to change the value of a variable. However, nothing keeps you from having a language where you allow that as long as Old remains usable, and New =/= Old once the update has taken place.

This can be done with immutability, which pretty much all functional languages support. When you update the tree, nodes that are in common are kept, and otherwise part of the tree points to the old one, giving you something a bit like this in memory:



Basically, the entire unchanged subtree starting at b is kept for both Old and New trees, but the rest changes in some way. The h node is also shared because it had no reason to change. The F node had to be copied and rewritten to allow to change what child it has, but note that if the content of F is large, that can be copied literally. I.e. if my node is {Current, Left, Right}, I need to change the node, but could still point to the existing 'Current' value from the older tree.

Garbage collection will later determine what can be reused or not. This lets you update trees in O(log n) memory as well as time, rather than O(n) memory if no sharing took place and deep copies were needed, regardless of the content of the nodes.

So single assignment is often used, but is not necessary for a language to be immutable.

In the case above, doing the update and allowing New to point to the tree in red would work, and Old could still keep its references intact and also work, despite New (the variable) changing definition over time. The data structure remained safe for all its users, though.

Pollyanna posted:

okay, so say i wanted to make a program return the number 7.

<...snip...>

so functional programming doesn't like that, and prefers x = 2 and y = x + 5? but wouldn't the steps basically be the same for that? you'd see that y = x + 5, but you don't know what x is, so you look backwards in the program for x's initial state...

you see what i mean? it's the same number of steps.

MononcQc posted:

Yes and no. That depends on the language. Immutability and single assignment are not necessarily the same exact thing.

Let's say I have a tree T:

code:

      d
    /   \
   b     g
 /  \   /  \
a    c f    h

Now let's say my code does:

code:

Old = T, % regular assignment
New = Old,
New = insert(e, New)

Now here, in a language like Erlang or Haskell or whatever, you would crash (or not compile) because you're trying to change the value of a variable. However, nothing keeps you from having a language where you allow that as long as Old remains usable, and New =/= Old once the update has taken place.

This can be done with immutability, which pretty much all functional languages support. When you update the tree, nodes that are in common are kept, and otherwise part of the tree points to the old one, giving you something a bit like this in memory:



Basically, the entire unchanged subtree starting at b is kept for both Old and New trees, but the rest changes in some way. The h node is also shared because it had no reason to change. The F node had to be copied and rewritten to allow to change what child it has, but note that if the content of F is large, that can be copied literally. I.e. if my node is {Current, Left, Right}, I need to change the node, but could still point to the existing 'Current' value from the older tree.

Garbage collection will later determine what can be reused or not. This lets you update trees in O(log n) memory as well as time, rather than O(n) memory if no sharing took place and deep copies were needed, regardless of the content of the nodes.

So single assignment is often used, but is not necessary for a language to be immutable.

In the case above, doing the update and allowing New to point to the tree in red would work, and Old could still keep its references intact and also work, despite New (the variable) changing definition over time. The data structure remained safe for all its users, though.

MononcQc posted:

Bloody posted:

i like how this diagram was designed to look like it was hand-drawn but clearly is not hand-drawn because it actually features like 2 distinct non-circles and font-consistent handwriting

MononcQc posted:

Which is visibly weird and hard to think about! Functional programming with regards to variables isn't about being economical on lines and whatnot, but more or less about using variables the way mathematicians can use them -- a fixed value you can reason about, and not a memory location or pointer or less abstract concept.

prefect posted:

it almost seems like there are no variables, only constants

Pollyanna posted:

yeah how did you make that

prefect posted:

it almost seems like there is no dana, only zuul

Pollyanna posted:

nice. that makes a lot of sense. in your example, haskell and erlang are immutable AND single assignment, right? hence why you can't change New. in languages that are immutable but not single assignment, you can still change New.
is that correct?

Pollyanna posted:

the way i had understood the whole "x = 1, y = x, print y + 1" thing is that like...there's a difference between y being equal to the same value/string/whatever that x is, and y being literally equal to x (like a nickname or alias). in long form, it'd be "y is equal to x, which is equal to 1, therefore y is equal to 1" as opposed to "y is x". does that make sense?

Pollyanna posted:

i don't quite see either of those in your example, cause it kinda ends up being a mix of the two. i had envisioned either an entirely new tree (i.e. a copy of all nodes rather than directly affected nodes) or the old tree with an e node attached to f. instead, it looks like it's trying to conserve energy or something by doing the bare minimum it needs to change. meaning, it creates new stuff for what changes, but what doesn't change already exists somewhere in memory, so it just points back to that.

is that correct?

prefect posted:

it almost seems like there are no variables, only constants

Bloody posted:

i like how this diagram was designed to look like it was hand-drawn but clearly is not hand-drawn because it actually features like 2 distinct non-circles and font-consistent handwriting

USSMICHELLEBACHMAN posted:

it looks like it came from here to me but i could be wrong

http://learnyouahaskell.com/

MononcQc posted:

It was originally hand-drawn, then put on a computer. I originally had my own handwriting for most of the drawings, but when I ended up doing the paper version, I (and my girlfriend, who retraced a shitload of illustrations to help me) used a handwritten font to make it more readable to everyone.

Many of these drawings though, when traced back, were using only 2-3 circles because gently caress retracing over all of them. Some are just rotated to give the impression of being handdrawn 100% of the time, but I had more things to do than carefully draw every circle all over again. The same circles are probably used in a bunch of places in the book, but the original ones are drawn by hand.

You can see that the C node is just the D node flipped over, for example.


It comes from the printed version of http://learnyousomeerlang.com -- the drawing I posted above only made it in the final print copy of the book and won't be on the website though.

Symbolic Butt posted:

pure functional programming is stuff like ml, haskell, erlang, lisp...

Bloody posted:

excellent, excellent. next problem: i want to do database things from a c# app. every previous time ive used a db ive used some sort of orm. i dont know how to write sql more complex than select * from butts where farts = something or whatever. also i really like that orms easily give strongly-typed results. what database should i use (mssql because c#?) and how do i do things as strongly typed as possible?

Pollyanna posted:

so functional programming has the advantage of being memory efficient? that would mean programs would run faster and take up less ram and such, right?

MononcQc posted:

Garbage collection will later determine what can be reused or not. This lets you update trees in O(log n) memory as well as time, rather than O(n) memory if no sharing took place and deep copies were needed, regardless of the content of the nodes.