One final, final thought 
Author Message
 One final, final thought

In Forth, at least in the interpreted version,
I can redefine the actions of any existing
language word, "!",DUP, or even "+"; and that
definition holds for all subsequent code, but
not code that existed before the redefinition.
Do your compilers deal with this?

In Forth, at least in the interpreted version,
I can go back into the compiled code and
CHANGE EXISTING DEFINITIONS from within
the action of a new verb that I define. (The
reason why I might wish to is neither here, nor
there, it being merely sufficient that I might want to.)

So, we might legitimately within Forth want a
program behaviour along the lines of
.
.
Verb A which increments the TOS.
.
.
Special changing action, but without
introducing a new definition
.
.
Verb A now decrements the TOS.

Such an action is perfectly within the terms
of reference of Forth, especially considering
the open availability of the BUILDS> DOES>
pair.
How do your compilers handle this situation, such that
what was intended, and quite legal in the interpretive
version now behaves exactly as was intended when it
comes to the compiled version?



Tue, 29 May 2001 03:00:00 GMT  
 One final, final thought

Quote:

>So, we might legitimately within Forth want a
>program behaviour along the lines of
>.
>.
>Verb A which increments the TOS.
>.
>.
>Special changing action, but without
>introducing a new definition
>.
>.
>Verb A now decrements the TOS.

The important point here, is that it is an action
which happens dynamically, and not a static
redefinition, and it could happen dynamically at
any time, the compiler being completely unable to
predict the path a program execution might take.


Tue, 29 May 2001 03:00:00 GMT  
 One final, final thought
In an indirect threaded Forth, it is certainly possible to redifine the
action of a word by patching the code field.

The problem comes with optimizing compilers, whether for threaded or native
code. These compilers can take groups of words and produce optimized code
for them.

For example, consider this definition:

: INCREMENT  1 + ;

The compiler may do optmization, for example, by replacing "1 +" with the
word "1+". Now if you patch "+" it will have no effect on the behaviour of
INCREMENT.

Another example is the patching of constants. Optimizing compilers often
turn constants into literals so that they can be further optimized. Changing
the value of the constant does not effect the words that used it.

6 CONSTANT SIX
: 6+  SIX + ;

7 ' SIX >BODY !  ( assumes knowlede of how CONSTANT is implemented )

1 6+ .

This may print 7 or 8, depending on the compiler.

The point is that you can do what you want with a given compiler if you know
how it is implemented. But there is not (and should not, IMO) be a standard
way to do this.

Andrew


Quote:
>In Forth, at least in the interpreted version,
>I can redefine the actions of any existing
>language word, "!",DUP, or even "+"; and that
>definition holds for all subsequent code, but
>not code that existed before the redefinition.
>Do your compilers deal with this?

>In Forth, at least in the interpreted version,
>I can go back into the compiled code and
>CHANGE EXISTING DEFINITIONS from within
>the action of a new verb that I define. (The
>reason why I might wish to is neither here, nor
>there, it being merely sufficient that I might want to.)

>So, we might legitimately within Forth want a
>program behaviour along the lines of
>.
>.
>Verb A which increments the TOS.
>.
>.
>Special changing action, but without
>introducing a new definition
>.
>.
>Verb A now decrements the TOS.

>Such an action is perfectly within the terms
>of reference of Forth, especially considering
>the open availability of the BUILDS> DOES>
>pair.
>How do your compilers handle this situation, such that
>what was intended, and quite legal in the interpretive
>version now behaves exactly as was intended when it
>comes to the compiled version?



Tue, 29 May 2001 03:00:00 GMT  
 One final, final thought

: In Forth, at least in the interpreted version,
: I can redefine the actions of any existing
: language word, "!",DUP, or even "+"; and that
: definition holds for all subsequent code, but
: not code that existed before the redefinition.
: Do your compilers deal with this?

Of course.  If you've redefined DUP with your own definition, the
previous optimizing version of DUP will be suppressed, and something
like `CALL DUP' will be placed in the object code.

: In Forth, at least in the interpreted version,
: I can go back into the compiled code and
: CHANGE EXISTING DEFINITIONS from within
: the action of a new verb that I define. (The
: reason why I might wish to is neither here, nor
: there, it being merely sufficient that I might want to.)
:
: So, we might legitimately within Forth want a
: program behaviour along the lines of
: .
: .
: Verb A which increments the TOS.
: .
: .
: Special changing action, but without
: introducing a new definition
: .
: .
: Verb A now decrements the TOS.

This is not legal ANS Forth behaviour.  In fact it's not legal
FORTH-83 behaviour either.  I suppose you could do it in a compiled
Forth by patching A, but why bother?

If you really wanted to do do this, you'd use vectored execution (aka
a function pointer) just as you would in C.

: Such an action is perfectly within the terms
: of reference of Forth, especially considering
: the open availability of the BUILDS> DOES>
: pair.
: How do your compilers handle this situation, such that
: what was intended, and quite legal in the interpretive
: version now behaves exactly as was intended when it
: comes to the compiled version?

It's not "quite legal in the interpretive version".  That's what made
people so cross when you were laying down the law about what Forth can
and can't do.  You have a particular idea about what Forth is that
doesn't correspond to present day reality.

Andrew.



Tue, 29 May 2001 03:00:00 GMT  
 One final, final thought

Quote:


> >So, we might legitimately within Forth want a
> >program behaviour along the lines of
> >.
> >.
> >Verb A which increments the TOS.
> >.
> >.
> >Special changing action, but without
> >introducing a new definition
> >.
> >.
> >Verb A now decrements the TOS.

> The important point here, is that it is an action
> which happens dynamically, and not a static
> redefinition, and it could happen dynamically at
> any time, the compiler being completely unable to
> predict the path a program execution might take.

You are right, it is dynamic, and it is normally handled by
some form of vectored operation, sometimes called DEFER .
Most Forths, interpreted or compiled support this ability.

In C, you would create something like;

typedef void ( *DEFEREDFUNC)();
DEFEREDFUNC specialAction;

Then it would be filled in as follows;

void CurrentAction(void)
{
    .... Whatever it does...

Quote:
}

specialAction = (DEFEREDFUNC) &CurrentAction;    // get address of the
current action function

Now, I'm not a great C programmer, so I may have made
some mistakes in the above, but it seems to me that this
general type of operation is beneficial in any language.

Tom Zimmer



Tue, 29 May 2001 03:00:00 GMT  
 One final, final thought
"Gareth Alun Evans"  writes:

Quote:
> In Forth, at least in the interpreted version,
> I can redefine the actions of any existing
> language word, "!",DUP, or even "+"; and that
> definition holds for all subsequent code, but
> not code that existed before the redefinition.
> Do your compilers deal with this?

        and your point is?

Quote:
> In Forth, at least in the interpreted version,
> I can go back into the compiled code and
> CHANGE EXISTING DEFINITIONS from within
> the action of a new verb that I define. (The
> reason why I might wish to is neither here, nor
> there, it being merely sufficient that I might want to.)

        and the point here is?

Quote:
> So, we might legitimately within Forth want a
> program behaviour along the lines of
> .
> .
> Verb A which increments the TOS.
> .
> .
> Special changing action, but without
> introducing a new definition
> .
> .
> Verb A now decrements the TOS.

> Such an action is perfectly within the terms
> of reference of Forth, especially considering
> the open availability of the BUILDS> DOES>
> pair.
> How do your compilers handle this situation, such that
> what was intended, and quite legal in the interpretive
> version now behaves exactly as was intended when it
> comes to the compiled version?

        Optimizing Forth compilers may not handle this at all,
        or may handle it by working with the code fragments
        found when decompiling the given word for optimization,
        or lots of other strategies. I fail to see why this
        is even a question.

--
Julian V. Noble

"Elegance is for tailors!"    -- Ludwig Boltzmann



Tue, 29 May 2001 03:00:00 GMT  
 One final, final thought

[sci.electronics.misc dropped, since I don't read it]


   :Optimizing Forth compilers may not handle this at all,
   :or may handle it by working with the code fragments
   :found when decompiling the given word for optimization,
   :or lots of other strategies. I fail to see why this
   :is even a question.

Actually, what I thought of when he started talking about mutating
definitions was Lisp. There are certainly optimising Lisp compilers
around. I suspect what happens is that you can't assume that the lambda
function you've just defined exists as a list any longer - but perhaps
Stephen Bevan, or someone else, would care to correct me?
--



Fri, 01 Jun 2001 03:00:00 GMT  
 One final, final thought

Quote:

> [sci.electronics.misc dropped, since I don't read it]


>    :Optimizing Forth compilers may not handle this at all,
>    :or may handle it by working with the code fragments
>    :found when decompiling the given word for optimization,
>    :or lots of other strategies. I fail to see why this
>    :is even a question.
> Actually, what I thought of when he started talking about mutating
> definitions was Lisp. There are certainly optimising Lisp compilers
> around. I suspect what happens is that you can't assume that the lambda
> function you've just defined exists as a list any longer - but perhaps
> Stephen Bevan, or someone else, would care to correct me?

Lots of ways to revector things. Brodie's DOER:  ... MAKE construct,
DEFER, my own USE( ... DEFINES , e.g. If he wants to see things get
redefined he should look at my FORmula TRANslator (v. 1.10 available
from taygeta.com now) where I reuse code by this technique. Also
available from the PHYS 551 Web page (www.phys.{*filter*}ia.edu/classes/ ).

--
Julian V. Noble

"Elegance is for tailors!"    -- Ludwig Boltzmann



Tue, 05 Jun 2001 03:00:00 GMT  
 One final, final thought


   :> Actually, what I thought of when he started talking about mutating
   :> definitions was Lisp. There are certainly optimising Lisp
   :> compilers around. I suspect what happens is that you can't assume
   :> that the lambda function you've just defined exists as a list any
   :> longer - but perhaps  Stephen Bevan, or someone else, would care
   :> to correct me?

   :Lots of ways to revector things. Brodie's DOER:  ... MAKE construct,
   :DEFER, my own USE( ... DEFINES , e.g. If he wants to see things get
   :redefined he should look at my FORmula TRANslator (v. 1.10 available
   :from taygeta.com now) where I reuse code by this technique. Also
   :available from the PHYS 551 Web page (www.phys.{*filter*}ia.
   :edu/classes/ ).

But this can be done in any language which allows functions to exist as
first-class objects (eg. C, Pascal, Scheme). BCPL even defines its
function names as variables holding the address of the function defined
(therefore in BCPL, all functions may be changed at runtime).

What I was thinking of is using Lisp's conceptual model of function
definitions as stored in the same way as everything else, ie. by lists,
headed with (lambda (bindings) ... ) Lisps that are implemented using
optimising compiler technology can't rely on that being true, in just
the same way as Forths implemented using compiler technology.
--



Wed, 06 Jun 2001 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Final Final beta of Win32 Extensions available!

2. final thought for tonight

3. Green Card Lottery- Final One?

4. Green Card Lottery- Final One?

5. Green Card Lottery- Final One?

6. Green Card Lottery- Final One?

7. Green Card Lottery- Final One?

8. Green Card Lottery- Final One?

9. Green Card Lottery- Final One?

10. Green Card Lottery- Final One?

11. One cool C+@: The final chapter?

12. Green Card Lottery- Final One?

 

 
Powered by phpBB® Forum Software