00:00:00 --- log: started retro/10.02.02 03:37:57 --- join: virl (~virl__@chello062178085149.1.12.vie.surfer.at) joined #retro 06:23:43 good morning 07:21:28 --- join: docl (~luke@97-120-80-164.ptld.qwest.net) joined #retro 07:26:31 wb 07:45:29 congrats on the 10.4 release :) 07:48:35 thanks :) 07:48:49 now I get to focus on the docs for a few evenings 07:55:11 --- quit: virl (Remote host closed the connection) 08:46:33 --- join: PrintStar (jba@SDF.LONESTAR.ORG) joined #retro 08:46:48 --- part: PrintStar left #retro 15:28:52 --- join: virl (~virl__@chello062178085149.1.12.vie.surfer.at) joined #retro 16:03:56 --- quit: SimonRC (Ping timeout: 246 seconds) 16:11:45 --- join: SimonRC (~sc@fof.durge.org) joined #retro 16:52:07 --- join: erider (~chatzilla@pool-173-69-160-231.bltmmd.fios.verizon.net) joined #retro 16:52:14 --- quit: erider (Changing host) 16:52:14 --- join: erider (~chatzilla@unaffiliated/erider) joined #retro 16:52:31 hi 17:18:31 hi 17:23:23 how are you doing docl 17:31:04 good evening 17:36:36 hi crc 17:36:59 * erider is working on some simple arrays in forth 17:43:02 cool 17:43:10 * docl is going good 17:43:31 what have you got so far? 17:48:20 you talking to me? 17:53:55 docl: are you asking what is the status of my simple array 18:26:25 yes 18:32:58 : array{ ( n -- ) create cells allot 18:33:00 does> cell+ ( index -- addr ) ; 18:35:52 docl: that is what I got but I am going to try vector execution 18:39:14 * docl needs to look up does> 18:42:54 what does does> do? 18:45:19 best guess is that it returns the pointer to the data from the parent of the word that the child can access 18:45:38 hmm 18:45:55 : .does ( a- ) compiler @ if swap literal, compile rdrop ;then drop ; 18:45:56 : does> 1 , here 0 , ` reclass ` ;; here swap ! here literal, ` .does ; compile-only 18:46:55 parent word is array{ and it can make child that can index the cells that the parent makes 18:47:12 1 , here 0 , ( put an address pointing to 0 on the stack) 18:47:13 children 18:47:51 docl: does> is used with create to assign a runtime action to a data structure 18:48:06 : foo create 10 , does> @ ; 18:48:08 foo bar 18:48:20 bar would act as a constant, pushing 10 to the stack when called 18:48:43 ok, almost getting it 18:48:43 the address of the data is on the stack after does> and can be used by any code following does> 18:49:11 continuation 18:49:35 :) 18:49:40 : counter create 0 , does> dup ++ @ ; 18:49:42 counter foo 18:49:54 the result returned by 'foo' would increase by 1 each time foo is called 18:49:55 I think does> gets the data 18:51:46 so does> looks at the top heap element basically? 18:52:11 yes 18:52:13 or whatever it is when it is called 18:52:19 yes 18:52:19 so kind of a local variable then 18:52:22 variable pointer : }show pointer ! pointer @ execute ; 18:52:24 yup 18:53:05 my vector 18:54:48 I want to try to build array of xt with create ... does> and the children that the parent make can index and execute 18:55:18 is the stack diagram in .does correct? looks like it is swapping when there is only one value left. 18:55:50 the stack diagram is probably wrong 18:56:23 : .does ( a- ) compiler @ if swap literal, compile rdrop ;then drop ; 18:57:03 it may expect more input when compiler is on than when it is not 18:57:08 crc I really believe that does> returns that pointer to the data 18:57:10 hmm 18:57:52 if not what else would it be needed for 18:58:48 does> will push the address of the data to the stack 18:59:09 but it also encompasses other, system-specific behavior with regards to attaching code to the create'd word 18:59:23 * crc was close to removing does> from retro's core... 19:00:14 docl: ( C: aa- R: aa-a ) 19:02:09 at compile time it takes two addresses, at runtime it takes two and returns one. 19:02:23 sounds about right 19:02:25 yes 19:02:42 * crc never updated the stack comments on it to reflect actual usage... sorry! 19:03:01 that's ok :) 19:05:20 I suspected that does> is pushing the pointer to the data on the stack and also turning the compiler back on 19:05:31 does> does not take anything from the stack? 19:06:02 does> only lays down some code (to push xt and data address pointers to stack, and compiles a call to .does) 19:06:08 I think it finds the address to the data 19:06:24 from the end-user perspective the final stack comment would be ( -a ) 19:06:39 since it leaves a value on the stack for the code following it to use 19:07:18 erider: the address is just pulled from the dictionary header made by 'create'; no real problem there 19:07:25 I suspected that does> is defined with here mix in somewhere 19:08:01 kind of like your rewind 19:08:30 erider: 19:08:32 : does> ( -a ) 19:08:33 1 , here 0 , ` reclass ` ;; here swap ! here literal, ` .does ; compile-only 19:08:46 1 , here 0 , 19:09:01 1 = ngaro instruction for "push value to stack" 19:09:02 then it can also compile more code on the end of the header that is tied to the word created 19:09:15 0 = dummy value for the instruction 19:09:23 here = pointer to the dummy value, will be changed later 19:09:27 ` reclass 19:09:31 compile a call to 'reclass' 19:09:35 ` ;; 19:09:38 compile a call to ;; 19:09:45 here swap ! 19:09:54 patch that dummy value to the start of the code following does> 19:09:58 here literal, 19:10:11 compile the address of the start of the code following does> as a value 19:10:18 ` .does 19:10:23 compile a call to .does 19:11:13 the .does class handles the rest 19:11:33 there are 4 words that make headers right 19:12:00 retro only ships with one word to make headers - create 19:12:08 : create variable constant 19:12:20 : uses create 19:12:23 variable uses create 19:12:26 constant uses create 19:12:31 at least, they do in retro 19:12:32 right 19:12:42 so : create 19:13:31 just 'create' 19:13:52 create makes a header, pointing to "here", with a class of ".data" 19:14:08 everything else just tweaks the header it builds 19:14:24 yeah I guess create is in : too 19:14:47 t: : ( "- ) create ' .word # (:) ; 19:14:51 or, in regular forth: 19:15:09 : : ( "- ) create ['] .word reclass ] ; 19:15:58 t: word create lit comma ; 19:16:14 ? 19:16:19 lol 19:17:12 crc do you use vector execution at all in retro 19:17:27 all words made with : are vectors in retro 19:17:34 you can change any of them, at any time 19:18:07 I want to make an array of xt 19:18:38 ' word , ' word2 , ' word3 , ...... :) 19:19:13 yeah I want to make it with create ... does> 19:19:36 : jump-table ( n"- ) create for ' , next does> ( n- ) cells + @ execute ; 19:19:51 have some first second and third stage some happening :) 19:19:53 3 jump-table foo + - * 19:20:05 2 3 2 foo . 19:21:18 that rocks! 19:21:19 note that the table would be relative to 0, not 1 19:21:25 so the first slot is #0 19:21:40 add a 1- after does> if you want it to be relative to 1 instead 19:22:00 for next is a retro structure right 19:22:33 yes 19:22:45 I'm not sure if reva has them.. 19:23:08 nope, you'd have to use do/loop instead 19:23:50 : jump-table ( n"- ) create 0 do ' , loop does> ( n- ) cells + @ execute ; 19:23:52 should work 19:24:50 ok well I talk to you more tomorrow I am going to does some stuff on paper with forth 19:25:35 * erider like language like forth and scheme you and write them down on paper and play with them 19:25:47 can* 19:25:51 ok I think I finally understand does> :) 19:26:16 basically everything after it is the class for the word you make 19:26:19 * erider we wait around for the explanation from docl 19:26:32 well* 19:26:32 : foo create 10 , does> @ ; 19:26:37 @ is the class 19:26:48 : counter create 0 , does> dup ++ @ ; 19:26:53 ++ @ is the class 19:27:17 yes 19:27:17 it takes the xt of the word that was just created and does everything after does> to it when it is called. 19:27:28 docl I think foo is the class and what it makes are methods 19:27:44 and the state-handling (what to do if compiling or interpreting) is handled by .does which acts as a "superclass" 19:28:02 ahhhh 19:28:36 is does> ever used in a non compiling context though? 19:28:45 no 19:28:53 but the code you write after it is 19:29:15 so does> has to either lay down code to handle it in the calling word, or execute it automatically if interpreting 19:30:06 without .does doing that, you'd have to do: does> state @ if ...compile-time actions... else ...interpret time variant.... then ; 19:30:18 which gets ugly and error prone 19:30:21 crc I look it is like this the word is the Class and create can make instances of the class but the only thing that can be inherited is the data from the superclass 19:31:05 does> is annoying to explain 19:31:10 * crc will have to do a wiki page on it soon 19:31:15 but I could be wrong 19:31:50 or does> just defines the methods of the class lol :) 19:32:15 talk to you guys later 19:35:57 it's an interesting word 19:36:11 like later, it takes some analysis and practice before you grasp it 19:36:29 but I suspect it is powerful once you do 19:36:48 * crc should write a word using both does> and later 19:36:59 :) 19:37:00 docl: it allows for some incredible tricks 19:37:50 --- quit: erider (Ping timeout: 272 seconds) 19:38:30 does> alters the most recently created word 19:38:30 : foo create does> repeat 1 . does> 2 . does> 3 . does> again ; 19:38:34 foo bar 19:38:43 then run bar a bunch of times 19:39:29 docl: yes 19:39:38 docl: so you need to be careful with it 19:39:46 similar to reclass, right? 19:39:47 but it's really handy at times 19:39:50 yes 19:40:02 it uses reclass, which is why it affects the most recently created word 19:40:37 woah, bar cycles through the definitions 19:40:45 looking at your example. nice. 19:42:53 the difference between does> and reclass is that does> uses the remainder of the word directly, whereas reclass is expecting an xt. 19:43:02 yes 19:43:53 by dealing with the remainder of the word, it is similar to later. 19:44:35 sort of. 19:49:27 : cycle create does> repeat 1 . does> 2 . does> 3 . does> again ; 19:49:27 : local-constant create , does> @ ; 19:49:27 : make-counter 0 create , does> dup ++ @ ; 19:49:56 cycle is a very interesting trick 19:50:08 it blurs the line between compile and run 19:50:28 basically it changes the class each time it is called 19:51:27 what keeps it from being an endless loop? 19:51:44 each does> returns to the caller :) 19:52:00 ahhh 19:52:06 so does> patches the class field, then returns to the caller 19:52:20 it's another subtle twist 19:52:27 very subtle 19:52:35 forth is awesome for allowing a seemingly simple word to be very complex in practice 19:54:20 the rdrop in .does is where the return part comes from? 19:55:07 "compile rdrop" means return to the calling word? 19:55:12 the ;; in does> actually 19:55:19 oh 19:55:48 rdrop exits the calling word 19:56:11 that's another interesting twist :) 19:56:24 :) 19:56:48 there's layers and layers of them in this word 19:56:49 if it didn't exit the caller after being used inside another definition, the full code after does> would be executed. hence the 'rdrop' 19:57:27 this word took be the better part of a year to understand, and I still can't find a good way to explain it :( 19:57:51 we're getting there 20:02:36 in : foo create , does> @ ; the code "@" is compiled, but not really as part of the word foo. 20:03:01 nope 20:03:11 It's more like a seperate word, the new class for bar 20:03:15 @ should be considered part of a new word 20:03:45 ok... so in that respect does> is like : 20:03:52 it starts a word (in a way) 20:03:59 "see foo" 20:04:18 you'll see the exit opcode, followed by the new code from does> 20:05:06 of course, ;then has an exit in it as well. so in a sense that makes code after it a new word in the same manner 20:05:31 the jump from if bridges that though 20:05:38 true 20:05:44 so if/;then is a bit more tightly bound than does> 20:06:11 that makes sense 20:27:42 * crc has started a page on does> at http://retroforth.org/pages/?CreateDoes 21:13:23 * crc is going to bed now; goodnight 23:02:06 --- quit: docl (Quit: Lost terminal) 23:21:37 --- join: sixforty (~sixforty@pdpc/supporter/active/sixforty) joined #retro 23:59:59 --- log: ended retro/10.02.02