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

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

Implementing ." in forth

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

Contents

  Implementing ." in forth Arnold Doray <invalid@invalid.com> - 2012-08-23 14:12 +0000
    Re: Implementing ." in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-23 14:45 +0000
      Re: Implementing ." in forth Arnold Doray <invalid@invalid.com> - 2012-08-24 11:30 +0000
        Re: Implementing ." in forth Josh Grams <josh@qualdan.com> - 2012-08-24 12:56 +0000
        Re: Implementing ." in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-24 14:41 +0000
          Re: Implementing ." in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-24 16:45 +0000
          Re: Implementing ." in forth Arnold Doray <invalid@invalid.com> - 2012-08-25 03:41 +0000
            Re: Implementing ." in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-25 09:05 +0000
              Re: Implementing ." in forth Arnold Doray <invalid@invalid.com> - 2012-08-29 15:48 +0000
                Re: Implementing ." in forth Coos Haak <chforth@hccnet.nl> - 2012-08-29 21:19 +0200
                Re: Implementing ." in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 13:00 +0000
    Re: Implementing ." in forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-23 12:00 -0500
    Re: Implementing ." in forth Spam@ControlQ.com - 2012-08-23 14:16 -0400
    Re: Implementing ." in forth Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-23 14:37 -0700
    Re: Implementing ." in forth "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-23 19:37 -0400
    Re: Implementing ." in forth hughaguilar96@yahoo.com - 2012-08-24 00:06 -0700
      Re: Implementing ." in forth Arnold Doray <invalid@invalid.com> - 2012-08-24 11:32 +0000
        Re: Implementing ." in forth Doug Hoffman <glidedog@gmail.com> - 2012-08-24 08:33 -0400
    Re: Implementing ." in forth jim@rainbarrel.com - 2012-08-24 09:15 -0700
    Re: Implementing ." in forth Chris Hinsley <chris.hinsley@gmail.com> - 2012-08-25 15:15 +0100

#15119 — Implementing ." in forth

I am trying to write a small compatability harness for Mini (mini.terra-
weather.com) and am stumbling over ." (Mini has built-in strings, and 
uses . instead of ." )

Anyway, I see it needs:

1) a PARSE to run immediately (because ." may be used inside a word),
2) then it needs to compile the string as a literal if in compilation 
mode. 
3) It needs to display the string, but not immediately. 

My problem is that there are some things that need to be done 
immediately, and others delayed. And there is a need to know if ." is 
being executed while in compilation mode. 

I am sure I am missing something. It surely can't be this complicated. I 
would greatly appreciate any help. 

Thanks,
Arnold

 

[toc] | [next] | [standalone]

#15120

Arnold Doray <invalid@invalid.com> writes:
>I am trying to write a small compatability harness for Mini (mini.terra-
>weather.com) and am stumbling over ." (Mini has built-in strings, and 
>uses . instead of ." )
>
>Anyway, I see it needs:
>
>1) a PARSE to run immediately (because ." may be used inside a word),
>2) then it needs to compile the string as a literal if in compilation 
>mode. 
>3) It needs to display the string, but not immediately. 
>
>My problem is that there are some things that need to be done 
>immediately, and others delayed. And there is a need to know if ." is 
>being executed while in compilation mode. 
>
>I am sure I am missing something. It surely can't be this complicated. I 
>would greatly appreciate any help. 

Well, the standard ." has undefined interpretation semantics, so you
just need to worry about the compilation semantics unless you want to
extend it.

You identified the parts correctly.  Here's an implementation in
standard Forth:

: ."
  [char] " parse    \ part 1)
  postpone sliteral \ part 2)
  postpone type     \ part 3)
; immediate

- 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 2012: http://www.euroforth.org/ef12/

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

#15130

On Thu, 23 Aug 2012 14:45:07 +0000, Anton Ertl wrote:

> Arnold Doray <invalid@invalid.com> writes:
>>I am trying to write a small compatability harness for Mini (mini.terra-
>>weather.com) and am stumbling over ." (Mini has built-in strings, and
>>uses . instead of ." )
>>
>>Anyway, I see it needs:
>>
>>1) a PARSE to run immediately (because ." may be used inside a word), 2)
>>then it needs to compile the string as a literal if in compilation mode.
>>3) It needs to display the string, but not immediately.
>>
>>My problem is that there are some things that need to be done
>>immediately, and others delayed. And there is a need to know if ." is
>>being executed while in compilation mode.
>>
>>I am sure I am missing something. It surely can't be this complicated. I
>>would greatly appreciate any help.
> 
> Well, the standard ." has undefined interpretation semantics, so you
> just need to worry about the compilation semantics unless you want to
> extend it.
> 
> You identified the parts correctly.  Here's an implementation in
> standard Forth:
> 
> : ."
>   [char] " parse    \ part 1)
>   postpone sliteral \ part 2)
>   postpone type     \ part 3)
> ; immediate
> 
> - anton

Thanks -- this would work only in compilation mode as you say. I was 
hoping to get ." to work in both compilation AND interpretation mode, as 
GForth does. 

Now, even if I had a COMPILATION? word to test if we are in compilation 
mode:

: [."]  [char] " parse ` sliteral ` type ; immediate
: (.")  [char] " parse type ; 

: ." compilation? if [."] else (.") then ; \ CLEARLY DOES NOT WORK

Would obviously not work since [."] branch would fire right away. No 
combination of POSTPONE or IMMEDIATE I can think of seems to work, which 
is what got me stumped.  

Is there no ANS Forth only solution to this problem of "mixed modes"??

SEEing GForth's solution: 

------
see ." 
noname : 
  34 parse type ;
latestxt

noname : 
  34 parse  POSTPONE SLiteral 16227928 compile, ;
latestxt
interpret/compile: ."  ok
-----

I don't really understand this. Could anyone explain what's happening 
here? 


Cheers,
Arnold












 

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

#15133

Arnold Doray wrote: <k17ojv$6ei$1@dont-email.me>
>: [."]  [char] " parse ` sliteral ` type ; immediate
>: (.")  [char] " parse type ; 
>
>: ." compilation? if [."] else (.") then ; \ CLEARLY DOES NOT WORK

Right: you need

: ." compilation? if postpone [."] else (.") then ; immediate

--Josh

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

#15135

Arnold Doray <invalid@invalid.com> writes:
>Thanks -- this would work only in compilation mode as you say. I was 
>hoping to get ." to work in both compilation AND interpretation mode, as 
>GForth does. 

If you want it to work properly, like Gforth does, you need to
implement a way to have words with independent interpretation and
compilation semantics, like Gforth does.

These days I think that having a recognizer for string literals and
then writing

"hello, world" type

is a better alternative, though.

>Now, even if I had a COMPILATION? word to test if we are in compilation 
>mode:
>
>: [."]  [char] " parse ` sliteral ` type ; immediate
>: (.")  [char] " parse type ; 
>
>: ." compilation? if [."] else (.") then ; \ CLEARLY DOES NOT WORK

Well, a slight variation of that would work when text-interpreted, but
not always when ticked or POSTPONEd:

: ." state @ if postpone [."] else postpone (.") then ; immediate

That's one of the infamous STATE-smart words.

>Is there no ANS Forth only solution to this problem of "mixed modes"??

You could fix the problem of the STATE-smart version as follows:

: ' 
  ' dup ['] ." = if drop ['] (.") then ;

: ['] ' postpone literal ; immediate

: postpone
  >in @ ['] ' catch if >in ! postpone postpone exit then
  ['] ." = if drop postpone [."] else >in ! postpone postpone then
; immediate

>SEEing GForth's solution: 
>
>------
>see ." 
>noname : 
>  34 parse type ;
>latestxt
>
>noname : 
>  34 parse  POSTPONE SLiteral 16227928 compile, ;
>latestxt
>interpret/compile: ."  ok
>-----
>
>I don't really understand this. Could anyone explain what's happening 
>here? 

The first colon definition is your (.").  It's a noname: definition,
which the decompiler decompiles a little differently (using the
Gforth-specific NONAME and LATESTXT words).  The second colon
definition is your [."].  The POSTPONE TYPE is compiled as "['] TYPE
COMPILE,", and the decompiler only shows the numerical value of the xt
of TYPE.  The Gforth word for building words with independent
interpretation and compilation semantics is "INTERPRET/COMPILE:", and
it takes the two xts and the name '."' and defines the word '."'.

- 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 2012: http://www.euroforth.org/ef12/

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

#15140

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>: ." state @ if postpone [."] else postpone (.") then ; immediate

This should be

: ." state @ if postpone [."] else (.") then ; immediate

- 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 2012: http://www.euroforth.org/ef12/

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

#15144

On Fri, 24 Aug 2012 14:41:44 +0000, Anton Ertl wrote:

>>
>>: [."]  [char] " parse ` sliteral ` type ; immediate 
>>: (.")  [char] " parse type ;
>>
>
> Well, a slight variation of that would work when text-interpreted, but
> not always when ticked or POSTPONEd:
> 
> : ." state @ if postpone [."] else postpone (.") then ; immediate
> 
> That's one of the infamous STATE-smart words.
> 
> 
> You could fix the problem of the STATE-smart version as follows:
> 
> : '
>   ' dup ['] ." = if drop ['] (.") then ;
> 
> : ['] ' postpone literal ; immediate
> 
> : postpone
>   >in @ ['] ' catch if >in ! postpone postpone exit then
>   ['] ." = if drop postpone [."] else >in ! postpone postpone then
> ; immediate
> 

To paraphrase your code: 

a) TICK switches the xt of ." for the xt of (.") 
b) COMPILE-TICK does the same, using the xt of (.")
c) POSTPONE instead uses the xt of [."]

I'm guessing the change to TICK is really to give the same result as
the new COMPILE-TICK, eg:

: test ['] ." ; 
test ' ." = .  -1  ok

But I can't see why you'd need the new COMPILE-TICK at all: 

There are only 2 things to do with an XT -- comparison and execution. 
Comparison is covered, since TICK is the only other word that can give an 
XT. So that leaves execution. But when the XT of ." is executed, should 
it not just do the right thing since it is "state smart"? 

Here are some tests I ran:

: ` postpone postpone ; immediate
: [.""] [char] " parse ` sliteral ` type ; immediate
: (."") [char] " parse type ;
: ."" state @ if ` [.""] else (."") then ; immediate

\ TICK and COMPILE-TICK have NOT been amended

\ Comparison test
: test ['] ."" ;

test ' ."" = .  -1  ok

\ Execution tests
: test2 ['] ."" execute ;

test2 Hello World"  Hello World ok

: test3 ['] ."" ;

test3 execute Hello World"  Hello World ok

' ."" execute Hello World"  Hello World ok


So my question is in what cases do the amendations to TICK, COMPILE-TICK 
and POSTPONE become necessary? 

(Many thanks for your very clear explanation on GForth's ." 
decompilation).

Cheers
Arnold


 

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

#15151

Arnold Doray <invalid@invalid.com> writes:
>On Fri, 24 Aug 2012 14:41:44 +0000, Anton Ertl wrote:
>
>>>
>>>: [."]  [char] " parse ` sliteral ` type ; immediate 
>>>: (.")  [char] " parse type ;
>>>
>>
>> Well, a slight variation of that would work when text-interpreted, but
>> not always when ticked or POSTPONEd:
>> 
>> : ." state @ if postpone [."] else postpone (.") then ; immediate
>> 
>> That's one of the infamous STATE-smart words.
>> 
>> 
>> You could fix the problem of the STATE-smart version as follows:
>> 
>> : '
>>   ' dup ['] ." = if drop ['] (.") then ;
>> 
>> : ['] ' postpone literal ; immediate
>> 
>> : postpone
>>   >in @ ['] ' catch if >in ! postpone postpone exit then
>>   ['] ." = if drop postpone [."] else >in ! postpone postpone then
>> ; immediate
>> 
>
>To paraphrase your code: 
>
>a) TICK switches the xt of ." for the xt of (.") 
>b) COMPILE-TICK does the same, using the xt of (.")
>c) POSTPONE instead uses the xt of [."]
>
>I'm guessing the change to TICK is really to give the same result as
>the new COMPILE-TICK, eg:
>
>: test ['] ." ; 
>test ' ." = .  -1  ok

No, the redefinition of ' and ['] is there to let these words produce
an xt for the interpretation semantics.  While the standard does not
define interpretation semantics and therefore does not define what ' ."
should do, it's a good idea to make it behave as described above for
consistency with ' S".

>There are only 2 things to do with an XT -- comparison and execution. 
>Comparison is covered, since TICK is the only other word that can give an 
>XT. So that leaves execution. But when the XT of ." is executed, should 
>it not just do the right thing since it is "state smart"? 

STATE-smart words generally don't do the right thing when ticked and
executed (see <http://www.taygeta.com/forth/a0007.htm>).

>Here are some tests I ran:
>
>: ` postpone postpone ; immediate
>: [.""] [char] " parse ` sliteral ` type ; immediate
>: (."") [char] " parse type ;
>: ."" state @ if ` [.""] else (."") then ; immediate
>
>\ TICK and COMPILE-TICK have NOT been amended
>
>\ Comparison test
>: test ['] ."" ;
>
>test ' ."" = .  -1  ok
>
>\ Execution tests
>: test2 ['] ."" execute ;
>
>test2 Hello World"  Hello World ok
>
>: test3 ['] ."" ;
>
>test3 execute Hello World"  Hello World ok
>
>' ."" execute Hello World"  Hello World ok
>
>
>So my question is in what cases do the amendations to TICK, COMPILE-TICK 
>and POSTPONE become necessary? 

: ]execute[ ] execute postpone [ ;

' ."" ]execute[ Hello World"
test ]execute[ Hello World"

: test4 postpone ." ;
: test5 [ test4 hello world" ] ; immediate

- 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 2012: http://www.euroforth.org/ef12/

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

#15243

On Sat, 25 Aug 2012 09:05:46 +0000, Anton Ertl wrote:

> STATE-smart words generally don't do the right thing when ticked and
> executed (see <http://www.taygeta.com/forth/a0007.htm>).

Thank you for the link. 

>>
>>
>>So my question is in what cases do the amendations to TICK, COMPILE-TICK
>>and POSTPONE become necessary?
> 
> : ]execute[ ] execute postpone [ ;
> 

I assume you meant: 

: ]execute[ ` ] execute ` [ ; 

> ' ."" ]execute[ Hello World"

Is this example meaningful? It appears to coerce the compilation 
semantics of a word outside a context of defining a new word... 

> test ]execute[ Hello World"

Not sure what you mean by this? Could you correct?

> 
> : test4 postpone ." ;
> : test5 [ test4 hello world" ] ; immediate
> 
> - anton

I'm assuming TEST4 is immediate while TEST5 is not ... this seems to work 
for me as expected... 

Cheers
Arnold

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

#15246

Op Wed, 29 Aug 2012 15:48:08 +0000 (UTC) schreef Arnold Doray:

> On Sat, 25 Aug 2012 09:05:46 +0000, Anton Ertl wrote:
> 
>> STATE-smart words generally don't do the right thing when ticked and
>> executed (see <http://www.taygeta.com/forth/a0007.htm>).
> 
> Thank you for the link. 
> 
>>>
>>>
>>>So my question is in what cases do the amendations to TICK, COMPILE-TICK
>>>and POSTPONE become necessary?
>> 
>>: ]execute[ ] execute postpone [ ;
>> 
> 
> I assume you meant: 
> 
>: ]execute[ ` ] execute ` [ ; 
> 
No. Before ] postpone is unnecessary, it is not immediate.

Please, use postpone like every one else. Or do you have a 32 character
wide screen like my old ZX Spectrum?

-- 
Coos

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

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

#15266

Arnold Doray <invalid@invalid.com> writes:
>On Sat, 25 Aug 2012 09:05:46 +0000, Anton Ertl wrote:
>
>> STATE-smart words generally don't do the right thing when ticked and
>> executed (see <http://www.taygeta.com/forth/a0007.htm>).
>
>Thank you for the link. 
>
>>>
>>>
>>>So my question is in what cases do the amendations to TICK, COMPILE-TICK
>>>and POSTPONE become necessary?
>> 
>> : ]execute[ ] execute postpone [ ;
>> 
>
>I assume you meant: 
>
>: ]execute[ ` ] execute ` [ ; 

I meant

: ]execute[ ] execute postpone [ ;

and that's what I wrote.  Why should I POSTPONE ] ?

>> ' ."" ]execute[ Hello World"
>
>Is this example meaningful? It appears to coerce the compilation 
>semantics of a word outside a context of defining a new word... 

How do you get the idea that compilation semantics play of ."" a role
here?  ."" is ticked, its compilation semantics do not come into play.

>> test ]execute[ Hello World"
>
>Not sure what you mean by this? Could you correct?

The point of these examples are to show cases where a STATE-smart .""
behaves differently from one that has [.""] as compilation semantics
and (."") as interpretation semantics.  I.e., to answer your question

|So my question is in what cases do the amendations to TICK, COMPILE-TICK 
|and POSTPONE become necessary? 

>> : test4 postpone ." ;
>> : test5 [ test4 hello world" ] ; immediate
>> 
>> - anton
>
>I'm assuming TEST4 is immediate while TEST5 is not ... this seems to work 
>for me as expected... 

It does not matter here whether TEST4 or TEST5 are immediate.

I don't know what you expect, but this is another case where the
behaviour of the STATE-smart ."" differs from the combined-semantics
one.

- 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 2012: http://www.euroforth.org/ef12/

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

#15121

Arnold Doray <invalid@invalid.com> wrote:
> I am trying to write a small compatability harness for Mini (mini.terra-
> weather.com) and am stumbling over ." (Mini has built-in strings, and 
> uses . instead of ." )
> 
> Anyway, I see it needs:
> 
> 1) a PARSE to run immediately (because ." may be used inside a word),
> 2) then it needs to compile the string as a literal if in compilation 
> mode. 
> 3) It needs to display the string, but not immediately. 
> 
> My problem is that there are some things that need to be done 
> immediately, and others delayed. And there is a need to know if ." is 
> being executed while in compilation mode. 
> 
> I am sure I am missing something. It surely can't be this complicated. I 
> would greatly appreciate any help. 

It is one of the trickiest words to implement.  The first problem is
to figure out how to get the string into the dictionary, and then how
to step over it at runtime.  Something like

: ,string ( a n -)   dup c,  >r  here r@ allot  r> cmove ;

adds the string to the dictionary.  At runtime you'll need to step
over the string with some R-stack hackery:

: (.")   r@ count  dup 1+ r> + >r  type ;
: ."   postpone (.")  [char] " parse ,string ; immediate

All quite untested and totally nonportable...

Andrew.

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

#15123

On Thu, 23 Aug 2012, Arnold Doray wrote:

> Date: Thu, 23 Aug 2012 14:12:52 +0000 (UTC)
> From: Arnold Doray <invalid@invalid.com>
> Newsgroups: comp.lang.forth
> Subject: Implementing ." in forth
> 
> I am trying to write a small compatability harness for Mini (mini.terra-
> weather.com) and am stumbling over ." (Mini has built-in strings, and
> uses . instead of ." )
>
> Anyway, I see it needs:
>
> 1) a PARSE to run immediately (because ." may be used inside a word),
> 2) then it needs to compile the string as a literal if in compilation
> mode.
> 3) It needs to display the string, but not immediately.
>
> My problem is that there are some things that need to be done
> immediately, and others delayed. And there is a need to know if ." is
> being executed while in compilation mode.
>
> I am sure I am missing something. It surely can't be this complicated. I
> would greatly appreciate any help.
>
> Thanks,
> Arnold

This is the approach I took in a previous C based forth ...

ok : x ." hi mom" ;
ok x
hi momok ' x see
: x
673459364    (quote)   'hi mom'
673459368    (literal)   6
673459376    type
673459380    *Next*
ok

The (quote) handles the generic quoted string, and is stateful. 
dot_quote contains the quote semantics, and compiles type or executes it 
as required by the state.  The C code to implement is reasonably 
straightforward ... at least you should be able to get the gist ... (I 
hope).


void  quote( Vm_t *vm ){  /* ( -- c_addr l | -- ) */
   String_t  sptr ;
   Cell_t    len ;

   PUSH( 34 ) ;  /* ascii 34 '"' */
   save2Delim( vm ) ;

   if( vm ->State ){ /* compiling ... */
     len = POP ;
     sptr = (String_t) POP ;
     Compile( "(quote)" ) ;  /* (quote) => do_quote (below) */
     fwd_mark( vm ) ;
     str_copy( (String_t) vm ->Here, (String_t) sptr, len ) ;
     vm ->Here += len ;
     align( vm ) ;
     fwd_resolve( vm ) ;
     Compile( "(literal)" ) ;
     PUSH( len );
     comma( vm ) ;
   }
}

void  do_quote( Vm_t *vm ){
   register Cell_t  *x ;
   register Cell_t  *y ;

   x = (Cell_t *) RPOP ; /* effectively, a branch! */
   RPUSH( *x );
   y = ++x;  /* push the address of the string */
   PUSH( y );
}

void  dot_quote( Vm_t *vm ){  /* ( -- ) */
   quote( vm ) ;
   if( vm ->State ){ /* still compiling ... */
     Compile( "type" ) ;
   } else
      type( vm ) ;
}

Not a Forth implementation, but I hope this helps ...

Cheers,
Rob Sciuk

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

#15125

On Aug 23, 3:12 pm, Arnold Doray <inva...@invalid.com> wrote:
> I am trying to write a small compatability harness for Mini (mini.terra-
> weather.com) and am stumbling over ." (Mini has built-in strings, and
> uses . instead of ." )
>
> Anyway, I see it needs:
>
> 1) a PARSE to run immediately (because ." may be used inside a word),
> 2) then it needs to compile the string as a literal if in compilation
> mode.
> 3) It needs to display the string, but not immediately.
>
> My problem is that there are some things that need to be done
> immediately, and others delayed. And there is a need to know if ." is
> being executed while in compilation mode.
>
> I am sure I am missing something. It surely can't be this complicated. I
> would greatly appreciate any help.
>
> Thanks,
> Arnold

My version of ." uses S" and TYPE.

Recall that S" when executed causes the address of the string that
follows it, and its length to be pushed to the stack.

I have S" that does the work (at interpretation time) of 'compiling'
the string (it is state smart) into a colon definition. It compiles a
reference to (S") which, at run time, pushes the address and length of
the string and corrects the instruction pointer to jump over it. It
(that is S" ) then compiles a reference to TYPE.

So, for the following:

: TEST ." Hello mother!" ;

You end up with the following:

(S") 13 H e l l o  m o t h e r ! _ TYPE

(the _ is a padding byte, which may not be required on your
implementation).

(S") was compiled into the definition by S"
The string length was compiled into the definition by S"
The string was compiled into the definition by S"

At execution time, as you can see, (S") pushes the string length,
which immediately follows it, to the stack. It calculates the address
of the string (address of the occurrence of (S") plus 2 cells) then
manipulates the instruction pointer so that TYPE immediately executes.

As already stated, interpretation semantics of ." are un-defined.

HTH

Mark

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

#15127

"Arnold Doray" <invalid@invalid.com> wrote in message
news:k15dp4$kag$1@dont-email.me...
> I am trying to write a small compatability harness for Mini (mini.terra-
> weather.com) and am stumbling over ." (Mini has built-in strings, and
> uses . instead of ." )
>
> Anyway, I see it needs:
>
> 1) a PARSE to run immediately (because ." may be used inside a word),
> 2) then it needs to compile the string as a literal if in compilation
> mode.
> 3) It needs to display the string, but not immediately.
>
> My problem is that there are some things that need to be done
> immediately, and others delayed. And there is a need to know if ." is
> being executed while in compilation mode.
>
> I am sure I am missing something. It surely can't be this complicated. I
> would greatly appreciate any help.
>

FYI, it's probably wrong somehow (i.e., STATE aware), but ...

I implemented ." as POSTPONEd S" followed by a STATE aware IF
to either TYPE or POSTPONE TYPE.

So, do you have S" implemented already?  You should.  In addition to ." it
can be used for C" too...


I implemented S" to do [CHAR] " WORD COUNT  (Is that PARSE ... ?), followed
by a STATE aware IF, i.e., STATE @ IF ... THEN.  This STATE aware IF is for
compiled strings.  It does two things: 1) POSTPONEs a word (S") and 2) has a
routine to CMOVE and ALLOT the string, i.e., compile it into the definition.
(S") get's the string's address using the interpreter's IP address from the
return stack, uses COUNT to get it's length, then and adjusts the
interpreter's IP address to skip over the stored string, instead of
interpreting it.


Rod Pemberton

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

#15129

On Thursday, August 23, 2012 7:12:52 AM UTC-7, Arnold Doray wrote:
> My problem is that there are some things that need to be done 
> immediately, and others delayed. And there is a need to know if ." is 
> being executed while in compilation mode. 

." only works inside of colon words --- use .( interpretively --- remember: "let the dictionary do the deciding."

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

#15131

On Fri, 24 Aug 2012 00:06:14 -0700, hughaguilar96 wrote:

> On Thursday, August 23, 2012 7:12:52 AM UTC-7, Arnold Doray wrote:
>> My problem is that there are some things that need to be done
>> immediately, and others delayed. And there is a need to know if ." is
>> being executed while in compilation mode.
> 
> ." only works inside of colon words --- use .( interpretively ---
> remember: "let the dictionary do the deciding."

Yes, that's right. But GForth lets you use it interactively too, which is 
what I wanted. Creating a ." that works in compilation only is a simple 
exercise. To do it for both interactive mode compilation mode is probably 
harder. -AD

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

#15132

On 8/24/12 7:32 AM, Arnold Doray wrote:
> On Fri, 24 Aug 2012 00:06:14 -0700, hughaguilar96 wrote:
>
>> On Thursday, August 23, 2012 7:12:52 AM UTC-7, Arnold Doray wrote:
>>> My problem is that there are some things that need to be done
>>> immediately, and others delayed. And there is a need to know if ." is
>>> being executed while in compilation mode.
>>
>> ." only works inside of colon words --- use .( interpretively ---
>> remember: "let the dictionary do the deciding."
>
> Yes, that's right. But GForth lets you use it interactively too, which is
> what I wanted. Creating a ." that works in compilation only is a simple
> exercise. To do it for both interactive mode compilation mode is probably
> harder. -AD

Those of us that try to write portable code, i.e., others can more 
easily run stuff we write, will use ." for compilation and .( for 
interpreting.

Gforth accepts .( when interpreting.

Having said that, do whatever you want.

-Doug

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

#15138

On Thursday, August 23, 2012 10:12:52 AM UTC-4, Arnold Doray wrote:
> I am trying to write a small compatability harness for Mini (mini.terra-
> 
> weather.com) and am stumbling over ." (Mini has built-in strings, and 
> 
> uses . instead of ." )
> 
> 
> 
> Anyway, I see it needs:
> 
> 
> 
> 1) a PARSE to run immediately (because ." may be used inside a word),
> 
> 2) then it needs to compile the string as a literal if in compilation 
> 
> mode. 
> 
> 3) It needs to display the string, but not immediately. 
> 
> 
> 
> My problem is that there are some things that need to be done 
> 
> immediately, and others delayed. And there is a need to know if ." is 
> 
> being executed while in compilation mode. 

Diaperglu Forth does it the way Mark Wills mentions with PARSE and S", although it is written in C.
And is similar to Anton Ertl's implementation except that it checks for state first and if the state is execute, it does a parse for a " then a TYPE.

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

#15153

I know I'm going to get in trouble for this, but I have:

: ."		\ ( -- )
	STATE @ IF					\ compiling?
		POSTPONE S"			\ read the string, and compile SLITS, etc.
		POSTPONE TYPE	\ compile the final TYPE
	ELSE
		'"' PARSE TYPE
	THEN
; IMMEDIATE

Corrections gratefully received !

Chris

[toc] | [prev] | [standalone]

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

csiph-web