[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] <shapr> I haven't seen a return of the troll, that's good
[15:18:54] <mtp> yeah
[15:38:54] <shapr> mtp: thanks for making the ban!
[16:08:26] <mtp> no problem :3
[16:45:50] <ephe_meral> 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] <hackerfoo> ephe_meral: I think I did an experiment once with a simple genetic algorithm a long time ago.
[17:20:31] <hackerfoo> More recently, I have used afl-fuzz to fuzz my compiler, which was interesting.
[17:20:56] <shapr> did it find problems?
[17:21:01] <shapr> or generate interesting inputs?
[17:21:12] <hackerfoo> Both
[17:21:22] <shapr> neat
[17:22:17] <hackerfoo> It works really well on my compiler, because my code is loaded with assertions.
[17:23:44] <ephe_meral> 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] <ephe_meral> like the operators in joy... it seems that kind of reduction would reduce the solution space of possible algorithms a lot
[17:25:01] <ephe_meral> maybe even more with additional stack/type signatures
[17:25:40] <hackerfoo> ephe_meral: Concatenative languages work better if you are generating random programs by concatenating them.
[17:25:50] <ephe_meral> for example, yeah
[17:26:46] <hackerfoo> 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] <hackerfoo> I would actually suggest using graphs instead, but it doesn't make much of a difference.
[17:29:31] <ephe_meral> 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] <hackerfoo> Static typing would help to narrow the search space, at least.
[17:29:53] <ephe_meral> if we add additional semantic information to the operations
[17:30:03] <ephe_meral> and let that guide a heuristic
[17:30:40] <hackerfoo> ephe_meral: Go ahead and try it. It's a fun and easy exercise. Just don't expect too much.
[17:30:44] <ephe_meral> like e.g. in what similar data transformation contexts (based on examples or more general rules) has this been used
[17:31:14] <ephe_meral> well more generally the question was how humans do programming
[17:31:23] <ephe_meral> 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] <evincar> Given a type like "type SmallOrBig { case small (UInt8) case big (UInt64) }", what should sizeof(SmallOrBig) be?
[19:33:16] <evincar> I have two options right now:
[19:33:21] <evincar> 1. max(sizeof(UInt8), sizeof(UInt64))+sizeof(Tag)
[19:33:40] <evincar> 2. sizeof(Tag)+sizeof(UInt8) if "small", sizeof(Tag)+sizeof(UInt64) if "big"
[19:33:52] <evincar> 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] <evincar> 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] <evincar> I'm leaning toward #1 for now (and it'll have to be that way in data structures like lists/arrays)
[19:35:45] <evincar> But #2 is attractive for the representation of a value on the stack
[20:56:11] <evincar> Eh, going with fixed-size objects for now, it's way simpler
[21:56:33] <hackerfoo> #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] <hackerfoo> 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).