Hello Matthias,
Matthias Trute writes:
>> We have two different cases of forward reference use.
>
> May I got it: You want a method to have forward declarations
> that later get incorporated into the code that uses the
> forwardly declared word.
>
> Something like
>
> foward foo
> : bar foo ;
>
Hi Enoch,
> We have two different cases of forward reference use.
May I got it: You want a method to have forward declarations
that later get incorporated into the code that uses the
forwardly declared word.
Something like
foward foo
: bar foo ;
: baz foo ;
:noname bla fupp ; resolve-to foo
a
Hello Matthias,
Matthias Trute writes:
>> Here is my current solution to eliminating defer indirection in simple
>> forward reference cases:
>>
>> Comments or is this "cookbook grade" :-)
>
> What is the expected output?
|S|1|marker ->test
|W|2|
|S|3|variable back&forth
|C|4|\
Hi ENoch,
> Here is my current solution to eliminating defer indirection in simple
> forward reference cases:
>
> variable back&forth
> \ use forward referenced word
> : forth& dp back&forth ! -1 , ; immediate
> \ use forward referenced xt
> : &forth postpone (literal) -1 , dp 1- back&forth
Hello Matthias & All:
>> But again, I'm not sure that I understood you correctly.
>> Matthias
>
> Your new cookbook entry regarding protecting deferred words from
> subsequent change (ie, "sealing") made it clear that our objectives are
> different. My aim is speed, how to remove a level of indire
Hi Matthias,
Matthias Trute writes:
> Hi Enoch,
>
>> I'm confused, please explain how this works...
>
> See my last mail, the code does (should do)
> exactly what I described there.
>
>> Aren't we supposed to patch the Edefer caller, not its callee?
>
> The code patches "truck" from being a defe
Hi Enoch,
> I'm confused, please explain how this works...
See my last mail, the code does (should do)
exactly what I described there.
> Aren't we supposed to patch the Edefer caller, not its callee?
The code patches "truck" from being a deferred word to a simple
call to the current redirection
Hello Mattias,
>> Yes, I suggest a run-time optimization step "with no going back"
>> where all FFdefer word calls would be reprogrammed to reach
>> immediately the FFdefer destination (skip the FFdefer word call).
>
> I think it's not necessary to have a special (defer) runtime, the
> developer c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Enoch,
> Yes, I suggest a run-time optimization step "with no going back"
> where all FFdefer word calls would be reprogrammed to reach
> immediately the FFdefer destination (skip the FFdefer word call).
I think it's not necessary to have a specia
Hello Matthias,
Matthias Trute writes:
> Hi Enoch,
>
> My recent changes were a code compacting, since defers and values are so
> close to each other.
>
>> May I suggest a new defer object, say, "FFdefer" that would be implemented
>> like "Edefer" except that if a certain global boolean, say, Fa
Hi Enoch,
My recent changes were a code compacting, since defers and values are so
close to each other.
> May I suggest a new defer object, say, "FFdefer" that would be implemented
> like "Edefer" except that if a certain global boolean, say, FastForward, is
> set then the first "xt_FFdeferfetch"
Hello Matthias & All:
As you are now improving the defer mechanism how about offering a way in
some instances to eliminate it completely?
One of Edefer important uses is to resolve forward references as AmForth
has no linkage editor (aka, linker). For example:
file1.frt
=
Edefer truck
:
12 matches
Mail list logo
