2024-11-06 01:01:48 <vms14       > I did not know I can:  ' some-word ' oh >body !
2024-11-06 01:02:49 <vms14       > which seems to set oh to be some-word
2024-11-06 01:03:54 <vms14       > nor that defer could be represented as : defer create ['] noop does> @ execute ;
2024-11-06 01:05:05 <vms14       > I think this is the kind of stuff that I wanted to learn from forth and the reason I see that power I wanted to discover in it
2024-11-06 01:05:39 <vms14       > will take some time to grasp properly
2024-11-06 01:05:47 <xentrac     > that's not guaranteed by the Forth standard, of course
2024-11-06 01:06:34 <xentrac     > the defer is, but the >body ! isn't
2024-11-06 01:06:39 <xentrac     > it's certainly valid to implement a Forth such that that will work
2024-11-06 01:07:14 <xentrac     > there are different designs
2024-11-06 01:07:42 <vms14       > yeah I was trying it in gforth and failed :/
2024-11-06 01:07:57 <vms14       > the examples in the book use forth 83
2024-11-06 01:11:08 <vms14       > there is a direct alternative to >body !  ?
2024-11-06 02:45:44 <xentrac     > I think gforth actually copies the cfa and dfa into every call to the word, rather than just the xt
2024-11-06 02:46:20 <xentrac     > that is, that's what its colon definitions are
2024-11-06 22:39:15 <veltas      > vms14: >BODY is standard for accessing data from xt, e.g. to modify content in an object that you can't get address directly because of DOES>
2024-11-06 22:40:07 <veltas      > You can put anything in that data area, if you CREATE'd it, but if not then you're definitely in forth-specific territory
2024-11-06 22:40:35 <veltas      > And there's nothing wrong with being forth-specific, just good to know what's portable and what isn't
2024-11-06 22:40:39 <veltas      > I won't judge
2024-11-06 22:45:02 <vms14       > oh
2024-11-06 22:45:34 <vms14       > I was wondering why gforth had IS
2024-11-06 22:45:47 <vms14       > makes sense
2024-11-06 22:46:31 <vms14       > so I can always:   create oh does> something... and some day I can ' oh >body !
2024-11-06 22:47:03 <vms14       > that's cool, ty veltas
2024-11-06 22:47:44 <vms14       > that's the kind of things I have interest in
2024-11-06 22:48:03 <vms14       > I assume there is much more
2024-11-06 23:07:56 <veltas      > IS is from the Forth 200x standard
2024-11-06 23:08:04 <veltas      > DEFER / IS etc
2024-11-06 23:08:57 <veltas      > This allows what Starting Forth calls 'vectorised execution'
2024-11-06 23:12:06 <veltas      > But you can do the same with:   : DEFER ( "name -- )  CREATE 0 , DOES> @ EXECUTE ;  : IS ( "name -- )  ' >BODY ! ;  ( ignoring compile-time version of IS)
2024-11-06 23:12:17 <veltas      > (not tested that code but you get idea)
2024-11-06 23:13:40 <veltas      > So in this version DEFER just CREATEs a cell variable, which executes the stored xt when run, and IS writes a given xt to that variable
2024-11-06 23:13:57 <veltas      > IS stack comment should be: ( xt "name -- )
2024-11-06 23:15:23 <veltas      > I wouldn't even bother making a defining word like DEFER , I would just have a variable, like in Starting Forth:
2024-11-06 23:15:28 <veltas      > VARIABLE ACTION   ( ... )  ' MY-WORD ACTION !   ACTION @ EXECUTE
2024-11-06 23:16:04 <veltas      > Or better yet:   VARIABLE 'ACTION   : ACTION 'ACTION @ EXECUTE ;
2024-11-06 23:17:18 <veltas      > And then you can defer defining ACTION's behaviour until later, below where it was declared and potentially used in other words
2024-11-06 23:17:23 <veltas      > Or change it dynamically