Logs: freenode/#haskell
| 2020-10-17 05:13:30 | <davean> | yes, thats what tcpdump helps with |
| 2020-10-17 05:13:35 | <davean> | or libpcap |
| 2020-10-17 05:13:42 | <larou> | ah, its to do with matching on record accessor names |
| 2020-10-17 05:13:45 | <davean> | But you can capture online without root |
| 2020-10-17 05:14:03 | <larou> | all my datatypes are just like HLists or whatever |
| 2020-10-17 05:14:05 | <davean> | gnumonik: you can code-gen the tables of names to lenses also |
| 2020-10-17 05:14:19 | × | toorevitimirp quits (~tooreviti@117.182.180.0) (Client Quit) |
| 2020-10-17 05:14:22 | <larou> | so you have "positional" data other than "record names" |
| 2020-10-17 05:14:40 | <larou> | i guess thats actually a pretty serious limitation for most practical uses |
| 2020-10-17 05:14:43 | <larou> | damn... |
| 2020-10-17 05:14:45 | <gnumonik> | You can kind of use type classes and higher rank types to pass another function to the String -> Lens function, but to get composition I'm pretty sure you need something like, (again) forall a c. (forall b. Lens' a b -> c) -> String -> c. If I'm wrong about that let me know but I can't think of anything |
| 2020-10-17 05:15:38 | <larou> | wait, isnt that what the template haskell machinery for autoderiving lesnes is for? |
| 2020-10-17 05:15:45 | <gnumonik> | And yeah I know about capabilities and was glossing over that, but anyway there has to be something better than lugging around most of GHCI to parse...record selectors |
| 2020-10-17 05:16:18 | <davean> | I'm confused why you're talking about doing the lenses the way you are - can you restate the problem? Because that signature doesn't make sense for what I understand you want |
| 2020-10-17 05:16:19 | → | toorevitimirp joins (~tooreviti@117.182.180.0) |
| 2020-10-17 05:16:39 | <larou> | well, i was doing it for scientific computations, where "locality" on a manifold is basically the end goal |
| 2020-10-17 05:16:45 | <dsal> | If you're using lens for "record selectors" then that might be the wrong tool for the job, especially if the job is an interactive runtime that behaves like haskell, but isn't haskell. |
| 2020-10-17 05:16:45 | <larou> | you just have structured access paterns |
| 2020-10-17 05:17:15 | <larou> | all the data is selected relative to some position, so all this string names stuff just never arises |
| 2020-10-17 05:17:49 | × | ephemera_ quits (~E@122.34.1.187) (Ping timeout: 258 seconds) |
| 2020-10-17 05:17:56 | <larou> | trying to enumerate all the different names would just be totally pointless! |
| 2020-10-17 05:18:08 | × | codedmart quits (~codedmart@149.28.9.205) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2020-10-17 05:18:09 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-10-17 05:18:13 | <gnumonik> | Well they're not actually just record selectors, and technically I need prisms too so talking about lenses is a bit wrong (is the general term for lens-ey things 'optics'?). Lemme try to restate the problem, gimme a min |
| 2020-10-17 05:18:25 | → | codedmart joins (~codedmart@149.28.9.205) |
| 2020-10-17 05:18:31 | <larou> | i guess i quotient away all the isomorphisms by record renaming as an equivalence class |
| 2020-10-17 05:18:51 | <davean> | Yah, optics |
| 2020-10-17 05:18:57 | × | anik quits (~anik@103.23.207.140) (Quit: My MacBook Air has gone to sleep. ZZZzzz…) |
| 2020-10-17 05:19:16 | <larou> | so isnt it just about the "shape" at the end of the day? |
| 2020-10-17 05:20:13 | → | pjb joins (~t@2a01cb04063ec50040327e18e003ea94.ipv6.abo.wanadoo.fr) |
| 2020-10-17 05:20:45 | <larou> | and then the logis is something like, lists are good. and then you Fix them and hopefully get graphs at some point |
| 2020-10-17 05:21:04 | <larou> | again, something to do with isomorphisms |
| 2020-10-17 05:21:30 | → | ephemera_ joins (~E@122.34.1.187) |
| 2020-10-17 05:21:38 | <larou> | and then with type hetroginaity you get the most general structure thats isomorphic to everything else |
| 2020-10-17 05:21:55 | <larou> | ah, that was the problem, the nested states were unfolding type hetroginous things |
| 2020-10-17 05:22:03 | <larou> | horror |
| 2020-10-17 05:22:41 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2020-10-17 05:22:59 | → | zoran119 joins (~zoran119@124-169-31-193.dyn.iinet.net.au) |
| 2020-10-17 05:23:24 | <larou> | i guess thats the point about product base functors |
| 2020-10-17 05:23:40 | <gnumonik> | So I have a DSL. Just for elaboration, the DSL is some pretty simple syntactical sugar over Edward KMett's "Machines" library, and the point is to allow for generation/modification/performing side effects with streams of network packets. I wrote the DSL on the assumption that there'd be some way to translate strings into optics in such a way that, if, e.g., _Foo is a prism and bar is a lens, you could type "Foo . bar" in the dsl |
| 2020-10-17 05:23:40 | <gnumonik> | to access the bar field of a product type inside a sum type "Foo." But.. I can't figure out how to go from string to the optics in a way that lets them compose. |
| 2020-10-17 05:24:03 | <gnumonik> | Again this is my first real haskell program ever, so I dunno if that was a horrid idea or if there's some obviously better approach |
| 2020-10-17 05:24:37 | <davean> | mmm, I see |
| 2020-10-17 05:25:01 | <larou> | wait, i thought lenses composed good |
| 2020-10-17 05:25:23 | <davean> | larou: he needs to match the type, but he's at runtime, so he has to prove he only composes correct ones ever |
| 2020-10-17 05:25:24 | → | bifunc2 joins (bifunc2@gateway/vpn/protonvpn/bifunc2) |
| 2020-10-17 05:25:31 | <davean> | Which is doable |
| 2020-10-17 05:25:33 | <gnumonik> | they do. as a *library* everything would work fine. but i wanted this to be used by people who won't install ghc |
| 2020-10-17 05:25:45 | <gnumonik> | er usable at least |
| 2020-10-17 05:25:55 | <larou> | whaaaat!? |
| 2020-10-17 05:26:01 | <bifunc2> | Can an integration test be done within an HUnit testCase, or are there more usual ways to do integration tests? |
| 2020-10-17 05:26:03 | <davean> | A) Thats not what lenses are for, B) I can see how to do it, but I'm not sure how much you'd like it |
| 2020-10-17 05:26:04 | <larou> | why throw away the compiler!? |
| 2020-10-17 05:26:24 | <davean> | gnumonik: You'd want a Map for every starting type, and return the result type with it |
| 2020-10-17 05:26:38 | <larou> | i thought DSLs were supposed to *leverage* the typechecker into their own type systems |
| 2020-10-17 05:26:40 | <davean> | it'll compose, you can fold them together |
| 2020-10-17 05:26:51 | <davean> | larou: depends on how deeply embeded they are, for example |
| 2020-10-17 05:27:11 | <larou> | hmmm |
| 2020-10-17 05:27:32 | <larou> | like, if they are supposed to do something the haskell typesystem cant? |
| 2020-10-17 05:28:14 | <davean> | I mean thats exactly one case |
| 2020-10-17 05:28:14 | <gnumonik> | Wait a Data.Map map? I'm a little confused on how that would work if the data types don't contain fields of all the same type. (Do heteogenous maps exist?) I might not be understanding you |
| 2020-10-17 05:28:31 | <larou> | in which case wouldnt it be better to compile it to a subset of haskell that *is* expressive enough? |
| 2020-10-17 05:29:04 | <gnumonik> | Yeah, I was a little ambitious in thinking that "Oh hey lenses are really neat, lemme throw them in my DSL as expressions". Or I didn't know enough to know that that wasn't a good idea |
| 2020-10-17 05:29:08 | → | unlink2 joins (~unlink2@p200300ebcf17c500f1cd4c5efbdddd1e.dip0.t-ipconnect.de) |
| 2020-10-17 05:29:22 | <larou> | not really sure how Map is implemented tbh... can you emulate it using list? |
| 2020-10-17 05:29:34 | <davean> | gnumonik: You can make them hetrogenious, or dependent. I was suggesting sometihng like (data OpticMap s = OMap (Map String (forall r . (Optic s r, r))) |
| 2020-10-17 05:30:11 | <larou> | and that impredictive right? |
| 2020-10-17 05:30:19 | <larou> | thats* |
| 2020-10-17 05:30:30 | <davean> | gnumonik: if you store the tag, you can look up the correct map next time ... etc |
| 2020-10-17 05:30:44 | <davean> | gnumonik: it'll get ugly, but you can make it work. I'm not sure you want to. |
| 2020-10-17 05:30:59 | <larou> | is the issue that a HList with a pair with an accessor index would be slow to lookup? |
| 2020-10-17 05:31:19 | <davean> | gnumonik: to be clear, I hate this approach |
| 2020-10-17 05:31:21 | <gnumonik> | I've been trying to solve this problem for a month out of sheer anger that I couldn't do it, I don't really care if it's ugly at this point :p |
| 2020-10-17 05:31:24 | <larou> | i mean, maybe you could use some kind of tree based thing thats faster.. |
| 2020-10-17 05:31:42 | <davean> | I'm pretty sure it'll work |
| 2020-10-17 05:32:17 | × | stree quits (~stree@50-108-72-205.adr01.mskg.mi.frontiernet.net) (Quit: Caught exception) |
| 2020-10-17 05:32:25 | <larou> | i cant tell if vinyl would be helpful... |
| 2020-10-17 05:32:34 | → | stree joins (~stree@50-108-72-205.adr01.mskg.mi.frontiernet.net) |
| 2020-10-17 05:33:27 | <larou> | runtime typechecking sounds off though... never seen that |
| 2020-10-17 05:33:31 | <davean> | you know the result type because you get a token and look up the next in the map that starts with that by having a top level map like Map 'r (forall s . Map String (forall r . (Optic s r, r)) |
| 2020-10-17 05:33:59 | <davean> | So your'e chaining through the connecting type |
| 2020-10-17 05:34:01 | <davean> | but ugh |
| 2020-10-17 05:34:06 | <davean> | Its *basicly* a type checker |
| 2020-10-17 05:34:14 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-10-17 05:34:32 | <davean> | Just linear chaining |
| 2020-10-17 05:34:54 | <davean> | er |
| 2020-10-17 05:35:00 | <larou> | what about parallel? |
| 2020-10-17 05:35:04 | <davean> | I mixed up an r and s above |
| 2020-10-17 05:35:08 | <larou> | like zipwith |
| 2020-10-17 05:35:11 | <gnumonik> | ohhhh I see now. That might work. That might not even be that bad. I have some template haskell that generates type for a data type and its subtypes (I know they aren't real subtypes, components I guess) until it reaches a "primitive" type (relative to the DSL) |
| 2020-10-17 05:35:18 | <gnumonik> | that I could probably use |
| 2020-10-17 05:35:24 | <larou> | im sure some mix of those two should be arbitrarily expressive |
| 2020-10-17 05:35:51 | <larou> | hmm, maybe its the difference between successive flat layers and a lattice like partial order for an arbitrary graph |
| 2020-10-17 05:36:06 | <larou> | the good thing about layers is they are obviously ordered |
| 2020-10-17 05:36:13 | <davean> | gnumonik: At least I gave you something to consider. |
| 2020-10-17 05:36:54 | <zoran119> | is anyone using vscode + haskell-language-server (with haskell.haskell plugin in vscode)? got to definition should work there, right? it doesn't seem to be able to find definition of my modules in other source files (only current source file)... |
| 2020-10-17 05:37:17 | <larou> | i really wanted something that could represent modern computing architectures so you could compile to bitcode for the virtual version and run it on regular hardware |
| 2020-10-17 05:37:24 | <gnumonik> | I appreciate it! I've been smashing my face against this for so long that any way of making it work is relieving |
| 2020-10-17 05:37:56 | <larou> | its the realisation thats the obstacle |
| 2020-10-17 05:38:36 | <gnumonik> | Though, actually, running into this problem made me dive deep into TH/Generics.SOP and really figure out the lens library at some depth, so I suppose it was a good problem to run into. |
All times are in UTC.