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

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

LatestXT

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

Contents

  LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-09 02:42 +0000
    Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-09 03:43 -0600
      Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-09 13:12 +0000
      Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-09 13:26 +0000
        Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-09 12:41 -0600
          Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 12:24 +0000
            Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 12:04 -0600
              Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 11:02 +0000
                Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-11 12:21 -0600
                  Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-12 17:35 +0000
                    Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-13 05:19 -0600
                      Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-13 15:12 +0000
                        Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-13 11:55 -0600
            Re: LatestXT Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-12-15 16:30 -0800
              Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 17:11 +0000
                Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-16 16:15 -0800
                  Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-17 03:22 -0600
                    Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-17 15:34 +0000
                      Re: LatestXT Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-12-17 08:04 -0800
                        Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-17 17:20 +0000
                          Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-17 12:38 -0600
                            Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-18 04:01 +0000
                              Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-17 22:06 -0800
                                Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-18 11:47 +0000
                                  Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-18 08:51 -0800
                                    Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-19 01:14 +0000
                                      Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-18 18:59 -0800
                              Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-18 04:40 -0600
                                Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-18 11:31 +0000
                                  Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-18 06:21 -0600
                                    Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-18 12:55 +0000
                                      Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-19 03:27 -0600
                          Re: LatestXT Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-12-18 07:21 -0800
                            Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-19 01:02 +0000
                              Re: LatestXT Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-12-18 17:32 -0800
                        Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-17 09:43 -0800
                        Re: LatestXT Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-12-19 20:40 +0000
                    Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-17 09:38 -0800
                      Re: LatestXT Mark Wills <markrobertwills@yahoo.co.uk> - 2011-12-18 01:08 -0800
                        Re: LatestXT Mark Wills <markrobertwills@yahoo.co.uk> - 2011-12-18 01:38 -0800
                          Re: LatestXT Coos Haak <chforth@hccnet.nl> - 2011-12-18 13:13 +0100
                        Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-18 08:55 -0800
        Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-09 09:36 -1000
        Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-10 03:24 +0000
          Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-09 20:12 -0800
          Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-09 18:15 -1000
            Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-10 10:18 +0000
              Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 11:39 +0000
                Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-10 16:31 +0000
                  Re: LatestXT Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-10 23:03 +0100
                    Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-11 02:34 +0000
                      Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-10 18:01 -1000
                        Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-11 09:46 +0000
                          Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-11 03:55 -0600
                            Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-11 11:35 +0000
                              Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-11 10:59 -1000
                                Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 02:19 +0000
                                  Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-11 17:38 -1000
                                    Re: LatestXT Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-12 13:22 +0100
                                  Re: LatestXT stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-12 10:34 +0000
                                    Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 12:32 +0000
                                      Re: LatestXT stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-12 14:55 +0000
                                        Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 16:18 +0000
                                          Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-12 09:09 -0800
                                            Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 17:51 +0000
                                              Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 12:03 -0600
                                              Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-12 10:51 -0800
                                                Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-13 12:16 +0000
                                                  Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-13 15:11 +0000
                                                  Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-13 08:00 -1000
                                          Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-12 18:18 +0000
                              Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-11 13:26 -0800
                              Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 03:51 -0600
                                Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 11:14 +0000
                                  Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 05:37 -0600
                                    Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 12:54 +0000
                          Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-11 11:05 -0800
                            Re: LatestXT Josh Grams <josh@qualdan.com> - 2011-12-11 23:25 +0000
                              Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-11 16:58 -0800
                              Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-12 17:21 +0000
                                Re: LatestXT Josh Grams <josh@qualdan.com> - 2011-12-12 21:50 +0000
                                  Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-13 16:44 +0000
                                    Re: LatestXT Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-13 22:13 +0000
                                Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-13 11:46 +0000
                                  Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-13 04:28 -0800
                                    Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-14 05:40 +0000
                                      Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-13 21:24 -1000
                                      Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 04:05 -0600
                                        Re: LatestXT Mark Wills <markrobertwills@yahoo.co.uk> - 2011-12-20 03:48 -0800
                                          Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-20 08:59 -0600
                            Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 03:21 +0000
                              Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-11 17:52 -1000
                              Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-12 12:41 +0000
                                Re: LatestXT Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-12 15:00 +0100
                              Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-12 09:37 -0800
                        Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 10:43 +0000
                      Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 10:21 +0000
                      Re: LatestXT Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-12 12:58 +0100
                    Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-11 03:35 -0600
                      Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 10:47 +0000
                        Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 03:54 -0600
                          Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-12 17:20 +0000
                            Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 11:53 -0600
                  Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-10 14:21 -0800
                    Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-11 02:37 +0000
                      Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-11 11:13 -0800
                  Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 11:25 +0000
                    Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-11 08:55 -1000
          Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 02:49 -0600
            Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 12:06 +0000
              Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 12:11 -0600
            Re: LatestXT Josh Grams <josh@qualdan.com> - 2011-12-10 12:33 +0000
        Re: LatestXT Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-12-10 18:52 +0000
          Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 10:50 +0000

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

#8017

Anton Ertl wrote: <2011Dec12.182133@mips.complang.tuwien.ac.at>
> Josh Grams <josh@qualdan.com> writes:
>>And in those other systems it is pretty easy to create definitions the
>>ANS way if that's what you want; easier, in fact, than doing it the
>>other way from an ANS system.
>
> Can you give an example of how to do the equivalent of
>
>: myconstant ( n "name" -- )
>  >r : r> postpone literal postpone ; ;
> 5 myconstant foo
> foo .
>
> in a system where : calls a text interpreter?

When this argument came up way back when, someone who was interested in
such systems gave an example showing that there were underlying factors
available which did not invoke the text interpreter.

I couldn't find the actual discussion, sorry.  It was a long time ago,
and Google seems flaky about old newsgroup results...

--Josh

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

#8040

Josh Grams <josh@qualdan.com> writes:
>Anton Ertl wrote: <2011Dec12.182133@mips.complang.tuwien.ac.at>
>> Josh Grams <josh@qualdan.com> writes:
>>>And in those other systems it is pretty easy to create definitions the
>>>ANS way if that's what you want; easier, in fact, than doing it the
>>>other way from an ANS system.
>>
>> Can you give an example of how to do the equivalent of
>>
>>: myconstant ( n "name" -- )
>>  >r : r> postpone literal postpone ; ;
>> 5 myconstant foo
>> foo .
>>
>> in a system where : calls a text interpreter?
>
>When this argument came up way back when, someone who was interested in
>such systems gave an example showing that there were underlying factors
>available which did not invoke the text interpreter.

Ok, so if one just changed the standard to invoke the text interpreter
from : and ], one could not do it in a standard program.  One would
need to standardize additional words.  Ok, with these rules, one might
make the text interpreter available as word in Forth-94, and then you
could easily emulate the other behaviour (in a less brittle way than
my first attempt).

Hmm, maybe we can do it already:

variable inner?  inner? off
variable inner>in 
: ;
  postpone ;
  inner? @ if
    >in @ inner>in !
    12345 throw
  then ; immediate

: inner-text-interpreter ( -- )
  inner? @ >r inner? on
  source >in @ /string 
  ['] evaluate catch dup 12345 = if
     drop 2drop 0 inner>in @ >in +!
  then
  r> inner? !
  throw ;

: :noname-parsing :noname inner-text-interpreter ;
: mdef :noname-parsing :noname-parsing ;
mdef ." bla;" ; ." bli" ;

This does not work, but the idea should be workable.

- 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 2011: http://www.euroforth.org/ef11/

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

#8051

On 13/12/2011 16:44, Anton Ertl wrote:
> Josh Grams<josh@qualdan.com>  writes:
>> Anton Ertl wrote:<2011Dec12.182133@mips.complang.tuwien.ac.at>
>>> Josh Grams<josh@qualdan.com>  writes:
>>>> And in those other systems it is pretty easy to create definitions the
>>>> ANS way if that's what you want; easier, in fact, than doing it the
>>>> other way from an ANS system.
>>>
>>> Can you give an example of how to do the equivalent of
>>>
>>> : myconstant ( n "name" -- )
>>>   >r : r>  postpone literal postpone ; ;
>>> 5 myconstant foo
>>> foo .
>>>
>>> in a system where : calls a text interpreter?
>>
>> When this argument came up way back when, someone who was interested in
>> such systems gave an example showing that there were underlying factors
>> available which did not invoke the text interpreter.
>
> Ok, so if one just changed the standard to invoke the text interpreter
> from : and ], one could not do it in a standard program.  One would
> need to standardize additional words.  Ok, with these rules, one might
> make the text interpreter available as word in Forth-94, and then you
> could easily emulate the other behaviour (in a less brittle way than
> my first attempt).
>
> Hmm, maybe we can do it already:
>
> variable inner?  inner? off
> variable inner>in
> : ;
>    postpone ;
>    inner? @ if
>      >in @ inner>in !
>      12345 throw
>    then ; immediate
>
> : inner-text-interpreter ( -- )
>    inner? @>r inner? on
>    source>in @ /string
>    ['] evaluate catch dup 12345 = if
>       drop 2drop 0 inner>in @>in +!
>    then
>    r>  inner? !
>    throw ;
>
> : :noname-parsing :noname inner-text-interpreter ;
> : mdef :noname-parsing :noname-parsing ;
> mdef ." bla;" ; ." bli" ;
>
> This does not work, but the idea should be workable.
>
> - anton

An intriguing exercise that I couldn't resist. The following works but 
has defects in that the mdef code has to be on one line, like the above, 
and the mdef code can't contain
    POSTPONE ; or ['] ;
These could be redefined in the nonamex-wordlist. Making it multi-line 
would be more difficult.

: >order ( wid -- )
    >r get-order 1+ r> swap set-order
;

wordlist constant nonamex-wordlist

get-current nonamex-wordlist set-current
: ;  >in @ postpone \ ; immediate
set-current

: :nonamex     \ Extended :noname
    nonamex-wordlist >order
    :noname
    source >in @ dup >r /string evaluate
    previous r> + >in ! postpone ;
;

: mdef  :nonamex :nonamex :nonamex ;
mdef  ." reversed" ; ." was " ; ." This " ;

cr cr execute execute execute

-- 
Gerry

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

#8028

On Mon, 12 Dec 2011 17:21:33 +0000, Anton Ertl wrote:

> 
> The mdef example is not particularly hard:
> 
> : parsing-:noname
>   :noname [char] ; parse evaluate postpone ; ;
> : mdef
>   parsing-:noname parsing-:noname ;
> mdef ." foo" ; ." bar" ;
> execute
> execute
> 

mdef ." close;" ; ." but no cigar" ;

Cheers,
Arnold

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

#8030

On Dec 13, 6:46 am, Arnold Doray <thinksqua...@gmail.com> wrote:
> On Mon, 12 Dec 2011 17:21:33 +0000, Anton Ertl wrote:
>
> > The mdef example is not particularly hard:
>
> > : parsing-:noname
> >   :noname [char] ; parse evaluate postpone ; ;
> > : mdef
> >   parsing-:noname parsing-:noname ;
> > mdef ." foo" ; ." bar" ;
> > execute
> > execute
>
> mdef ." close;" ; ." but no cigar" ;

I presume this refers to the brittleness of the implementation (names
beginning with ";", definitions longer than one line)?

Both of those can be dealt with in various ways, but OTOH none of the
examples you've shown requires more than a one-liner, so you haven't
posed a problem that *required* a less brittle solution.

And the solution of pairing the opening word with a closing word
naturally extends to bridge words that close then immediately open
again, to give the same effect without the brittleness of your
*definition*'s hard wiring the number of different definitions to
follow each other without any indication of how many successive
definitions are required. As a dummy:

: my: ( act1here ) :noname ( act2here ) ;
: ;my ( act3here )
   POSTPONE ; ( act4here ) ; IMMEDIATE
: ;my: POSTPONE ;my my: ; IMMEDIATE

my: ." solution" ;my: ." better"
;my: SPACE ;my: CR ;my

EXECUTE SWAP EXECUTE EXECUTE EXECUTE

I don't have time to benchtest that, so tell me if it works.

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

#8055

On Tue, 13 Dec 2011 04:28:34 -0800, BruceMcF wrote:

> On Dec 13, 6:46 am, Arnold Doray <thinksqua...@gmail.com> wrote:
>> On Mon, 12 Dec 2011 17:21:33 +0000, Anton Ertl wrote:
>>
>> > The mdef example is not particularly hard:
>>
>> > : parsing-:noname
>> >   :noname [char] ; parse evaluate postpone ; ;
>> > : mdef
>> >   parsing-:noname parsing-:noname ;
>> > mdef ." foo" ; ." bar" ;
>> > execute
>> > execute
>>
>> mdef ." close;" ; ." but no cigar" ;
> 
> I presume this refers to the brittleness of the implementation (names
> beginning with ";", definitions longer than one line)?
> 

The brittleness is that PARSE needs to know when to stop. Using ; as a 
stop token is what's brittle about Anton's solution. 

> Both of those can be dealt with in various ways, but OTOH none of the
> examples you've shown requires more than a one-liner, so you haven't
> posed a problem that *required* a less brittle solution.
> 

MDEF is a puzzle, like a Sudoku or crossword puzzle. 

But more than just a puzzle, it can pique curiosity, stir interest and 
promote learning. Aren't these goals worthy of a less brittle solution?

IMHO, to be an effective Forth programmer, you need to understand 
*clearly* how these constructs work and how Forth works internally. 

Your collective responses to the MDEF puzzle have helped me understand 
clearly how :NONAME , : , ; the text parser, PARSE , EVALUATE and 
POSTPONE work.  

That's a lot of pedagogical mileage from a single simple example, yes?


> And the solution of pairing the opening word with a closing word
> naturally extends to bridge words that close then immediately open
> again, to give the same effect without the brittleness of your
> *definition*'s hard wiring the number of different definitions to follow
> each other without any indication of how many successive definitions are
> required. As a dummy:
> 
> : my: ( act1here ) :noname ( act2here ) ; : ;my ( act3here )
>    POSTPONE ; ( act4here ) ; IMMEDIATE
> : ;my: POSTPONE ;my my: ; IMMEDIATE
> 
> my: ." solution" ;my: ." better"
> ;my: SPACE ;my: CR ;my
> 
> EXECUTE SWAP EXECUTE EXECUTE EXECUTE
> 
> I don't have time to benchtest that, so tell me if it works.

Yes, this is similar to Stephen's example upthread. It works. 

Cheers,
Arnold

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

#8057

On 12/13/11 7:40 PM, Arnold Doray wrote:
...
> MDEF is a puzzle, like a Sudoku or crossword puzzle.
>
> But more than just a puzzle, it can pique curiosity, stir interest and
> promote learning. Aren't these goals worthy of a less brittle solution?
>
> IMHO, to be an effective Forth programmer, you need to understand
> *clearly* how these constructs work and how Forth works internally.
>
> Your collective responses to the MDEF puzzle have helped me understand
> clearly how :NONAME , : , ; the text parser, PARSE , EVALUATE and
> POSTPONE work.
>
> That's a lot of pedagogical mileage from a single simple example, yes?

I'm glad you've learned a lot.  However, many of the most effective 
Forth programmers I know have little interest in the internal working of 
these things, but they know very well how to use Forth to solve 
real-world application problems, which rarely require this sort of 
arcana. If asked about using multiple :nonames in a definition, they 
just blink and say, "WHY???"

One of the big differences between folks on c.l.f and workaday Forth 
programmers is that the folks here are motivated more by intellectual 
curiosity than by a concern with making code work effectively in the 
project at hand.  God knows I have nothing against intellectual 
curiosity, but it's a very different pov.

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]

#8060

Arnold Doray <thinksquared@gmail.com> wrote:
> 
> MDEF is a puzzle, like a Sudoku or crossword puzzle. 
> 
> But more than just a puzzle, it can pique curiosity, stir interest and 
> promote learning. Aren't these goals worthy of a less brittle solution?
> 
> IMHO, to be an effective Forth programmer, you need to understand 
> *clearly* how these constructs work and how Forth works internally. 

You certainly do not have to know all this arcane internal stuff to be
an effective Forth programmer.

There's a classic syndrome of Forth programmers inventing their own
parsers, syntaxes, and control structures, not for any practical
reason but because they can.  Not everyone suffers from this: some
just learn straightforward Forth and get on with what they really
wanted to do.  Most sufferers eventually get over it, and go back to
straightforward coding.

Extending the language can be really useful, but if you do it
everywhere you'll end up with something that is very hard to maintain.
Think of metaprogramming as being like strong drink or MSG: useful,
but best used in moderation.  Many LISPers tend to think of LISP
macros in the same terms, for much the same reasons.

Andrew.

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

#8240

On Dec 14, 10:05 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
>
> Extending the language can be really useful, but if you do it
> everywhere you'll end up with something that is very hard to maintain.
>

Or a DSL... Just depends on your point of view, I guess ;-)

Back to lurking...

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

#8245

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> On Dec 14, 10:05?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>>
>> Extending the language can be really useful, but if you do it
>> everywhere you'll end up with something that is very hard to maintain.
> 
> Or a DSL...

Or both!  :-)

> Just depends on your point of view, I guess ;-)

Sure.  You can write whole new languages in Forth, and many have.  

Andrew.

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

#7955

On Sun, 11 Dec 2011 11:05:03 -0800, BruceMcF wrote:

> On Dec 11, 4:46 am, Arnold Doray <thinksqua...@gmail.com> wrote:
>> But I still think it's not the best way of doing things. It is much
>> nicer for :NONAME to invoke the text parser before the next word runs.
> 
> You are proposing burning down the village to try to open a locked door.
> What you are proposing is to completely abandon the incremental compiler
> system and convert Forth to an all-interpreted language. The whole
> *point* of the compiled definition is that the words execute *in the
> sequence* that you specify.

Just in case there's a misunderstanding, let me try to describe clearly:

: mdef :noname :noname ; 

Here's what I propose should happen to something like:

mdef ." bingo" ; ." rover" ; 

1) MDEF executes. 

2) The first :NONAME executes, putting <xt1><colon-sys> on the stack and 
switches to compilation state. My proposal is that it also kicks off the 
text parser. 

3) The text parser reads from the input stream. It parses ." bingo" into 
the current XT and terminates at ; because ; is immediate. ; signals an 
end to the parsing and removes <colon-sys> from the stack. 

4) At this point, in ANS forth, the text parsing will continue with 
." rover" and executing it. It then goes on to the next ; giving an error 
since we are now in interpretative state. My proposal is that the text 
parser instead be suspended after the first ; and control passed back to 
the next word to execute. 

5) The next :NONAME executes, steps (2) and (3) are repeated. The stack 
is now <xt1><xt2>.

6) MDEF terminates. 

And the advantages: 

1) All definitions are serialized.  This makes the semantics of :NONAME 
obvious.
   
2) It increases the range of use of :NONAME. For instance, the MDEF would 
work. Currently it does not. 

3) The XT of the :NONAME would be available to definitions following it. 

4) It doesn't break existing code, as far as I can see. 

In fact, as others have pointed out, polyForth behaved this way. If true, 
it's been done in the past. The current forths I've tested, include 
GForth  don't do this. 

It is the "why" I am interested in. There must be a good reason. I 
suspect it's because it involves changing the behaviour of ; to pass 
control to the next word, instead of letting the text parser continue 
(step 4). 

In any case, I don't see how the changes in (2) and (4) convert Forth to 
an "all-interpretative" language as you claim. Could you please elaborate?

Thanks,
Arnold

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

#7957

On 12/11/11 5:21 PM, Arnold Doray wrote:
> On Sun, 11 Dec 2011 11:05:03 -0800, BruceMcF wrote:
>
>> On Dec 11, 4:46 am, Arnold Doray<thinksqua...@gmail.com>  wrote:
>>> But I still think it's not the best way of doing things. It is much
>>> nicer for :NONAME to invoke the text parser before the next word runs.
>>
>> You are proposing burning down the village to try to open a locked door.
>> What you are proposing is to completely abandon the incremental compiler
>> system and convert Forth to an all-interpreted language. The whole
>> *point* of the compiled definition is that the words execute *in the
>> sequence* that you specify.
>
> Just in case there's a misunderstanding, let me try to describe clearly:
>
> : mdef :noname :noname ;
>
> Here's what I propose should happen to something like:
>
> mdef ." bingo" ; ." rover" ;
>
> 1) MDEF executes.
>
> 2) The first :NONAME executes, putting<xt1><colon-sys>  on the stack and
> switches to compilation state. My proposal is that it also kicks off the
> text parser.
>
> 3) The text parser reads from the input stream. It parses ." bingo" into
> the current XT and terminates at ; because ; is immediate. ; signals an
> end to the parsing and removes<colon-sys>  from the stack.
>
> 4) At this point, in ANS forth, the text parsing will continue with
> ." rover" and executing it. It then goes on to the next ; giving an error
> since we are now in interpretative state. My proposal is that the text
> parser instead be suspended after the first ; and control passed back to
> the next word to execute.
>
> 5) The next :NONAME executes, steps (2) and (3) are repeated. The stack
> is now<xt1><xt2>.

I understand what you want. You want the compilation to nest, somehow. 
Do you advocate extending this behavior to : ? Do you understand what 
havoc this can create with optimizing compilers?

> 6) MDEF terminates.
>
> And the advantages:
>
> 1) All definitions are serialized.  This makes the semantics of :NONAME
> obvious.

The semantics of :NONAME are already obvious. They just aren't what you 
want them to be.

> 2) It increases the range of use of :NONAME. For instance, the MDEF would
> work. Currently it does not.
>
> 3) The XT of the :NONAME would be available to definitions following it.

Why would this be better than having named definitions?

> 4) It doesn't break existing code, as far as I can see.

It absolutely does. No system behaves this way. The text interpreter is 
a simple structure, with simple rules.  As soon as you start allowing 
compilation to nest the simplicity of the atomic text interpreter is broken.

> In fact, as others have pointed out, polyForth behaved this way. If true,
> it's been done in the past. The current forths I've tested, include
> GForth  don't do this.

No. polyFORTH had separate compile and interpret loops. It most 
assuredly did not support nested compilation or do what you're talking 
about. And when FORTH, Inc. changed to the current ANS Forth-compatible 
model, it was an improvement on all fronts.

> It is the "why" I am interested in. There must be a good reason. I
> suspect it's because it involves changing the behaviour of ; to pass
> control to the next word, instead of letting the text parser continue
> (step 4).

It involves coupling the text interpreter to compilation in ways that 
open cans of worms that no one wants to deal with.

> In any case, I don't see how the changes in (2) and (4) convert Forth to
> an "all-interpretative" language as you claim. Could you please elaborate?

I would not use that term, but I assure you it's a significant change 
whose benefit is unclear and whose consequences are unattractive.

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]

#7980

Arnold Doray <thinksquared@gmail.com> writes:
>2) It increases the range of use of :NONAME. For instance, the MDEF would 
>work. Currently it does not. 

And other things wouldn't work.  That's not an increase, it's a shift.

>3) The XT of the :NONAME would be available to definitions following it. 

It is.

>4) It doesn't break existing code, as far as I can see. 

Sure it does.  Bernd Paysan presented one example:

: myconstant ( n "name" -- )
  >r : r> postpone literal postpone ; ;
5 myconstant foo
foo .

If : invoked the text interpreter, as you desire, this would result in
a "undefined" word error at the second occurence of FOO instead of the
intended behaviour of definining a colon definition equivalent to

: foo 5 ;

and then executing it and printing the result.

>In fact, as others have pointed out, polyForth behaved this way. If true, 
>it's been done in the past. The current forths I've tested, include 
>GForth  don't do this. 
>
>It is the "why" I am interested in.

It's non-standard.  Why is it non-standard?  There may be something in
the standard that discusses the reasons, but I do not find it at the
moment.  Anyway, the standardized approach certainly had been widely
practiced in systems such as fig-Forth, and apparently the committee
felt that the benefits to programs of standardizing it outweighed the
benefits to systems on not standardizing it.  As someone who makes use
of this feature in my programs, I think that was the right decision.

- 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 2011: http://www.euroforth.org/ef11/

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

#7986

Anton Ertl wrote:
> It's non-standard.  Why is it non-standard?  There may be something in
> the standard that discusses the reasons, but I do not find it at the
> moment.  Anyway, the standardized approach certainly had been widely
> practiced in systems such as fig-Forth, and apparently the committee
> felt that the benefits to programs of standardizing it outweighed the
> benefits to systems on not standardizing it.  As someone who makes use
> of this feature in my programs, I think that was the right decision.

It's about meta-programming, about using macros.  You should be able to 
mix :noname and postpone in one definition, to create further 
definitions without resorting to string manipulations and evaluate.

Hugh Aguilar fortunately is quiet ATM, but he proposed :name for even 
more meta-programming, since : is parsing, and when you want to meta-
program, you probably also don't want the name of the function to be 
parsed from the input stream.  His :name proposal failed, since it 
solves the problem only for one word (colon), and Anton suggested 
execute-parsing as more general solution.

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

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

#7999

On Dec 11, 10:21 pm, Arnold Doray <thinksqua...@gmail.com> wrote:

> : mdef :noname :noname ;

> Here's what I propose should happen to something like:

> mdef ." bingo" ; ." rover" ;

> 1) MDEF executes.

> 2) The first :NONAME executes, putting <xt1><colon-sys> on the stack and
> switches to compilation state. My proposal is that it also kicks off the
> text parser.

How do you make it *not* kick off the text parser, when you want to
*keep executing stuff* and have the text interpreter naturally start
compiling because its in compiler state? By making the kicking off of
the text parser automatic instead of manual
   ... ' EXECUTE ...
   ... [CHAR] ; PARSE EVALUATE POSTPONE ; ...

... you complicate the entire system, requiring some kind of mode
variable to *prevent* the compilation state from firing off when you
don't want it to.

All to avoid:

: mdef: dostuff :noname ;
: ;mdef POSTPONE ; domorestuff ; IMMEDIATE

mdef: ." bingo" ;mdef
mdef: ." rover" ;mdef

> 1) All definitions are serialized.  This makes the semantics of :NONAME
> obvious.

The semantics of :NONAME is already obvious to someone who is used to
Forth but has never seen :NONAME before.

> 2) It increases the range of use of :NONAME. For instance, the MDEF would work. Currently it does not.

Preventing one thing and allowing another is not an increase in the
range, its a shift in the range. You have not said anything that makes
the shift in the range look attractive to me. Losing the ability to
build the start of a definition (whether named or unnamed, if as I
presume, for consistency the same change is done to ":") and then
allow the existing built-in compiler to finish it is far more lost
than the ability to define definition initiators that require an
arbitrary number of definitions before I can escape back to
interpretation mode.

> 3) The XT of the :NONAME would be available to definitions following it.

All you need is a close definition word corresponding to your start
definition word to grab the XT when it is available. So it seems like
this is about a reluctance to define a set of words as opposed to a
single word.

> 4) It doesn't break existing code, as far as I can see.

Either you are making :NONAME inconsistent with : or else it causes
code breakage of a word as simple as pass:
   : pass: >R : R> ;

Under your proposal, the literal that has been passed is no longer on
the stack at the start of compilation, because compilation proceeds
from ":" until the definition is completed, and "then" the literal is
put on the stack.

Changing the timing of execution of every word with a : or a :NONAME
compiled into it *and then followed by additional code*, which at
present is performed *before* the following definition and under your
proposal would now happen *after* the following definition ...
obviously that is going to cause code breakage.

> It is the "why" I am interested in. There must be a good reason. I
> suspect it's because it involves changing the behaviour of ; to pass
> control to the next word, instead of letting the text parser continue
> (step 4).

> In any case, I don't see how the changes in (2) and (4) convert Forth to an "all-interpretative" language as you claim. Could you please elaborate?

I hadn't made sense of precisely what you were asking for.

You are asking for :noname to, in effect, contain the compiler, rather
than switch the state of the two-state interpreter/compiler. That is a
fundamental design decision. The changes that it entails would cause
code breakage, all over the place. Its not a "modification" of
Forth94, but rather the start of specifying an entirely distinct
family of Forth.

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

#7931

"Elizabeth D. Rather" <erather@forth.com> writes:
>It drove people nuts.  Suppose you typed:
>
>: foo  ( -- ) doors 0 do
>
>...and then thought to yourself, wait a minute, what's the value of 
>doors again? So you type:
>
>doors .
>
>...You will then be very confused because the system just says, "ok" 
>without executing doors and . because what has happened is that the 
>compiler kept right on compiling the definition foo including a 
>reference to doors and . and is still compiling, and will continue until 
>you type ; or an error occurs.
>
>It seemed nice at the time, but caused a lot of trouble.

I don't see the difference between the Forth-94 behaviour and the
PolyForth behaviour here.

- 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 2011: http://www.euroforth.org/ef11/

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

#7929

Arnold Doray <thinksquared@gmail.com> writes:
>On Sat, 10 Dec 2011 23:03:46 +0100, Bernd Paysan wrote:
>When TEST executes, it executes :NONAME first, which puts the colon-sys 
>on the stack and switches over to *compilation* state. This is crystal 
>clear from the '94 Spec. Yes, I know the colon-sys is implementation 
>dependent. Also clear from the spec. 
>
>The issue I have is that now forth is in *compilation* state. Shouldn't 
>the text parser parse the input stream *immediately*, before moving on to 
>the next word in TEST? 

No.  Compilation state is just a state of a variable.  It just
modifies the behaviour of words that read the variable, in particular
the text interpreter.  But the word that's currently running is TEST,
and this word does not change what it does depending on STATE.  So it
continues, performing .S and then the run-time semantics of ";".  The
latter returns execution to the text interpreter, which then performs
the compilation semantics of the words in the input stream.

>As an analogy, the words [ and ] immediately switch the forth between 
>interpretative and compilation states.

They also just change the state, and they change it when they are
executed (in particular, ] is not immediate, and [ can be POSTPONEd or
ticked).  The effect of this state change also only affects words that
read the state, in particular the text interpreter.

- 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 2011: http://www.euroforth.org/ef11/

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

#7974

Arnold Doray wrote:
> When TEST executes, it executes :NONAME first, which puts the
> colon-sys on the stack and switches over to compilation state. This is
> crystal clear from the '94 Spec. Yes, I know the colon-sys is
> implementation dependent. Also clear from the spec.
> 
> The issue I have is that now forth is in compilation state. Shouldn't
> the text parser parse the input stream *immediately*, before moving on
> to the next word in TEST?

No.  It is in compilation state, but the text parser now has called 
TEST, and waits for TEST to return.  Once TEST returns, the text parser 
will parse the next word, and, since it is in compilation state now, 
compile it, and repeat (parse another word, compile it, etc.).

:NONAME is not calling the text parser.

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

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

#7924

Bernd Paysan <bernd.paysan@gmx.de> wrote:

> IIRC, PolyForth had it the way you [Arnold Doray] expect it - : and
> ] just started another parsing loop, but this eliminates some
> possibilities.  E.g. I can write CONSTANT without CREATE DOES> that
> way:
> 
> : Constant  >r  : r> postpone literal postpone ; ;

polyFORTH could (can?) do that too, just a different way:

: CONSTANT   CREATE  colon USE  COMPILE LITERAL  COMPILE ; ;

... which I think I prefer, really.

Andrew.

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

#7932

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>
>> IIRC, PolyForth had it the way you [Arnold Doray] expect it - : and
>> ] just started another parsing loop, but this eliminates some
>> possibilities.  E.g. I can write CONSTANT without CREATE DOES> that
>> way:
>> 
>> : Constant  >r  : r> postpone literal postpone ; ;
>
>polyFORTH could (can?) do that too, just a different way:
>
>: CONSTANT   CREATE  colon USE  COMPILE LITERAL  COMPILE ; ;

Not

: CONSTANT   CREATE  colon USE  [COMPILE] LITERAL  [COMPILE] ; ;

?

The COMPILE I know does not parse and is not very appropriate for most
immediate words.  But then I don't know PolyForth.

- 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 2011: http://www.euroforth.org/ef11/

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

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

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

csiph-web