Re: [forth200x] Doing DOES>
- Mitch Bradley wrote:
> Instead of:A slight variation of that is already possible in Forth-94:
> : MY-DEFINER CREATE <builder-stuff> DOES> <action-stuff> ;
> It would be better to say:
> : MY-ACTION <action-stuff> ;
> : MY-DEFINER ['] MY-ACTION ACTOR: <builder-stuff> ;
: MY-ACTION <action-stuff> ;
align here <builder-stuff> ['] MY-ACTION ACTOR: ;
> The only new word here is ACTOR: ( xt "<spaces>name" -- )That would then be:
: actor: ( addr xt "<spaces>name" -- )
>r >r : r> postpone literal r> compile, postpone ; ;This technique can also be varied to not work with addresses, but
directly with the data (where it is constant), allowing optimization
that is not possible with DOES>:
: offset: ( n "name" -- )
\ "name" execution: ( addr -- addr+n )
>r : r> postpone literal postpone + postpone ; ;- anton
- This looks interesting. I agree with what you say about DOES> being odd. In any case though, the action and the builder parts are going to execute at different times and (in the case of a cross-compiler) on different machines. There is nothing that can be done to change that..An advantage of your method over mine is that yours doesn't involve manually compiling the action word, which can be clumsy.. A disadvantage of your method is that manual compilation is sometimes a good thing as the action word contains literals that are not known until the time when the builder stuff is/has executed.Another disadvantage of your method is that you are still pulling the names out of the input stream. This isn't bad with one-action words, because the programmer writes something like this:MY-DEFINER XXXSo far so good; this is just like a DOES> word. The problem comes with multi-action words in which the programmer writes something like this:MY-DEFINER XXX &XXX XXX++ XXX--That is requiring the programmer to know all of the helper words that will be generated and get them in the correct order. That shouldn't be his job. He should just provide the single name XXX and let MY-DEFINER derive the helper word names from the XXX by pasting on suffixes and prefixes as needed.I still think that my :NAME is the simpler and more robust solution. Also, my :NAME can be used for a lot of things other than just "the abstract thing that DOES> does." I mentioned early-binding OOP and local variables previously.I also think that it makes more sense to define colon in terms of :NAME, rather than define :NAME in terms of colon.. The former is trivial. The latter is complicated and requires taking recourse in EVALUATE. Also, the programmer may want to define his own custom version of colon that generates helper words. All in all, it is best to provide a low-level word such as :NAME and define the high-level words such as colon on top of it, rather than provide the high-level colon and then use EVALUATE to define the low-level :NAME on top if it.I'll bet that your ACTOR: and ACTORS: could be defined in terms of :NAME without any other divergence from ANS-Forth standard code. True?
- --- In firstname.lastname@example.org, Hugh Aguilar <hughaguilar96@...> wrote:
> So far so good; this is just like a DOES> word. The problem comes with multi-action words in which the programmer writes something like this:Yes that wouldn't work well, and I don't think it was Mitch,s intention. Since Forth already uses prefixes to distinguish multiple actions, perhaps the cleanest syntax would be
> MY-DEFINER XXX &XXX XXX++ XXX--
> That is requiring the programmer to know all of the helper words that will be generated and get them in the correct order. That shouldn't be his job. He should just provide the single name XXX and let MY-DEFINER derive the helper word names from the XXX by pasting on suffixes and prefixes as needed.
xt <prefix> ACTION <actor-name>
where ACTION associates an existing prefix with all future words defined by an existing actor name.
: VALUE ['] @ Actor: 0 , ;
' ! TO action VALUE
- Mitch Bradley's idea was good, and your idea is also good. That's the funny thing about Forth programmers --- they are always coming up with good ideas.The purpose of :NAME is to give the Forth programmers a low-level tool that they can use to implement high-level constructs. Lots of people have their own idea regarding "the abstract thing that DOES> does," as well as various other abstract things. People use Forth (rather than C, etc.) so they can implement these ideas, rather than just fit themselves into the procrustean bed that their language designer has made for them. Well, go for it! I don't really expect that many people will use :NAME directly in their application code. Most of them will write some kind of wrapper around it, and use that in their application code.