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

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

Can every Forth do this?

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

Contents

  Can every Forth do this? JennyB <jennybrien@googlemail.com> - 2014-10-07 07:33 -0700
    Re: Can every Forth do this? Roger Levy <roger.levy@gmail.com> - 2014-10-07 08:58 -0700
    Re: Can every Forth do this? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-07 16:16 +0000
      Re: Can every Forth do this? november.nihal@gmail.com - 2014-10-08 06:17 -0700
        Re: Can every Forth do this? Mark Wills <markwills1970@gmail.com> - 2014-10-08 09:55 -0700
        Re: Can every Forth do this? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-09 15:26 +0000
          Re: Can every Forth do this? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-09 19:42 +0100
    Re: Can every Forth do this? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-07 18:16 +0000
      Re: Can every Forth do this? Jason Damisch <jasondamisch@yahoo.com> - 2014-10-07 11:32 -0700
      Re: Can every Forth do this? Mark Wills <markwills1970@gmail.com> - 2014-10-07 14:27 -0700
        Re: Can every Forth do this? "Elizabeth D. Rather" <erather@forth.com> - 2014-10-07 13:38 -1000
          Re: Can every Forth do this? Mark Wills <markwills1970@gmail.com> - 2014-10-07 20:21 -0700
          Re: Can every Forth do this? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-08 11:33 +0000
            Re: Can every Forth do this? JennyB <jennybrien@googlemail.com> - 2014-10-08 06:25 -0700
              Re: Can every Forth do this? november.nihal@gmail.com - 2014-10-08 08:14 -0700
                Re: Can every Forth do this? Mark Wills <markwills1970@gmail.com> - 2014-10-08 10:10 -0700
                  Re: Can every Forth do this? JennyB <jennybrien@googlemail.com> - 2014-10-08 11:42 -0700
                    Re: Can every Forth do this? Roger Levy <roger.levy@gmail.com> - 2014-10-08 12:31 -0700
                      Re: Can every Forth do this? JennyB <jennybrien@googlemail.com> - 2014-10-09 07:03 -0700
                    Re: Can every Forth do this? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-08 19:33 +0000
                  Re: Can every Forth do this? november.nihal@gmail.com - 2014-10-08 16:39 -0700
                    Re: Can every Forth do this? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-08 23:45 +0000
            Re: Can every Forth do this? Harold <hzrabbie@gmail.com> - 2014-10-08 14:23 -0700
              Re: Can every Forth do this? "Elizabeth D. Rather" <erather@forth.com> - 2014-10-08 12:48 -1000
              Re: Can every Forth do this? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-08 23:39 +0000
          Re: Can every Forth do this? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 13:17 +0000
          Re: Can every Forth do this? Roger Levy <roger.levy@gmail.com> - 2014-10-08 07:33 -0700
            Re: Can every Forth do this? Roger Levy <roger.levy@gmail.com> - 2014-10-08 07:33 -0700
    Re: Can every Forth do this? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-07 20:23 +0100

Page 1 of 2  [1] 2  Next page →

#33730 — Can every Forth do this?

I've often seen implementation-specific versions of this, or its equivalent, and wondered if there are any Forth where it is not practical:

   DOES xt -- n
   Where xt belongs to a word defined by 
    CREATE ... DOES>
   n uniquely identifies its parent.

Is it also practical to derive n directly from the parent without creating a prototype child and then calling DOES ?
.

[toc] | [next] | [standalone]

#33731

What are you trying to do?

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

#33733

JennyB <jennybrien@googlemail.com> writes:
>I've often seen implementation-specific versions of this, or its equivalent, and wondered if there are any Forth where it is not practical:
>
>   DOES xt -- n
>   Where xt belongs to a word defined by 
>    CREATE ... DOES>
>   n uniquely identifies its parent.

Should be possible everywhere, because EXECUTE needs to identify the
DOES> part in order to work.  Concerning "uniquely", in theory two
equal DOES> parts might have the same identity as far as EXECUTE is
concerned, but I doubt that any current Forth system does that
optimization.

>Is it also practical to derive n directly from the parent without creating a prototype child and then calling DOES ?

No, there may be several DOES> in a word, and CREATE and DOES> may be
in different words, and there may be several DOES> applied to the same
CREATEd word.  Even specifying what you want is probably difficult,
and even for a simple definition (where you only support one DOES> in
a word, and want to derive the definer from that) you incur additional
implementation cost whether that feature is used or not (you would
need an additional header field AFAICS).

- 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 2014: http://www.euroforth.org/ef14/

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

#33754

This caught my attention as I wasn't aware this was possible, the ability to have several does> in a word.

" [snipped ] ... 

No, there may be several DOES> in a word, and CREATE and DOES> may be 
in different words, and there may be several DOES> applied to the same 
CREATEd word.  

... [ snipped ]"

Does anyone have any examples I could look at to understand ?

NN.

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

#33765

On Wednesday, 8 October 2014 14:17:49 UTC+1, novembe...@gmail.com  wrote:
> This caught my attention as I wasn't aware this was possible, the ability to have several does> in a word.
> 
> 
> 
> " [snipped ] ... 
> 
> 
> 
> No, there may be several DOES> in a word, and CREATE and DOES> may be 
> 
> in different words, and there may be several DOES> applied to the same 
> 
> CREATEd word.  
> 
> 
> 
> ... [ snipped ]"
> 
> 
> 
> Does anyone have any examples I could look at to understand ?
> 
> 
> 
> NN.

Here's an example from my retro system:

http://www.youtube.com/watch?v=VxvNvCGdhdA

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

#33787

november.nihal@gmail.com writes:
>This caught my attention as I wasn't aware this was possible, the ability to have several does> in a word.
>
>" [snipped ] ... 
>
>No, there may be several DOES> in a word, and CREATE and DOES> may be 
>in different words, and there may be several DOES> applied to the same 
>CREATEd word.  
>
>... [ snipped ]"
>
>Does anyone have any examples I could look at to understand ?

Actually useful exaple (but not sure whether you understand it):

<http://www.complang.tuwien.ac.at/forth/struct.fs>

Look at CREATE-FIELD, DOFIELD, DOZEROFIELD, and FIELD.

Simple contrived example:

: x ( f -- )
  does> drop ." a"
  does> drop ." b" ;

create a x
a
a
a
x
a
a
a

Have fun thinking it through:-)

- 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 2014: http://www.euroforth.org/ef14/

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

#33789

On 09/10/2014 16:26, Anton Ertl wrote:
> november.nihal@gmail.com writes:
>> This caught my attention as I wasn't aware this was possible, the ability to have several does> in a word.
>>
>> " [snipped ] ...
>>
>> No, there may be several DOES> in a word, and CREATE and DOES> may be
>> in different words, and there may be several DOES> applied to the same
>> CREATEd word.
>>
>> ... [ snipped ]"
>>
>> Does anyone have any examples I could look at to understand ?
>
> Actually useful exaple (but not sure whether you understand it):
>
> <http://www.complang.tuwien.ac.at/forth/struct.fs>
>
> Look at CREATE-FIELD, DOFIELD, DOZEROFIELD, and FIELD.
>
> Simple contrived example:
>
> : x ( f -- )
>    does> drop ." a"
>    does> drop ." b" ;
>
> create a x
> a
> a
> a
> x
> a
> a
> a
>
> Have fun thinking it through:-)
>

And if you want more amusement here is how you can implement an FSM with 
it. It's not very practical though.

defer init
: ?key ( x ch -- f )  \ f = true if char not recognised
    nip key dup [char] q = abort" Aborted"
    dup emit <>
;

\ all op's are ( ad -- )
: state-d ." state-d " [char] d ?key 0= if cr ." Recognised" cr then init ;
: state-c ." state-c " [char] c ?key if init exit then does> state-d ;
: state-b ." state-b " [char] b ?key if init exit then does> state-c ;
: state-a ." state-a " [char] a ?key if init exit then does> state-b ;

:noname does> state-a ; is init

create run init
cr run 0 >in !       \ loop until 'q' is pressed

All the states can be put into one definition with multiple DOES>'s

-- 
Gerry

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

#33734

In article <9b988010-d503-43f9-bb61-5407e919ac8a@googlegroups.com>,
JennyB  <jennybrien@googlemail.com> wrote:
>I've often seen implementation-specific versions of this, or its equivalent, and wondered if there are any Forth where it is not practical:
>
>   DOES xt -- n
>   Where xt belongs to a word defined by
>    CREATE ... DOES>
>   n uniquely identifies its parent.
>
>Is it also practical to derive n directly from the parent without creating a prototype child and then calling DOES ?
>.

You need to tell a lot more before I understand this
question. Apparently Anton Ertl does, but even with his
answer I don't understand what you're asking.

E.g. the "parent" of a word is not a jargon I'm familiar with.

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]

#33735

On Tuesday, October 7, 2014 11:16:50 AM UTC-7, Albert van der Horst wrote:

> E.g. the "parent" of a word is not a jargon I'm familiar with.

This probably relates to some sort of object programming paradigm.  Given that this is Forth, that would be a pretty broad topic.  The possibilites are nearly endless.

Jason

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

#33739

The parent is the word that creates the child. 

: constant create , does> @ ;
9 constant nine

Constant is the parent of nine. 

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

#33742

On 10/7/14 11:27 AM, Mark Wills wrote:
> The parent is the word that creates the child.
>
> : constant create , does> @ ;
> 9 constant nine
>
> Constant is the parent of nine.
>

So, if the question is whether you can *always* get to CONSTANT from 
nine, the answer is no. In some implementations you could get to nine's 
parent from its xt, but some implementations of CONSTANT compile 
literals in place or do other things, so there is no xt.

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]

#33746

Indeed. I my implementation it would not be very easy at all. The child words contain some data that is used to execute a branch to the does> code in the parent. It would be very difficult to get back to the dictionary entry or the c for a off the parent from there. 

The simplest solution would be store some data in the child  at CREATE time allowing the parent word to be looked up.

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

#33750

In article <YPudnUS6_47k5KnJnZ2dnUU7-cOdnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 10/7/14 11:27 AM, Mark Wills wrote:
>> The parent is the word that creates the child.
>>
>> : constant create , does> @ ;
>> 9 constant nine
>>
>> Constant is the parent of nine.
>>
>
>So, if the question is whether you can *always* get to CONSTANT from
>nine, the answer is no. In some implementations you could get to nine's
>parent from its xt, but some implementations of CONSTANT compile
>literals in place or do other things, so there is no xt.

Indeed in ciforth you would have

9 CONSTANT nine
' nine >DFA @ .
9 OK

But that is because CONSTANT is defined in the standard and can be
implemented evert which way.

If constant is defined in the above way, you can get from nine to 9
by the phrase

' nine >BODY @

which is AFAIK perfectly sound ISO Forth.

The OP was talking about an xt.
Maybe >BODY was the word he was looking for.

Now CONSTANT may be special, but all home brew defining words
made using CREATE DOES> allow similar manipulations.

>
>Cheers,
>Elizabeth

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]

#33757

I'll try to explain. 

Say you have a defining word : FOO CREATE ... DOES> BAR ;

You have an xt which may, or may not, have been defined by FOO and you want to do something with it if, and only if, it was.

You need some quick-and-dirty type checking.  I have several times seen system-specific code in this pattern:

   foo A
   ' A does CONSTANT foo-like

and the runtime test

    ( xt ) does foo-like = IF

but I don't think I've ever seen DOES factored out, and I wondered about the possible problems.

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

#33761

Would this be something along the lines of what you are trying to do ?

: typ  ( a b name -- )
	create , , ( [id] [space] )
	does>
		create
		dup @ ,
		here ,
		cell+ @ dup , chars allot
		does> 2 cells +
	;

: does ( xt -- n ) 2 cells - @ ;

\ create some typ s
1  1 typ chr
2  2 typ sint
4  3 typ inte
8  4 typ lint
8  5 typ flt
10 6 typ dbl

\ define using type
chr  AA
sint BB
inte CC
lint DD
flt  EE
dbl  FF

\ get type through child via does
\ just checking what space I have allotted
cr cr
cr aa . aa @ . aa lcount . . aa does .
cr bb . bb @ . bb lcount . . bb does .
cr cc . cc @ . cc lcount . . cc does .
cr dd . dd @ . dd lcount . . dd does .
cr ee . ee @ . ee lcount . . ee does .
cr ff . ff @ . ff lcount . . ff does .

\ get 'n' through words created using typ
cr cr
cr ' chr  >body @ .
cr ' sint >body @ .
cr ' inte >body @ .
cr ' lint >body @ .
cr ' flt  >body @ .
cr ' dbl  >body @ .


If not then I don't think I have understood the intention and I will leave it for others. 

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

#33767

On Wednesday, 8 October 2014 16:14:15 UTC+1, novembe...@gmail.com  wrote:
> Would this be something along the lines of what you are trying to do ?
> 
> 
> 
> : typ  ( a b name -- )
> 
> 	create , , ( [id] [space] )
> 
> 	does>
> 
> 		create
> 
> 		dup @ ,
> 
> 		here ,
> 
> 		cell+ @ dup , chars allot
> 
> 		does> 2 cells +
> 
> 	;
> 
> 
> 
> : does ( xt -- n ) 2 cells - @ ;
> 
> 
> 
> \ create some typ s
> 
> 1  1 typ chr
> 
> 2  2 typ sint
> 
> 4  3 typ inte
> 
> 8  4 typ lint
> 
> 8  5 typ flt
> 
> 10 6 typ dbl
> 
> 
> 
> \ define using type
> 
> chr  AA
> 
> sint BB
> 
> inte CC
> 
> lint DD
> 
> flt  EE
> 
> dbl  FF
> 
> 
> 
> \ get type through child via does
> 
> \ just checking what space I have allotted
> 
> cr cr
> 
> cr aa . aa @ . aa lcount . . aa does .
> 
> cr bb . bb @ . bb lcount . . bb does .
> 
> cr cc . cc @ . cc lcount . . cc does .
> 
> cr dd . dd @ . dd lcount . . dd does .
> 
> cr ee . ee @ . ee lcount . . ee does .
> 
> cr ff . ff @ . ff lcount . . ff does .
> 
> 
> 
> \ get 'n' through words created using typ
> 
> cr cr
> 
> cr ' chr  >body @ .
> 
> cr ' sint >body @ .
> 
> cr ' inte >body @ .
> 
> cr ' lint >body @ .
> 
> cr ' flt  >body @ .
> 
> cr ' dbl  >body @ .
> 
> 
> 
> 
> 
> If not then I don't think I have understood the intention and I will leave it for others.

That's the sort of thing I was alluding to in my earlier post. 
The parent word lays down some sort of identifier that the child can
use later if it needs to.

I would have posted some code but it was 4:20 am and I was using
my mobile 'phone :-)

Your code seemed to work on my retro ITC system as far as I could
tell - unfortunately I don't have LCOUNT. I did a search of the ANS
word-set but I didn't see it.

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

#33769

All I need to do is distinguish the xt of a word defined by a particular defining word from any other arbitrary xt.

I've checked the only Forth I have to hand at the moment (gforth for Android) and there the definition of DOES is simply @. I suspect it is the same on many Forth,  but in some it many be different, or only possible in low-level code. 

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

#33770

On Wednesday, October 8, 2014 2:42:58 PM UTC-4, JennyB wrote:
> All I need to do is distinguish the xt of a word defined by a particular defining word from any other arbitrary xt.
> 
> 
> 
> I've checked the only Forth I have to hand at the moment (gforth for Android) and there the definition of DOES is simply @. I suspect it is the same on many Forth,  but in some it many be different, or only possible in low-level code.

May I ask what the purpose of this is?

Anyway don't count on implementation details.  That's not good practice.  Implement your own CREATE DOES> if you want to count on anything.

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

#33783

On Wednesday, 8 October 2014 20:31:44 UTC+1, Roger Levy  wrote:

> May I ask what the purpose of this is?
> 
> 
> 
> Anyway don't count on implementation details.  That's not good practice.  Implement your own CREATE DOES> if you want to count on anything.

It turns out to have been a dead end, but an interesting one.

I was thinking of the Recognizers, which seen a good way to clean up the Forth interpreter model.  A Recognizer takes a string addr u and returns the result (xt, number, float, string, whatever) and the address of a table that shows how to interpret, compile or postpone it. If it does not recognize the string, it returns the original string and the table R:FAIL.

That makes interpreters simply a stack of recognizers that are executed in turn, ending with the first that does not return R:FAIL.  The one at the bottom simply throws a "word not found" error. You then use the returned table to interpret, or compile the result according to current STATE, and parse again. Any word that takes a string and returns a table may be a recognizer, and you could swap them in and out at need.

So, how to write a Standard Forth interpreter on this model without adding anything more than necessary?

Standard Forth already has a SEARCH-ORDER stack, so can were simply use it to hold recognizers? 

First thought: We need a Recognizer for each individual wordlist.  Looks like a job for CREATE DOES>

: SEARCH-LIST \ addr u wid -- xt table | addr u table
   >R 2DUP R> SEARCH-WORDLIST 
   CASE
    -1 OF NIP NIP R:NORMAL ENDOF
     1 OF NIP NIP R:IMMEDIATE ENDOF
     0 OF 2DROP R:FAIL 
   ENDCASE ;


: FINDER  CREATE , \ wordlist
  DOES>  @ SEARCH-LIST ;


FORTH-WORDLIST FINDER REC:FORTH

Simple.

Put your error-handler at the bottom of the SEARCH order, put an INTEGER recognizer on top. If your forth has FP, add a recognizer for that, and make that the minimal search order.

Nearly done.

Now, what Standard words require a wordlist from an item on the search order stack?  SEARCH-WORDLIST, SET-CURRENT and DEFINITIONS.

This is where I raised my original question.
The last two must throw an error if they given a recognizer that is not defined by FINDER, otherwise they set the associated wordlist as the compilation wordlist and store the recognizer to be returned by GET-CURRENT. SEARCH-WORDLIST can simply return zero for inappropriate recognizers.  FIND can then be defined in terms of SEARCH-WORDLIST - apply to each search order item in turn until you get a non-zero or run out of items.

If I can be sure to distinguish FINDER recognizers from others, that's more or less it.

But...

WORDLIST CONSTANT AWORDLIST

Can't be done this way, unless there are such things as nameless DOES>  and that just seems too bizarre.

The difference between wordlists and recognizers is fundamental, and should be reflected in the main interpreter. They're a bit like normal and immediate words, but on a different level. 

The simplest way to distinguish them would be both were even; leave wordlists alone and set the lsb of recognizers before they go on the search order:

  : MATCHES  1+ CONSTANT ; \ needs system-dependant work to be seen by ORDER

  ' REC:DATES MATCHES DATES

  : SEARCH-WORDLIST  DUP 1 AND IF DROP 2DROP 0 ELSE SEARCH-WORDLIST THEN ;

and the main interpreter goes down the search order doing:

              ... DUP 1 AND IF \ it's a recognizer
                   1- EXECUTE ELSE
                 SEARCH-LIST THEN

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

#33771

In article <c859198c-8603-4eb5-be88-4893037fb2a5@googlegroups.com>,
JennyB  <jennybrien@googlemail.com> wrote:
>All I need to do is distinguish the xt of a word defined by a particular
>defining word from any other arbitrary xt.
>
>I've checked the only Forth I have to hand at the moment (gforth for
>Android) and there the definition of DOES is simply @. I suspect it is
>the same on many Forth,  but in some it many be different, or only
>possible in low-level code.

I can tell you how it is in ciforth.

Suppose we have
: myclass   CREATE blabla DOES> bloblo ;

There are two data items associated with ape after
... ( data )  myclass ape

The first thing is a pointer to the bloblo code. This must be
data because it can be changed by the next DOES> that comes
along. This field is hidden, the only way to touch it portably
is via DOES> .
The other is the payload data set up by the code blabla.
This can be accessed portably via
  ' ape >BODY

In all ciforths the place where the pointer resides can be found
via the data field of ape:
' ape >DFA @

So with another @ you will have an address that is one to one
with the bloblo code
' ape >DFA @ @ CONSTANT =bloblo

Now we can test anything for blobloness:

( xt - flag ) \ is xt a bloblo?
: ?bloblo    >DFA @ @ =bloblo = ;

myclass note    ' note ?bloblo .
-1 OK

: class2 CREATE bleble DOES> blu blu ;

class2 note    ' note ?bloblo .
0 OK

P.S. Most Forths are designed more for speed than transparency and
the situation around CREATE DOES> can be messy.

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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web