Newest at the top
| 2026-01-23 23:54:05 +0100 | fp | (~Thunderbi@2001-14ba-6e24-3000--198.rev.dnainternet.fi) (Ping timeout: 245 seconds) |
| 2026-01-23 23:49:43 +0100 | <haskellbridge> | <Liamzee> but i guess the real point is that there's no real advantage to let (@) = (,) in traverse (uncurry when) [ cond @ action...] |
| 2026-01-23 23:48:19 +0100 | <geekosaur> | and macros can be typed (see typed TH, granting that TH is not very usable as macro systems go) |
| 2026-01-23 23:47:54 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2026-01-23 23:47:51 +0100 | <haskellbridge> | <Liamzee> i love my traverse abuse, turning control flow into data is fun |
| 2026-01-23 23:47:30 +0100 | <geekosaur> | functions aren't typed in scheme, amnd as monochrom says, there's no way to tell just from looking at code using it whether it's even a function |
| 2026-01-23 23:47:04 +0100 | <monochrom> | (Sure, I can look up the docs. Now add the empirical fact that programmers don't write docs.) |
| 2026-01-23 23:46:38 +0100 | <haskellbridge> | <Liamzee> the real question is whether hof zoo is a key advantage |
| 2026-01-23 23:46:35 +0100 | <monochrom> | What I don't like about Lisp/Scheme macros is that if you write so much as "(f x)" then I have no idea what's its evaluation order because I can't remember whether f is a function or a macro. |
| 2026-01-23 23:46:24 +0100 | <haskellbridge> | <Liamzee> i guess macros vs functions is more of a smaller difference, macros tend to be untyped, functions tend to be typed |
| 2026-01-23 23:45:02 +0100 | <monochrom> | And like geekosaur said, there is also a symmetric difference. |
| 2026-01-23 23:44:29 +0100 | <monochrom> | Conversely, Lisp doesn't have a good laziness story, so macro is better! |
| 2026-01-23 23:43:55 +0100 | <monochrom> | Haskell does not have a good macro story, so lazy function is usually better in Haskell. (Try implementing "for" as a TH macro, then try using it.) |
| 2026-01-23 23:43:09 +0100 | <geekosaur> | what I was getting at is that I consider them just different mechanisms. each may have advantages in some situations and disadvantages in others |
| 2026-01-23 23:42:31 +0100 | <haskellbridge> | <Liamzee> well, runtime macros |
| 2026-01-23 23:42:23 +0100 | Gravifer | (~Gravifer@user/Gravifer) Gravifer |
| 2026-01-23 23:42:15 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 265 seconds) |
| 2026-01-23 23:42:15 +0100 | <haskellbridge> | <Liamzee> i mean any language with strong macros can define custom control structures |
| 2026-01-23 23:42:03 +0100 | Gravifer | (~Gravifer@user/Gravifer) (Client Quit) |
| 2026-01-23 23:41:38 +0100 | <geekosaur> | Haskell's laziness lets you define some things that must be built-in control structures in other languages as functions. But the same can be said of Tcl and Ruby, in their own ways |
| 2026-01-23 23:41:26 +0100 | <haskellbridge> | <Liamzee> well, i was wondering if for/for_ being functions in Haskell were advantages, HOF zoo has the issue that you'd actually need to know what the HOFs used are |
| 2026-01-23 23:41:15 +0100 | Gravifer | (~Gravifer@user/Gravifer) Gravifer |
| 2026-01-23 23:40:48 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2026-01-23 23:40:38 +0100 | <geekosaur> | does it have to be one or the other? |
| 2026-01-23 23:40:01 +0100 | <haskellbridge> | <Liamzee> is it better or worse than for is a function in Haskell, vs being a macro in Lisp or syntax in a traditional language? |
| 2026-01-23 23:25:21 +0100 | Psychotic1 | (~Psychotic@2600:1007:b0a4:acff:921e:44c6:4ad9:edda) (Remote host closed the connection) |
| 2026-01-23 23:16:09 +0100 | oskarw | (~user@user/oskarw) (Remote host closed the connection) |
| 2026-01-23 23:15:14 +0100 | Psychotic1 | (~Psychotic@2600:1007:b0a4:acff:921e:44c6:4ad9:edda) |
| 2026-01-23 23:14:49 +0100 | Psychotic1 | (~Psychotic@2600:1007:b0a4:acff:921e:44c6:4ad9:edda) (Quit: Leaving) |
| 2026-01-23 23:12:12 +0100 | Googulator | (~Googulato@2a01-036d-0106-030a-3891-da7f-f3f3-f997.pool6.digikabel.hu) |
| 2026-01-23 23:01:55 +0100 | <gentauro> | :( |
| 2026-01-23 23:01:54 +0100 | <gentauro> | I guess now SimCorp "owns" APL |
| 2026-01-23 23:01:35 +0100 | <gentauro> | oh Dialog, Swedish company that was purchased by SimCorp iirc |
| 2026-01-23 22:55:13 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) (Ping timeout: 264 seconds) |
| 2026-01-23 22:54:54 +0100 | acidjnk | (~acidjnk@p200300d6e71719732cd814db2eedd90f.dip0.t-ipconnect.de) acidjnk |
| 2026-01-23 22:46:03 +0100 | <haskellbridge> | <sm> ah, it was in the matrix Haskell room. "random: this talk on APL teaching and style (https://youtu.be/9xCJ3BCIudI) was really interesting. Contrasts (and similarities) with Haskell came up a few times." |
| 2026-01-23 22:43:59 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2026-01-23 22:42:12 +0100 | <EvanR> | I'm not sure |
| 2026-01-23 22:41:57 +0100 | <haskellbridge> | <sm> did you see that APL video I linked EvanR ? |
| 2026-01-23 22:36:19 +0100 | jmcantrell_ | jmcantrell |
| 2026-01-23 22:32:14 +0100 | <EvanR> | (not that they ended up optimized in any way) |
| 2026-01-23 22:31:52 +0100 | <EvanR> | because of how much it can be decomplected |
| 2026-01-23 22:31:29 +0100 | <EvanR> | I'm fascinated by the one or two APLs implemented in haskell |
| 2026-01-23 22:29:08 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2026-01-23 22:29:08 +0100 | haritz | (~hrtz@140.228.70.141) (Changing host) |
| 2026-01-23 22:29:08 +0100 | haritz | (~hrtz@140.228.70.141) |
| 2026-01-23 22:28:54 +0100 | <monochrom> | Someone wrote a "Liskell" for Lisp syntax but Haskell semantics. :) |
| 2026-01-23 22:28:52 +0100 | <EvanR> | a consensus about lisp sounds ominous AF |
| 2026-01-23 22:28:41 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2026-01-23 22:26:24 +0100 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |