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

#26515

Howerd <howerdo@yahoo.co.uk> writes:
>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?

The usual way is to implement it as a :NONAME definition that's being
jumped around with AHEAD ... THEN.  Plus there's some additional
administrative stuff.

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

As long as the containing definition.

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

#26432

On 10/12/13 3:56 AM, Andrew Haley wrote:
> 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.

Very clear, thank you. What is the advantage of doing this over simply 
making a definition with a name, or using :noname? I realize it's 
syntactically different, but is there a real advantage?

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#26434

Elizabeth D. Rather wrote:
> Very clear, thank you. What is the advantage of doing this over simply
> making a definition with a name, or using :noname? I realize it's
> syntactically different, but is there a real advantage?

Syntax matters.  A typical case of quotations are implicit loops, like 
TRAVERSE-WORDLIST.  You can view [: bla bla ;] <wid> TRAVERSE-WORDLIST as 
loop.  "bla bla" can be very short, e.g. to count words, you just have

[: ( n nt -- n+1 flag ) drop 1+ true ;]

as body.  That's not worth to define as word of its own.  If you have a 
longer body, you will of course define it as word of its own; maybe 
excluding something like the "continue" flag.

Factor uses quotations a lot in that way, and this opens up the use of 
higher-order functions.  In theory, using named words is functionally 
equivalent, but in practice, syntax matters too much.

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

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

#26446

On Saturday, October 12, 2013 2:40:24 PM UTC-7, Elizabeth D. Rather wrote:
> On 10/12/13 3:56 AM, Andrew Haley wrote:
> > 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.

 
> Very clear, thank you. What is the advantage of doing this over simply 
> making a definition with a name, or using :noname? I realize it's 
> syntactically different, but is there a real advantage?

This isn't "very clear" --- it is not an explanation at all --- he is not mentioning the crux of the matter, which is that the quotation has to have access to the local variables of the function that it is created in. Without access to the creator's locals, there is no advantage over :NONAME or just a named colon word, which is the grossly crude method that I use in my novice package because I don't have quotations available --- this is why I have abandoned Forth-200x.

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

#26456

Elizabeth D. Rather <erather@forth.com> wrote:
> On 10/12/13 3:56 AM, Andrew Haley wrote:
>> 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.
> 
> Very clear, thank you. What is the advantage of doing this over simply 
> making a definition with a name, or using :noname? I realize it's 
> syntactically different, but is there a real advantage?

What is a "real advantage" when it comes to notation?

I'll knock the question right back: what is the real advantage of
a word like DOES>

assembler definitions
: instruction ( n)   create ,  does> @ , ;

over a word called USE that takes an XT and sets the latest
definition's action:

: (instruction) ( - n)   @ , ;
: instruction ( n)   create ,  ['] (instruction) use ;

?

There's no "real advantage" to DOES>, is there?  Why not have words
for the two actions like this?

Andrew.

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

#26553

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>What is a "real advantage" when it comes to notation?
>
>I'll knock the question right back: what is the real advantage of
>a word like DOES>
>
>assembler definitions
>: instruction ( n)   create ,  does> @ , ;
>
>over a word called USE that takes an XT and sets the latest
>definition's action:
>
>: (instruction) ( - n)   @ , ;
>: instruction ( n)   create ,  ['] (instruction) use ;
>
>?
>
>There's no "real advantage" to DOES>, is there?  Why not have words
>for the two actions like this?

Actually, that's a cleaner approach that avoids issues like specifying
the meanining of RECURSE in the DOES> part and locals across DOES>, or
control flow around DOES>.

And once we have quotations, it's just as convenient to write:

: instruction ( n "name" -- )
  create ,
  [: @ , ;] use ;

For a more interesting example, consider (from
http://www.complang.tuwien.ac.at/forth/struct.fs):

: dofield ( -- )
does> ( name execution: addr1 -- addr2 )
    @ + ;

: dozerofield ( -- )
    immediate
does> ( name execution: -- )
    drop ;

: field ( align1 offset1 align size "name" --  align2 offset2 )
    \ name execution: addr1 -- addr2
    2 pick >r \ this uglyness is just for optimizing with dozerofield
    create-field
    r> if \ offset<>0
	dofield
    else
	dozerofield
    then ;

This could be written as:

: field ( align1 offset1 align size "name" --  align2 offset2 )
    2 pick >r create-field r> if
      [: @ + ;]
    else
      immediate [: drop ;]
    then
    use ;

(USE is in use for a different purpose, but I stayed with USE for the
purposes of this discussion, because I want to get somewhere before
the all-important naming discussion starts).

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

#26564

Anton Ertl wrote:
> (USE is in use for a different purpose, but I stayed with USE for the
> purposes of this discussion, because I want to get somewhere before
> the all-important naming discussion starts).

Haha. BTW, current git Gforth has this "use", it's called "set-does>".  
Works only if the passed xt is a colon definition (that's due to the way 
dodoes is implemnted).

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

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

#26516

"Elizabeth D. Rather" <erather@forth.com> writes:
>Very clear, thank you. What is the advantage of doing this over simply 
>making a definition with a name

You don't need to make up a name for the helper definition.  E.g., instead of

: cw-helper ( nt -- f )
  drop 1+ true ;

: count-words ( wid -- u )
  0 ['] cw-helper rot traverse-wordlist ;

you can write

: count-words ( wid -- u )
  0 [: drop 1+ true ;] rot traverse-wordlist

>or using :noname?

There is no easy standard way to get the xt of a :NONAME definition to
the consumer in cases like this.

The following is non-standard and less readable than the versions above

:noname ( nt -- f )
  drop 1+ true ;

>r : count-words 0 [ r> ] literal rot traverse-wordlist ;

The following is standard, but we need another named word, and the
readability is not great, either:

variable helper-xt

:noname ( nt -- f )
  drop 1+ true ; helper-xt !

: count-words 0 [ helper-xt @ ] literal rot traverse-wordlist ;

>I realize it's 
>syntactically different, but is there a real advantage?

It does not provide any additional functionality, if that is your
question.  It just allows more convenient notation.

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

#26520

On 14/10/2013 18:27, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> Very clear, thank you. What is the advantage of doing this over simply
>> making a definition with a name
>
> You don't need to make up a name for the helper definition.  E.g., instead of
>
> : cw-helper ( nt -- f )
>    drop 1+ true ;
>
> : count-words ( wid -- u )
>    0 ['] cw-helper rot traverse-wordlist ;
>
> you can write
>
> : count-words ( wid -- u )
>    0 [: drop 1+ true ;] rot traverse-wordlist
>
>> or using :noname?
>
> There is no easy standard way to get the xt of a :NONAME definition to
> the consumer in cases like this.

What about PASS (invented by Michael Gassanenko I believe) which is standard

: pass >r ' execute r> ; immediate

:noname ( nt -- f )
     drop 1+ true ;
pass : count-words 0 literal rot traverse-wordlist ;

I'm not arguing that it's as readable as using a quotation, just an easy 
standard way of doing it.

-- 
Gerry

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

#26559

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 14/10/2013 18:27, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> or using :noname?
>>
>> There is no easy standard way to get the xt of a :NONAME definition to
>> the consumer in cases like this.
>
>What about PASS (invented by Michael Gassanenko I believe) which is standard
>
>: pass >r ' execute r> ; immediate
>
>:noname ( nt -- f )
>     drop 1+ true ;
>pass : count-words 0 literal rot traverse-wordlist ;
>
>I'm not arguing that it's as readable as using a quotation, just an easy 
>standard way of doing it.

Yes, that's probably the easiest standard way, but it is also not very
satisfying.  It requires defining PASS, and it's still not as readable
as a quotation.

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

#26489

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> A quotation is block of Forth code that has no name...
> So this example prints 99:
> : example   [: 99 . ;] execute ; ...
> Note that a quotation is only a notational convenience.

I find myself wishing for something more like a lightweight module
symbol to make temporary named functions, rather than getting rid of the
names completely.  Something inspired by old-fashioned 16-line screens:

PARAGRAPH( foo bar ) \ only foo and bar are visible from this paragraph
: tempthing blah blah ;
: another-temp blah blah blah ;
: foo ( n -- n n ) tempthing xyz another-temp ;
: whatsit xyz foo ;
: bar ( n -- )  whatsit 3 foo tempthing blah blah ;
/PARAGRAPH

The /PARAGRAPH forgets all symbols defined in the paragraph, except
the ones named for export at the top of the paragraph.  /PARAGRAPH
could be combined with starting a new paragraph:

+PARAGRAPH( quux baz )  \ equivalent to /PARAGRAPH PARAGRAPH( ... )
: quux ... ;
: baz ... ;
/PARAGRAPH

Does that look tempting?

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

#26491

On Monday, October 14, 2013 5:58:22 AM UTC+2, Paul Rubin wrote:
[..]
> Does that look tempting?

Yes, it does, that's why iForth has had something like this since 1996.

You will eventually want to adjust SEE so that it can (still) show 
the names of the hidden definitions. Debugging becomes a pain if
this is not implemented. 
Likewise, your fine-grained paragraph style will backfire
when debugging, because on larger projects you don't know which 
paragraph contains the bug, and enabling all the temporaries
can be a lot of work. In iForth this only needs a single \ before DEPRIVE.

-marcel 

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

#26495

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> A quotation is block of Forth code that has no name...
>> So this example prints 99:
>> : example   [: 99 . ;] execute ; ...
>> Note that a quotation is only a notational convenience.
> 
> I find myself wishing for something more like a lightweight module
> symbol to make temporary named functions, rather than getting rid of the
> names completely.  Something inspired by old-fashioned 16-line screens:
> 
> PARAGRAPH( foo bar ) \ only foo and bar are visible from this paragraph
> : tempthing blah blah ;
> : another-temp blah blah blah ;
> : foo ( n -- n n ) tempthing xyz another-temp ;
> : whatsit xyz foo ;
> : bar ( n -- )  whatsit 3 foo tempthing blah blah ;
> /PARAGRAPH
> 
> The /PARAGRAPH forgets all symbols defined in the paragraph, except
> the ones named for export at the top of the paragraph.  /PARAGRAPH
> could be combined with starting a new paragraph:
> 
> +PARAGRAPH( quux baz )  \ equivalent to /PARAGRAPH PARAGRAPH( ... )
> : quux ... ;
> : baz ... ;
> /PARAGRAPH
> 
> Does that look tempting?

What is it for?  It looks a bit like private members in C++ or static
declarations in C.  I suppose it would save a bit of memory.

Andrew.

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

#26496

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> PARAGRAPH( foo bar ) \ only foo and bar are visible from this paragraph
> What is it for?  It looks a bit like private members in C++ or static
> declarations in C.  I suppose it would save a bit of memory.

Wasn't thinking about memory.  It's just to control namespace pollution
resulting from writing a lot of named internal factors of the exported
words.  They'd otherwise either be globally visible or else have to be
managed in some messy way with wordlists.

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

#26500

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> PARAGRAPH( foo bar ) \ only foo and bar are visible from this paragraph
>> What is it for?  It looks a bit like private members in C++ or static
>> declarations in C.  I suppose it would save a bit of memory.
> 
> Wasn't thinking about memory.  It's just to control namespace
> pollution resulting from writing a lot of named internal factors of
> the exported words.  They'd otherwise either be globally visible or
> else have to be managed in some messy way with wordlists.

So what if they're globally visible?  It's only an actual problem if
they shadow something else, and as Forth Inc have pointed out it's
easy to fix such things at integration time.  I know that many
languages (Java, C++, etc) freak out about namespace pollution, but do
you know that it's actually something worth worrying about for Forth
programmers?

Andrew.

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

#26501

On Monday, October 14, 2013 11:29:38 AM UTC+2, Andrew Haley wrote:
> So what if they're globally visible? 
> It's only an actual problem if they shadow something else, 
> and as Forth Inc have pointed out it's easy to fix such 
> things at integration time. I know that many languages 
> (Java, C++, etc) freak out about namespace pollution, 
> but do you know that it's actually something worth 
> worrying about for Forth programmers?

As Roelf's posting shows (*), it is an acquired taste. 

I find it useful because it helps to find out how to get 
a piece of code to do its thing (not to find out how it 
works). It also helps to factor out parts that can be 
globally useful. With it, WORDS gives a good overview of 
the structure of a multi-file project.

-marcel

(*) Roelf:  : PRIVATE ; : DEPRIVE ; : PRIVATES ; and your
private life will be public again.

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

#26506

In article <7bb5a6cd-dc3b-46cd-9a4d-5e34a6a4b47f@googlegroups.com>,
 m.a.m.hendrix@tue.nl wrote:

> On Monday, October 14, 2013 11:29:38 AM UTC+2, Andrew Haley wrote:
> > So what if they're globally visible? 
> > It's only an actual problem if they shadow something else, 
> > and as Forth Inc have pointed out it's easy to fix such 
> > things at integration time. I know that many languages 
> > (Java, C++, etc) freak out about namespace pollution, 
> > but do you know that it's actually something worth 
> > worrying about for Forth programmers?
> 
> As Roelf's posting shows (*), it is an acquired taste. 
> 
> I find it useful because it helps to find out how to get 
> a piece of code to do its thing (not to find out how it 
> works). It also helps to factor out parts that can be 
> globally useful.

That's one of the problems an outsider might have. At
times I encounter private words/parts being very useful
globally. I would have factored differently.
 
> With it, WORDS gives a good overview of 
> the structure of a multi-file project.
> 
> -marcel
> 
> (*) Roelf:  : PRIVATE ; : DEPRIVE ; : PRIVATES ; and your
> private life will be public again.

Yes, I know ;-)
And there are other means as well.

BTW, never had a 'shadow' problem in iForth or other
Forth, after making public what was needed.

-roelf

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

#26502

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> So what if they're globally visible?  It's only an actual problem if
> they shadow something else, 

Picking enough new names to prevent shadowing is a problem in its own
right.  I don't think it's really like static functions in C.  It's more
like local variables in C functions.  It's common for C functions to be
a few tens of LOC long and use a number of internal variables.  In Forth
the function is instead split into a half dozen named factors, and those
names start getting cumbersome after a while.  I end up numbering
instead, like foo.1, foo.2 etc. but that's not so descriptive.

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

#26507

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> So what if they're globally visible?  It's only an actual problem if
>> they shadow something else, 
> 
> Picking enough new names to prevent shadowing is a problem in its own
> right.  I don't think it's really like static functions in C.  It's more
> like local variables in C functions.  It's common for C functions to be
> a few tens of LOC long and use a number of internal variables.  In Forth
> the function is instead split into a half dozen named factors, and those
> names start getting cumbersome after a while.  I end up numbering
> instead, like foo.1, foo.2 etc. but that's not so descriptive.

You reuse some names.  As long as they don't shadow something global,
it's not going to be a problem.

IME, this tends to be raised as a problem by users of other languages.
Have you ever encountered such a problem in a Forth program?

Andrew.

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

#26512

On 14/10/2013 15:21, Andrew Haley wrote:
> Paul Rubin <no.email@nospam.invalid> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> So what if they're globally visible?  It's only an actual problem if
>>> they shadow something else,
>>
>> Picking enough new names to prevent shadowing is a problem in its own
>> right.  I don't think it's really like static functions in C.  It's more
>> like local variables in C functions.  It's common for C functions to be
>> a few tens of LOC long and use a number of internal variables.  In Forth
>> the function is instead split into a half dozen named factors, and those
>> names start getting cumbersome after a while.  I end up numbering
>> instead, like foo.1, foo.2 etc. but that's not so descriptive.
>
> You reuse some names.  As long as they don't shadow something global,
> it's not going to be a problem.
>
> IME, this tends to be raised as a problem by users of other languages.
> Have you ever encountered such a problem in a Forth program?
>
Yes! Many times.

I use VFX under Windows where I find that the various display objects 
such as edit boxes, display 'panels' etc. each need to respond to the 
various Windows messages.

One such message is the one informing an application that an object has 
been resized and a word to respond to that message might be DORESIZE 
(say). Each of those objects will respond to that message in a different 
way and I want to identify each object's responses properly.

So I end up with something like:
	editboxRESIZE, winpanelRESIZE, gridRESIZE, listRESIZE etc. You get the 
picture.

Mores recently I use vocabularies/wordlists to separate these words, but 
I often retain a prefix of some sort just to reinforce my intentions.



-- 
Graham Smith

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

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

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

csiph-web