[00:11:37] * jamtho [jamtho!~jamtho@host217-42-112-25.range217-42.btcentralplus.com] has joined the channel. [00:47:50] * jtimon [jtimon!~quassel@73.189.35.88] has joined the channel. [01:36:43] * Sonderblade [Sonderblade!~bjourne@h-52-183.A157.priv.bahnhof.se] has joined the channel. [01:44:51] * jamtho [jamtho!~jamtho@host217-42-112-25.range217-42.btcentralplus.com] has quit (Remote host closed the connection). [01:45:21] * jamtho [jamtho!~jamtho@host217-42-112-25.range217-42.btcentralplus.com] has joined the channel. [01:49:58] * jamtho [jamtho!~jamtho@host217-42-112-25.range217-42.btcentralplus.com] has quit (Ping timeout: 255 seconds). [01:50:11] * jtimon [jtimon!~quassel@73.189.35.88] has quit (Remote host closed the connection). [02:00:53] * evincar [evincar!~jonathanp@75-142-42-181.dhcp.reno.nv.charter.com] has joined the channel. [02:01:39] I'm working toward making everything unboxed by default in Kitten [02:02:58] Currently [1, 2, 3] has type (-> List) and { 1 } has type (-> (-> Int32)), and both of these are boxed [02:04:31] I'm considering adding {| ... |} for an unboxed closure and [| 1, 2, 3 |] for an unboxed array (Int32^3) [02:05:10] But I'm not sure which meaning to assign to which syntax [02:05:45] That is, [...] and {...} could be unboxed while [|...|] and {|...|} could be boxed [02:06:51] I dunno whether it's better to make the "default" (simpler notation without ||) more performant but less usable, or vice versa [02:07:27] Since there'll necessarily be a few more limitations on unboxed types [02:12:03] jeaye: Hey [02:14:56] evincar: Yo, good to see you're alive. :) [02:15:24] jeaye: Thanks, ditto :) [02:16:25] What do you think about the above? Should I use [...]+{...} for boxed lists & closures and [|...|]+{|...|} for unboxed, or vice versa? [02:17:47] In C++ terms: boxed list = std::vector, unboxed list = array, boxed closure = std::function, unboxed closure = lambda [02:17:57] I would lean toward having [..] and {..} be unboxed and making them as usable as possible. [02:18:58] I'll have to figure out how to get map/fold/etc. to work with unboxed arrays then [02:19:11] I think that'd be preferable, from a user's standpoint. [02:19:18] Otherwise they're not terribly useful [02:19:23] Yeah, at least for performance [02:19:30] Though it'd be much harder for you. [02:19:42] [|...|] and {|...|} seem like good syntax for explicit boxing. [02:19:48] Then [1, 2, 3] (unboxed array) would have the same representation at runtime as 1 2 3 (numbers on the stack) [02:20:09] They're just "grouped" by the types [02:20:22] I see. [02:21:35] Hm, if I had slices that could be used for iteration, I could use them to implement operations over both boxed and unboxed lists [02:21:49] With anonymous functions, it's more difficult, but it would be in line with what C++ does regarding boxing. [02:22:13] []{} => unboxed; [&]{} => boxed [02:22:39] Well no, lambdas have unboxed closures in C++ unless you put them in std::function [02:22:49] They're stack-allocated structs [02:23:03] umm [02:23:07] You're right. [02:23:16] However, that does raise an important point [02:23:34] That if the closure is empty, it should be usable as a C function pointer [02:23:45] Yes, that's where my line of thought was going. [02:23:54] That's how it works in C++ as well. [02:24:08] I can probably have an unsafe primitive to split a closure into the captured values + a function pointer [02:24:16] So you could pass them to C APIs with "user data" parameters [02:24:22] That'd be pretty slick. [02:24:35] Like pthread_create or something [02:25:41] I have been redesigning a lot of jank and would love to run some of it by you. We should meet up sometime soon. [02:26:32] Cool, I'd be down [02:26:48] You still live in the same place? [02:27:09] Yes, but currently visiting the gf, so I'm out of town [02:27:26] No problem; that means you're like 3 blocks from us though. [02:27:37] Oh cool :) [02:28:22] I dunno how much longer I'm going to be there, since we're gonna try to move later this summer [02:28:33] Most likely to the east bay [02:28:49] Why's that? [02:30:45] We want to get a place together, my current place won't accept her on the lease, and I'd like to spend less [02:31:23] They have a policy that *each* tenant must be able to pay the full rent [02:31:47] And that's probably not going to happen right now because she's just recently graduated [02:33:46] Make sense. [02:33:57] Well, I'll try to catch you before you go. [02:46:06] Hm, not sure how to implement unboxed operations efficiently in a way that's easy to typecheck [02:46:28] e.g., map (A^N, (A -> B) -> B^N) [02:46:53] Could be implemented like: -> f; [||] { f call append } fold_left to_array [02:47:12] That is, it builds a boxed list of the results then unboxes it [02:47:35] (Assuming unboxed lists are foldable here) [02:48:28] You can't incrementally build up an unboxed array because its type changes according to its size [02:50:49] I could do it unsafely, but it'd be nice to have these things checked as much as possible [02:51:59] Eh, I'll figure it out [02:52:59] Thought of a neat little feature recently, sorta borrowed from Perl [02:53:36] "..." as an expression always typechecks, but aborts at runtime with a "not yet implemented" failure [02:54:22] So you could write "define foo (Int32 -> Int32) { ... }" with the implementation to be filled in later [02:54:53] Might also report its inferred type in the failure message [02:55:10] Should make it a little easier to build programs up incrementally [03:01:34] It's analogous to "typed holes" with -fdefer-type-errors in Haskell [03:20:09] evincar Thats a stupid rule your landlord imposes if you ask me [03:21:41] * FreeFull [FreeFull!~freefull@defocus/sausage-lover] has quit (Ping timeout: 255 seconds). [03:48:31] tgunr: Yup. I understand it if you're taking on multiple tenants at once, but if I want to add someone to the lease...I've already been paying 100% of the rent and could continue to do so [04:56:21] * evincar [evincar!~jonathanp@75-142-42-181.dhcp.reno.nv.charter.com] has quit (Ping timeout: 260 seconds). [08:01:43] * Sgeo_ [Sgeo_!~Sgeo@ool-18e4354b.dyn.optonline.net] has joined the channel. [08:03:03] * Sgeo [Sgeo!~Sgeo@ool-18e4354b.dyn.optonline.net] has quit (Ping timeout: 268 seconds). [15:03:20] evincar: It's probably because eviction is difficult. If you add someone to the lease and then leave, the landlord would probably have a hard time getting the remaining tenant evicted. [16:08:10] * FreeFull [FreeFull!~freefull@defocus/sausage-lover] has joined the channel. [16:19:08] * Sgeo__ [Sgeo__!~Sgeo@ool-18e4354b.dyn.optonline.net] has joined the channel. [16:21:56] * Sgeo_ [Sgeo_!~Sgeo@ool-18e4354b.dyn.optonline.net] has quit (Ping timeout: 268 seconds). [16:22:27] * MDead [MDead!~MDude@pa-67-234-94-147.dhcp.embarqhsd.net] has joined the channel. [16:24:47] * MDude [MDude!~MDude@pa-67-234-94-147.dhcp.embarqhsd.net] has quit (Ping timeout: 240 seconds). [16:24:54] * MDead is now known as MDude [18:04:39] * Sonderblade [Sonderblade!~bjourne@h-52-183.A157.priv.bahnhof.se] has quit (Quit: Konversation terminated!). [18:23:09] * FreeFull [FreeFull!~freefull@defocus/sausage-lover] has quit (Ping timeout: 240 seconds). [21:10:29] * jamtho_ [jamtho_!~jamtho@host217-42-112-25.range217-42.btcentralplus.com] has joined the channel. [21:11:31] * colonelj [colonelj!~kernelj@unaffiliated/colonelj] has joined the channel. [21:59:05] * jtimon [jtimon!~quassel@c-73-189-35-88.hsd1.ca.comcast.net] has joined the channel. [22:37:17] * flogbot [flogbot!~flogbot@2001:4800:7814:0:2804:b05a:ff04:4ba7] has quit (Ping timeout: 276 seconds). [22:37:25] * flogbot [flogbot!~flogbot@2001:4800:7814:0:2804:b05a:ff04:4ba7] has joined the channel. [22:37:25] :wilhelm.freenode.net 353 flogbot = #concatenative :flogbot jtimon colonelj jamtho_ MDude Sgeo__ tgunr mollerse erg rotty hackerfoo m_hackerfoo dustinm` shachaf doublec puckipedia otoburb kanzure earl carvite merry rjungemann diginet strmpnk bmp PiDelport shmibs rgrinberg ephe_meral lonjil flout jeremyheiler jeaye groovy2shoes [22:37:25] :wilhelm.freenode.net 366 flogbot #concatenative :End of /NAMES list. [22:39:47] * evincar [evincar!~jonathanp@75-142-42-181.dhcp.reno.nv.charter.com] has joined the channel. [22:43:52] * jamtho [jamtho!~jamtho@host217-42-112-25.range217-42.btcentralplus.com] has joined the channel. [22:45:15] * jtimon [jtimon!~quassel@c-73-189-35-88.hsd1.ca.comcast.net] has quit (Ping timeout: 260 seconds). [22:46:08] * jamtho_ [jamtho_!~jamtho@host217-42-112-25.range217-42.btcentralplus.com] has quit (Ping timeout: 276 seconds). [23:31:26] * evincar [evincar!~jonathanp@75-142-42-181.dhcp.reno.nv.charter.com] has quit (Ping timeout: 255 seconds). [23:47:53] * jtimon [jtimon!~quassel@c-73-189-35-88.hsd1.ca.comcast.net] has joined the channel.