00:00:00 --- log: started forth/19.09.16 00:17:51 --- join: mtsd (~mtsd@77.110.61.100) joined #forth 00:39:21 --- join: cp (~cp@b157153.ppp.asahi-net.or.jp) joined #forth 01:05:36 --- join: xek_ (~xek@user-94-254-232-167.play-internet.pl) joined #forth 01:11:34 --- join: dys (~dys@2003:5b:203b:100:a64c:c8ff:fef4:13a6) joined #forth 01:19:25 --- quit: xek_ (Ping timeout: 245 seconds) 01:29:44 --- quit: gravicappa (Ping timeout: 268 seconds) 02:11:24 --- quit: rdrop-exit (Quit: Lost terminal) 03:06:31 --- join: xek_ (~xek@user-94-254-232-167.play-internet.pl) joined #forth 03:23:28 --- join: gravicappa (~gravicapp@178.214.255.73) joined #forth 03:31:02 --- join: rdrop-exit (~markwilli@112.201.170.86) joined #forth 03:37:41 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 03:47:22 --- quit: proteusguy (Remote host closed the connection) 04:06:41 --- join: proteusguy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 04:06:42 --- mode: ChanServ set +v proteusguy 04:22:15 --- quit: gravicappa (Ping timeout: 246 seconds) 05:00:31 --- quit: xek_ (Ping timeout: 258 seconds) 06:26:00 --- quit: proteusguy (Ping timeout: 240 seconds) 06:27:14 --- quit: rdrop-exit (Quit: Lost terminal) 06:29:44 --- join: proteusguy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 06:29:44 --- mode: ChanServ set +v proteusguy 06:36:14 --- join: xek (~xek@public-gprs411373.centertel.pl) joined #forth 06:51:28 --- quit: mtsd (Quit: Leaving) 08:09:18 --- quit: xek (Read error: Connection reset by peer) 08:40:40 --- quit: dys (Ping timeout: 245 seconds) 08:57:28 --- join: xek (~xek@user-94-254-232-167.play-internet.pl) joined #forth 09:04:03 --- join: gravicappa (~gravicapp@h109-187-48-254.dyn.bashtel.ru) joined #forth 09:07:33 --- quit: proteusguy (Ping timeout: 250 seconds) 09:07:55 --- quit: proteusdude (Ping timeout: 245 seconds) 09:20:38 --- join: proteusguy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 09:20:38 --- mode: ChanServ set +v proteusguy 09:21:20 --- join: proteusdude (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 09:21:21 --- mode: ChanServ set +v proteusdude 09:53:36 --- quit: gravicappa (Ping timeout: 240 seconds) 10:07:01 --- join: WickedShell (~WickedShe@159-118-128-145.cpe.cableone.net) joined #forth 10:17:06 --- join: xek_ (~xek@public-gprs410816.centertel.pl) joined #forth 10:19:12 --- quit: xek (Ping timeout: 240 seconds) 10:30:17 --- join: karswell (~user@cust125-dsl91-135-5.idnet.net) joined #forth 11:24:32 --- join: gravicappa (~gravicapp@h109-187-48-254.dyn.bashtel.ru) joined #forth 11:43:20 --- join: xek (~xek@user-94-254-232-167.play-internet.pl) joined #forth 11:45:42 --- quit: xek_ (Ping timeout: 258 seconds) 11:46:20 --- quit: gravicappa (Ping timeout: 265 seconds) 11:59:52 --- join: ryke (~Thunderbi@mail.homecaregiverstn.org) joined #forth 12:12:18 --- quit: proteusguy (Ping timeout: 268 seconds) 13:45:48 --- join: imode (~imode@unaffiliated/imode) joined #forth 13:52:24 --- quit: xek (Ping timeout: 246 seconds) 14:46:24 --- quit: ryke (Ping timeout: 240 seconds) 14:49:44 --- join: ryke (~Thunderbi@mail.homecaregiverstn.org) joined #forth 15:24:09 --- quit: ryke (Ping timeout: 245 seconds) 16:02:08 --- join: proteusguy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 16:02:08 --- mode: ChanServ set +v proteusguy 16:04:27 --- quit: proteusdude (Ping timeout: 258 seconds) 16:10:03 --- join: dave0 (~davezero@069.d.003.ncl.iprimus.net.au) joined #forth 16:17:35 --- join: proteusdude (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 16:17:35 --- mode: ChanServ set +v proteusdude 17:14:02 --- join: rdrop-exit (~markwilli@112.201.170.86) joined #forth 19:19:29 --- quit: siraben (Read error: Connection reset by peer) 19:19:38 --- quit: nonlinear[m] (Read error: Connection reset by peer) 19:19:39 --- quit: jimt[m] (Write error: Connection reset by peer) 19:20:28 --- join: ryke (~Thunderbi@71-9-171-192.dhcp.jcsn.tn.charter.com) joined #forth 19:30:41 --- join: jimt[m] (jimtmatrix@gateway/shell/matrix.org/x-iknhclvrwycespwh) joined #forth 19:38:19 --- quit: cheater (Ping timeout: 245 seconds) 19:45:28 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth 19:51:16 --- quit: irsol (*.net *.split) 19:51:16 --- quit: tangentstorm (*.net *.split) 19:51:16 --- quit: pointfree (*.net *.split) 19:56:44 --- join: irsol (~irsol@unaffiliated/contempt) joined #forth 19:56:44 --- join: tangentstorm (michal@learnprogramming/etc/tangentstorm) joined #forth 19:56:44 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-psjnrtwopcehutpy) joined #forth 20:19:20 --- quit: irsol (*.net *.split) 20:19:20 --- quit: tangentstorm (*.net *.split) 20:19:20 --- quit: pointfree (*.net *.split) 20:24:45 --- join: irsol (~irsol@unaffiliated/contempt) joined #forth 20:24:45 --- join: tangentstorm (michal@learnprogramming/etc/tangentstorm) joined #forth 20:24:45 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-psjnrtwopcehutpy) joined #forth 20:25:13 --- join: siraben (sirabenmat@gateway/shell/matrix.org/x-vapwfeoxozaloyoh) joined #forth 20:25:13 --- join: nonlinear[m] (nonlineari@gateway/shell/matrix.org/x-qsewekabumnxlzbj) joined #forth 20:32:25 --- join: gravicappa (~gravicapp@h109-187-48-254.dyn.bashtel.ru) joined #forth 20:50:25 so I have a queue-based language that looks vaguely like Forth. 20:51:41 it's a barebones interpreter in Python, but I'm curious: has anybody swapped Forth's data stack for a queue? 20:52:23 not me 20:53:13 https://repl.it/repls/BrilliantUrbanEyestrain 20:53:13 Someone posted about that a few months ago, was that you? 20:53:28 line 171. no, but was it that guy who gave a talk about FIFOs in Forth? 20:53:35 https://www.reddit.com/r/Forth/comments/7th72t/the_case_for_forth_fifos_in_place_of_stacks_pdf/ <-- this guy? 20:54:36 Don't recall who it was specifically, you'd need to rummage through the archives. 20:55:13 interesting. I've only seen that post. 20:55:40 a queue forth is surprisingly usable. 20:55:53 you can see the implementation of `pick` there. 20:57:30 Thou shalt not PICK; and Thou shalt never ROLL. -- C.Moore 20:57:41 ;-) 20:57:49 the thing that makes the magic happen is `last`, which brings something from the end of the queue to the start. 20:58:27 if you hit the `run` button you can see a queue trace. 20:58:38 As far as I'm concerned, stack are necessary, queues are on an as-need basis 20:59:32 it's a well-known result that you can simulate a stack with a queue but not vice versa. what's interesting is via `roll` and `last`, you can save results for later or recall them arbitrarily. 21:02:04 Sure you can simulate, but stacks are about locality of reference, keeping the top few slots on the stack hot 21:03:09 same goes for a queue. 21:03:22 take a peek at that repl.it link. 21:03:38 line 171 to 239. 21:04:29 I barely had to do anything to convert to using a queue. 21:04:54 Does a queue help with nesting (calls and returns) 21:05:54 you'd still need a return stack if you wanted to do recursion (which is implicity here, using Python's), but I _am_ curious as to what'd happen if you used a call queue instead of a call stack... 21:06:12 via partitioning the queue into two, it's possible to have both the data queue and a return stack in the same memory region. 21:07:22 logically you could also probably fit the dictionary into a single queue, because it's effectively a linear memory store with circular iteration. 21:07:43 there's some result regarding multi-tape turing machines that mentions that. 21:08:18 A Forth stack is not necessarily in RAM, ideally it's on-chip 21:08:56 never said RAM, you can use an internal on-chip circular buffer. 21:09:56 I assumed when you were speaking of memory region, sorry 21:10:23 's all good. 21:11:22 I had another queue-based language (implementation only, you don't actually touch the queue) and didn't think it was _possible_ to, y'know, use a queue for calculations. but it'd be really interesting to have a bunch of words executing concurrently at different places in the queue. I think there's some literature on that somewhere.. 21:14:08 Mill architecture? Belt machine? 21:14:38 https://en.wikipedia.org/wiki/Mill_architecture 21:14:46 isn't that the one where a certain few elements from the head of the queue are directly addressible? 21:14:53 for stuff like pipelining and parallelism. 21:15:25 "Thus, the Mill uses a novel temporal register addressing scheme, the belt by analogy to a conveyor belt." 21:15:36 yeah, that's the one. 21:16:34 "While a belt machine presents an operand queue as the program model, the mill architecture doesn't implement the belt as a physical queue (shift register) in the implemented hardware. Instead it is a semantic representation of the bypass network present in most fast computers, which intercepts pipelined accesses to registers, routing them directly to the execution units that need the result." 21:19:06 it's interesting because a lot of the literature on queue machines says something similar to that. lots of dataflow architectures. 21:19:08 Highly pipelined VLIW, doesn't grab me. 21:20:35 yeah, not into the mill architecture. that and the fact that I'm skeptical they'll ever produce an actual working chip. 21:22:21 I'd prefer a grid of many tiny stack machines + a handful of medium machines 21:23:26 GA144 fan are ye. 21:23:50 love the concept. ring processors are also pretty neat. 21:24:53 that 256-core brainfuck CPU was wild. 21:24:54 Not entirely, I'd prefer a mix 21:25:42 A 2-level hierarchy 21:26:20 Not as homogeneous as what Chuck is doing 21:27:52 I like homogeneous systems. 21:28:47 They tend to not be as practical 21:29:22 there's no reason they can't be. 21:29:28 There have been some studies 21:31:12 In theory maybe, but in practice they're usually not 21:31:26 I think that's due to historical reasons. 21:31:38 nobody really wanted an expensive lisp machine. 21:32:10 It was junk 21:32:26 I'd disagree. 21:33:12 It was never going to be competitive performance wise, no matter what they did 21:33:57 while I agree, I don't think the concept is a bad one. bad executions don't mean the concept is bad. 21:34:37 In engineering you can't ignore economics 21:34:46 my point was that the failure of a lisp machine is the historical precedent for people thinking "this is bad". 21:36:17 My point is heterogeneous is usually more competitive and practical than homogeneous, despite the theorital beauty of homogeneous systems 21:36:44 and designs 21:37:12 Look at the evolution of the FPGA market 21:37:14 you can't really... measure practicality unless you have actual systems out there being used in the same way. 21:37:49 which nobody is doing. because everybody thinks it's a bad idea. 21:38:03 If you can't get your systems out there in the first place, maybe they're not practical 21:38:43 catch 22. nobody wants to design homogenous systems because they're not popular due to a historical precedent, therefore there are no homogenous systems out there. 21:39:05 it's funny you're saying this in a Forth channel too. a Forth system is homogenous from bottom to top software wise (and hardware). 21:40:49 Are you saying that disproves my point? 21:41:04 ;-) 21:41:20 just saying that it's funny you're saying it in a forth system. 21:41:30 s/system/channel 21:42:00 I'll try to dig up some papers 21:42:35 --- part: imode left #forth 22:26:23 --- quit: WickedShell (Remote host closed the connection) 23:10:41 --- quit: dddddd (Remote host closed the connection) 23:42:55 --- quit: proteusguy (Ping timeout: 258 seconds) 23:44:59 --- quit: proteusdude (Ping timeout: 245 seconds) 23:48:28 --- join: proteusguy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 23:48:28 --- mode: ChanServ set +v proteusguy 23:52:48 --- quit: proteusguy (Ping timeout: 240 seconds) 23:57:54 --- join: xek (~xek@user-94-254-232-167.play-internet.pl) joined #forth 23:59:24 --- join: proteusdude (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 23:59:24 --- mode: ChanServ set +v proteusdude 23:59:59 --- log: ended forth/19.09.16