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

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

quick review of <BUILDS and CREATE history

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

Contents

  quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 13:15 -0500
    Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-19 20:07 +0000
      Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-19 21:45 +0000
    Re: quick review of <BUILDS and CREATE history Coos Haak <chforth@hccnet.nl> - 2014-01-19 22:02 +0100
    Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 17:24 -0600
      Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-19 14:54 -1000
        Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 22:37 -0500
          Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-19 18:01 -1000
            Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 00:27 -0500
              Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-19 20:54 -1000
                Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-19 21:19 -1000
                Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 16:14 -0500
                  Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-20 12:07 -1000
                    Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 11:37 -0500
                      Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-21 17:41 +0000
                      Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 08:30 -1000
                        Re: quick review of <BUILDS and CREATE history oh2aun@gmail.com - 2014-01-21 11:17 -0800
                          Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 09:44 -1000
                        Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 15:18 -0500
                          Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 12:07 -1000
                            Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 22:04 -0500
                              Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 19:21 -1000
                                Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-22 13:38 +0000
                                  Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-22 08:50 -1000
                                Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-23 17:17 -0500
                                  Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-23 13:46 -1000
                                    Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 15:07 +0100
                                      Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-25 15:18 +0000
                                        Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-25 20:18 +0100
                                          Re: quick review of <BUILDS and CREATE history Coos Haak <chforth@hccnet.nl> - 2014-01-25 20:44 +0100
                                            Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-25 21:41 +0100
                                          Re: quick review of <BUILDS and CREATE history "Alex McDonald" <blog@rivadpm.com> - 2014-01-25 22:47 +0000
                                            Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-26 01:54 +0100
                                            Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 16:49 +0000
                                          Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 15:40 +0000
                                            Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-27 23:00 +0100
                                              Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-27 19:43 -0500
                                              Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-28 09:25 +0000
                                                Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-28 19:45 +0100
                                                  Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 15:32 +0000
                                              Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:20 +0000
                                    Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-25 15:28 +0000
                                      Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-25 13:51 -0600
                                        Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 15:34 +0000
                                  Re: quick review of <BUILDS and CREATE history Lars Brinkhoff <lars.spam@nocrew.org> - 2014-01-24 08:11 +0100
                                  Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 01:28 -0800
                                    Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 05:00 -0500
                                      Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 09:32 -1000
                                      Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 17:48 -0500
                                        Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 13:14 -1000
                                        Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 16:16 -0800
                                Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-23 12:13 -0500
                              Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-22 13:32 +0000
              Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-20 04:14 -0800
                Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-20 06:31 -0600
                  Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-20 08:04 -1000
                    Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-21 14:09 +0000
                Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 16:14 -0500
    Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-22 17:44 -0800
    Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-22 18:24 -0800
      Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-23 14:00 +0000
        Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-23 11:06 -0800
          Re: quick review of <BUILDS and CREATE history Paul Rubin <no.email@nospam.invalid> - 2014-01-23 11:33 -0800
            Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-23 11:42 -0800
          Re: quick review of <BUILDS and CREATE history Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 11:51 -0800

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#27998

On Tue, 21 Jan 2014 17:07:54 -0500, Elizabeth D. Rather  
<erather@forth.com> wrote:
> On 1/21/14 10:18 AM, Rod Pemberton wrote:

>> Sorry, yes, that should've had two colons which was, hopefully, obvious:
>>: : CREATE :NONAME DROP ...
>
> CREATE is inappropriate here. You want your word that builds a header.
> And :NONAME is also inappropriate because it returns the xt that youhave  
> to DROP. All you need to do is build the header, have a code
> field that points to DOCOL, and start the compiler.

I must've run into a problem somewhere.

It appears I backed out (CREATE) and these definitions:

: : (CREATE) COMPILE ENTER ] SMUDGE ;
: CREATE (CREATE) COMPILE DOVAR ;

I also had this definition for ; in another file paired with the
definition of : above:

: ; COMPILE EXIT SMUDGE [COMPILE] [ ; IMMEDIATE

It appears that (CREATE) when I backed it out is very similar to
the operations I have for :NONAME plus the BL WORD COUNT .. CMOVE
for name field in my : definition.

>> I have a low-level : and this would be for defining a new
>> high-level : in Forth.
>
> Why do you need 2 versions of : ?
>

I was attempting to eliminate the as much code in C as I could.
The idea was minimize as much non-standard behavior as possible by
having as little of the code in C as is possible.  If I can express
: in high-level Forth, I may be able to eliminate the bootstrap
version of : in C.

> There is nothing about a :NONAME to link.
>

I have to link "around" it.  I.e., the pointer used for linking could
be incorrect without a header for :NONAME.  Of course, it could
be correct also.  I don't know right now.  It gets updated somewhere
automatically.  I don't recall where I put that...  Sigh, I really
needed to review my code before discussing.

> Yes, the thing built by :NONAME has a code field, normally
> (in an ITC Forth) the address of DODOES, followed by the
> executable content.
>
> [...]
>
> An xt needs to be the address of the code required to execute the word.
> It has to be there for all words. That isn't what I'm calling the
> "header". A "header" consists of name and linking info.
>

Ah, the CFA is not part of the header...  So, words still have a CFA
without the header.

Sigh, I should've realized that.  The low-level "primitives" - because
they're in C - have NFA, LFA, DOES field, etc which can be placed after
the CFA and PFA by the C compiler.  The high-level Forth is compiled
sequentially.

Okay, that should mean the :NONAME definitions don't need a header.
It's still compiling an CFA, the ENTER.

> Hope this helps.
>

Yes.  Thanks.  I'm thinking what you said earlier should work.


Rod Pemberton

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

#28000

On 1/21/14 5:04 PM, Rod Pemberton wrote:
> On Tue, 21 Jan 2014 17:07:54 -0500, Elizabeth D. Rather
> <erather@forth.com> wrote:
>> On 1/21/14 10:18 AM, Rod Pemberton wrote:
>
>>> Sorry, yes, that should've had two colons which was, hopefully, obvious:
>>> : : CREATE :NONAME DROP ...
>>
>> CREATE is inappropriate here. You want your word that builds a header.
>> And :NONAME is also inappropriate because it returns the xt that
>> youhave to DROP. All you need to do is build the header, have a code
>> field that points to DOCOL, and start the compiler.
>
> I must've run into a problem somewhere.
>
> It appears I backed out (CREATE) and these definitions:
>
> : : (CREATE) COMPILE ENTER ] SMUDGE ;
> : CREATE (CREATE) COMPILE DOVAR ;

SMUDGE needs to go before ] since ] will compiler the definition, and 
it's during the compilation process it needs to be smudged.

I assume COMPILE ENTER and COMPILE DOVAR put the appropriate runtime 
addresses in the code fields, right?

> I also had this definition for ; in another file paired with the
> definition of : above:
>
> : ; COMPILE EXIT SMUDGE [COMPILE] [ ; IMMEDIATE

Ok.

> It appears that (CREATE) when I backed it out is very similar to
> the operations I have for :NONAME plus the BL WORD COUNT .. CMOVE
> for name field in my : definition.
>
>>> I have a low-level : and this would be for defining a new
>>> high-level : in Forth.
>>
>> Why do you need 2 versions of : ?
>>
>
> I was attempting to eliminate the as much code in C as I could.
> The idea was minimize as much non-standard behavior as possible by
> having as little of the code in C as is possible.  If I can express
> : in high-level Forth, I may be able to eliminate the bootstrap
> version of : in C.
>
>> There is nothing about a :NONAME to link.
>>
>
> I have to link "around" it.  I.e., the pointer used for linking could
> be incorrect without a header for :NONAME.  Of course, it could
> be correct also.  I don't know right now.  It gets updated somewhere
> automatically.  I don't recall where I put that...  Sigh, I really
> needed to review my code before discussing.

Why? Normally, a system remembers the last link field, often in a 
variable named LAST. So, when you're linking a new definition that is 
the place that your new link needs to point to. If :NONAME doesn't 
change it, everything will be fine.

>> Yes, the thing built by :NONAME has a code field, normally
>> (in an ITC Forth) the address of DODOES, followed by the
>> executable content.
>>
>> [...]
>>
>> An xt needs to be the address of the code required to execute the word.
>> It has to be there for all words. That isn't what I'm calling the
>> "header". A "header" consists of name and linking info.
>>
>
> Ah, the CFA is not part of the header...  So, words still have a CFA
> without the header.

In fact, the embedded code generated by a cross-compiler may have all 
definitions starting with a code field followed by the code, with the 
heads all kept in the cross-compiler for use during interactive development.

> Sigh, I should've realized that.  The low-level "primitives" - because
> they're in C - have NFA, LFA, DOES field, etc which can be placed after
> the CFA and PFA by the C compiler.  The high-level Forth is compiled
> sequentially.

Sounds like too many fields, unless I misunderstand you. Let's clear up 
some more issues:

NFA means "name field address" or the address of the name field in the 
header. It isn't normally a cell anywhere; words like >NAME generate it 
as an offset from the xt of the word (usuallly by adding or subtracting 
an implementation-dependent number of bytes). Likewise, the address of 
the other fields (code field or parameter field) can be calculated. And 
there is no DOES field, since DOES> patches the code field.

> Okay, that should mean the :NONAME definitions don't need a header.
> It's still compiling an CFA, the ENTER.
>
>> Hope this helps.
>>
>
> Yes.  Thanks.  I'm thinking what you said earlier should work.

Yay. I hope your code cleans up a lot as a result.

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]

#28003

"Elizabeth D. Rather" <erather@forth.com> writes:
>> It appears I backed out (CREATE) and these definitions:
>>
>> : : (CREATE) COMPILE ENTER ] SMUDGE ;
>> : CREATE (CREATE) COMPILE DOVAR ;
>
>SMUDGE needs to go before ] since ] will compiler the definition, and 
>it's during the compilation process it needs to be smudged.

In standard Forth ] just switches to compile state, so doing SMUDGE
afterwards is ok; the text interpreter that does the compilation will
only get control back after the SMUDGE.

- 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]

#28004

On 1/22/14 3:38 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> It appears I backed out (CREATE) and these definitions:
>>>
>>> : : (CREATE) COMPILE ENTER ] SMUDGE ;
>>> : CREATE (CREATE) COMPILE DOVAR ;
>>
>> SMUDGE needs to go before ] since ] will compiler the definition, and
>> it's during the compilation process it needs to be smudged.
>
> In standard Forth ] just switches to compile state, so doing SMUDGE
> afterwards is ok; the text interpreter that does the compilation will
> only get control back after the SMUDGE.

True. I was remembering some implementations in which ] is a loop.

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]

#28042

On Wed, 22 Jan 2014 00:21:23 -0500, Elizabeth D. Rather  
<erather@forth.com> wrote:

> Normally, a system remembers the last link field, often in a
> variable named LAST. So, when you're linking a new definition
> that is the place that your new link needs to point to. If
> :NONAME doesn't change it, everything will be fine.

Actually, indirectly, that *IS* the crux of my current problem!

It appears I had CREATE (CREATE) and :NONAME correct at one point.
But, :NONAME failed to work with RECURSE when I implemented it.
I fixed that issue by adding a dictionary header to :NONAME at
which point :NONAME's definition was only slightly different from
(CREATE).  Some time later, I realized the two were basically the
same, backed out (CREATE) and CREATE even though they're required
by ANS ... oops.  After that, I was working on re-coding and moving
around high-level versions of : and ; which added to the mess.  So,
I think I can get back to using correct versions of CREATE (CREATE)
and :NONAME but then my RECURSE won't work with :NONAME.

The issue is my RECURSE uses LAST which in my system points to the
start of the dictionary header (not LFA) to find the CFA which is
my XT.  For high-level Forth words, the CFA is just past the
dictionary header.  (CREATE) updates LAST so it points to the
most recent : definition.  If :NONAME doesn't have a dictionary
header, doesn't call (CREATE), and doesn't update LAST directly,
then LAST is set to the prior : definition, not the current :NONAME
definition.  Then, my RECURSE  obtains the wrong XT since it uses
LAST.  I fixed that issue by adding a header to :NONAME which was
incorrect.  If there is no dictionary header for a :NONAME definition,
how does LAST provide the correct value to RECURSE?  So, I'm assuming
RECURSE must use some method other than LAST to find the current
definition.  AIR, both ' and FIND need names.  How else does one
find a :NONAME definition?  Even if I correct LAST to point to
the LFA, I'll have the same problem, i.e., no apparent way to find
a :NONAME definition for RECURSE.

> And there is no DOES field, since DOES> patches the code field.

I had problems with that before.  A few people here helped out.
I ended up creating an extra field for DOES even though I didn't
want it.  I'm going to leave that issue alone for a while.  AIR,
the other solutions required modifyihg the PFA area too, which
could lead to problems.


Rod Pemberton

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

#28043

On 1/23/14 12:17 PM, Rod Pemberton wrote:
> On Wed, 22 Jan 2014 00:21:23 -0500, Elizabeth D. Rather
> <erather@forth.com> wrote:
>
>> Normally, a system remembers the last link field, often in a
>> variable named LAST. So, when you're linking a new definition
>> that is the place that your new link needs to point to. If
>> :NONAME doesn't change it, everything will be fine.
>
> Actually, indirectly, that *IS* the crux of my current problem!
>
> It appears I had CREATE (CREATE) and :NONAME correct at one point.
> But, :NONAME failed to work with RECURSE when I implemented it.
> I fixed that issue by adding a dictionary header to :NONAME at
> which point :NONAME's definition was only slightly different from
> (CREATE).  Some time later, I realized the two were basically the
> same, backed out (CREATE) and CREATE even though they're required
> by ANS ... oops.  After that, I was working on re-coding and moving
> around high-level versions of : and ; which added to the mess.  So,
> I think I can get back to using correct versions of CREATE (CREATE)
> and :NONAME but then my RECURSE won't work with :NONAME.
>
> The issue is my RECURSE uses LAST which in my system points to the
> start of the dictionary header (not LFA) to find the CFA which is
> my XT.  For high-level Forth words, the CFA is just past the
> dictionary header.  (CREATE) updates LAST so it points to the
> most recent : definition.  If :NONAME doesn't have a dictionary
> header, doesn't call (CREATE), and doesn't update LAST directly,
> then LAST is set to the prior : definition, not the current :NONAME
> definition.  Then, my RECURSE  obtains the wrong XT since it uses
> LAST.  I fixed that issue by adding a header to :NONAME which was
> incorrect.  If there is no dictionary header for a :NONAME definition,
> how does LAST provide the correct value to RECURSE?  So, I'm assuming
> RECURSE must use some method other than LAST to find the current
> definition.  AIR, both ' and FIND need names.  How else does one
> find a :NONAME definition?  Even if I correct LAST to point to
> the LFA, I'll have the same problem, i.e., no apparent way to find
> a :NONAME definition for RECURSE.
>
>> And there is no DOES field, since DOES> patches the code field.
>
> I had problems with that before.  A few people here helped out.
> I ended up creating an extra field for DOES even though I didn't
> want it.  I'm going to leave that issue alone for a while.  AIR,
> the other solutions required modifyihg the PFA area too, which
> could lead to problems.

Yes, you raised this topic in June 2012 (according to Google). If it 
were me, I'd simply declare that RECURSE won't work in :NONAME. If 
that's non-standard, it's not a limitation that will affect many people, 
since neither RECURSE nor :NONAME is used very often in my experience. 
And there's a really easy workaround:

DEFER FOO
:NONAME ... FOO ... ; IS FOO

Bingo.

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]

#28069

Elizabeth D. Rather wrote:
> Yes, you raised this topic in June 2012 (according to Google). If it
> were me, I'd simply declare that RECURSE won't work in :NONAME. If
> that's non-standard, it's not a limitation that will affect many people,
> since neither RECURSE nor :NONAME is used very often in my experience.

The solutition to RECURSE in :NONAME is have something like a LASTXT 
variable, where you store the last XT generated.  Or, as we handle it now in 
Gforth: RECURSE is just the alias to the last definition you made.  That got 
us rid of all the odds you had with RECURSE before (like not being able to 
POSTPONE it as intented).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#28089

Bernd Paysan <bernd.paysan@gmx.de> writes:
>The solutition to RECURSE in :NONAME is have something like a LASTXT 
>variable, where you store the last XT generated.  Or, as we handle it now in 
>Gforth: RECURSE is just the alias to the last definition you made.  That got 
>us rid of all the odds you had with RECURSE before (like not being able to 
>POSTPONE it as intented).

What do you mean with "POSTPONE it as intended".  The specification fo
RECURSE is clear:

|6.1.2120 RECURSE
|CORE
|
|	Interpretation: Interpretation semantics for this word are undefined.
|
|	Compilation: ( -- )
|
|Append the execution semantics of the current definition to the
|current definition. An ambiguous condition exists if RECURSE appears
|in a definition after DOES>.

So you can use POSTPONE RECURSE to define aliases of RECURSE:

: myself postpone recurse ; immediate
: test dup if dup . 1- myself then ;
5 test . \ should print "5 4 3 2 1 0"

That works correctly in 0.7.0, so what do you mean with "got rid of
all the odds"?

- 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]

#28092

Anton Ertl wrote:
> So you can use POSTPONE RECURSE to define aliases of RECURSE:
> 
> : myself postpone recurse ; immediate
> : test dup if dup . 1- myself then ;
> 5 test . \ should print "5 4 3 2 1 0"
> 
> That works correctly in 0.7.0, so what do you mean with "got rid of
> all the odds"?

Ok, POSTPONE did work all right (we had to), but now you can also use ['] 
RECURSE to get the xt of the current definition (which normally isn't that 
easy...).  You can also have TO or IS RECURSE, if the currently defined word 
has an IS or TO action (usually it won't have one, though ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#28093

Op Sat, 25 Jan 2014 20:18:32 +0100 schreef Bernd Paysan:

> Anton Ertl wrote:
>> So you can use POSTPONE RECURSE to define aliases of RECURSE:
>> 
>>: myself postpone recurse ; immediate
>>: test dup if dup . 1- myself then ;
>> 5 test . \ should print "5 4 3 2 1 0"
>> 
>> That works correctly in 0.7.0, so what do you mean with "got rid of
>> all the odds"?
> 
> Ok, POSTPONE did work all right (we had to), but now you can also use ['] 
> RECURSE to get the xt of the current definition (which normally isn't that 
> easy...).  You can also have TO or IS RECURSE, if the currently defined word 
> has an IS or TO action (usually it won't have one, though ;-).

Example?

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#28095

Coos Haak wrote:
>> Ok, POSTPONE did work all right (we had to), but now you can also use [']
>> RECURSE to get the xt of the current definition (which normally isn't
>> that
>> easy...).  You can also have TO or IS RECURSE, if the currently defined
>> word has an IS or TO action (usually it won't have one, though ;-).
> 
> Example?

For the ['] part, an example is fairly easy.  Let's say you want to display 
something, and there' a deferred word which causes a redisplay when a redraw 
is necessary:

: draw-foo ( -- ) ['] recurse is redraw
  <things to draw a foo> ;

Then after draw-foo, it will not only draw it now, but also whenever there's 
a redraw necessary.

TO and IS for normal words?  Not very likely, but think of a method:

m: foo ( xt -- ) change-behavior? IF is recurse ELSE drop THEN ;m

That assumes that you can assign new behavior to a method with IS or TO (in 
current git Gforth, they do the same thing).

m: would create something with a TO/IS action.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#28096

on 25/01/2014 19:18:28, Bernd Paysan wrote:
> Anton Ertl wrote:
>> So you can use POSTPONE RECURSE to define aliases of RECURSE:
>>
>> : myself postpone recurse ; immediate
>> : test dup if dup . 1- myself then ;
>> 5 test . \ should print "5 4 3 2 1 0"
>>
>> That works correctly in 0.7.0, so what do you mean with "got rid of
>> all the odds"?
> 
> Ok, POSTPONE did work all right (we had to), but now you can also use
> ['] RECURSE to get the xt of the current definition (which normally

That is plainly wrong. ' RECURSE will return a different xt than [']
RECURSE, and ['] clearly states "The execution token returned by the
compiled phrase "['] X" is the same value returned by "' X" outside of
compilation state.


> isn't that easy...). You can also have TO or IS RECURSE, if the
> currently defined word has an IS or TO action (usually it won't have
> one, though ;-).
> 

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

#28100

Alex McDonald wrote:

> on 25/01/2014 19:18:28, Bernd Paysan wrote:
>> Anton Ertl wrote:
>>> So you can use POSTPONE RECURSE to define aliases of RECURSE:
>>>
>>> : myself postpone recurse ; immediate
>>> : test dup if dup . 1- myself then ;
>>> 5 test . \ should print "5 4 3 2 1 0"
>>>
>>> That works correctly in 0.7.0, so what do you mean with "got rid of
>>> all the odds"?
>> 
>> Ok, POSTPONE did work all right (we had to), but now you can also use
>> ['] RECURSE to get the xt of the current definition (which normally
> 
> That is plainly wrong. ' RECURSE will return a different xt than [']
> RECURSE, and ['] clearly states "The execution token returned by the
> compiled phrase "['] X" is the same value returned by "' X" outside of
> compilation state.

: test ['] recurse ; ' recurse test . . 140485567108688 140485567108688  ok

So what's the problem?

The interpretation semantics of RECURSE is by the standard undefined.  It 
does execute the last definition in current git Gforth.

I accept that if a word can be [']-ed, it also can be '-ed, and the 
interpretation semantics is identical to ' it and EXECUTE that.  All those 
conditions are met here.  RECURSE is just an alias to the current/last 
definition.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#28127

"Alex McDonald" <blog@rivadpm.com> writes:
>> Ok, POSTPONE did work all right (we had to), but now you can also use
>> ['] RECURSE to get the xt of the current definition (which normally
>
>That is plainly wrong. ' RECURSE will return a different xt than [']
>RECURSE, and ['] clearly states "The execution token returned by the
>compiled phrase "['] X" is the same value returned by "' X" outside of
>compilation state.

When I asked about ['] EXIT, I got an informal answer that a standard
program cannot tick words without interpretation semantics.  That
would apply to RECURSE, too.  So a standard system can do funny things
when the user ticks RECURSE; whether it is wise to do the thing that
git Gforth does is up for discussion.

- 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]

#28126

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> So you can use POSTPONE RECURSE to define aliases of RECURSE:
>> 
>> : myself postpone recurse ; immediate
>> : test dup if dup . 1- myself then ;
>> 5 test . \ should print "5 4 3 2 1 0"
>> 
>> That works correctly in 0.7.0, so what do you mean with "got rid of
>> all the odds"?
>
>Ok, POSTPONE did work all right (we had to), but now you can also use ['] 
>RECURSE to get the xt of the current definition (which normally isn't that 
>easy...).

: foo recursive ['] foo ;

For :NONAME words it's a bit lower-level:

: foo [ lastxt ]L ;

Both pretty easy.  And both non-standard, but so is ['] RECURSE.

Some may wonder what this is good for, but I have used it in an
application, e.g.:

: bb-data-flow recursive { bb -- }
    assert( bb is-bb? )
    regs-changed off
    bb bb-predecessors @ bb ['] data-flow map-set1
    regs-changed @ if
      bb definers-in bb bb-gen bb definers-out regs-mask
      bb bb-successors @ ['] bb-data-flow map-set
    endif ;

I.e., it is useful for graph-walking algorithms, where you use
recursion to visit a successor in the graph, and combine that with the
xt-passing style for cycling through the successors of a given node.

Anyway, back to ['] RECURSE and friends: a RECURSE that always is a
named reference to the latest word is a cute trick, but is so unusual
and unlike the way the usual Forth words work that I wonder if it is a
good idea or a bad one (it would not be the first cute trick in the
Forth world that turned out to be a bad idea).  I guess we will see.

- 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]

#28137

Anton Ertl wrote:
> Anyway, back to ['] RECURSE and friends: a RECURSE that always is a
> named reference to the latest word is a cute trick, but is so unusual
> and unlike the way the usual Forth words work that I wonder if it is a
> good idea or a bad one (it would not be the first cute trick in the
> Forth world that turned out to be a bad idea).  I guess we will see.

Having SYNONYM in the standard means that named references to something else 
isn't unusual, it's a necessary feature.  The definition of RECURSE 
therefore is a simple

' noop Alias recurse

The next thing is then to give the address of the alias pointer of RECURSE a 
name so that you can change that alias (the noop is just a dummy).  The 
POSTPONE RECURSE thing works, since in git Gforth, postpone is compiling the 
name token as literal plus a word that performs the compilation action of a 
name token.  As we have introduced name tokens in the standard, too, this is 
the obvious (generic) way to do it (name tokens on git Gforth are almost 
identical to xts, with the exception that an alias has a name token of its 
own).

IMHO this is both the smallest possible and the most general implementation 
of RECURSE.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#28146

On Mon, 27 Jan 2014 17:00:16 -0500, Bernd Paysan <bernd.paysan@gmx.de>  
wrote:

> The definition of RECURSE therefore is a simple
>
> ' noop Alias recurse
>
> [...]
>
> IMHO this is both the smallest possible and the most
> general implementation of RECURSE.

Is that even worth pointing out, if the typical RECURSE
definition is something like this:

: RECURSE LATESTXT @ COMPILE, ; IMMEDIATE

Why does it matter that yours is smallest and more general?


Rod Pemberton

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

#28150

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Anyway, back to ['] RECURSE and friends: a RECURSE that always is a
>> named reference to the latest word is a cute trick, but is so unusual
>> and unlike the way the usual Forth words work that I wonder if it is a
>> good idea or a bad one (it would not be the first cute trick in the
>> Forth world that turned out to be a bad idea).  I guess we will see.
>
>Having SYNONYM in the standard means that named references to something else 
>isn't unusual, it's a necessary feature.

Yes, but a word that is changed whenever some word is defined is
unusual.

Ok, the value LASTXT returns changes whenever a word is defined, so we
have something like that already.  But that's the only purpose of
LASTXT, so that's not really surprising.  For RECURSE the original
purpose is just to compile a reference to the last defined word, not
to be a synonym for the last defined word, so for RECURSE it's
surprising, at least for me.  Maybe we will find productive uses for
this new, extended RECURSE, and hopefully there are no pitfalls that
we find only afterwards.

- 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]

#28158

Anton Ertl wrote:
> Yes, but a word that is changed whenever some word is defined is
> unusual.
> 
> Ok, the value LASTXT returns changes whenever a word is defined, so we
> have something like that already.  But that's the only purpose of
> LASTXT, so that's not really surprising.  For RECURSE the original
> purpose is just to compile a reference to the last defined word, not
> to be a synonym for the last defined word, so for RECURSE it's
> surprising, at least for me.  Maybe we will find productive uses for
> this new, extended RECURSE, and hopefully there are no pitfalls that
> we find only afterwards.

If you look at the rationale of RECURSE, you will find that "on some systems 
this is called MYSELF".  If you think of RECURSE as MYSELF, I suspect that 
your surprise is going away.

The reason I made this change for was that the original RECURSE didn't do 
all what RECURSIVE could do.  The obviously missing part is ['] the curent 
word.

The obvious difference between git Gforth's RECURSE and Gforth's 0.7.x 
RECURSE is when you [COMP'] both.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#28170

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Yes, but a word that is changed whenever some word is defined is
>> unusual.
>> 
>> Ok, the value LASTXT returns changes whenever a word is defined, so we
>> have something like that already.  But that's the only purpose of
>> LASTXT, so that's not really surprising.  For RECURSE the original
>> purpose is just to compile a reference to the last defined word, not
>> to be a synonym for the last defined word, so for RECURSE it's
>> surprising, at least for me.  Maybe we will find productive uses for
>> this new, extended RECURSE, and hopefully there are no pitfalls that
>> we find only afterwards.
>
>If you look at the rationale of RECURSE, you will find that "on some systems 
>this is called MYSELF".  If you think of RECURSE as MYSELF, I suspect that 
>your surprise is going away.

Yes, MYSELF is probably less surprising in that respect, but even
worse than RECURSE for implementing recursion.

>The reason I made this change for was that the original RECURSE didn't do 
>all what RECURSIVE could do.  The obviously missing part is ['] the curent 
>word.

Ok, but RECURSIVE is preferable anyway, because calling the word by
name instead of by RECURSE tells the reader the "what", not the "how".

And for the few cases where you want to tick the currently-defined
word, giving these words names is a small burden, if any (at least I
have not missed the ability to tick the current :NONAME definition
yet).

- 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]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web