2025/07/14

Newest at the top

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 +0200pavonia(~user@user/siracusa) (Ping timeout: 248 seconds)
2025-07-14 18:42:19 +0200perro(~aaron@syn-072-191-245-069.res.spectrum.com) (Ping timeout: 268 seconds)
2025-07-14 18:41:42 +0200Jerryeee(~Thunderbi@user/Jerryeee) (Quit: Jerryeee)
2025-07-14 18:34:58 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Remote host closed the connection)
2025-07-14 18:33:36 +0200wootehfoot(~wootehfoo@user/wootehfoot) wootehfoot
2025-07-14 18:30:36 +0200ttybitnik(~ttybitnik@user/wolper) ttybitnik
2025-07-14 18:28:52 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf) ezzieyguywuf
2025-07-14 18:28:21 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf) (Ping timeout: 252 seconds)
2025-07-14 18:27:30 +0200dtman34(~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) (Client Quit)
2025-07-14 18:26:26 +0200merijn(~merijn@77.242.116.146) (Ping timeout: 248 seconds)
2025-07-14 18:25:11 +0200Jerryeee(~Thunderbi@user/Jerryeee) Jerryeee
2025-07-14 18:24:34 +0200dtman34(~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) dtman34
2025-07-14 18:23:58 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh
2025-07-14 18:23:53 +0200sp1ff(~user@c-67-160-173-55.hsd1.wa.comcast.net) sp1ff
2025-07-14 18:23:42 +0200dtman34(~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 +0200poscat(~poscat@user/poscat) poscat
2025-07-14 18:13:01 +0200poscat(~poscat@user/poscat) (Remote host closed the connection)
2025-07-14 18:11:15 +0200dtman34(~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34
2025-07-14 18:10:15 +0200dtman34(~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 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Ping timeout: 248 seconds)
2025-07-14 18:07:10 +0200caubert(~caubert@user/caubert) caubert
2025-07-14 18:06:34 +0200trickard_(~trickard@cpe-92-98-47-163.wireline.com.au)
2025-07-14 18:03:51 +0200trickard(~trickard@cpe-92-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-07-14 17:54:58 +0200caubert(~caubert@user/caubert) (Ping timeout: 272 seconds)
2025-07-14 17:46:08 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-07-14 17:44:58 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Read error: Connection reset by peer)
2025-07-14 17:38:44 +0200weary-traveler(~user@user/user363627) user363627
2025-07-14 17:30:22 +0200ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2025-07-14 17:29:44 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-07-14 17:28:31 +0200weary-traveler(~user@user/user363627) (Remote host closed the connection)
2025-07-14 17:28:13 +0200ChaiTRex(~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 +0200acidjnk(~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 +0200CiaoSen(~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. :)
2025-07-14 17:22:11 +0200 <tomsmeding> you can certainly interpret accelerate into repa but that's... a bit pointless?
2025-07-14 17:21:53 +0200 <tomsmeding> that's the other way round
2025-07-14 17:21:48 +0200 <tomsmeding> yeah repa's typing is not suitable for a deeply embedded language
2025-07-14 17:21:47 +0200 <juri_> https://github.com/blambo/accelerate-repa looks like someone's attempt.. 14 years back. :)
2025-07-14 17:20:43 +0200 <tomsmeding> I expect that the typing of repa is too haskelly to be able to make a proper "accelerate backend" for repa
2025-07-14 17:19:54 +0200 <juri_> accelerate-io-repa is part of it. haven't done the "does it work" legwork.