Newest at the top
2024-05-12 11:10:59 +0200 | <sandbag> | for python, I can understand because of lots of abstraction. is it similar in haskell? |
2024-05-12 11:10:51 +0200 | <mauke> | depends on the task and the language |
2024-05-12 11:10:14 +0200 | <sandbag> | functional languages do look a bit similar to python (mostly syntax and less amount of code). if you look at C or Go, you are writing a lot of code. but in python or haskell, it's less |
2024-05-12 11:10:14 +0200 | <[Leary]> | The MLs do share Haskell's parametric polymorphism and some syntax, but Haskell being both pure and lazy is somewhat of an island; there are no widely used programming languages that are genuinely similar. |
2024-05-12 11:09:39 +0200 | <mauke> | but not lazy and not pure (ad-hoc side effects allowed everywhere) |
2024-05-12 11:08:56 +0200 | <mauke> | very similar syntax and type system |
2024-05-12 11:08:53 +0200 | <sandbag> | ah, that's great. i will pick it up after writing some haskell |
2024-05-12 11:08:02 +0200 | <mauke> | pretty similar in many ways |
2024-05-12 11:07:54 +0200 | <sandbag> | btw, completely offtopic but is ocaml similar to haskell or completely different? |
2024-05-12 11:06:41 +0200 | <sandbag> | that's interesting |
2024-05-12 11:06:21 +0200 | <mauke> | or in our case, to eliminate the need for naming arguments in lambda functions |
2024-05-12 11:06:09 +0200 | <mauke> | "Combinatory logic is a notation to eliminate the need for quantified variables in mathematical logic." |
2024-05-12 11:06:09 +0200 | mikess | (~mikess@user/mikess) (Quit: mikess) |
2024-05-12 11:06:03 +0200 | <sandbag> | i will resume my journey on functional programming |
2024-05-12 11:05:49 +0200 | <mauke> | if you want to get scared, https://en.wikipedia.org/wiki/Combinatory_logic |
2024-05-12 11:05:25 +0200 | <sandbag> | anywho, thanks for the explanation. it's much clear now |
2024-05-12 11:05:19 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Quit: WeeChat 4.2.2) |
2024-05-12 11:04:48 +0200 | <sandbag> | and i suck at math |
2024-05-12 11:04:43 +0200 | <sandbag> | looks like a very complex math equation :| |
2024-05-12 11:04:40 +0200 | <mauke> | and now you can write all functions without arguments :-) |
2024-05-12 11:04:19 +0200 | <mauke> | commonly known as S and K, defined as: K x y = x; S x y z = (x z) (y z) |
2024-05-12 11:03:57 +0200 | <sandbag> | true |
2024-05-12 11:03:38 +0200 | <mauke> | but it turns out you can always do it if you allow some simple helper functions |
2024-05-12 11:03:38 +0200 | euleritian | (~euleritia@ip-185-104-138-28.ptr.icomera.net) |
2024-05-12 11:03:23 +0200 | <sandbag> | so, if you are referencing or using some other function, at that time arguments aren't required |
2024-05-12 11:03:10 +0200 | <mauke> | you can't directly get the 'x' out of the middle of an expression |
2024-05-12 11:02:53 +0200 | <mauke> | or even just \x -> f x 42 |
2024-05-12 11:02:44 +0200 | <sandbag> | yeah |
2024-05-12 11:02:21 +0200 | <mauke> | here we use the argument x not just as the last argument to some other function |
2024-05-12 11:02:00 +0200 | <mauke> | consider \x -> f x x |
2024-05-12 11:01:46 +0200 | <mauke> | not completely |
2024-05-12 11:01:27 +0200 | <mauke> | \x -> (... anything here ...) x |
2024-05-12 11:01:27 +0200 | <sandbag> | in that manner, doesn't that eliminate the need of arguments then? |
2024-05-12 11:01:20 +0200 | <mauke> | well, and the thing it's applying the (inner) function to is the argument of the (outer) function |
2024-05-12 11:01:00 +0200 | <mauke> | any time you have a function whose outermost expression (in the function body) is a function application |
2024-05-12 11:00:43 +0200 | <sandbag> | oh, could be any function? |
2024-05-12 11:00:12 +0200 | <mauke> | doesn't even have to be "middle" or "top" |
2024-05-12 11:00:05 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
2024-05-12 10:59:44 +0200 | <sandbag> | ah, that makes sense. so i can get away by not passing arguments to some middle function which points to a top function which has the same argument |
2024-05-12 10:58:17 +0200 | <mauke> | just as in 'f x = g x' you can "cancel" the x on both sides, so in 'html_ content = (el "html") content' you can cancel the content on both sides |
2024-05-12 10:57:58 +0200 | <sandbag> | im new to functional programming. forgive me for any kind of silly questions :) |
2024-05-12 10:57:09 +0200 | <sandbag> | your snippet makes sense. so the one I sent is similar? |
2024-05-12 10:56:57 +0200 | <mauke> | it comes to the same thing |
2024-05-12 10:56:54 +0200 | <mauke> | fundamentally, it's like writing 'f = g' instead of 'f x = g x' |
2024-05-12 10:56:30 +0200 | <mauke> | because all it does is forward its argument to another function |
2024-05-12 10:56:18 +0200 | <mauke> | which means it is functionally equivalent to just el "html" |
2024-05-12 10:56:06 +0200 | <mauke> | which says: html_ is defined as a function (of one argument, content) that applies (el "html") to that argument |
2024-05-12 10:55:48 +0200 | <sandbag> | i meant html_ = el "html" |
2024-05-12 10:55:16 +0200 | <mauke> | html_ = \content -> (el "html") content |
2024-05-12 10:55:07 +0200 | <mauke> | html_ content = el "html" content -- the original definition, is the same as: |