Logs: freenode/#haskell
| 2021-03-27 18:37:36 | <curl> | can this be called a composition algebra? |
| 2021-03-27 18:37:54 | → | average joins (uid473595@gateway/web/irccloud.com/x-cgevxjwlwytwuber) |
| 2021-03-27 18:38:28 | <curl> | im not sure how to compare it with pipes or conduit for that kind of graph based streaming functions |
| 2021-03-27 18:38:44 | <curl> | but the composed mapAccumL functions seems much more natural |
| 2021-03-27 18:39:08 | <curl> | if we ignore trying to work with branching |
| 2021-03-27 18:39:24 | <curl> | but i guess you have to have that for the API to be complete |
| 2021-03-27 18:39:45 | <curl> | but then have to faff around with zipping and unzipping all these argument lists over a graph somehow |
| 2021-03-27 18:40:38 | <curl> | maybe there is a more natural way to represent this kind of branching of composed functions... |
| 2021-03-27 18:40:48 | <curl> | like lambda syntax or something |
| 2021-03-27 18:41:44 | <curl> | i mean, if this API didnt have branching it would just be category, with (.) |
| 2021-03-27 18:41:59 | <curl> | category + branching seems cool |
| 2021-03-27 18:42:36 | → | minoru_shiraeesh joins (~shiraeesh@46.34.207.84) |
| 2021-03-27 18:42:47 | → | ddellacosta joins (ddellacost@gateway/vpn/mullvad/ddellacosta) |
| 2021-03-27 18:42:52 | <curl> | polyvariadic category? |
| 2021-03-27 18:42:59 | × | __minoru__shirae quits (~shiraeesh@77.94.25.214) (Ping timeout: 265 seconds) |
| 2021-03-27 18:43:38 | <curl> | its a shame the dots it needs are the complicated owl like structures that are so difficult to parse from pointless style |
| 2021-03-27 18:43:51 | <curl> | :t ((.).(.)) |
| 2021-03-27 18:43:52 | <lambdabot> | (b -> c) -> (a1 -> a2 -> b) -> a1 -> a2 -> c |
| 2021-03-27 18:44:36 | <curl> | even fixed points of states |
| 2021-03-27 18:44:44 | <curl> | composing them with themselves a bunch of times |
| 2021-03-27 18:44:52 | <curl> | like an unrolled recursive function |
| 2021-03-27 18:44:58 | → | ddellaco_ joins (~ddellacos@86.106.143.144) |
| 2021-03-27 18:45:19 | → | jamm_ joins (~jamm@unaffiliated/jamm) |
| 2021-03-27 18:45:31 | <curl> | if you can only have trees and not have self reference to make graphs then you cant get recursive reference |
| 2021-03-27 18:46:35 | <curl> | so then haskell syntax is richer than such a tree |
| 2021-03-27 18:47:09 | <curl> | and to represent what we need, to have recursive functions and manage the syntax of programs somehow represented over a graph |
| 2021-03-27 18:47:09 | × | ddellacosta quits (ddellacost@gateway/vpn/mullvad/ddellacosta) (Ping timeout: 246 seconds) |
| 2021-03-27 18:47:24 | <curl> | is to represent a lazy functional langauge |
| 2021-03-27 18:47:38 | <curl> | started from fusion of states in a graph |
| 2021-03-27 18:48:00 | <curl> | now a functional language gets states on its functions |
| 2021-03-27 18:48:17 | <curl> | ie, variable programs |
| 2021-03-27 18:48:34 | <curl> | thats what this graph of state functions basically represents |
| 2021-03-27 18:48:54 | × | carlomagno quits (~cararell@148.87.23.11) (Ping timeout: 246 seconds) |
| 2021-03-27 18:48:57 | <curl> | thinking of states pared with state functions as basically being like variable functions |
| 2021-03-27 18:49:00 | → | carlomagno1 joins (~cararell@148.87.23.11) |
| 2021-03-27 18:49:01 | <curl> | functions with memory |
| 2021-03-27 18:49:11 | <curl> | leading to functional program with memory at the functions |
| 2021-03-27 18:49:31 | × | jamm_ quits (~jamm@unaffiliated/jamm) (Ping timeout: 245 seconds) |
| 2021-03-27 18:49:35 | <curl> | but trying to represent this on a graph in a GADT seems impossible |
| 2021-03-27 18:50:39 | <curl> | ie Haskell itself cant express the structure needed for its own abstract syntax in its recursive state. it probably just evaluates all the references into a big tree |
| 2021-03-27 18:51:01 | <curl> | and never bothers trying to have it in a grpah like thing as the recursive tree proper |
| 2021-03-27 18:51:22 | <curl> | which means if we *could* get a proper graph thing, then it could probably make a nice layer in GHC |
| 2021-03-27 18:51:36 | <curl> | and that then we could work with this kind of syntax tree on an actual graph |
| 2021-03-27 18:51:51 | <curl> | when we interface with GHC's intermediate structures |
| 2021-03-27 18:52:12 | <geekosaur> | I thought STG level was a graph |
| 2021-03-27 18:52:17 | <curl> | not sure if its a few language extensions away from folding in on itself... |
| 2021-03-27 18:52:32 | <curl> | maybe they do the graph thing properly, but not in haskell syntax |
| 2021-03-27 18:52:34 | → | heatsink joins (~heatsink@2600:1700:bef1:5e10:1cfc:5265:7008:dc13) |
| 2021-03-27 18:52:47 | <curl> | its not a GADT we can work with *as a graph* |
| 2021-03-27 18:53:00 | <curl> | like a GADT is *of a tree* |
| 2021-03-27 18:53:21 | <curl> | but if there was one, idk, maybe the STG thing would be easier to represent |
| 2021-03-27 18:53:24 | <curl> | and work with |
| 2021-03-27 18:54:05 | <curl> | and then that this GADT++ language extension would cause a possibly large refactoring of intermediate graph structures of haskell syntax |
| 2021-03-27 18:54:27 | <curl> | which i guess requires the graph for its recursive nature and lazy evaluation |
| 2021-03-27 18:54:29 | × | nbloomf quits (~nbloomf@2600:1700:ad14:3020:16f:a8e3:b3e2:cec6) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-03-27 18:55:39 | <curl> | all it needs is some kind of way of referencing positions in the tree during their GADT construction |
| 2021-03-27 18:56:20 | <curl> | as if they were records |
| 2021-03-27 18:56:56 | <curl> | like as if they were so dependently typed as that their accessing could be used throughout the tree in a typesafe way, but that it was elevated atually into the language syntax |
| 2021-03-27 18:57:36 | <curl> | lists being built from Sum types, dont get nice records |
| 2021-03-27 18:58:47 | <curl> | sum-records could make record-lists, and these at syntax level could be used in GADTs to refer to other parts of themselves by the other records, for "closing edges" |
| 2021-03-27 18:59:43 | → | nbloomf joins (~nbloomf@2600:1700:ad14:3020:16f:a8e3:b3e2:cec6) |
| 2021-03-27 18:59:53 | → | p8m joins (p8m@gateway/vpn/protonvpn/p8m) |
| 2021-03-27 19:00:20 | → | geowiesnot joins (~user@87-89-181-157.abo.bbox.fr) |
| 2021-03-27 19:00:26 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-03-27 19:00:54 | <curl> | the good thing about it being its supposed to support haskell syntax |
| 2021-03-27 19:01:16 | <curl> | so you shuold as a result of this referencing, be able to write recursive programs properly onto the GADT syntax tree |
| 2021-03-27 19:01:49 | <curl> | and be unable to do this in a normal GADT |
| 2021-03-27 19:03:15 | <curl> | as a result of not being able to say while writing the GADT, "the contents thats going here is a copy of some other recursive call to another part of this structure" |
| 2021-03-27 19:04:03 | × | codygman__ quits (~user@47.186.207.161) (Remote host closed the connection) |
| 2021-03-27 19:04:24 | → | codygman__ joins (~user@47.186.207.161) |
| 2021-03-27 19:04:37 | <curl> | eg i should be able to say that the list of branches contains only one branch, and the tree it references is *this node* |
| 2021-03-27 19:05:06 | <curl> | at that point, by saying that, forcing the element to have infinite depth |
| 2021-03-27 19:05:18 | × | Mrbuck quits (~Mrbuck@gateway/tor-sasl/mrbuck) (Quit: WeeChat 2.8) |
| 2021-03-27 19:05:34 | × | geowiesnot quits (~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 260 seconds) |
| 2021-03-27 19:05:50 | → | Sheilong joins (uid293653@gateway/web/irccloud.com/x-dvleaosxdfpycapj) |
| 2021-03-27 19:06:55 | <curl> | i just thought of this sum-records thing now btw, but it kind of makes clearer how such a reference would be made (specifying "this node") |
| 2021-03-27 19:07:46 | → | Reggie_ joins (~reggie@c-73-83-218-159.hsd1.wa.comcast.net) |
| 2021-03-27 19:07:53 | <curl> | i managed to encode haskell datatypes with records as a datatype ok |
| 2021-03-27 19:08:12 | <curl> | maybe it would be possible to implement this sum-records like that aswell |
| 2021-03-27 19:08:25 | <curl> | sounds like too much work for me |
| 2021-03-27 19:08:57 | <curl> | https://gist.github.com/fog-hs/19abbf2ee8cf1f9f0c39abf0772da34e |
| 2021-03-27 19:09:20 | → | idhugo_ joins (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) |
| 2021-03-27 19:09:35 | <curl> | a pair ended up being like; |
| 2021-03-27 19:09:36 | <curl> | FSum HList ('Sum_T name '[ '(name, '[a,b])]) |
| 2021-03-27 19:09:50 | <curl> | that name is the records implementation |
| 2021-03-27 19:10:39 | <curl> | it says its a sum of just one thing, so there is no choice, so even product types are sums of products |
| 2021-03-27 19:11:29 | <curl> | the first name parameter to Sum_T says thats which its "pointing to" like a type level Either thing |
| 2021-03-27 19:12:17 | <curl> | you actually need that when extending to lists of choices, otherwise you cant write things like fromLeft properly |
| 2021-03-27 19:12:31 | <curl> | fromLeft being unsafe |
| 2021-03-27 19:12:52 | × | notzmv quits (~zmv@unaffiliated/zmv) (Ping timeout: 252 seconds) |
| 2021-03-27 19:13:07 | <curl> | ie Either *not* having a type specifying if its left or right is actually the exception because its so short that the unsafe things are allowed |
| 2021-03-27 19:14:11 | <curl> | notice how the "product" part of; |
| 2021-03-27 19:14:12 | <curl> | FSum HList ('Sum_T name '[ '(name, '[a,b])]) |
| 2021-03-27 19:14:18 | × | Reggie_ quits (~reggie@c-73-83-218-159.hsd1.wa.comcast.net) (Ping timeout: 268 seconds) |
| 2021-03-27 19:14:21 | <curl> | which is just '[a.b] |
| 2021-03-27 19:14:40 | <curl> | as the parameters to a typed list (sum of *products*) |
| 2021-03-27 19:14:55 | <curl> | so the contents are unlabled, name only apearing on the sum type |
| 2021-03-27 19:15:55 | × | idhugo_ quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Remote host closed the connection) |
| 2021-03-27 19:16:22 | → | idhugo_ joins (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) |
| 2021-03-27 19:16:33 | <curl> | so im saying that if i zip a list of names there too, so that instead of mimicing haskell syntax, i get records than now extend over both sum and product layers, so should go right down through the GADT, and every position should then have an index |
All times are in UTC.