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 4 of 4 — ← Prev page 1 2 3 [4]

#26529

On 14/10/2013 22:29, Gerry Jackson wrote:
> On 14/10/2013 21:50, Alex McDonald wrote:
>> on 14/10/2013 17:38:15, Gerry Jackson wrote:
>>> On 14/10/2013 15:23, Andrew Haley wrote:
>>>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>>>>> On 14/10/2013 13:10, Alex McDonald wrote:
>>>>>> on 14/10/2013 09:41:28, Gerry Jackson wrote:
>>>>>>> On 12/10/2013 16:50, Alex McDonald wrote:
>>>>>>>> on 12/10/2013 15:12:40, Bernd Paysan wrote:
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> We have quotations, we don't have closures. They are easy to
>>>>>>>>> implement
>>>>>>>>> with a bit of carnal knowledge, and we can make them standard
>>>>>>>>> (so far,
>>>>>>>>> nobody has proposed an RfD).
>>>>>>>>
>>>>>>>> Hugh's right that they can't be implemented in only ANS Forth;
>>>>>>>
>>>>>>> It's been done e.g. see Stephen Pelc's summary near the end of this
>>>>>>> discussion:
>>>>>>> https://groups.google.com/forum/?hl=en#!
>> msg/comp.lang.forth/x8hUOj1MetU/tSHs6EMudLEJ
>>>>>>>
>>>>>>> which you replied to.
>>>>>>>
>>>>>>
>>>>>> Do you mean the zip file? It doesn't exist. Can you repost the code?
>>>>>>
>>>>>
>>>>> Sorry that site has been taken down for various reasons, if you
>>>>> send me
>>>>> an email address I'll email the zip file to you.
>>>>
>>>> I remember someone posted some code that required a complex OOP
>>>> package, but I couldn't tease the code out of the OOP.  I haven't seen
>>>> a straightforward Forth implmentation.
>>>
>>> It can't be as straightforward (Alex didn't say straightforward) as an
>>> implementation that's system specific such as those posted for various
>>> systems. It's not difficult in principle and but is difficult to
>>> explain without a diagram, but here goes.
>>>
>>> I used :lam ... ;lam as the outer definition containing quotations (to
>>> avoid complications using : and ; ) and a :lam definition is compiled
>>> in two passes.
>>>
>>> The first pass scans the text, when it sees a [: it does a SAVE-INPUT
>>> and pushes the returned data onto a stack and carries on scanning.
>>>
>>> When it reaches the end of the enclosing definition ;lam it starts
>>> pass 2 by unstacking the data from the last SAVE-INPUT and does a
>>> RESTORE-INPUT to jump back to the start of the last quotation. It then
>>> compiles the quotation as a :noname definition.
>>>
>>> The next ;] does another SAVE-INPUT and stacks it
>>> and RESTORE-INPUTs to either the preceding quotation or the :lam.
>>> The compilation of the outer definition skips over the already
>>> compiled quotations. And so on until ;lam is executed.
>>>
>>> Diagrammatically (and I hope newsreaders don't screw this up with
>>> proportional fonts)
>>>
>>> :lam foo   ...   [:         ...      ;]  ...   ;lam
>>> A             B                   C
>>> save-input A
>>> scan--------> save-input B
>>> scan------------------------> restore-input B
>>> i.e. jump to B
>>> <-----------------------------
>>> execute :noname
>>> compile ---------> save-input C
>>> execute ;
>>> restore-input A
>>> <------------------------------------
>>> execute :
>>> compile -----> restore-input C
>>> i.e. jump to C ------>
>>> compile ---> execute ;
>>>
>>> It is simple to extend this to multiple and nested quotations
>>>
>>> The complication you're thinking of might be because it also includes
>>> closures which is where the OOP comes in (mini-oof's not complex). I'm
>>> not going to attempt to explain that here.
>>>
>>> I did it all as a proof that it could be done in ANS Forth to counter
>>> those who said it couldn't, more for fun than anything. I've
>>> implemented quotations in a straightforward way in my Forth system.
>>>
>>> Anyway as I said to Alex, if you or anyone wants a copy, send me an
>>> email with an email address that works.
>>>
>>
>> Although it might be written in ANS Forth, I don't think this results in
>> code that can compile an ANS Forth program.
>>
>> Words such as ( a comment about [: ) or parsing as in POSTPONE ; will
>> throw off any simple "deferred scan".
>>
>
> It's wise to look at any code before pontificating at what it will and
> won't do. You're as bad as Hugh:-) In fact it will scan comments and
> text bracketed by ( " and all standard parsing words like ' and
                                                             ^
Sorry I meant [']

> POSTPONE. But you are partly right in that there are restrictions e.g.
> if someone writes a word like
>
> : bar parse-name ; immediate
>
> it won't handle  :lam foo ... [: ... bar [: ... ;] ... ;lam
> or               :lam foo ... bar s" ... ;lam
> and so on because there is a limit to what can be done without writing a
> full blown Forth interpreter.
>
> Other restrictions are listed in the readme file, they are ones I think
> I could live with had I used the package extensively.
>
> Are you sure you don't want to look at the package? ISTR that you ignore
> emails to the email address in your c.l.f posts - you certainly ignored
> one I accidentally sent soon after Thunderbird changed its interface for
> replies to newsgroups some time ago.
>


-- 
Gerry

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

#26530

on 14/10/2013 22:29:34, Gerry Jackson wrote:
> On 14/10/2013 21:50, Alex McDonald wrote:

[snip]

>>>
>>
>> Although it might be written in ANS Forth, I don't think this results in
>> code that can compile an ANS Forth program.
>>
>> Words such as ( a comment about [: ) or parsing as in POSTPONE ; will
>> throw off any simple "deferred scan".
>>
> 
> It's wise to look at any code before pontificating at what it will and
> won't do. You're as bad as Hugh:-) 

Dear God, no... that's a scurrilous assertion. In a different age, I
would have demanded pistols at dawn. 

But I believe Hugh is right; it's not possible to do this properly in ANS
Forth.

> In fact it will scan comments and
> text bracketed by ( " and all standard parsing words like ' and
> POSTPONE. But you are partly right in that there are restrictions e.g.
> if someone writes a word like
> 
>: bar parse-name ; immediate
> 
> it won't handle  :lam foo ... [: ... bar [: ... ;] ... ;lam
> or               :lam foo ... bar s" ... ;lam
> and so on because there is a limit to what can be done without writing
> a full blown Forth interpreter.

I'd say my pontificate was pretty accurate in that case; it might be
smarter than a simple deferred scan, but it doesn't result in code that
can compile any ANS Forth program.  

> 
> Other restrictions are listed in the readme file, they are ones I
> think I could live with had I used the package extensively.
> 
> Are you sure you don't want to look at the package? 

I've got a solution that is carnally aware; it works well, and is pretty
simple (and it will compile ANS Forth). You can send it to < a le x at
riva dpm dot com > with the usual squish & substitutions.

> ISTR that you
> ignore emails to the email address in your c.l.f posts - you certainly
> ignored one I accidentally sent soon after Thunderbird changed its
> interface for replies to newsgroups some time ago.
> 

Yes, that's a spam trap, and it gets literally hundreds a day. Apparently
I have a lot of Nat West bank accounts.

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

#26539

Alex McDonald wrote:
> I'm pretty sure [quotations] can't be done without carnal knowledge. 

My idea is to chop up the surrounding definition in three parts.
This is a simplified, INCOMPLETE, and possibly buggy attempt:

variable xt
: jump   xt @ execute ;
: [:   postpone jump postpone ; :noname ; immediate
: ;]   postpone ; >r :noname r> postpone literal ; immediate
: ;   postpone ; xt ! ; immediate

Obviously, there are many shortcomings here.  I haven't tried very
hard, but I would hope it could be made to work.

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

#26544

> Obviously, there are many shortcomings here.  I haven't tried very
> hard, but I would hope it could be made to work.

I didn't consider local variables.  Those would be hard to fix, I
guess.

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

#26547

On 15/10/2013 07:00, Lars Brinkhoff wrote:
> Alex McDonald wrote:
>> I'm pretty sure [quotations] can't be done without carnal knowledge.
>
> My idea is to chop up the surrounding definition in three parts.
> This is a simplified, INCOMPLETE, and possibly buggy attempt:
>
> variable xt
> : jump   xt @ execute ;
> : [:   postpone jump postpone ; :noname ; immediate
> : ;]   postpone ; >r :noname r> postpone literal ; immediate
> : ;   postpone ; xt ! ; immediate
>
> Obviously, there are many shortcomings here.  I haven't tried very
> hard, but I would hope it could be made to work.
>

I think it works OK for simple definitions but not if quotations are 
included in control structures e.g.

: foo if [: ." A quotation" ;] execute then ;

won't compile on many, if not all, systems

-- 
Gerry

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

#26578

Gerry Jackson wrote:
> I think it works OK for simple definitions but not if quotations are
> included in control structures e.g.
>
> : foo if [: ." A quotation" ;] execute then ;
>
> won't compile on many, if not all, systems

Oh, right!

I made a correction that saves and restores the control flow stack
around the quotation, but it would only work on those rare
implementations that use the data stack as the control flow stack.

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

#26587

Op Wed, 16 Oct 2013 12:11:34 +0200 schreef Lars Brinkhoff:

> Gerry Jackson wrote:
>> I think it works OK for simple definitions but not if quotations are
>> included in control structures e.g.
>>
>>: foo if [: ." A quotation" ;] execute then ;
>>
>> won't compile on many, if not all, systems
> 
> Oh, right!
> 
> I made a correction that saves and restores the control flow stack
> around the quotation, but it would only work on those rare
> implementations that use the data stack as the control flow stack.

Rare? I've never encountered one that put them elsewhere ;-)

-- 
Coos

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

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

#26588

on 16/10/2013 11:11:36, Lars Brinkhoff wrote:
> Gerry Jackson wrote:
>> I think it works OK for simple definitions but not if quotations are
>> included in control structures e.g.
>>
>> : foo if [: ." A quotation" ;] execute then ;
>>
>> won't compile on many, if not all, systems
> 
> Oh, right!
> 
> I made a correction that saves and restores the control flow stack
> around the quotation, but it would only work on those rare

As Coos noted, they're not rare.

> implementations that use the data stack as the control flow stack.
> 

How do you know the number of cells to save & restore? 

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

#26593

Alex McDonald wrote:
>> I made a correction that saves and restores the control flow stack
>> around the quotation, but it would only work on those rare
> As Coos noted, they're not rare.

I was trying to be witty.

>> implementations that use the data stack as the control flow stack.
> How do you know the number of cells to save & restore? 

By redefining : to note DEPTH at the beginning of the definition.

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

#26451

To be a bit more precise: The quotation is part of the code of the
surrounding colon definition.

Is this fundamentally different from DOES> code, in that it is there until forgotten and can be re-used?

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

#26477

On Saturday, October 12, 2013 10:49:26 PM UTC-7, Clyde W. Phillips Jr. wrote:
> To be a bit more precise: The quotation is part of the code of the
> surrounding colon definition.
> 
> Is this fundamentally different from DOES> code, in that it is there until forgotten and can be re-used?

Closures and DOES> are totally different concepts. I don't use DOES> at all; it is a halfway step toward OOP. Closures and OOP are totally different concepts. Closures were invented in the Scheme/Lisp world long before anybody knew about OOP --- this is still the best place to learn about them --- now we have a lot of Lisp derivative languages that also have closures, but not always full-blown implementations. Java claims to have closures, but they are so limited as to be totally useless --- I wouldn't call them closures at all.

In my novice package (http://www.forth.org/novice.html) I have a very crude attempt at providing closure-like facility. See EACH in the LIST.4TH file; it is documented. I have the closure (I call it a "toucher" in the docs, which is kind of an ugly word that I regret now) access the creator function's data via the parameter stack, rather than via the local variables. Also, the toucher is just a named colon word itself; it is not defined within the creator function like it should be. The word that uses the toucher (EACH in this case) has to be specially written so that it holds all of its own data on the return stack while EXECUTEing the toucher, so that data doesn't get in the way when the toucher looks on the parameter stack for the creator function's data. This is incredibly crude and ugly --- if the Lispers were to see this, they would likely laugh themselves to death at the Forthers. It was the best I could do though within the ANS-Forth straight-jacket (and Forth-200x is just as restrictive).

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

#26476

On Friday, October 11, 2013 10:42:10 AM UTC-7, 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 ;
> 
> 
> 
> 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] | [prev] | [next] | [standalone]

#26513

JennyB <jennybrien@googlemail.com> writes:
>Standard Forth does have one limited means of string-building - pictured nu=
>meric output of using <# =B7=B7=B7 #> Unfortunately, that generates the cha=
>racters 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=20
>      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 ;

Read the part about >STRING-EXECUTE.  Now use EMIT, TYPE, and
>STRING-EXECUTE, instead of S+, C+, and <S S>, and you get:

: make-path ( dir-a dir-u file-a file-u -- path-a path-u )
  [: 2swap type [char] / emit type ;] >string-execute ;
\ or you can use    ." /"

: >z ( c-addr u -- c-addr )
  [: type 0 emit ;] >string-execute ;

One difference is that you have to FREE the result of >STRING-EXECUTE,
but then it is valid until you free it, not until the next
>STRING-EXECUTE (that would be another option, but I like that option
even less).

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

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

#26549

On Monday, 14 October 2013 17:26:19 UTC+1, Anton Ertl  wrote:

> 
> One difference is that you have to FREE the result of >STRING-EXECUTE,
> 
> but then it is valid until you free it, not until the next
> 
> >STRING-EXECUTE (that would be another option, but I like that option
> 
> even less).
> 
So >STRING-EXECUTE allocates memory for the string in the current region (if you are using regions)? Otherwise the memory has to be freed manually? I really don't like the latter option. 

I was trying to think of something that would work even if you didn't have ALLOCATE. The problem I had (and didn't solve) was what to do when you want to use your $TEMP as input for another $TEMP. Two strategies suggest themselves.

1. Leave it up to the application programmer. If they want to do that they need to save the string elsewhere. If you need to accommodate several temporary strings at a time then a good solution might be a circular buffer.

2. Have a circular buffer in the system to which every $TEMP is typed directly. 

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

#26590

JennyB <jennybrien@googlemail.com> writes:
>On Monday, 14 October 2013 17:26:19 UTC+1, Anton Ertl  wrote:
>
>> 
>> One difference is that you have to FREE the result of >STRING-EXECUTE,
>> 
>> but then it is valid until you free it, not until the next
>> 
>> >STRING-EXECUTE (that would be another option, but I like that option
>> 
>> even less).
>> 
>So >STRING-EXECUTE allocates memory for the string in the current region (if you are using regions)? Otherwise the memory has to be freed manually? I really don't like the latter option. 

Currently >STRING-EXECUTE ALLOCATEs memory for the resulting string,
and has to be FREEd manually.  I don't really like it, either, but
it's better than the alternatives.  If you like to free the string
automatically on the next invocation, that's easy to arrange:

variable buf 0 buf !
: >string-execute1 ( xt -- c-addr u )
  buf @ ?dup if 
    free throw then
  >string-execute over buf ! ;

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

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

#26592

Anton Ertl wrote:

> Currently >STRING-EXECUTE ALLOCATEs memory for the resulting string,
> and has to be FREEd manually.  I don't really like it, either, but
> it's better than the alternatives.  If you like to free the string
> automatically on the next invocation, that's easy to arrange:
> 
> variable buf 0 buf !
> : >string-execute1 ( xt -- c-addr u )
>   buf @ ?dup if
>     free throw then
>   >string-execute over buf ! ;

One of the nicest things about the TYPE/EMIT method is that you can replace 
your wrapper if you need some other behavior - the actual string creation is 
still the same.

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

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

#26740

On Wednesday, October 16, 2013 1:58:01 PM UTC-4, Bernd Paysan wrote:
> 
> One of the nicest things about the TYPE/EMIT method is that you can replace 
> your wrapper if you need some other behavior - the actual string creation is 
> still the same.
> 
This would be cleaner than manually concatenating strings for whatever an OS call wants. I envision three parts of the flow:

1. A word that saves and reassigns TYPE/EMIT/CR behavior.
2. Your code here.
3. A word that restores TYPE etc. and returns the string.

What would be good names for (1) and (3)?

I assume a static buffer would be fine, so you don't have to worry about when to deallocate it. But that's just wrapper implementation.

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

#26743

Brad Eckert wrote:

> On Wednesday, October 16, 2013 1:58:01 PM UTC-4, Bernd Paysan wrote:
>> 
>> One of the nicest things about the TYPE/EMIT method is that you can
>> replace your wrapper if you need some other behavior - the actual string
>> creation is still the same.
>> 
> This would be cleaner than manually concatenating strings for whatever an
> OS call wants. I envision three parts of the flow:
> 
> 1. A word that saves and reassigns TYPE/EMIT/CR behavior.
> 2. Your code here.
> 3. A word that restores TYPE etc. and returns the string.
> 
> What would be good names for (1) and (3)?

Usually, you have vectored IO, so to save TYPE/EMIT/CR, you save something 
like OP-VECTOR (VFX, Gforth) and set it to another output vector (with your 
own TYPE/EMIT/CR).  You could have a word that defines a simple IO vector:

simple-io: ( type-xt emit-xt cr-xt "name" -- )

which just needs to be called to set OP-VECTOR.

> I assume a static buffer would be fine, so you don't have to worry about
> when to deallocate it. But that's just wrapper implementation.

One cell is easiest saved on the return stack.

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

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

#26752

On Tuesday, October 29, 2013 12:10:29 PM UTC-4, Bernd Paysan wrote:
> Usually, you have vectored IO, so to save TYPE/EMIT/CR, you save something 
> like OP-VECTOR (VFX, Gforth) and set it to another output vector (with your 
> own TYPE/EMIT/CR).  You could have a word that defines a simple IO vector:
> 
I found that SwiftForth has [BUF to redirect I/O to a buffer and BUF] to restore. Rick VanNorman came up with this small lexicon while he was at FORTH Inc.

Usage:
   [BUF  <do some output>  BUF]
   @BUF returns the address and length of the buffered output.
   BUFZ returns the address of buffered output as a z-string.
   .BUF types the buffer.  Don't do this inside a [BUF BUF] pair.

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

#26760

Brad Eckert <hwfwguy@gmail.com> writes:
>On Wednesday, October 16, 2013 1:58:01 PM UTC-4, Bernd Paysan wrote:
>> 
>> One of the nicest things about the TYPE/EMIT method is that you can replace 
>> your wrapper if you need some other behavior - the actual string creation is 
>> still the same.
>> 
>This would be cleaner than manually concatenating strings for whatever an OS call wants. I envision three parts of the flow:
>
>1. A word that saves and reassigns TYPE/EMIT/CR behavior.
>2. Your code here.
>3. A word that restores TYPE etc. and returns the string.
>
>What would be good names for (1) and (3)?

That's a bad interface.  What happens if there is an exception in 2,
e.g., if the user types ^C?  TYPE, EMIT, etc. are not restored.

A better interface is 

<name> ( xt1 xt2 -- )
xt1 has stack effect ( c-addr u -- )
xt2 has the stack effect ( i*x -- j*x )

Replace TYPE with xt1 EXECUTE, and EMIT with TYPEing the char, and CR
with TYPEing a newline.  Then EXECUTE xt2.  Restore TYPE, EMIT, CR
upon leaving <name>.

I'll leave the all-important naming discussion to more enlightened
people.  IIRC Bernd Paysan has suggested a word of this kind ealier
and called it $TEMP.

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

[toc] | [prev] | [standalone]

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

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

csiph-web