00:00:00 --- log: started forth/12.03.23 00:02:25 --- log: started forth/12.03.23 00:02:25 --- join: clog (~nef@bespin.org) joined #forth 00:02:25 --- topic: 'Forth Programming | logged by clog at http://bit.ly/91toWN | links: qr.net/gforth isforth.com forthfreak.net qr.net/ans_standard | Buy forth chips from www.greenarraychips.com | prize money for coding an efficient SHA-256 hashing algorithm for the chips, talk to docl or foucist' 00:02:25 --- topic: set by foucist!~foucist@ps14150.dreamhost.com on [Thu Jan 19 01:03:52 2012] 00:02:25 --- names: list (clog +tschak_ +ttmrichter +Snoopy_1711 +Snoopy_1611 +karswell +MrBusiness +kulp +remyhr +Nisstyre +segher +newcup +ASau +boulon1515 +DGASAU` +dom96 +cataska +crc +nighty^ +nighty +mark4 +Inode +malyn +koisoke +ivan` +shachaf +kandinski +yiyus +nottwo +_phred) 00:02:26 --- mode: ChanServ set +v clog 00:36:48 --- quit: ttmrichter (Quit: Leaving) 00:58:52 --- join: sunwukong (~vukung@catv-80-98-247-63.catv.broadband.hu) joined #forth 00:58:53 --- mode: ChanServ set +v sunwukong 01:27:11 --- join: ttmrichter (~ttmrichte@61.184.205.206) joined #forth 01:27:11 --- mode: ChanServ set +v ttmrichter 02:41:46 --- quit: MrBusiness (Quit: Leaving) 02:51:14 --- quit: Snoopy_1611 () 02:51:14 --- quit: Snoopy_1711 (Read error: Connection reset by peer) 06:58:49 --- join: nighty- (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 06:58:49 --- mode: ChanServ set +v nighty- 08:01:04 --- nick: kulp -> ku|p 08:01:15 --- nick: ku|p -> kuilp 08:01:18 --- nick: kuilp -> kulp 09:04:42 --- join: Kumul (~Kumul@adsl-72-50-91-28.prtc.net) joined #forth 09:04:43 --- mode: ChanServ set +v Kumul 09:22:50 --- join: MayDaniel (~MayDaniel@unaffiliated/maydaniel) joined #forth 09:22:51 --- mode: ChanServ set +v MayDaniel 10:08:01 --- quit: ttmrichter (Quit: Leaving) 10:47:01 --- nick: kulp -> kwlp 10:47:39 --- nick: kwlp -> percom 10:47:45 --- quit: percom (Disconnected by services) 10:47:55 --- join: kulp_ (~kulp@rox.li) joined #forth 10:47:56 --- mode: ChanServ set +v kulp_ 10:48:04 --- nick: kulp_ -> kwlp 10:48:16 --- part: kwlp left #forth 12:12:19 I'm slightly stuck about what to do about about execution tokens on a virtual machine. I need first-class environments. Static scope is OK and of course native code is always generated within the context of a lexical environment, so for that case, a return stack with plain return pointers is fine. 12:12:50 However, I want to be lazy and do a bootstrap version with some variant of token threading and no native compilation. 12:13:13 So either an execution token must consist of the code pointer and an environment pointer, or else it must be a reference to some heap-allocated object with the same information. 12:14:49 It would be convenient to have execution tokens in the same format as entities on the return stack, and allocating heap space for the XT,ENV pair on each branch would be awfully inefficient, so the return stack should probably be double-wide. 12:15:10 This is a bit clumsy, but otherwise fine, until I want to transition to native code generation. 12:19:06 Basically I have quotations/word definitions that are tied together with objects that append a quotation (which may include symbol definitions) to a dictionary. But a single quotation may live in several different lexical environments. 12:19:23 Should I just bite the bullet and so some sort of code generation straight off, or is there a better way? 12:20:22 (this is for a somewhat lispified colorforth derivative) 12:32:12 What is your background? 12:33:09 First class environments are not easy even in way more powerful languages. 12:35:19 Modelling execution token as a "code -- environment" pair 12:35:19 doesn't seem sound even when possible. 12:38:41 why not? 12:41:50 Because they are computations rather than plain values. 12:42:16 If you know CK-machines, execution token is transformation. 12:42:28 Transition. 12:47:54 CK-machine? 12:51:42 --- quit: remyhr (Ping timeout: 246 seconds) 12:54:57 ASau: my background is mostly with lisp (mostly scheme) and forth. Is there some better way to represent the execution token? 12:58:15 but probably best to just always generate native code and forget about the tuples. 12:59:18 Alright, do you understand what SECD machine is? 13:00:02 Or even better. 13:00:23 Execution token is in Scheme terms a procedure. 13:00:52 yes i am familiar with the secd model 13:02:12 Execution token is datum that you can interpret as machine state transformation. 13:02:54 If you represent your procedure as list of atoms a la Lisp 1.5, 13:02:58 it can be a list. 13:03:07 Or atom. 13:03:49 right. the problem though is that the lists have symbols whose bindings depend on the environment 13:03:55 and the same list can live in multiple environments 13:04:35 That's in dynamic binding. 13:04:45 If you use static binding like in Scheme, they don't. 13:05:43 Don't forget that in Scheme (and in Common Lisp, unless declared specially) 13:06:01 you resolve values of free variables when you create closure. 13:11:26 Also, "defun" or "define" (in Scheme) is not a binding actually. 13:11:31 yes and indeed that is no problem in eg lisp where evaulating a lambda form actually generates the code for that list. probably i should just do it that way and stop trying to keep compilation semantics out of this. 13:13:20 Or not _just_ a binding at least. 13:13:25 Depending on how you count it. 13:14:03 "defun" does not introduce new binding, it updates place. 13:15:16 "(defun f (args) forms)" is actually (something like) 13:15:23 "(setf (symbol-function 'f) (function (lambda (args) forms)))". 13:15:26 Note "setf". 13:17:55 right and i don't like the separate namespaces in common lisp, but that is not what is important here. the defun or lambda or whatever is evaluated in the context of a lexical enviornment, against which is code is generated and either bound or returned as a lambda, yes? 13:20:04 but yes, I just need to generate native code and never attempt to interpret the lists directly, and it should be fine. 13:20:20 --- quit: MayDaniel (Read error: Connection reset by peer) 13:56:36 --- join: tschak__ (~tschak@pool-96-226-11-78.dllstx.fios.verizon.net) joined #forth 13:56:36 --- mode: ChanServ set +v tschak__ 13:59:57 --- quit: tschak_ (Ping timeout: 246 seconds) 15:15:49 --- join: DocPlatypus (~skquinn@108-75-59-67.lightspeed.hstntx.sbcglobal.net) joined #forth 15:15:50 --- mode: ChanServ set +v DocPlatypus 15:18:29 --- join: MrBusiness (~MrBusines@184.99.7.19) joined #forth 15:18:29 --- mode: ChanServ set +v MrBusiness 15:26:03 --- join: remyhr (~remy@pob78-1-82-238-158-96.fbx.proxad.net) joined #forth 15:26:03 --- mode: ChanServ set +v remyhr 16:02:35 --- quit: sunwukong (Quit: ERC Version 5.3 (IRC client for Emacs)) 16:08:20 --- quit: DocPlatypus (Ping timeout: 260 seconds) 16:10:30 --- quit: tschak__ (Ping timeout: 246 seconds) 16:46:17 --- join: nighty_ (~nighty@69-165-220-105.dsl.teksavvy.com) joined #forth 16:46:18 --- mode: ChanServ set +v nighty_ 16:46:32 --- join: Inode_ (~inode@time.uk.chromedpork.net) joined #forth 16:46:32 --- mode: ChanServ set +v Inode_ 16:55:39 --- quit: nighty- (*.net *.split) 16:55:40 --- quit: nighty (*.net *.split) 16:55:41 --- quit: Inode (*.net *.split) 16:55:41 --- quit: malyn (*.net *.split) 20:27:57 --- join: DocPlatypus (~skquinn@108-75-59-67.lightspeed.hstntx.sbcglobal.net) joined #forth 20:27:57 --- mode: ChanServ set +v DocPlatypus 20:43:14 --- join: ttmrichter (~ttmrichte@61.184.206.217) joined #forth 20:43:14 --- mode: ChanServ set +v ttmrichter 21:55:37 --- join: prototrout (~prototrou@ip-64-255-129-170.far.ideaone.net) joined #forth 21:55:38 --- mode: ChanServ set +v prototrout 22:19:13 --- part: prototrout left #forth 22:55:57 --- quit: Kumul (Quit: gone) 23:59:59 --- log: ended forth/12.03.23