[00:13:38] * evincar [evincar!~jonathanp@173-228-12-115.dsl.dynamic.fusionbroadband.com] has quit (Ping timeout: 255 seconds). [01:01:00] * jtimon [jtimon!~quassel@199.31.134.37.dynamic.jazztel.es] has joined the channel. [04:16:38] * tgunr [tgunr!~tgunr@cpe-76-173-79-238.hawaii.res.rr.com] has quit (Read error: Connection reset by peer). [04:18:03] * tgunr [tgunr!~tgunr@cpe-76-173-79-238.hawaii.res.rr.com] has joined the channel. [06:07:13] * FreeFull [FreeFull!~freefull@defocus/sausage-lover] has quit. [06:09:00] * strmpnk [strmpnk!sid2261@gateway/web/irccloud.com/x-iuycnljhbmapbyqj] has quit (*.net *.split). [06:09:01] * rgrinberg [rgrinberg!sid50668@gateway/web/irccloud.com/x-qiyduqufojhpgzfg] has quit (*.net *.split). [06:09:01] * lonjil [lonjil!~quassel@2a02:418:6050:ed15:ed15:ed15:e741:32d6] has quit (*.net *.split). [06:10:23] * rgrinberg [rgrinberg!sid50668@gateway/web/irccloud.com/x-zvkufqehjqorigvz] has joined the channel. [06:10:31] * strmpnk [strmpnk!sid2261@gateway/web/irccloud.com/x-fditkavblrudgfht] has joined the channel. [06:14:28] * lonjil [lonjil!~quassel@2a02:418:6050:ed15:ed15:ed15:e741:32d6] has joined the channel. [09:22:25] * madmalik [madmalik!uid13697@gateway/web/irccloud.com/x-mgxpgeuwvvjctwin] has joined the channel. [12:56:23] * jtimon [jtimon!~quassel@199.31.134.37.dynamic.jazztel.es] has quit (Ping timeout: 248 seconds). [14:29:30] I haven't seen a return of the troll, that's good [15:18:54] yeah [15:38:54] mtp: thanks for making the ban! [16:08:26] no problem :3 [16:45:50] hi! i was wondering, has anyone tried targeting concatinative languages for program synthesis? i.e. as a basis for something like inductive programming? [17:06:40] * FreeFull [FreeFull!~freefull@defocus/sausage-lover] has joined the channel. [17:19:26] ephe_meral: I think I did an experiment once with a simple genetic algorithm a long time ago. [17:20:31] More recently, I have used afl-fuzz to fuzz my compiler, which was interesting. [17:20:56] did it find problems? [17:21:01] or generate interesting inputs? [17:21:12] Both [17:21:22] neat [17:22:17] It works really well on my compiler, because my code is loaded with assertions. [17:23:44] well, my unfounded hypothesis is that concatenative languages might be an interesting target because of their inherent simplicity and because of the way abstractions can be introduced [17:24:39] like the operators in joy... it seems that kind of reduction would reduce the solution space of possible algorithms a lot [17:25:01] maybe even more with additional stack/type signatures [17:25:40] ephe_meral: Concatenative languages work better if you are generating random programs by concatenating them. [17:25:50] for example, yeah [17:26:46] It doesn't really solve the underlying problem that the search space is huge, high dimensional, and incredibly spiky, all things that make search and optimization ineffective. [17:28:07] I would actually suggest using graphs instead, but it doesn't make much of a difference. [17:29:31] hackerfoo: yes, but i think we can do better - since with this concatenation you could probably construct candidate algorithms one operation at a time [17:29:33] Static typing would help to narrow the search space, at least. [17:29:53] if we add additional semantic information to the operations [17:30:03] and let that guide a heuristic [17:30:40] ephe_meral: Go ahead and try it. It's a fun and easy exercise. Just don't expect too much. [17:30:44] like e.g. in what similar data transformation contexts (based on examples or more general rules) has this been used [17:31:14] well more generally the question was how humans do programming [17:31:23] and whether that can be simulated in some domains [17:59:17] * tgunr [tgunr!~tgunr@cpe-76-173-79-238.hawaii.res.rr.com] has quit (Quit: Textual IRC Client: www.textualapp.com). [19:05:37] * evincar [evincar!~jonathanp@173-228-12-115.dsl.dynamic.fusionbroadband.com] has joined the channel. [19:33:10] Given a type like "type SmallOrBig { case small (UInt8) case big (UInt64) }", what should sizeof(SmallOrBig) be? [19:33:16] I have two options right now: [19:33:21] 1. max(sizeof(UInt8), sizeof(UInt64))+sizeof(Tag) [19:33:40] 2. sizeof(Tag)+sizeof(UInt8) if "small", sizeof(Tag)+sizeof(UInt64) if "big" [19:33:52] Option 1 means a fixed size but wasted space [19:34:15] * jtimon [jtimon!~quassel@199.31.134.37.dynamic.jazztel.es] has joined the channel. [19:35:00] Option 2 means constructing & pattern-matching on a value doesn't need to adjust the stack because it can just push/pop the tag [19:35:31] I'm leaning toward #1 for now (and it'll have to be that way in data structures like lists/arrays) [19:35:45] But #2 is attractive for the representation of a value on the stack [20:56:11] Eh, going with fixed-size objects for now, it's way simpler [21:56:33] #2 also requires that you determine the values in order, where with #1, you can reserve space and then write out of order, which can be useful. [21:57:29] It's best to avoid dependencies, because it can make optimization and parallelism difficult. [23:45:32] * madmalik [madmalik!uid13697@gateway/web/irccloud.com/x-mgxpgeuwvvjctwin] has quit (Quit: Connection closed for inactivity).