Newest at the top
| 2025-07-14 18:49:55 +0200 | tromp | (~textual@2001:1c00:3487:1b00:89d3:7d92:7b20:925) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-07-14 18:47:29 +0200 | fp | (~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 252 seconds) |
| 2025-07-14 18:46:23 +0200 | perro | (~aaron@2600:100c:b211:ed4b:edc0:bd27:9bff:d562) |
| 2025-07-14 18:46:20 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-14 18:46:01 +0200 | acidjnk | (~acidjnk@p200300d6e70b6602dc09300ac5aeb77e.dip0.t-ipconnect.de) acidjnk |
| 2025-07-14 18:45:55 +0200 | <gaze__> | like -- I'm using the DSL to generate imperative code, but I also want to write imperative code in the DSL, and I was wondering how much I can avoid writing the function table out like defun "functionName" do blahblahblah in some gihugeous function |
| 2025-07-14 18:44:50 +0200 | <gaze__> | function type unification I mean |
| 2025-07-14 18:44:42 +0200 | <gaze__> | Anyone have an example of a DSL with only first-order named functions that lifts type unification to the host language? |
| 2025-07-14 18:42:58 +0200 | pavonia | (~user@user/siracusa) (Ping timeout: 248 seconds) |
| 2025-07-14 18:42:19 +0200 | perro | (~aaron@syn-072-191-245-069.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2025-07-14 18:41:42 +0200 | Jerryeee | (~Thunderbi@user/Jerryeee) (Quit: Jerryeee) |
| 2025-07-14 18:34:58 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Remote host closed the connection) |
| 2025-07-14 18:33:36 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-07-14 18:30:36 +0200 | ttybitnik | (~ttybitnik@user/wolper) ttybitnik |
| 2025-07-14 18:28:52 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) ezzieyguywuf |
| 2025-07-14 18:28:21 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Ping timeout: 252 seconds) |
| 2025-07-14 18:27:30 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) (Client Quit) |
| 2025-07-14 18:26:26 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2025-07-14 18:25:11 +0200 | Jerryeee | (~Thunderbi@user/Jerryeee) Jerryeee |
| 2025-07-14 18:24:34 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) dtman34 |
| 2025-07-14 18:23:58 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-07-14 18:23:53 +0200 | sp1ff | (~user@c-67-160-173-55.hsd1.wa.comcast.net) sp1ff |
| 2025-07-14 18:23:42 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-14 18:15:46 +0200 | poscat | (~poscat@user/poscat) poscat |
| 2025-07-14 18:13:01 +0200 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
| 2025-07-14 18:11:15 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-14 18:10:15 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-14 18:09:21 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 248 seconds) |
| 2025-07-14 18:07:10 +0200 | caubert | (~caubert@user/caubert) caubert |
| 2025-07-14 18:06:34 +0200 | trickard_ | (~trickard@cpe-92-98-47-163.wireline.com.au) |
| 2025-07-14 18:03:51 +0200 | trickard | (~trickard@cpe-92-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-07-14 17:54:58 +0200 | caubert | (~caubert@user/caubert) (Ping timeout: 272 seconds) |
| 2025-07-14 17:46:08 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-07-14 17:44:58 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Read error: Connection reset by peer) |
| 2025-07-14 17:38:44 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-07-14 17:30:22 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-07-14 17:29:44 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-07-14 17:28:31 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-07-14 17:28:13 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 244 seconds) |
| 2025-07-14 17:27:53 +0200 | <tomsmeding> | that's the fun way :) |
| 2025-07-14 17:27:14 +0200 | <juri_> | I'm finding out all of the things the hard way. :) |
| 2025-07-14 17:25:39 +0200 | acidjnk | (~acidjnk@p200300d6e70b6600550565d8f561750a.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-07-14 17:24:45 +0200 | <tomsmeding> | iirc repa does not have a forward permutation primitive, but perhaps for machine learning you don't need that very much |
| 2025-07-14 17:23:42 +0200 | <tomsmeding> | sure |
| 2025-07-14 17:23:38 +0200 | <juri_> | I'm not tied-tied yet. it's just the first tool grabbed. |
| 2025-07-14 17:23:18 +0200 | <tomsmeding> | programming models are very similar |
| 2025-07-14 17:23:07 +0200 | <tomsmeding> | if you're not tied to exactly the 'repa' library, tough, repa code and accelerate code should be fairly easily inter-convertible |
| 2025-07-14 17:22:36 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 276 seconds) |
| 2025-07-14 17:22:35 +0200 | <juri_> | tl;dr: future problems. right now, i'm still implementing the transformer block. |
| 2025-07-14 17:22:11 +0200 | <juri_> | oh. yeah. :) |