Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #27799 > unrolled thread

late binding

Back to article view | Back to comp.lang.forth

Contents

  late binding Paul Rubin <no.email@nospam.invalid> - 2014-01-11 01:59 -0800
    Re: late binding Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-11 04:16 -0600
      Re: late binding Paul Rubin <no.email@nospam.invalid> - 2014-01-11 03:06 -0800
        Re: late binding anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 15:31 +0000
    Re: late binding albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-11 14:05 +0000
    Re: late binding Ron Aaron <rambamist@gmail.com> - 2014-01-11 17:58 +0200
    Re: late binding "Elizabeth D. Rather" <erather@forth.com> - 2014-01-11 08:55 -1000
      Re: late binding Paul Rubin <no.email@nospam.invalid> - 2014-01-11 11:23 -0800
        Re: late binding "Elizabeth D. Rather" <erather@forth.com> - 2014-01-11 10:37 -1000
    Re: late binding Michael L Gassanenko <m_l_g3@yahoo.com> - 2014-01-13 00:01 -0800
      Re: late binding m.a.m.hendrix@tue.nl - 2014-01-13 04:18 -0800
    Re: late binding Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-13 00:51 -0800
    Re: late binding Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-01-13 14:40 +0100
    Re: late binding anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 14:41 +0000

#27799 — late binding

In this era of avant-garde Forth innovation such as Chuck using circular
stacks and having IF not pop the condition from the stack, I wonder if
anyone has experimented with late binding.  Basically if you say

  : FOO 1 BAR + ;

instead of getting an error message saying BAR is undefined, the
compiler would just make a dictionary entry for BAR, with its CFA
pointing to code that prints an error message.  Only when you try to
actually run FOO, do you get a message saying BAR is undefined.  If you
say

   : FOO 1 BAR + ;
   : BAR 4 ;

then the : BAR finds the existing dictionary entry for BAR and
overwrites the CFA in-place.  Now running FOO prints 5.  You can
redefine BAR:

   : FOO 1 BAR + ;
   : BAR 4 ;

   FOO   5 ok    \ FOO prints 5

   : BAR 8 ;     \ overwrite the same CFA again
   FOO   9 ok    \ FOO now prints 9

It costs an extra memory access depending on implementation, not too
bad.  The advantage is you can now redefine words during debugging,
without having to reload the whole program which usually means
clobbering the program state.  When you redefine a word, all callers
will now call the new word.  Also you no longer have to define each word
before it's used.

I know you can do a version of this with DEFER, but this idea is more
pervasive.

Is this just terrible, from a Forth cultural (or other) standpoint?

[toc] | [next] | [standalone]

#27802

Paul Rubin <no.email@nospam.invalid> wrote:
> In this era of avant-garde Forth innovation such as Chuck using circular
> stacks and having IF not pop the condition from the stack, I wonder if
> anyone has experimented with late binding.  Basically if you say
> 
>  : FOO 1 BAR + ;
> 
> instead of getting an error message saying BAR is undefined, the
> compiler would just make a dictionary entry for BAR, with its CFA
> pointing to code that prints an error message.  Only when you try to
> actually run FOO, do you get a message saying BAR is undefined.  If you
> say
> 
>   : FOO 1 BAR + ;
>   : BAR 4 ;
> 
> then the : BAR finds the existing dictionary entry for BAR and
> overwrites the CFA in-place.  Now running FOO prints 5.  You can
> redefine BAR:
> 
>   : FOO 1 BAR + ;
>   : BAR 4 ;
> 
>   FOO   5 ok    \ FOO prints 5
> 
>   : BAR 8 ;     \ overwrite the same CFA again
>   FOO   9 ok    \ FOO now prints 9
> 
> It costs an extra memory access depending on implementation, not too
> bad.  The advantage is you can now redefine words during debugging,
> without having to reload the whole program which usually means
> clobbering the program state.  When you redefine a word, all callers
> will now call the new word.  Also you no longer have to define each word
> before it's used.
> 
> I know you can do a version of this with DEFER, but this idea is more
> pervasive.
> 
> Is this just terrible, from a Forth cultural (or other) standpoint?

It's not productive.  Almost everyone using Forth has had some kind of
idea like this: I implemented it when I was a very new Forth
programmer and found that I didn't use it.  In practice, you simply
recompile the words you're working on.  I think some cross-compilers
use this because it can be tricky to solve problems of circular
references, but it's not usually necessary.

Andrew.

[toc] | [prev] | [next] | [standalone]

#27804

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> In practice, you simply recompile the words you're working on.  

The trouble with that is it's easy to forget to recompile some words
that depend on the words you've changed.  I guess since they're later in
the source file, it might be possible to add an editing command to
recompile everything from the cursor on downwards.  Currently in Emacs,
there's a command that recompiles the current paragraph, defined as a
chunk of code delimited by blank lines, which works pretty well for
hacking on a local section (put blank lines around it til you're done
debugging it).

> I think some cross-compilers use this because it can be tricky to
> solve problems of circular references, but it's not usually necessary.

DEFER might enough for that situation.

[toc] | [prev] | [next] | [standalone]

#27865

Paul Rubin <no.email@nospam.invalid> writes:
>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I think some cross-compilers use this because it can be tricky to
>> solve problems of circular references, but it's not usually necessary.
>
>DEFER might enough for that situation.

I probably is, but defining and resolving DEFERred words in a cross
compiler also has it's own cost (to the user of the cross-compiler,
but also the developer of the cross compiler), and it imposes a
run-time cost.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#27810

In article <7xr48eg7q1.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>In this era of avant-garde Forth innovation such as Chuck using circular
>stacks and having IF not pop the condition from the stack, I wonder if
>anyone has experimented with late binding.  Basically if you say
>
>  : FOO 1 BAR + ;
>
>instead of getting an error message saying BAR is undefined, the
>compiler would just make a dictionary entry for BAR, with its CFA
>pointing to code that prints an error message.  Only when you try to
>actually run FOO, do you get a message saying BAR is undefined.  If you
>say
>
>   : FOO 1 BAR + ;
>   : BAR 4 ;
>
>then the : BAR finds the existing dictionary entry for BAR and
>overwrites the CFA in-place.  Now running FOO prints 5.  You can
>redefine BAR:
>
>   : FOO 1 BAR + ;
>   : BAR 4 ;
>
>   FOO   5 ok    \ FOO prints 5
>
>   : BAR 8 ;     \ overwrite the same CFA again
>   FOO   9 ok    \ FOO now prints 9

The way you propose makes changes to INTERPRET .
It could be done not too invasively by catching errors,
provided INTERPRET throws an error, but again this would
require an indirect threaded Forth.
Almost the same effect can be had by forward definitions,
which in its turn is syntactic sugar for DEFER.
In an indirect threaded Forth this is pretty easy and it
has no run time overhead.

:F BAR :     \ Forward reference
: FOO 1 BAR + ;
:R BAR 4 ;   \ Resolving definition or redefining definition.

This I have added at ciforth, and it uses the exact technique
you describe, but it is explicit. It makes good use of our
modular compiler.
So
:F is an alias for :
:R patches a previous definition, like you propose.

ciforth carnal code:
SCR #126
 0 ( :2 :F :R                                    )  \ AvdH B2sep21
 1 WANT ALIAS
 2 \ Alias of : , define a word for the second time.
 3 : :2   IN @ NAME FOUND >R R@ HIDDEN IN !   :   R> HIDDEN ;
 4 \ Use for dummy forward definitions.
 5 ': ALIAS :F
 6 \ Resolve an earlier dummy definition for recursion.
 7 : :R   IN @ NAME FOUND >R R@ HIDDEN IN !   :   R@ HIDDEN
 8   LATEST >DFA @ R> >DFA ! ;
 9
10
11
12
13
14
15                                                                 OK

>
>It costs an extra memory access depending on implementation, not too
>bad.  The advantage is you can now redefine words during debugging,
>without having to reload the whole program which usually means
>clobbering the program state.  When you redefine a word, all callers
>will now call the new word.  Also you no longer have to define each word
>before it's used.
>
>I know you can do a version of this with DEFER, but this idea is more
>pervasive.

For mutually recursive definitions it is much more readable than DEFER.

I occasionaly patch the datafield of a colon definition during
debugging. I never thought of using :R for that, thanks!
Doing this automatically, would just have too many pitfalls.

>
>Is this just terrible, from a Forth cultural (or other) standpoint?

I guess not. It is just not the kind of thing you want in a standard
to be imposed on every one.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#27813

On 01/11/2014 11:59 AM, Paul Rubin wrote:
> In this era of avant-garde Forth innovation such as Chuck using circular
> stacks and having IF not pop the condition from the stack, I wonder if
> anyone has experimented with late binding. 

Yes, "8th" has late-binding, but only on-demand, using the word "`" (the
backtick).

The reason is that, say "+" may apply to a Number or a String (among
other things), and you may for example have an Array of one or the other
type.  So if you have a case where you don't know the type of item until
runtime, you can use the late-binding word.

Of course, that is going to be slower than interpret-time binding, but
if you need it, it is very handy to have.

[toc] | [prev] | [next] | [standalone]

#27815

On 1/10/14 11:59 PM, Paul Rubin wrote:
> In this era of avant-garde Forth innovation such as Chuck using circular
> stacks and having IF not pop the condition from the stack, I wonder if
> anyone has experimented with late binding.  Basically if you say
>
[example snipped]
>
> It costs an extra memory access depending on implementation, not too
> bad.  The advantage is you can now redefine words during debugging,
> without having to reload the whole program which usually means
> clobbering the program state.  When you redefine a word, all callers
> will now call the new word.  Also you no longer have to define each word
> before it's used.
>
> I know you can do a version of this with DEFER, but this idea is more
> pervasive.
>
> Is this just terrible, from a Forth cultural (or other) standpoint?


As Andrew says, people have been trying this since the 80's, and it just 
never caught on. I have two thoughts:

* Recommended development practice is to factor the portion of the 
application you're working on such that you can focus on it and ignore 
the previously tested portions of your application. Then when the code 
is debugged you can add it to the "stable" parts.

* How long does it take you to "reload the whole program"? On the 
systems I've worked with in the last 10-15 years even large programs 
load in a second or less. So the incentive to avoid this is minimal.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#27816

"Elizabeth D. Rather" <erather@forth.com> writes:
> As Andrew says, people have been trying this since the 80's, and it
> just never caught on.

Ok, that's a reasonable answer: yes the idea has been tried, and the
advantages weren't compelling (though by implication, at least it wasn't
completely nuts).  Thanks both of you.

> * How long does it take you to "reload the whole program"? ... even
> large programs load in a second or less.

It's not just loading, but there is often setup or other operations
after the program starts running, before it gets to the part you're
trying to debug.  If you can avoid repeating that, it can speed things
up.

[toc] | [prev] | [next] | [standalone]

#27822

On 1/11/14 9:23 AM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> As Andrew says, people have been trying this since the 80's, and it
>> just never caught on.
>
> Ok, that's a reasonable answer: yes the idea has been tried, and the
> advantages weren't compelling (though by implication, at least it wasn't
> completely nuts).  Thanks both of you.
>
>> * How long does it take you to "reload the whole program"? ... even
>> large programs load in a second or less.
>
> It's not just loading, but there is often setup or other operations
> after the program starts running, before it gets to the part you're
> trying to debug.  If you can avoid repeating that, it can speed things
> up.

Try making a file that loads your program and then interpretively does 
the setup things. Just plain Forth works fine as a scripting language. 
Pretty much anything you can type you can execute interpretively in a file.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#27855

1) you don't always need late binding, so you can use EVALUATE

2) I have seen something similar in a target compiler that loaded only the words that are invoked. Some words are defined as library words. When a library word is found, a forward reference to it is added to the code. On ';', the referenced library words are loaded, recursively (that is, including words referenced by library words).

3) Error "undefined" is a very useful indication of syntax problems. In all the experiments that I have seen it always was reported at compile-time.

[toc] | [prev] | [next] | [standalone]

#27859

On Monday, January 13, 2014 9:01:01 AM UTC+1, Michael L Gassanenko wrote:
> 3) Error "undefined" is a very useful indication of syntax problems. 
> In all the experiments that I have seen it always was reported at 
> compile-time.

That is a good point! You don't want to encounter an untested branch
when the lander is pottering around on Mars already.

-marcel

[toc] | [prev] | [next] | [standalone]

#27856

Nice!

I implemented ED: and ;ED (ED is short for EDIT) in my hobby system:

: HELLO ." HELLO MOTHER!" CR ;
: TEST  HELLO ;

TEST
HELLO MOTHER!
ok

ED: HELLO 10 0 DO I . LOOP ;ED
TEST
0 1 2 3 4 5 6 7 8 9 ok

See http://turboforth.net/ed.html

There's a lot of pre-amble as my site is aimed at Forth newbies. Skip down to the section entitle ED: and ;ED.

Cheers

[toc] | [prev] | [next] | [standalone]

#27862

Dear Paul Rubin,

> The advantage is you can now redefine words during debugging,
> without having to reload the whole program which usually means
> clobbering the program state.  When you redefine a word, all callers
> will now call the new word.

this is implemented in tForth written by Terry Holmes which did run 
on the Canon Cat as a natural feature of a token threaded implementation.
It simply has to change token table to change all occurences to new definition.

It doesn't allow you to compile words undefined in dictionary before, 
but of course you can define an "empty" word like yours with error message inside
yourself and redefine it later.

> Is this just terrible, from a Forth cultural (or other) standpoint?

It depends. On token threading implementations it is fine, 
but on a native code system, this is either a performance hit or
a call opcode backpatching journey through whole dictionary, if possible
with given instruction set.

I gratefully received a copy of tForth for DOS by John "Sandy" Bumgarner, 
and I can ask him if I can share this with you.

Matthias Koch

[toc] | [prev] | [next] | [standalone]

#27864

Paul Rubin <no.email@nospam.invalid> writes:
> You can
>redefine BAR:
>
>   : FOO 1 BAR + ;
>   : BAR 4 ;
>
>   FOO   5 ok    \ FOO prints 5
>
>   : BAR 8 ;     \ overwrite the same CFA again
>   FOO   9 ok    \ FOO now prints 9
>
>It costs an extra memory access depending on implementation, not too
>bad.  The advantage is you can now redefine words during debugging,
>without having to reload the whole program which usually means
>clobbering the program state.  When you redefine a word, all callers
>will now call the new word.  Also you no longer have to define each word
>before it's used.
>
>I know you can do a version of this with DEFER, but this idea is more
>pervasive.
>
>Is this just terrible, from a Forth cultural (or other) standpoint?

At least it's not as terrible as EVALUATE-based macros, because this
kind of redefinition binds at the compile time of the new BAR, whereas
EVALUATE-based macros are a gross cross between early and late
binding; and yet, EVALUATE-based macros have their fans, so your
simulation of late binding will probably be acceptable to many.

Anyway, the standard Forth way of name binding works out very well for
dealing with multiple independent definitions of the same name (see
<http://www.complang.tuwien.ac.at/forth/language-features.html>; I
should expand the other sections:-).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web