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

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

Simple Strings

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

Contents

  Simple Strings JennyB <jennybrien@googlemail.com> - 2013-10-11 10:42 -0700
    Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-11 21:05 +0200
      Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-11 15:49 -0700
        Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-11 16:21 -0700
          Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-11 16:28 -0700
          Re: Simple Strings mhx@iae.nl - 2013-10-12 01:03 -0700
          Re: Simple Strings albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-24 12:04 +0000
            Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-25 02:32 -0700
              Re: Simple Strings albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-25 11:43 +0000
                Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-25 06:03 -0700
      Re: Simple Strings hughaguilar96@yahoo.com - 2013-10-11 21:26 -0700
        Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-11 23:33 -0700
          Re: Simple Strings "WJ" <w_a_x_man@yahoo.com> - 2013-10-12 18:40 +0000
        Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-12 05:40 -0500
          Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-12 04:36 -0700
            Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-12 08:56 -0500
              Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-12 14:04 -0700
                Re: Simple Strings Coos Haak <chforth@hccnet.nl> - 2013-10-13 01:04 +0200
                  Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-13 03:25 +0200
                Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-13 02:01 -0500
                Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-14 17:24 +0000
              Re: Simple Strings "Elizabeth D. Rather" <erather@forth.com> - 2013-10-12 11:40 -1000
                Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-13 00:53 +0200
                Re: Simple Strings hughaguilar96@yahoo.com - 2013-10-12 22:13 -0700
                Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-13 02:16 -0500
                  Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 14:57 +0000
                    Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-15 19:45 +0200
                Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-14 17:27 +0000
                  Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 20:14 +0100
                    Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 16:06 +0000
              Re: Simple Strings Paul Rubin <no.email@nospam.invalid> - 2013-10-13 20:58 -0700
                Re: Simple Strings m.a.m.hendrix@tue.nl - 2013-10-14 00:00 -0700
                Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 03:18 -0500
                  Re: Simple Strings Paul Rubin <no.email@nospam.invalid> - 2013-10-14 01:49 -0700
                    Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 04:29 -0500
                      Re: Simple Strings m.a.m.hendrix@tue.nl - 2013-10-14 03:01 -0700
                        Re: Simple Strings Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-10-14 15:09 +0200
                      Re: Simple Strings Paul Rubin <no.email@nospam.invalid> - 2013-10-14 03:26 -0700
                        Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 09:21 -0500
                          Re: Simple Strings Graham Smith <"s\" xyzgrahams@tectime.com\" 3 /string"> - 2013-10-14 17:49 +0100
                            Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 12:53 -0500
                        Re: Simple Strings "Elizabeth D. Rather" <erather@forth.com> - 2013-10-14 09:26 -1000
                        Re: Simple Strings albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-28 18:19 +0000
                Re: Simple Strings Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-10-14 11:02 +0200
                Re: Simple Strings Marc Olschok <nobody@nowhere.invalid> - 2013-10-15 14:43 +0000
                  Re: Simple Strings albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-15 15:59 +0000
                    Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-16 12:12 +0000
                      Re: Simple Strings albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-17 11:52 +0000
            Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-12 16:55 +0100
        Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-12 16:12 +0200
          Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-12 16:50 +0100
            Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 09:41 +0100
              Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-14 13:10 +0100
                Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 13:46 +0100
                  Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 09:23 -0500
                    Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 17:38 +0100
                      Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 12:56 -0500
                        Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 20:33 +0100
                      Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-14 21:50 +0100
                        Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 22:29 +0100
                          Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 22:31 +0100
                          Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-14 22:46 +0100
                Re: Simple Strings Lars Brinkhoff <lars.spam@nocrew.org> - 2013-10-15 08:00 +0200
                  Re: Simple Strings Lars Brinkhoff <lars.spam@nocrew.org> - 2013-10-15 13:20 +0200
                  Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-15 13:36 +0100
                    Re: Simple Strings Lars Brinkhoff <lars.spam@nocrew.org> - 2013-10-16 12:11 +0200
                      Re: Simple Strings Coos Haak <chforth@hccnet.nl> - 2013-10-16 17:36 +0200
                      Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-16 17:01 +0100
                        Re: Simple Strings Lars Brinkhoff <lars.spam@nocrew.org> - 2013-10-16 20:52 +0200
    Re: Simple Strings "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-10-12 22:49 -0700
      Re: Simple Strings hughaguilar96@yahoo.com - 2013-10-13 10:31 -0700
    Re: Simple Strings hughaguilar96@yahoo.com - 2013-10-13 10:30 -0700
    Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-14 16:26 +0000
      Re: Simple Strings JennyB <jennybrien@googlemail.com> - 2013-10-15 07:36 -0700
        Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-16 16:05 +0000
          Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-16 19:58 +0200
            Re: Simple Strings Brad Eckert <hwfwguy@gmail.com> - 2013-10-29 07:40 -0700
              Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-29 17:10 +0100
                Re: Simple Strings Brad Eckert <hwfwguy@gmail.com> - 2013-10-29 16:39 -0700
              Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-30 12:00 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#26396 — Simple Strings

I've been studying Anton's EuroForth string paper and generally agree with his conclusions. c-addr u is the best way to represent strings on the stack, but we need a simple way to generate new strings of indeterminate length without having to worry too much about memory. 

Standard Forth does have one limited means of string-building - pictured numeric output of using <# ··· #> Unfortunately, that generates the characters in the wrong order for most other purposes. :(

But imagine a similar syntax:

     <S c-addr u -- place string in buffer
      S+ c-addr u -- append string to buffer
      C+ char -- append char to buffer 
      S> -- c-addr u return string in buffer - valid till next use of <S

   : make-path ( dir-a dir-u file-a file-u -- path-a path-u )
             2swap <S [char] / c+ s+ S> ;
   : >z  ( c-addr u -- c-addr ) <S 0 c+ S> DROP ;

In each case the string returned is purely temporary, meant for immediate consumption. If two or more temporary strings are needed at the same time then the buffer can be made into a stack:

     <S build first string 
     <S build second string 
      S> return second string
      S> return first string 

[toc] | [next] | [standalone]

#26398

JennyB wrote:

> I've been studying Anton's EuroForth string paper and generally agree with
> his conclusions. c-addr u is the best way to represent strings on the
> stack, but we need a simple way to generate new strings of indeterminate
> length without having to worry too much about memory.
> 
> Standard Forth does have one limited means of string-building - pictured
> numeric output of using <# ··· #> Unfortunately, that generates the
> characters in the wrong order for most other purposes. :(
> 
> But imagine a similar syntax:
> 
>      <S c-addr u -- place string in buffer
>       S+ c-addr u -- append string to buffer
>       C+ char -- append char to buffer
>       S> -- c-addr u return string in buffer - valid till next use of <S
> 
>    : make-path ( dir-a dir-u file-a file-u -- path-a path-u )
>              2swap <S [char] / c+ s+ S> ;
>    : >z  ( c-addr u -- c-addr ) <S 0 c+ S> DROP ;

Please use TYPE and EMIT instead of S+ and C+.  And there's no need to have 
<S put some string into place (which often would be empty): Just start a new 
string.  The next thing is that we now have quotations, which make handling 
this statefull stuff easier (what to do in case of an exception?).  So I 
have

$TMP ( xt -- addr u ) revector TYPE and EMIT so that all outputs of xt 
construts a string which is returned as addr u.  This string is valid to the 
next call of $TMP.

Wow, it's just one single word to construct arbitrary strings.  There are 
things hidden inside, but the important part is that you can use . for 
numbers, F. for floating point, and so on.

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

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

#26403

On Friday, October 11, 2013 8:05:07 PM UTC+1, Bernd Paysan wrote:
> JennyB wrote:
> 
> 
> 
> > I've been studying Anton's EuroForth string paper and generally agree with
> 
> > his conclusions. c-addr u is the best way to represent strings on the
> 
> > stack, but we need a simple way to generate new strings of indeterminate
> 
> > length without having to worry too much about memory.
> 
> > 
> 
> > Standard Forth does have one limited means of string-building - pictured
> 
> > numeric output of using <# ··· #> Unfortunately, that generates the
> 
> > characters in the wrong order for most other purposes. :(
> 
> > 
> 
> > But imagine a similar syntax:
> 
> > 
> 
> >      <S c-addr u -- place string in buffer
> 
> >       S+ c-addr u -- append string to buffer
> 
> >       C+ char -- append char to buffer
> 
> >       S> -- c-addr u return string in buffer - valid till next use of <S
> 
> > 
> 
> >    : make-path ( dir-a dir-u file-a file-u -- path-a path-u )
> 
> >              2swap <S [char] / c+ s+ S> ;
> 
> >    : >z  ( c-addr u -- c-addr ) <S 0 c+ S> DROP ;
> 
> 
> 
> Please use TYPE and EMIT instead of S+ and C+.  And there's no need to have 
> 
> <S put some string into place (which often would be empty): Just start a new 
> 
> string.  The next thing is that we now have quotations, which make handling 
> 
> this statefull stuff easier (what to do in case of an exception?).  So I 
> 
> have
> 
> 
> 
> $TMP ( xt -- addr u ) revector TYPE and EMIT so that all outputs of xt 
> 
> construts a string which is returned as addr u.  This string is valid to the 
> 
> next call of $TMP.
> 
> 
> 
> Wow, it's just one single word to construct arbitrary strings.  There are 
> 
> things hidden inside, but the important part is that you can use . for 
> 
> numbers, F. for floating point, and so on.
> 
> 
> 
> -- 
> 
> Bernd Paysan
> 
> "If you want it done right, you have to do it yourself"
> 
> http://bernd-paysan.de/

Hi Bernd,

That is really neat :-)

Best regards,
Howerd

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

#26404

On Friday, October 11, 2013 11:49:13 PM UTC+1, Howerd wrote:
> On Friday, October 11, 2013 8:05:07 PM UTC+1, Bernd Paysan wrote:
> 
> > JennyB wrote:
> 
> > 
> 
> > 
> 
> > 
> 
> > > I've been studying Anton's EuroForth string paper and generally agree with
> 
> > 
> 
> > > his conclusions. c-addr u is the best way to represent strings on the
> 
> > 
> 
> > > stack, but we need a simple way to generate new strings of indeterminate
> 
> > 
> 
> > > length without having to worry too much about memory.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > Standard Forth does have one limited means of string-building - pictured
> 
> > 
> 
> > > numeric output of using <# ··· #> Unfortunately, that generates the
> 
> > 
> 
> > > characters in the wrong order for most other purposes. :(
> 
> > 
> 
> > > 
> 
> > 
> 
> > > But imagine a similar syntax:
> 
> > 
> 
> > > 
> 
> > 
> 
> > >      <S c-addr u -- place string in buffer
> 
> > 
> 
> > >       S+ c-addr u -- append string to buffer
> 
> > 
> 
> > >       C+ char -- append char to buffer
> 
> > 
> 
> > >       S> -- c-addr u return string in buffer - valid till next use of <S
> 
> > 
> 
> > > 
> 
> > 
> 
> > >    : make-path ( dir-a dir-u file-a file-u -- path-a path-u )
> 
> > 
> 
> > >              2swap <S [char] / c+ s+ S> ;
> 
> > 
> 
> > >    : >z  ( c-addr u -- c-addr ) <S 0 c+ S> DROP ;
> 
> > 
> 
> > 
> 
> > 
> 
> > Please use TYPE and EMIT instead of S+ and C+.  And there's no need to have 
> 
> > 
> 
> > <S put some string into place (which often would be empty): Just start a new 
> 
> > 
> 
> > string.  The next thing is that we now have quotations, which make handling 
> 
> > 
> 
> > this statefull stuff easier (what to do in case of an exception?).  So I 
> 
> > 
> 
> > have
> 
> > 
> 
> > 
> 
> > 
> 
> > $TMP ( xt -- addr u ) revector TYPE and EMIT so that all outputs of xt 
> 
> > 
> 
> > construts a string which is returned as addr u.  This string is valid to the 
> 
> > 
> 
> > next call of $TMP.
> 
> > 
> 
> > 
> 
> > 
> 
> > Wow, it's just one single word to construct arbitrary strings.  There are 
> 
> > 
> 
> > things hidden inside, but the important part is that you can use . for 
> 
> > 
> 
> > numbers, F. for floating point, and so on.
> 
> > 
> 
> > 
> 
> > 
> 
> > -- 
> 
> > 
> 
> > Bernd Paysan
> 
> > 
> 
> > "If you want it done right, you have to do it yourself"
> 
> > 
> 
> > http://bernd-paysan.de/
> 
> 
> 
> Hi Bernd,
> 
> 
> 
> That is really neat :-)
> 
> 
> 
> Best regards,
> 
> Howerd

Hi Jenny & Bernd,

Here is some code for this. 
But is this really any better than just constructing the string using  APPEND ?
I've changed the names to s[ and s] because I think that S< and >S look too much like < and > , YMMV .

Best regards,
Howerd

\ StringTMP.f   2013 Oct 12
\ Use TYPE  EMIT and CR to construct a string

$100 constant |StringTMP| 
|StringTMP| Buffer: StringTMP[]

variable SavedEmit
variable SavedType
variable SavedCR

: s-emit ( c -- )
  pad c!  pad 1  StringTMP[] append
;

: s-type ( caddr c -- )   
   StringTMP[] append   
;

: s-cr ( -- )  #13 s-emit  #10 s-emit ;

: s[ ( -- )    \ start vectored string output
   0 StringTMP[] c!        \ clear our string buffer
   'EMIT @ SavedEmit !   \ save the current vectors
   'TYPE @ SavedType !  
   'CR @ SavedCR !
   ['] s-emit 'EMIT !
   ['] s-type 'TYPE !
   ['] s-cr 'CR !
;


: ]s ( -- c-addr c )    \ end vectored string output
    SavedEmit @ 'EMIT !  \ restore the current vectors
    SavedType @ 'TYPE !
    SavedCR @ 'CR !
    StringTMP[] count      \ return the string
;

: $TMP ( xt -- c-addr c )  \ return a string from the output of the word xt
   s[  execute  ]s
;

\ example usage

: ShowAstring ( -- )
   s[  
   cr  ." Hello string... "  27 emit 85 emit  07 emit  
   space  123 . space cr cr ."  well that was easy"  cr  
   ]s 2dup type dump
;


: MakeAstring ( -- )   cr  ." Hello string... "  27 emit 
   85 emit  07 emit  space  123 . space 
   cr cr ."  well that was easy"  cr 
;

: ShowAstring2
   ['] MakeAstring $TMP 2dup type dump
;

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

#26405

On Saturday, October 12, 2013 12:21:01 AM UTC+1, Howerd wrote:
> On Friday, October 11, 2013 11:49:13 PM UTC+1, Howerd wrote:
> 
> > On Friday, October 11, 2013 8:05:07 PM UTC+1, Bernd Paysan wrote:
> 
> > 
> 
> > > JennyB wrote:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > I've been studying Anton's EuroForth string paper and generally agree with
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > his conclusions. c-addr u is the best way to represent strings on the
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > stack, but we need a simple way to generate new strings of indeterminate
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > length without having to worry too much about memory.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > Standard Forth does have one limited means of string-building - pictured
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > numeric output of using <# ··· #> Unfortunately, that generates the
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > characters in the wrong order for most other purposes. :(
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > But imagine a similar syntax:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >      <S c-addr u -- place string in buffer
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >       S+ c-addr u -- append string to buffer
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >       C+ char -- append char to buffer
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >       S> -- c-addr u return string in buffer - valid till next use of <S
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >    : make-path ( dir-a dir-u file-a file-u -- path-a path-u )
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >              2swap <S [char] / c+ s+ S> ;
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >    : >z  ( c-addr u -- c-addr ) <S 0 c+ S> DROP ;
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > Please use TYPE and EMIT instead of S+ and C+.  And there's no need to have 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > <S put some string into place (which often would be empty): Just start a new 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > string.  The next thing is that we now have quotations, which make handling 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > this statefull stuff easier (what to do in case of an exception?).  So I 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > have
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > $TMP ( xt -- addr u ) revector TYPE and EMIT so that all outputs of xt 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > construts a string which is returned as addr u.  This string is valid to the 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > next call of $TMP.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > Wow, it's just one single word to construct arbitrary strings.  There are 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > things hidden inside, but the important part is that you can use . for 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > numbers, F. for floating point, and so on.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > -- 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > Bernd Paysan
> 
> > 
> 
> > > 
> 
> > 
> 
> > > "If you want it done right, you have to do it yourself"
> 
> > 
> 
> > > 
> 
> > 
> 
> > > http://bernd-paysan.de/
> 
> > 
> 
> > 
> 
> > 
> 
> > Hi Bernd,
> 
> > 
> 
> > 
> 
> > 
> 
> > That is really neat :-)
> 
> > 
> 
> > 
> 
> > 
> 
> > Best regards,
> 
> > 
> 
> > Howerd
> 
> 
> 
> Hi Jenny & Bernd,
> 
> 
> 
> Here is some code for this. 
> 
> But is this really any better than just constructing the string using  APPEND ?
> 
> I've changed the names to s[ and s] because I think that S< and >S look too much like < and > , YMMV .
> 
> 
> 
> Best regards,
> 
> Howerd
> 
> 
> 
> \ StringTMP.f   2013 Oct 12
> 
> \ Use TYPE  EMIT and CR to construct a string
> 
> 
> 
> $100 constant |StringTMP| 
> 
> |StringTMP| Buffer: StringTMP[]
> 
> 
> 
> variable SavedEmit
> 
> variable SavedType
> 
> variable SavedCR
> 
> 
> 
> : s-emit ( c -- )
> 
>   pad c!  pad 1  StringTMP[] append
> 
> ;
> 
> 
> 
> : s-type ( caddr c -- )   
> 
>    StringTMP[] append   
> 
> ;
> 
> 
> 
> : s-cr ( -- )  #13 s-emit  #10 s-emit ;
> 
> 
> 
> : s[ ( -- )    \ start vectored string output
> 
>    0 StringTMP[] c!        \ clear our string buffer
> 
>    'EMIT @ SavedEmit !   \ save the current vectors
> 
>    'TYPE @ SavedType !  
> 
>    'CR @ SavedCR !
> 
>    ['] s-emit 'EMIT !
> 
>    ['] s-type 'TYPE !
> 
>    ['] s-cr 'CR !
> 
> ;
> 
> 
> 
> 
> 
> : ]s ( -- c-addr c )    \ end vectored string output
> 
>     SavedEmit @ 'EMIT !  \ restore the current vectors
> 
>     SavedType @ 'TYPE !
> 
>     SavedCR @ 'CR !
> 
>     StringTMP[] count      \ return the string
> 
> ;
> 
> 
> 
> : $TMP ( xt -- c-addr c )  \ return a string from the output of the word xt
> 
>    s[  execute  ]s
> 
> ;
> 
> 
> 
> \ example usage
> 
> 
> 
> : ShowAstring ( -- )
> 
>    s[  
> 
>    cr  ." Hello string... "  27 emit 85 emit  07 emit  
> 
>    space  123 . space cr cr ."  well that was easy"  cr  
> 
>    ]s 2dup type dump
> 
> ;
> 
> 
> 
> 
> 
> : MakeAstring ( -- )   cr  ." Hello string... "  27 emit 
> 
>    85 emit  07 emit  space  123 . space 
> 
>    cr cr ."  well that was easy"  cr 
> 
> ;
> 
> 
> 
> : ShowAstring2
> 
>    ['] MakeAstring $TMP 2dup type dump
> 
> ;

and also :

: make-path ( dir-a file-a -- path-a )
   s[ 2swap type [char] / emit  type  ]s 
;

: ttmake-path ( -- )   s" pathname"  s" filename"  make-path type ;

: >z  ( c-addr u -- c-addr )   s[  type  0 emit  ]s  drop ; 

: tt>z  s" hello" >z zcount type ;

H.

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

#26414

On Saturday, October 12, 2013 1:21:01 AM UTC+2, Howerd wrote:
> On Friday, October 11, 2013 11:49:13 PM UTC+1, Howerd wrote:
[..]
: $free  ( c-addr -- ) FREE ?allocate ;	\ optionally
: $temp  0 ALLOCATE ?allocate 0 ; ( -- c-addr 0 ) 

: $+ ( $temp c-addr u -- c-addr2 u2 ) 
	LOCALS| u c-addr |  DLOCAL str 
	str u + RESIZE ?allocate DROP
	c-addr  str +  u CMOVE
	str u + ;

: make-path ( dir-a dir-u file-a file-u -- path-a path-u )
        $temp 2rot $+  S" /" $+  2swap $+ ;

: >z  ( c-addr u -- c-addr2 ) $temp 2swap $+  S\" \z" $+  DROP ;

: PI-fmt ( -- c-addr u ) $temp  s" result = " $+ PI (F.) $+ ;

Splitting a string is left as an exercise for the reader (for
consistency the result should be two temp$s)

-marcel

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

#26672

In article <91315aab-5cae-4b6a-bee2-dc1d1ca2d749@googlegroups.com>,
Howerd  <howerdo@yahoo.co.uk> wrote:

<SNIP>
>Hi Jenny & Bernd,
>
>Here is some code for this.
>But is this really any better than just constructing the string using  APPEND ?
>I've changed the names to s[ and s] because I think that S< and >S look
>too much like < and > , YMMV .

This is a utility. As such it shouldn't use PAD and it is allowed
to use carnal knowledge. Then it becomes sooo much neater.
Please note that assuming vectoring through 'TYPE 'EMIT etc. is carnal
(At least in ciforth).
anyway.
>
>Best regards,
>Howerd

WANT $-PREFIX
WANT RESTORED

>
>\ StringTMP.f   2013 Oct 12
>\ Use TYPE  EMIT and CR to construct a string
>
>$100 constant |StringTMP|

same

>|StringTMP| Buffer: StringTMP[]

CREATE StringTMP[] |StringTMP| ALLOT

>
>variable SavedEmit
>variable SavedType
>variable SavedCR
>
>: s-emit ( c -- )
>  pad c!  pad 1  StringTMP[] append
>;
>

Did you know this trick?

: s-emit DSP@ 1 ( now it is a 1 char string containing c )
    StringTMP[] append   ( c) DROP ;

gone

>: s-type ( caddr c -- )
>   StringTMP[] append
>;
>

: s-type stringTMP[] $+! ;

>: s-cr ( -- )  #13 s-emit  #10 s-emit ;
>

gone

>: s[ ( -- )    \ start vectored string output
>   0 StringTMP[] c!        \ clear our string buffer
>   'EMIT @ SavedEmit !   \ save the current vectors
>   'TYPE @ SavedType !
>   'CR @ SavedCR !
>   ['] s-emit 'EMIT !
>   ['] s-type 'TYPE !
>   ['] s-cr 'CR !
>;

: S[ 's-type 'TYPE 3 CELLS MOVE ;

>
>
>: ]s ( -- c-addr c )    \ end vectored string output
>    SavedEmit @ 'EMIT !  \ restore the current vectors
>    SavedType @ 'TYPE !
>    SavedCR @ 'CR !
>    StringTMP[] count      \ return the string
>;

: ]s 'TYPE RESTORED StringTMP[] $@ ;       \ return the string

>
>: $TMP ( xt -- c-addr c )  \ return a string from the output of the word xt
>   s[  execute  ]s
>;

same

>
>\ example usage
>
>: ShowAstring ( -- )
>   s[
>   cr  ." Hello string... "  27 emit 85 emit  07 emit
>   space  123 . space cr cr ."  well that was easy"  cr
>   ]s 2dup type dump
>;
>
>
>: MakeAstring ( -- )   cr  ." Hello string... "  27 emit
>   85 emit  07 emit  space  123 . space
>   cr cr ."  well that was easy"  cr
>;
>
>: ShowAstring2
>   ['] MakeAstring $TMP 2dup type dump
>;

same

>
>
>

I recapulate what it looks like in ciforth:
Note that 'TYPE is the dea of TYPE :a constant, that is
the same compiling or interpreting.

: s-type        stringTMP[] $+! ;
: s[            's-type 'TYPE 3 CELLS MOVE   "" StringTMP[] $! ;
: ]s            'TYPE RESTORED   StringTMP[] $@ ;

Note that we never leave the $ abstraction. So we can replace
the strings by braindamaged 1] strings and it all works
(until you get above length 256)

A one-screener to add in a new release.

>
Groetjes Albert

1] This is a term coined in the ciforth documentation.
COUNT is an alias for $@ for brain-damaged strings.
The counterpart is BD-$! .
-- 
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]

#26674

On Thursday, 24 October 2013 13:04:43 UTC+1, Albert van der Horst  wrote:
> In article <91315aab-5cae-4b6a-bee2-dc1d1ca2d749@googlegroups.com>,
> 
> Howerd  <how....@yahoo.co.uk> wrote:
> 
> 
> 
> <SNIP>
> 
> >Hi Jenny & Bernd,
> 
> >
> 
> >Here is some code for this.
> 
> >But is this really any better than just constructing the string using  APPEND ?
> 
> >I've changed the names to s[ and s] because I think that S< and >S look
> 
> >too much like < and > , YMMV .
> 
> 
> 
> This is a utility. As such it shouldn't use PAD and it is allowed
> 
> to use carnal knowledge. Then it becomes sooo much neater.
> 
> Please note that assuming vectoring through 'TYPE 'EMIT etc. is carnal
> 
> (At least in ciforth).
> 
> anyway.
> 
> >
> 
> >Best regards,
> 
> >Howerd
> 
> 
> 
> WANT $-PREFIX
> 
> WANT RESTORED
> 
> 
> 
> >
> 
> >\ StringTMP.f   2013 Oct 12
> 
> >\ Use TYPE  EMIT and CR to construct a string
> 
> >
> 
> >$100 constant |StringTMP|
> 
> 
> 
> same
> 
> 
> 
> >|StringTMP| Buffer: StringTMP[]
> 
> 
> 
> CREATE StringTMP[] |StringTMP| ALLOT
> 
> 
> 
> >
> 
> >variable SavedEmit
> 
> >variable SavedType
> 
> >variable SavedCR
> 
> >
> 
> >: s-emit ( c -- )
> 
> >  pad c!  pad 1  StringTMP[] append
> 
> >;
> 
> >
> 
> 
> 
> Did you know this trick?
> 
> 
> 
> : s-emit DSP@ 1 ( now it is a 1 char string containing c )
> 
>     StringTMP[] append   ( c) DROP ;
> 
> 
> 
> gone
> 
> 
> 
> >: s-type ( caddr c -- )
> 
> >   StringTMP[] append
> 
> >;
> 
> >
> 
> 
> 
> : s-type stringTMP[] $+! ;
> 
> 
> 
> >: s-cr ( -- )  #13 s-emit  #10 s-emit ;
> 
> >
> 
> 
> 
> gone
> 
> 
> 
> >: s[ ( -- )    \ start vectored string output
> 
> >   0 StringTMP[] c!        \ clear our string buffer
> 
> >   'EMIT @ SavedEmit !   \ save the current vectors
> 
> >   'TYPE @ SavedType !
> 
> >   'CR @ SavedCR !
> 
> >   ['] s-emit 'EMIT !
> 
> >   ['] s-type 'TYPE !
> 
> >   ['] s-cr 'CR !
> 
> >;
> 
> 
> 
> : S[ 's-type 'TYPE 3 CELLS MOVE ;
> 
> 
> 
> >
> 
> >
> 
> >: ]s ( -- c-addr c )    \ end vectored string output
> 
> >    SavedEmit @ 'EMIT !  \ restore the current vectors
> 
> >    SavedType @ 'TYPE !
> 
> >    SavedCR @ 'CR !
> 
> >    StringTMP[] count      \ return the string
> 
> >;
> 
> 
> 
> : ]s 'TYPE RESTORED StringTMP[] $@ ;       \ return the string
> 
> 
> 
> >
> 
> >: $TMP ( xt -- c-addr c )  \ return a string from the output of the word xt
> 
> >   s[  execute  ]s
> 
> >;
> 
> 
> 
> same
> 
> 
> 
> >
> 
> >\ example usage
> 
> >
> 
> >: ShowAstring ( -- )
> 
> >   s[
> 
> >   cr  ." Hello string... "  27 emit 85 emit  07 emit
> 
> >   space  123 . space cr cr ."  well that was easy"  cr
> 
> >   ]s 2dup type dump
> 
> >;
> 
> >
> 
> >
> 
> >: MakeAstring ( -- )   cr  ." Hello string... "  27 emit
> 
> >   85 emit  07 emit  space  123 . space
> 
> >   cr cr ."  well that was easy"  cr
> 
> >;
> 
> >
> 
> >: ShowAstring2
> 
> >   ['] MakeAstring $TMP 2dup type dump
> 
> >;
> 
> 
> 
> same
> 
> 
> 
> >
> 
> >
> 
> >
> 
> 
> 
> I recapulate what it looks like in ciforth:
> 
> Note that 'TYPE is the dea of TYPE :a constant, that is
> 
> the same compiling or interpreting.
> 
> 
> 
> : s-type        stringTMP[] $+! ;
> 
> : s[            's-type 'TYPE 3 CELLS MOVE   "" StringTMP[] $! ;
> 
> : ]s            'TYPE RESTORED   StringTMP[] $@ ;
> 
> 
> 
> Note that we never leave the $ abstraction. So we can replace
> 
> the strings by braindamaged 1] strings and it all works
> 
> (until you get above length 256)
> 
> 
> 
> A one-screener to add in a new release.
> 
> 
> 
> >
> 
> Groetjes Albert
> 
> 
> 
> 1] This is a term coined in the ciforth documentation.
> 
> COUNT is an alias for $@ for brain-damaged strings.
> 
> The counterpart is BD-$! .
> 
> -- 
> 
> 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

Hi Albert,

> Did you know this trick?
> : s-emit DSP@ 1 ( now it is a 1 char string containing c )
>     StringTMP[] append   ( c) DROP ;
This is great if you are working "under the hood" , for example DSP@ is SP@ in SwiftForth, and this is non-portable.
Presumably a Forth that does not have a real address for the stack has some other way of doing this...

My view of Forth is coloured by colorForth, so I tend not to define "utilities", but I prefer to load everything that I need for an application, from scratch.

I also don't like (but use all the time in C) the idea of passing pointers around. I find a real buffer conceptually simpler - you can dump or type it to see what is going on.
Your implementation of s[ and s] requires that the original string is writable, which is not always the case.
If you follow this route, maybe you should define "static" types, to protect you from the sort of bugs you get in C...

Sorry if I am being a bit negative - this all seems so very C-like ;-)

Best regards,
Howerd

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

#26676

In article <f7e8ff3a-d428-47e3-998a-27a072e77ab7@googlegroups.com>,
Howerd  <howerdo@yahoo.co.uk> wrote:
>On Thursday, 24 October 2013 13:04:43 UTC+1, Albert van der Horst  wrote:
>> In article <91315aab-5cae-4b6a-bee2-dc1d1ca2d749@googlegroups.com>,
>>
>> Howerd  <how....@yahoo.co.uk> wrote:

<SNIP original implementation of s[ utility. >

>>
>> I recapulate what it looks like in ciforth:
>>
>> Note that 'TYPE is the dea of TYPE :a constant, that is
>>
>> the same compiling or interpreting.
>> : s-type        stringTMP[] $+! ;
>> : s[            's-type 'TYPE 3 CELLS MOVE   "" StringTMP[] $! ;
>> : ]s            'TYPE RESTORED   StringTMP[] $@ ;
>>
>> Note that we never leave the $ abstraction. So we can replace
>> the strings by braindamaged 1] strings and it all works
>> (until you get above length 256)
>> A one-screener to add in a new release.
>>
>> >
>>
>> Groetjes Albert
>>
>>
>>
>> 1] This is a term coined in the ciforth documentation.
>>
>> COUNT is an alias for $@ for brain-damaged strings.
>>
>> The counterpart is BD-$! .
>>
>> --
>>
>> Albert van der Horst, UTRECHT,THE NETHERLANDS
>> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
>
>Hi Albert,
>
>> Did you know this trick?
>> : s-emit DSP@ 1 ( now it is a 1 char string containing c )
>>     StringTMP[] append   ( c) DROP ;
>This is great if you are working "under the hood" , for example DSP@ is
>SP@ in SwiftForth, and this is non-portable.
>Presumably a Forth that does not have a real address for the stack has
>some other way of doing this...
>
>My view of Forth is coloured by colorForth, so I tend not to define
>"utilities", but I prefer to load everything that I need for an
>application, from scratch.

Wel, there are probably building blocks that you use more that once,
that would I call once.
By the way I'm impressed with anybody getting real work down with
colorforth...


>
>I also don't like (but use all the time in C) the idea of passing
>pointers around. I find a real buffer conceptually simpler - you can
>dump or type it to see what is going on.

These are definitely not c-strings. They are addr,len pairs like used
preferably by new definitions in the standard, like SEARCH-WORDLIST.

>Your implementation of s[ and s] requires that the original string is
>writable, which is not always the case.

That is definitely not required. I hate the guts of WORD, because it
copies to a place where it can prepend a count, and I hate c-strings
because of the zeroes it writes.
I replace BL WORD FIND by NAME FOUND in my implementation of Forth,
such that what is passed around are (addr,len) pairs where addr
points directly in the input buffer.

So look again. You're really missing something.
The best thing is $/ "string-slash" , which splits a string on a delimiter.
<funny voice> No copy-copy, really. </funny voice>.
"
    \ Getting the first line of file aap in ciforth:
    "aap" GET-FILE ^J $/

    \ Get the first word of the first line
    BL $/
    \ It is a filename. Get rid of the C: if present.
    2DUP &: $^ IF &: $/ 2DROP THEN
    \ Now write that out on the error channel for debugging
    ETYPE
    ...
"
After the file is slurped none of the manipulations involves moving
characters around.

>If you follow this route, maybe you should define "static" types, to
>protect you from the sort of bugs you get in C...

I can hide definitions, if I want to. ( HIDE PAD ) I rarely do.

>
>Sorry if I am being a bit negative - this all seems so very C-like ;-)

It is merely a very thin abstraction layer. Like helper words that
remember an address in IF and back patch it in THEN.

And then, the pointers in c aren't so bad per se. Addresses as identification of
objects seems unavoidable in any language. It is the idea that there
is a type hidden in a character pointer which assumes it is null ended
which is bad.

>
>Best regards,
>Howerd
>
-- 
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]

#26677

On Friday, 25 October 2013 12:43:25 UTC+1, Albert van der Horst  wrote:
> In article <f7e8ff3a-d428-47e3-998a-27a072e77ab7@googlegroups.com>,
> 
> Howerd  <how....@yahoo.co.uk> wrote:
> 
> >On Thursday, 24 October 2013 13:04:43 UTC+1, Albert van der Horst  wrote:
> 
> >> In article <91315aab-5cae-4b6a-bee2-dc1d1ca2d749@googlegroups.com>,
> 
> >>
> 
> >> Howerd  <how....@yahoo.co.uk> wrote:
> 
> 
> 
> <SNIP original implementation of s[ utility. >
> 
> 
> 
> >>
> 
> >> I recapulate what it looks like in ciforth:
> 
> >>
> 
> >> Note that 'TYPE is the dea of TYPE :a constant, that is
> 
> >>
> 
> >> the same compiling or interpreting.
> 
> >> : s-type        stringTMP[] $+! ;
> 
> >> : s[            's-type 'TYPE 3 CELLS MOVE   "" StringTMP[] $! ;
> 
> >> : ]s            'TYPE RESTORED   StringTMP[] $@ ;
> 
> >>
> 
> >> Note that we never leave the $ abstraction. So we can replace
> 
> >> the strings by braindamaged 1] strings and it all works
> 
> >> (until you get above length 256)
> 
> >> A one-screener to add in a new release.
> 
> >>
> 
> >> >
> 
> >>
> 
> >> Groetjes Albert
> 
> >>
> 
> >>
> 
> >>
> 
> >> 1] This is a term coined in the ciforth documentation.
> 
> >>
> 
> >> COUNT is an alias for $@ for brain-damaged strings.
> 
> >>
> 
> >> The counterpart is BD-$! .
> 
> >>
> 
> >> --
> 
> >>
> 
> >> Albert van der Horst, UTRECHT,THE NETHERLANDS
> 
> >> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
> 
> >
> 
> >Hi Albert,
> 
> >
> 
> >> Did you know this trick?
> 
> >> : s-emit DSP@ 1 ( now it is a 1 char string containing c )
> 
> >>     StringTMP[] append   ( c) DROP ;
> 
> >This is great if you are working "under the hood" , for example DSP@ is
> 
> >SP@ in SwiftForth, and this is non-portable.
> 
> >Presumably a Forth that does not have a real address for the stack has
> 
> >some other way of doing this...
> 
> >
> 
> >My view of Forth is coloured by colorForth, so I tend not to define
> 
> >"utilities", but I prefer to load everything that I need for an
> 
> >application, from scratch.
> 
> 
> 
> Wel, there are probably building blocks that you use more that once,
> 
> that would I call once.
> 
> By the way I'm impressed with anybody getting real work down with
> 
> colorforth...
> 
> 
> 
> 
> 
> >
> 
> >I also don't like (but use all the time in C) the idea of passing
> 
> >pointers around. I find a real buffer conceptually simpler - you can
> 
> >dump or type it to see what is going on.
> 
> 
> 
> These are definitely not c-strings. They are addr,len pairs like used
> 
> preferably by new definitions in the standard, like SEARCH-WORDLIST.
> 
> 
> 
> >Your implementation of s[ and s] requires that the original string is
> 
> >writable, which is not always the case.
> 
> 
> 
> That is definitely not required. I hate the guts of WORD, because it
> 
> copies to a place where it can prepend a count, and I hate c-strings
> 
> because of the zeroes it writes.
> 
> I replace BL WORD FIND by NAME FOUND in my implementation of Forth,
> 
> such that what is passed around are (addr,len) pairs where addr
> 
> points directly in the input buffer.
> 
> 
> 
> So look again. You're really missing something.
> 
> The best thing is $/ "string-slash" , which splits a string on a delimiter.
> 
> <funny voice> No copy-copy, really. </funny voice>.
> 
> "
> 
>     \ Getting the first line of file aap in ciforth:
> 
>     "aap" GET-FILE ^J $/
> 
> 
> 
>     \ Get the first word of the first line
> 
>     BL $/
> 
>     \ It is a filename. Get rid of the C: if present.
> 
>     2DUP &: $^ IF &: $/ 2DROP THEN
> 
>     \ Now write that out on the error channel for debugging
> 
>     ETYPE
> 
>     ...
> 
> "
> 
> After the file is slurped none of the manipulations involves moving
> 
> characters around.
> 
> 
> 
> >If you follow this route, maybe you should define "static" types, to
> 
> >protect you from the sort of bugs you get in C...
> 
> 
> 
> I can hide definitions, if I want to. ( HIDE PAD ) I rarely do.
> 
> 
> 
> >
> 
> >Sorry if I am being a bit negative - this all seems so very C-like ;-)
> 
> 
> 
> It is merely a very thin abstraction layer. Like helper words that
> 
> remember an address in IF and back patch it in THEN.
> 
> 
> 
> And then, the pointers in c aren't so bad per se. Addresses as identification of
> 
> objects seems unavoidable in any language. It is the idea that there
> 
> is a type hidden in a character pointer which assumes it is null ended
> 
> which is bad.
> 
> 
> 
> >
> 
> >Best regards,
> 
> >Howerd
> 
> >
> 
> -- 
> 
> 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

Hi Albert,

> These are definitely not c-strings. 
No, more like structs...

>>Your implementation of s[ and s] requires that the original string is
>>writable, which is not always the case.
>That is definitely not required.
OK - I looked at this code 
 : s[            's-type 'TYPE 3 CELLS MOVE   "" StringTMP[] $! ; 
and assumed that you are copying pointers - I looked closer and I see that you are not...

>> If you follow this route, maybe you should define "static" types, to
>> protect you from the sort of bugs you get in C...
Ooops - I meant to say "const" - brain failure ;-)
This does not apply anyway, as you are not writing to the source string...

> By the way I'm impressed with anybody getting real work down with
> colorforth...
Its not that difficult - honest!

Best regards,
Howerd

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

#26406

On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
> ... we now have quotations, which make handling 
> this statefull stuff easier (what to do in case of an exception?).  

We now have quotations??? Since when? That is not possible under ANS-Forth.

When I brought up quotations on the Forth-200x mailing list, Elizabeth Rather asked that somebody please explain to her what they are, but nobody did. I'm not aware that anybody on the Forth-200x committee knows what quotations are, much less how to implement them. I suggested to Elizabeth Rather that the next time she is teaching her novice class, she ask her students to explain the concept to her --- I assume that all of her students are familiar with basic concepts such as this.

Quotations, or closures, or whatever you call them, are the primary feature of my own language --- this is largely why I have abandoned Forth-200x.

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

#26412

On Saturday, October 12, 2013 5:26:44 AM UTC+1, hughag...@yahoo.com wrote:
> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
> 
> > ... we now have quotations, which make handling 
> 
> > this statefull stuff easier (what to do in case of an exception?).  
> 
> 
> 
> We now have quotations??? Since when? That is not possible under ANS-Forth.
> 
> 
> 
> When I brought up quotations on the Forth-200x mailing list, Elizabeth Rather asked that somebody please explain to her what they are, but nobody did. I'm not aware that anybody on the Forth-200x committee knows what quotations are, much less how to implement them. I suggested to Elizabeth Rather that the next time she is teaching her novice class, she ask her students to explain the concept to her --- I assume that all of her students are familiar with basic concepts such as this.
> 
> 
> 
> Quotations, or closures, or whatever you call them, are the primary feature of my own language --- this is largely why I have abandoned Forth-200x.

Hi Hugh,

I think I get closures :
http://en.wikipedia.org/wiki/Closure_%28computer_science%29
 
But what exactly is a "quotation" in software land?
I Googled "Computer programming quotations" and found this :
http://en.wikiquote.org/wiki/Programming

Maybe someone can enlighten Elizabeth and me with a link?

Best regards,
Howerd

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

#26428

Howerd wrote:

> On Saturday, October 12, 2013 5:26:44 AM UTC+1, hughag...@yahoo.com wrote:
> > On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
> > 
> > > ... we now have quotations, which make handling 
> > 
> > > this statefull stuff easier (what to do in case of an exception?).  
> > 
> > 
> > 
> > We now have quotations??? Since when? That is not possible under ANS-Forth.
> > 
> > 
> > 
> > When I brought up quotations on the Forth-200x mailing list, Elizabeth Rather asked that somebody please explain to her what they are, but nobody did. I'm not aware that anybody on the Forth-200x committee knows what quotations are, much less how to implement them. I suggested to Elizabeth Rather that the next time she is teaching her novice class, she ask her students to explain the concept to her --- I assume that all of her students are familiar with basic concepts such as this.
> > 
> > 
> > 
> > Quotations, or closures, or whatever you call them, are the primary feature of my own language --- this is largely why I have abandoned Forth-200x.
> 
> Hi Hugh,
> 
> I think I get closures :
> http://en.wikipedia.org/wiki/Closure_%28computer_science%29

Example of a closure in Racket (Scheme):


(let ((multiplier 800))
  (for-each
    ;; The closure.
    (lambda (n) (displayln (list n (* n multiplier))))
    '(1 1 2 3 5 8 13 21)))

(1 800)
(1 800)
(2 1600)
(3 2400)
(5 4000)
(8 6400)
(13 10400)
(21 16800)

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

#26418

hughaguilar96@yahoo.com wrote:
> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
>> ... we now have quotations, which make handling 
>> this statefull stuff easier (what to do in case of an exception?).  
> 
> We now have quotations??? Since when? That is not possible under ANS-Forth.
> 

> When I brought up quotations on the Forth-200x mailing list,
> Elizabeth Rather asked that somebody please explain to her what they
> are, but nobody did. I'm not aware that anybody on the Forth-200x
> committee knows what quotations are, much less how to implement
> them.

Oh come on, this is so ridiculous it must be a troll.  I posted an
implementation (for SwiftForth) at

https://groups.google.com/group/comp.lang.forth/msg/4316e4d74781196d?hl=en
https://groups.google.com/group/comp.lang.forth/msg/376b37a10b0067a1?hl=en

Bernd's is at
http://www.complang.tuwien.ac.at/viewcvs/cgi-bin/viewcvs.cgi/gforth/quotations.fs?rev=1.2&view=markup

We already had the discussion with Elizabeth about what quotations are
for in *this* *newsgroup*.

Andrew.

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

#26421

On Saturday, October 12, 2013 11:40:29 AM UTC+1, Andrew Haley wrote:
> hugha.........@yahoo.com wrote:
> 
> > On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
> 
> >> ... we now have quotations, which make handling 
> 
> >> this statefull stuff easier (what to do in case of an exception?).  
> 
> > 
> 
> > We now have quotations??? Since when? That is not possible under ANS-Forth.
> 
> > 
> 
> 
> 
> > When I brought up quotations on the Forth-200x mailing list,
> 
> > Elizabeth Rather asked that somebody please explain to her what they
> 
> > are, but nobody did. I'm not aware that anybody on the Forth-200x
> 
> > committee knows what quotations are, much less how to implement
> 
> > them.
> 
> 
> 
> Oh come on, this is so ridiculous it must be a troll.  I posted an
> 
> implementation (for SwiftForth) at
> 
> 
> 
> https://groups.google.com/group/comp.lang.forth/msg/4316e4d74781196d?hl=en
> 
> https://groups.google.com/group/comp.lang.forth/msg/376b37a10b0067a1?hl=en
> 
> 
> 
> Bernd's is at
> 
> http://www.complang.tuwien.ac.at/viewcvs/cgi-bin/viewcvs.cgi/gforth/quotations.fs?rev=1.2&view=markup
> 
> 
> 
> We already had the discussion with Elizabeth about what quotations are
> 
> for in *this* *newsgroup*.
> 
> 
> 
> Andrew.

Hi Andrew,

I remember the thread, and I also remember not understanding then what quotations are for. 

Maybe I am suffering from the delusion that if something does not have a Wikipedia page it doesn't exist.

I seem to remember Anton saying that quotations are not the same as closures.
This limits my lack of understanding by one item out of infinity ;-)

Best regards,
Howerd

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

#26423

Howerd <howerdo@yahoo.co.uk> wrote:
> 
> I remember the thread, and I also remember not understanding then
> what quotations are for.

OK, so I'll try again.

A quotation is block of Forth code that has no name, but it has an XT.
It's like a :noname word except that it occurs inside a definition.
So this example prints 99:

: example   [: 99 . ;] execute ;

This example prints 99 in a CATCH block:

: example   [: 99 . ;] catch if ."  caught!" then ;

Think about a word like Forth Inc's ACTIVATE, which takes a task
address and starts a tasks executing everything after the ACTIVATE,
returning to the caller.  So, to make task PRINTER print a line you'd
do

: example   printer activate  ." Hello, world!" cr ;

It's traditionally implemented like this, given a word execute-in-task
that actually starts a task:

\ execute-in-task ( task xt - ) Set task to execute XT.
: activate ( a - )   r> execute-in-task ;

The trouble is that this is highly nonportable.  R> doesn't
necessarily return an XT, and unbalanced return stacks aren't portable
for other reasons.

A quotation can easily perform the function of ACTIVATE without return
stack hackery:

: example   printer [: ." Hello, world!" cr ;] execute-in-task ;

Note that a quotation is only a notational convenience.  You can do
this by creating named words, ticking them, and passing them to other
words.  But notation *matters*.  It changes the way people think.

Andrew.

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

#26431

On Saturday, October 12, 2013 2:56:20 PM UTC+1, Andrew Haley wrote:
> Howerd <howe....@yahoo.co.uk> wrote:
> 
> > 
> 
> > I remember the thread, and I also remember not understanding then
> 
> > what quotations are for.
> 
> 
> 
> OK, so I'll try again.
> 
> 
> 
> A quotation is block of Forth code that has no name, but it has an XT.
> 
> It's like a :noname word except that it occurs inside a definition.
> 
> So this example prints 99:
> 
> 
> 
> : example   [: 99 . ;] execute ;
> 
> 
> 
> This example prints 99 in a CATCH block:
> 
> 
> 
> : example   [: 99 . ;] catch if ."  caught!" then ;
> 
> 
> 
> Think about a word like Forth Inc's ACTIVATE, which takes a task
> 
> address and starts a tasks executing everything after the ACTIVATE,
> 
> returning to the caller.  So, to make task PRINTER print a line you'd
> 
> do
> 
> 
> 
> : example   printer activate  ." Hello, world!" cr ;
> 
> 
> 
> It's traditionally implemented like this, given a word execute-in-task
> 
> that actually starts a task:
> 
> 
> 
> \ execute-in-task ( task xt - ) Set task to execute XT.
> 
> : activate ( a - )   r> execute-in-task ;
> 
> 
> 
> The trouble is that this is highly nonportable.  R> doesn't
> 
> necessarily return an XT, and unbalanced return stacks aren't portable
> 
> for other reasons.
> 
> 
> 
> A quotation can easily perform the function of ACTIVATE without return
> 
> stack hackery:
> 
> 
> 
> : example   printer [: ." Hello, world!" cr ;] execute-in-task ;
> 
> 
> 
> Note that a quotation is only a notational convenience.  You can do
> 
> this by creating named words, ticking them, and passing them to other
> 
> words.  But notation *matters*.  It changes the way people think.
> 
> 
> 
> Andrew.

Hi Andrew,

Thank you for a very clear explanation :-)

Is there any (easy) way of implementing this apart from giving each quotation a 
hidden internal name? i.e. without using the usual dictionary structure?

What is the lifetime of a quotation expected to be?

I think these two questions are related.

> But notation *matters*.  It changes the way people think. 
This seems to be _lack_ of notation, or lack of a name for a piece of code.
Interesting. I will have to ponder the implications...

Best regards,
Howerd

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

#26435

Op Sat, 12 Oct 2013 14:04:30 -0700 (PDT) schreef Howerd:

UTC+1, Andrew Haley wrote:
<snipped long winding ggroups dou> On Saturday, October 12, 2013 2:56:20 PM
> 
> Hi Andrew,
> 
> Thank you for a very clear explanation :-)
> 
> Is there any (easy) way of implementing this apart from giving each quotation a 
> hidden internal name? i.e. without using the usual dictionary structure?
> 
Why does it need a name, (hidden in this case?). :NONAME doesn't either
have a name. Though I know of an implementation that give e.g. WORDLIST a
null name.

> What is the lifetime of a quotation expected to be?
As long as the colon definition of which is part of.

> 
> I think these two questions are related.
I think not.

> 
>> But notation *matters*.  It changes the way people think. 
> This seems to be _lack_ of notation, or lack of a name for a piece of code.
> Interesting. I will have to ponder the implications...
The quotation is enclosed in [: and ;]
Isn't that a notation/syntax?

> 
> Best regards,
> Howerd

-- 
Coos

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

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

#26437

Coos Haak wrote:
>> What is the lifetime of a quotation expected to be?
> As long as the colon definition of which is part of.

To be a bit more precise: The quotation is part of the code of the 
surrounding colon definition.  A word can return a quotation which is alive 
"forever" (i.e. until you forget the word or execute a marker).  So things 
like "access to locals within the surrounding word" is better avoided - this 
would only work reliable when you had implemented real closures; and while 
that certainly is possible, it is IMHO not desireable for Forth (too 
complicated).

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

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

#26453

Hi,

Howerd <howerdo@yahoo.co.uk> wrote:
> On Saturday, October 12, 2013 2:56:20 PM UTC+1, Andrew Haley wrote:
> 
> Thank you for a very clear explanation :-)
> 
> Is there any (easy) way of implementing this apart from giving each
> quotation a hidden internal name? i.e. without using the usual
> dictionary structure?

Yes.  I posted an implementation (for SwiftForth) at

https://groups.google.com/group/comp.lang.forth/msg/4316e4d74781196d?hl=en
https://groups.google.com/group/comp.lang.forth/msg/376b37a10b0067a1?hl=en

> What is the lifetime of a quotation expected to be?

Forever.

>> But notation *matters*.  It changes the way people think. 

> This seems to be _lack_ of notation, or lack of a name for a piece
> of code.

Well, yes.  Very Forthly...

Andrew.

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web