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

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

Re: local variable

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: local variable hughaguilar96@gmail.com - 2015-07-04 19:52 -0700
    Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 07:24 +0100
      Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 02:04 -0700
        Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 10:36 +0100
          Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 03:25 -0700
            Re: local variable Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-05 15:28 +0200
              Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 08:11 -0700
                Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 08:21 -0700
                  Re: local variable Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-05 23:53 +0200
                    Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 20:31 -0700
              Re: local variable hughaguilar96@gmail.com - 2015-07-05 19:56 -0700
          Re: local variable hughaguilar96@gmail.com - 2015-07-05 19:57 -0700
            Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-07-06 08:09 +0100
              Re: local variable hughaguilar96@gmail.com - 2015-07-06 19:59 -0700
                Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-07-07 08:30 +0100
                  Re: local variable Michael Barry <barrym95838@yahoo.com> - 2015-07-10 00:35 -0700
                    Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-10 01:41 -0700
                      Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-07-10 13:55 +0100
                        Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-10 07:13 -0700
                          Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-07-10 16:29 +0100
                            Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-10 08:57 -0700
                              Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-07-10 17:48 +0100
                                Re: local variable Paul Rubin <no.email@nospam.invalid> - 2015-07-10 10:02 -0700
                                  Re: local variable "WJ" <w_a_x_man@yahoo.com> - 2015-09-16 17:30 +0000
                                Re: local variable Mark Wills <markwills1970@gmail.com> - 2015-07-10 10:28 -0700
                                  Re: local variable "Elizabeth D. Rather" <erather@forth.com> - 2015-07-10 08:00 -1000
                                    Re: local variable hughaguilar96@gmail.com - 2015-07-10 21:31 -0700
                                  Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-07-10 19:13 +0100
                                    Re: local variable "Elizabeth D. Rather" <erather@forth.com> - 2015-07-10 09:06 -1000
                                      Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-11 14:10 +0000
                                        Re: local variable humptydumpty <ouatubi@gmail.com> - 2015-07-11 10:14 -0700
                                          Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-12 15:56 +0000
                                            Re: local variable humptydumpty <ouatubi@gmail.com> - 2015-07-12 11:48 -0700
                                Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-10 21:21 -0700
                                  Re: local variable hughaguilar96@gmail.com - 2015-07-10 21:56 -0700
                                  Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-07-11 23:51 +0100
                                Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-11 13:42 +0000
                                  Re: local variable franck.bensusan@gmail.com - 2015-07-12 02:17 -0700
                                    Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-12 15:12 +0000
                                      Re: local variable franck.bensusan@gmail.com - 2015-07-13 02:37 -0700
                                        Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-13 16:13 +0000
                                          Re: local variable franck.bensusan@gmail.com - 2015-07-13 14:48 -0700
                                            Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-14 06:41 +0000
                                              Re: local variable franck.bensusan@gmail.com - 2015-07-14 01:44 -0700
                            Re: local variable Bernd Linsel <bl1@gmx.com> - 2015-07-11 11:03 +0200
                              Re: local variable Bernd Linsel <bl1@gmx.com> - 2015-07-11 11:11 +0200
                                Re: local variable hughaguilar96@gmail.com - 2015-07-12 16:43 -0700
                              Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-11 15:14 +0000
                                Re: local variable Julian Fondren <julian.fondren@gmail.com> - 2015-07-11 17:57 -0700
                                  Re: local variable anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-12 15:32 +0000
                    Re: local variable "Alex McDonald" <blog@rivadpm.com> - 2015-07-10 13:13 +0100
                  Re: local variable hughaguilar96@gmail.com - 2015-07-10 21:48 -0700
        Re: local variable franck.bensusan@gmail.com - 2015-07-05 03:47 -0700
          Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 04:15 -0700
            Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 04:27 -0700
              Re: local variable Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 04:39 -0700
            Re: local variable franck.bensusan@gmail.com - 2015-07-05 07:08 -0700

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

#40495

> What is a static language or a dynamic language? They are terms I'm
> unfamiliar with, unless you mean static vs dynamic typing, which is not
> what we're taking about here. The discussion is about quotations in
> relation to name scope and closure-like behaviour.
> 
A dynamic language is a language that needs a garbage collector.

> > 
> > The fact is that Gforth doesn't have what I and Hugh have, quotations
> > which can "see" locals of an outer level. Probably Hugh is proud of
> > that and calls his quotations "real". "Real" or "not real" but
> > definetely better.
> 
> Why better? Do you have a use case you can show? I also support this
> feature, but I haven't found a use for it.

It's about high order words (like "map", "filter", "apply", etc. see Oforth, see Factor) in strong relation with data structures. 

What I'm trying to achieve is to have a as much as possible a classical forth 
system but with support for general purpose data structures and high 
order words + quotations at a level that will not require a garbage
collector.

Something like a "static" Oforth or a "static" Factor. :-D

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

#40496

on 10/07/2015 16:57:56, Raimond Dragomir wrote:
> 
>> What is a static language or a dynamic language? They are terms I'm
>> unfamiliar with, unless you mean static vs dynamic typing, which is not
>> what we're taking about here. The discussion is about quotations in
>> relation to name scope and closure-like behaviour.
>>
> A dynamic language is a language that needs a garbage collector.

C++ has closures but no GC
http://www.cprogramming.com/c++11/c++11-lambda-closures.html, and the
same is true of Rust http://doc.rust-lang.org/book/README.html.

> 
>> >
>> > The fact is that Gforth doesn't have what I and Hugh have, quotations
>> > which can "see" locals of an outer level. Probably Hugh is proud of
>> > that and calls his quotations "real". "Real" or "not real" but
>> > definetely better.
>>
>> Why better? Do you have a use case you can show? I also support this
>> feature, but I haven't found a use for it.
> 
> It's about high order words (like "map", "filter", "apply", etc. see
> Oforth, see Factor) in strong relation with data structures.

I get that, but I was wondering what the benefit of using outer locals in
quotations might be.

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

#40497

"Alex McDonald" <blog@rivadpm.com> writes:
> C++ has closures but no GC
> http://www.cprogramming.com/c++11/c++11-lambda-closures.html, and the
> same is true of Rust http://doc.rust-lang.org/book/README.html.

Yes but I think Lisp programmers would look at that and groan.
Traditionally such closures are allocated on the heap and garbage
collected, because of the upward funarg problem:
   https://en.wikipedia.org/wiki/Funarg_problem

> I get that, but I was wondering what the benefit of using outer locals
> in quotations might be.

Here's a Python example:

    def square(x): return x*x
    def double(x): return x*2

    def compose(f,g):
        def c(x): return f(g(x))  # <--- uses outer locals
        return c  # <---- c uses upward funargs

    double_square = compose(double, square)

    print(double_square(3))    # prints 18 which is 2*(3*3)

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

#42035

Paul Rubin wrote:

> > I was wondering what the benefit of using outer locals
> > in quotations might be.
> 
> Here's a Python example:
> 
>     def square(x): return x*x
>     def double(x): return x*2
> 
>     def compose(f,g):
>         def c(x): return f(g(x))  # <--- uses outer locals
>         return c  # <---- c uses upward funargs
> 
>     double_square = compose(double, square)
> 
>     print(double_square(3))    # prints 18 which is 2*(3*3)


Oforth:

: square { dup * }
: double { 2 * }

: compose(f, g) { #[ g perform f perform ] }

compose( #double, #square ) Constant new: double-square

3 double-square perform .

18 ok

-- 
The report card by the American Society of Civil Engineers showed the national
infrastructure a single grade above failure, a step from declining to the point
where everyday things simply stop working the way people expect them to. ---
washingtonpost.com/local/trafficandcommuting/us-infrastructure-gets-d-in-annual-report/2013/03/19/c48cb010-900b-11e2-9cfd-36d6c9b5d7ad_story.html

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

#40498

I was wondering what the benefit of quotations might be. They seem rather pointless to me. "Me too" features. 

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

#40501

On 7/10/15 7:28 AM, Mark Wills wrote:
> I was wondering what the benefit of quotations might be. They seem rather pointless to me. "Me too" features.
>

Yes. I've asked that in the past, and the answers so far have been 
unpersuasive.

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]

#40513

On Friday, July 10, 2015 at 11:00:23 AM UTC-7, Elizabeth D. Rather wrote:
> On 7/10/15 7:28 AM, Mark Wills wrote:
> > I was wondering what the benefit of quotations might be. They seem rather pointless to me. "Me too" features.
> >
> 
> Yes. I've asked that in the past, and the answers so far have been 
> unpersuasive.
> 
> Cheers,
> Elizabeth

The purpose of quotations, insofar as LOTD, is to allow people to write general-purpose data-structures. The idea is that the code-library writer writes a higher-order function that traverses the data-structure and executes a quotation for every node. The quotation is able to communicate with its parent function because it has access to the parent function's local variables. 

If a bar-feature higher-order function is used, then the quotation can communicate with the parent function via the stack --- bar-feature higher-order functions are more complicated to write (they have to be written in assembly-language rather than in LOTD) and they tend to be slower because they are pushing all of their internal data to the return-stack every time they execute the quotation to get it off the data-stack and out of the way --- bar-feature higher-order functions can be convenient an efficient in some simple cases (linked lists), but it is idiomatic in LOTD to communicate via the parent function's local variables as this is can be written in LOTD rather than assembly-language, it makes for cleaner and more readable code, and in many cases is more efficient (especially with more complicated data-structures and/or more complicated quotations).

In the document (section-17) I quote you:
Does "*every* application" you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your "general-purpose" structure.

I think the reason why you find quotations to be "unpersuasive" is because you are actively trying to prevent general-purpose data-structures from being written in Forth. Forth has such a bad reputation because of you that I changed the name of my language to LOTD (Language Of The Damned). For example, over here (https://embdev.net/topic/370139#4181561) I mentioned my design and I only got one response: "Bytecode stuff is interesting, but eventually people will care about robustness and how easy they can achieve their goal. Programming aspects DO count, and you'll get very little attention from the industry by using Forth.." 

ANS-Forth has ruined Forth's reputation --- nobody wants to read anything new about Forth, because they assume that they already know everything there is to know about Forth from their study of ANS-Forth, and they believe that the Forth community is totally ignorant of how to write general-purpose reusable code-libraries.

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

#40502

on 10/07/2015 18:28:48, Mark Wills wrote:
> I was wondering what the benefit of quotations might be. They seem
> rather pointless to me. "Me too" features.
> 

.. [: refill drop interpreter ;] catch ...

This is part of QUIT. It could have been

: quit-interpret refill drop interpreter ;

.. ['] quit-interpreter catch ...

I believe quotations to be clearer. They're also very simple to
implement.

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

#40504

On 7/10/15 8:13 AM, Alex McDonald wrote:
> on 10/07/2015 18:28:48, Mark Wills wrote:
>> I was wondering what the benefit of quotations might be. They seem
>> rather pointless to me. "Me too" features.
>>
>
> .. [: refill drop interpreter ;] catch ...
>
> This is part of QUIT. It could have been
>
> : quit-interpret refill drop interpreter ;
>
> .. ['] quit-interpreter catch ...
>
> I believe quotations to be clearer. They're also very simple to
> implement.
>

Clarity is in the eye of the beholder. In my experience, the thing 
you're most likely to want to CATCH is a lot more complicated than this 
example, and deserves to be its own definition.

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]

#40524

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 7/10/15 8:13 AM, Alex McDonald wrote:
>> on 10/07/2015 18:28:48, Mark Wills wrote:
>>> I was wondering what the benefit of quotations might be. They seem
>>> rather pointless to me. "Me too" features.
>>>
>>
>> .. [: refill drop interpreter ;] catch ...
>>
>> This is part of QUIT. It could have been
>>
>> : quit-interpret refill drop interpreter ;
>>
>> .. ['] quit-interpreter catch ...
>>
>> I believe quotations to be clearer. They're also very simple to
>> implement.
>>
>
>Clarity is in the eye of the beholder. In my experience, the thing 
>you're most likely to want to CATCH is a lot more complicated than this 
>example, and deserves to be its own definition.

In my experience, there are quite a few cases where the dfinition you
want to pass to CATCH is quite short.  Even if it does a lot of
things, these may be bundled in words that are useful factors on their
own, making the thing that you pass to CATCH a one-off definition
containing 2-3 words, as in the example above.

And it's not just CATCH.  For lack of quotations, Forthers have used
various tricks (such as return-address manipulation) to allow them to
avoid having to write a separate definition.  I don't use this stuff
myself, so I don't find examples easily, but I have seen these
techniques used a lot in Forth.

And there is one such word even in the standard: DOES>.  A cleaner
variant would have been ( xt ) SET-DOES>, but it would have required
creating an additional named colon definition for the stuff that's now
behind DOES>; e.g., instead of 

: +field ( "name" n -- )
  create ,
does> ( addr1 -- addr2 )
  @ + ;

one would have to define

: (+field) ( addr1 -- addr2 )
  @ + ;
: +field  ( "name" n -- )
  create , ['] (+field) set-does> ;

Apparently the code after DOES> did not deserve its own definition.
Let's look at a variant of that from real code:

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

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

: create-field ( align1 offset1 align size "name" --  align2 offset2 )
    ...

: 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 ;

Here the mechanics of DOES> forced us to factor at least one of the
DOES> out, and for clarity, I factored both out.  People have been
confused by this code, because it does not follow the usual pattern of
DOES> usage.  Here's a version that uses quotations and SET-DOES>:

: create-field ( align1 offset1 align size "name" --  align2 offset2 )
    ...

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

Of course, if you think that the quotations deserve their own
definition, you are free to factor it out, and you are free to take
any other factoring decision.  Quotations and SET-DOES> allow you to
perform factoring as appropriate for the code at hand, instead of
forcing some particular, possibly inappropriate factoring decisions.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#40530

On Saturday, July 11, 2015 at 5:49:26 PM UTC+3, Anton Ertl wrote:
> "Elizabeth D. Rather" <> writes:
> >On 7/10/15 8:13 AM, Alex McDonald wrote:
> >> on 10/07/2015 18:28:48, Mark Wills wrote:
> >>> I was wondering what the benefit of quotations might be. They seem
> >>> rather pointless to me. "Me too" features.
> >>>
> >>
> >> .. [: refill drop interpreter ;] catch ...
> >>
> >> This is part of QUIT. It could have been
> >>
> >> : quit-interpret refill drop interpreter ;
> >>
> >> .. ['] quit-interpreter catch ...
> >>
> >> I believe quotations to be clearer. They're also very simple to
> >> implement.
> >>
> >
> >Clarity is in the eye of the beholder. In my experience, the thing 
> >you're most likely to want to CATCH is a lot more complicated than this 
> >example, and deserves to be its own definition.
> 
> In my experience, there are quite a few cases where the dfinition you
> want to pass to CATCH is quite short.  Even if it does a lot of
> things, these may be bundled in words that are useful factors on their
> own, making the thing that you pass to CATCH a one-off definition
> containing 2-3 words, as in the example above.
> 
> And it's not just CATCH.  For lack of quotations, Forthers have used
> various tricks (such as return-address manipulation) to allow them to
> avoid having to write a separate definition.  I don't use this stuff
> myself, so I don't find examples easily, but I have seen these
> techniques used a lot in Forth.
> 
> And there is one such word even in the standard: DOES>.  A cleaner
> variant would have been ( xt ) SET-DOES>, but it would have required
> creating an additional named colon definition for the stuff that's now
> behind DOES>; e.g., instead of 
> 
> : +field ( "name" n -- )
>   create ,
> does> ( addr1 -- addr2 )
>   @ + ;
> 
> one would have to define
> 
> : (+field) ( addr1 -- addr2 )
>   @ + ;
> : +field  ( "name" n -- )
>   create , ['] (+field) set-does> ;
> 
> Apparently the code after DOES> did not deserve its own definition.
> Let's look at a variant of that from real code:
> 
> : dofield ( -- )
> does> ( name execution: addr1 -- addr2 )
>     @ + ;
> 
> : dozerofield ( -- )
>     immediate
> does> ( name execution: -- )
>     drop ;
> 
> : create-field ( align1 offset1 align size "name" --  align2 offset2 )
>     ...
> 
> : 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 ;
> 
> Here the mechanics of DOES> forced us to factor at least one of the
> DOES> out, and for clarity, I factored both out.  People have been
> confused by this code, because it does not follow the usual pattern of
> DOES> usage.  Here's a version that uses quotations and SET-DOES>:
> 
> : create-field ( align1 offset1 align size "name" --  align2 offset2 )
>     ...
> 
> : field ( align1 offset1 align size "name" --  align2 offset2 )
>     2 pick >r
>     create-field
>     r> if
>       [: @ + ;]
>     else
>       immediate [: drop ;]
>     then
>     set-does> ;
> 
> Of course, if you think that the quotations deserve their own
> definition, you are free to factor it out, and you are free to take
> any other factoring decision.  Quotations and SET-DOES> allow you to
> perform factoring as appropriate for the code at hand, instead of
> forcing some particular, possibly inappropriate factoring decisions.
> 
> - 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

Hi!

> 
> And it's not just CATCH.  For lack of quotations, Forthers have used
> various tricks (such as return-address manipulation) to allow them to
> avoid having to write a separate definition.  I don't use this stuff
> myself, so I don't find examples easily, but I have seen these
> techniques used a lot in Forth.
> 

Count macros too into this tricks, like this for traversing wordlists
(quickly tested on gforth-07.3):


: ]wordlist     ( ctime: ca u --  ;rtime: name-token -- name-token
                ;compile code described in STRING of stack effect at run-time)
        ] 2>R
        ]] cell+ BEGIN @ dup WHILE [[   \ pre-code
        2R> evaluate
        ]] REPEAT [[                    \ post-code
; immediate


\ example:

: mywords       ( ca u wid --  ;till wordname STRING print WID wordlist names ) 
        [   S\" ( ca u name-token )  dup 2over rot name>string compare WHILE dup name>string type 2 spaces"
        ]wordlist THEN drop 2drop
;

S" tuck" get-current mywords
S" xlerb" get-current mywords


I do not understand that need for quotations.

Have a nice day,
humptydumpty

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

#40551

humptydumpty <ouatubi@gmail.com> writes:
>Count macros too into this tricks, like this for traversing wordlists
>(quickly tested on gforth-07.3):
>
>
>: ]wordlist     ( ctime: ca u --  ;rtime: name-token -- name-token
>                ;compile code described in STRING of stack effect at run-time)
>        ] 2>R
>        ]] cell+ BEGIN @ dup WHILE [[   \ pre-code
>        2R> evaluate
>        ]] REPEAT [[                    \ post-code
>; immediate
>
>
>\ example:
>
>: mywords       ( ca u wid --  ;till wordname STRING print WID wordlist names ) 
>        [   S\" ( ca u name-token )  dup 2over rot name>string compare WHILE dup name>string type 2 spaces"
>        ]wordlist THEN drop 2drop
>;
>
>S" tuck" get-current mywords
>S" xlerb" get-current mywords
>
>
>I do not understand that need for quotations.

If you have a word that takes an xt (e.g., CATCH), you either need a
separate definition, or quotations.  So quotations allow you to
integrate such words in a macro (if you want).

Concerning your example, while it uses EVALUATE properly (unlike,
e.g., Wil Baden's EVALUATE-based macros), the use of EVALUATE is
unnecessary here:

: wordlist< ]] cell+ BEGIN @ dup WHILE [[ ; immediate
: >wordlist ]] REPEAT [[ ; immediate

: mywords 
  wordlist<
    dup 2over rot name>string compare WHILE dup name>string type 2 spaces
    >wordlist THEN
  drop 2drop ;

BTW, note that TRAVERSE-WORDLIST is in Forth-2012.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#40553

On Sunday, July 12, 2015 at 7:12:08 PM UTC+3, Anton Ertl wrote:
> humptydumpty <> writes:
> >Count macros too into this tricks, like this for traversing wordlists
> >(quickly tested on gforth-07.3):
> >
> >
> >: ]wordlist     ( ctime: ca u --  ;rtime: name-token -- name-token
> >                ;compile code described in STRING of stack effect at run-time)
> >        ] 2>R
> >        ]] cell+ BEGIN @ dup WHILE [[   \ pre-code
> >        2R> evaluate
> >        ]] REPEAT [[                    \ post-code
> >; immediate
> >
> >
> >\ example:
> >
> >: mywords       ( ca u wid --  ;till wordname STRING print WID wordlist names ) 
> >        [   S\" ( ca u name-token )  dup 2over rot name>string compare WHILE dup name>string type 2 spaces"
> >        ]wordlist THEN drop 2drop
> >;
> >
> >S" tuck" get-current mywords
> >S" xlerb" get-current mywords
> >
> >
> >I do not understand that need for quotations.
> 
> If you have a word that takes an xt (e.g., CATCH), you either need a
> separate definition, or quotations.  So quotations allow you to
> integrate such words in a macro (if you want).
> 
> Concerning your example, while it uses EVALUATE properly (unlike,
> e.g., Wil Baden's EVALUATE-based macros), the use of EVALUATE is
> unnecessary here:
> 
> : wordlist< ]] cell+ BEGIN @ dup WHILE [[ ; immediate
> : >wordlist ]] REPEAT [[ ; immediate
> 
> : mywords 
>   wordlist<
>     dup 2over rot name>string compare WHILE dup name>string type 2 spaces
>     >wordlist THEN
>   drop 2drop ;
> 
> BTW, note that TRAVERSE-WORDLIST is in Forth-2012.
> 
> - 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

Thank you!

Have a nice day,
humptydumpty

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

#40512

> > A dynamic language is a language that needs a garbage collector.
> 
> C++ has closures but no GC
> http://www.cprogramming.com/c++11/c++11-lambda-closures.html, and the
> same is true of Rust http://doc.rust-lang.org/book/README.html.
> 
And your point is...? Did I say that a dynamic language is the one having
closures or lambda functions? Did I say that having quotations you need
a dynamic language? Did I say that C++ is a dynamic language?

> > 
> >> >
> >> > The fact is that Gforth doesn't have what I and Hugh have, quotations
> >> > which can "see" locals of an outer level. Probably Hugh is proud of
> >> > that and calls his quotations "real". "Real" or "not real" but
> >> > definetely better.
> >>
> >> Why better? Do you have a use case you can show? I also support this
> >> feature, but I haven't found a use for it.
> > 
> > It's about high order words (like "map", "filter", "apply", etc. see
> > Oforth, see Factor) in strong relation with data structures.
> 
> I get that, but I was wondering what the benefit of using outer locals in
> quotations might be.

Comunicating or sharing state info between the levels. Basically it's all
about local variables, and I know, in forth this is kind of a shame to use
locals.

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

#40515

On Friday, July 10, 2015 at 9:21:45 PM UTC-7, Raimond Dragomir wrote:
> > > A dynamic language is a language that needs a garbage collector.
> > 
> > C++ has closures but no GC
> > http://www.cprogramming.com/c++11/c++11-lambda-closures.html, and the
> > same is true of Rust http://doc.rust-lang.org/book/README.html.
> > 
> And your point is...? Did I say that a dynamic language is the one having
> closures or lambda functions? Did I say that having quotations you need
> a dynamic language? Did I say that C++ is a dynamic language?

So far, Raimond is the only person on comp.lang.forth who has understood LOTD --- now we see poor Raimond getting his words twisted by Alex the word-twister --- and predictably Raimond gets frustrated and angry, which is Alex's greatest delight (what Alex refers to as a "slam dunk").

This seems to be the standard strategy of the ANS-Forth cult --- twist everybody else's words and tell blatant lies about them to make them appear stupid --- I don't think the ANS-Forth cult is fooling anybody; I think the Forth community is ignored in the real world because everybody is on to your tricks.

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

#40540

on 11/07/2015 05:21:41, Raimond Dragomir wrote:
>> > A dynamic language is a language that needs a garbage collector.
>>
>> C++ has closures but no GC
>> http://www.cprogramming.com/c++11/c++11-lambda-closures.html, and the
>> same is true of Rust http://doc.rust-lang.org/book/README.html.
>>
> And your point is...? Did I say that a dynamic language is the one
> having closures or lambda functions? Did I say that having quotations
> you need a dynamic language? Did I say that C++ is a dynamic language?

I'm sorry, I thought you might be interested. My bad.

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

#40522

"Alex McDonald" <blog@rivadpm.com> writes:
>C++ has closures but no GC
>http://www.cprogramming.com/c++11/c++11-lambda-closures.html

They are not fully capable closures, although C++ tries to give you as
much as is possible without requiring GC; the section "How are Lambda
Closures Implemented?" are most enlightening in this respect: So you
can capture referenced variables by-reference (i.e., you access the
original variable through a pointer), but then you must not pass the
lambda outside the scope(s) of the captured variables; or you can
capture the variable by making a copy, then any changes to the
captured variable do not affect the original or any other lamda that
also captures the original variable.

Both options fall short of the power of full-blown closures; e.g., you
cannot implement objects based on C++ lambdas, which you can do with
full-blown closures.

Both options have been proposed as ways to allow outer locals in
Forth.  I think we will have to see whether these options give enough
benefit to justify their implementation cost.

>> It's about high order words (like "map", "filter", "apply", etc. see
>> Oforth, see Factor) in strong relation with data structures.
>
>I get that, but I was wondering what the benefit of using outer locals in
>quotations might be.

If the higher-order word calls a word with the stack effect n1 -- n2,
and you want to pass additional arguments, it would be nice if you
could pass these arguments through a local variable; e.g.

( addr u ) [: n + ;] foreach 

Bernd Paysan thinks we don't need that, and that we can use the stack
for passing additional stuff; so here we would do it as follows:

n ( addr u ) [: over + ;] foreach drop

I am not convinced that this is good enough in every case, but the
question is if the cases where this technique is too cumbersome or
impossible are frequent enough to matter.  I think we should go with
it for a while, until we know where the limits of this technique are.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#40543

Le samedi 11 juillet 2015 16:07:26 UTC+2, Anton Ertl a écrit :
> 
> If the higher-order word calls a word with the stack effect n1 -- n2,
> and you want to pass additional arguments, it would be nice if you
> could pass these arguments through a local variable; e.g.
> 
> ( addr u ) [: n + ;] foreach 
> 
> Bernd Paysan thinks we don't need that, and that we can use the stack
> for passing additional stuff; so here we would do it as follows:
> 
> n ( addr u ) [: over + ;] foreach drop
> 
> I am not convinced that this is good enough in every case, but the
> question is if the cases where this technique is too cumbersome or
> impossible are frequent enough to matter.  I think we should go with
> it for a while, until we know where the limits of this technique are.
> 

I agree.

Quotations with additional arguments on the stack are very restrictives.

Here it's easy because you know exactly how foreach works : 
- The quotation will be performed only once for each element.
- When the quotation is performed, the stack is ok.

foreach has been written in a way that the quotation is
allowed to use data stack and everything is under control.

But, if you send a quotation to an unknow high order word, you
know nothing. You just know that, at one point (or many points), 
it will be performed.

For instance a sort algorithm that sort according to a quotation.
This quotation should never use the data stack, unless the sort
says very carefully what is allowed and what is not with the data stack.

With parameters into the quotation, you don't mind. sort is written the way 
it wants, it can push objects on the stack, nobody cares. 
And the quotation will work. Much simplier.

Unless the purpose is to only have foreach as high order function ?
In this case, it does not matter... It will always be possible
to write the quotation to work according to the parameters on the stack.
Exactly the same point as local variables for words... 
With lots of "over" and "drop" :)

Franck.

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

#40548

franck.bensusan@gmail.com writes:
>Le samedi 11 juillet 2015 16:07:26 UTC+2, Anton Ertl a =E9crit=A0:
>> Bernd Paysan thinks we don't need that, and that we can use the stack
>> for passing additional stuff; so here we would do it as follows:
>>=20
>> n ( addr u ) [: over + ;] foreach drop
>>=20
>> I am not convinced that this is good enough in every case, but the
>> question is if the cases where this technique is too cumbersome or
>> impossible are frequent enough to matter.  I think we should go with
>> it for a while, until we know where the limits of this technique are.
>>=20
>
>I agree.
>
>Quotations with additional arguments on the stack are very restrictives.
>
>Here it's easy because you know exactly how foreach works :=20
>- The quotation will be performed only once for each element.
>- When the quotation is performed, the stack is ok.
>
>foreach has been written in a way that the quotation is
>allowed to use data stack and everything is under control.
>
>But, if you send a quotation to an unknow high order word, you
>know nothing. You just know that, at one point (or many points),=20
>it will be performed.

"Unknown high order word"?  Can you give an example?

The typical case is that the programmer knows the word he wants to
call, whether it is FOREACH, SORT, or whatever, and he writes the
quotation specifically for the word it is passed into.

>For instance a sort algorithm that sort according to a quotation.
>This quotation should never use the data stack, unless the sort
>says very carefully what is allowed and what is not with the data stack.

Sure.  The suggestion by Bernd Paysan is that we write all the
high-order words in such a way that none of the data internal to the
high-order word is on the data stack when the passed xt is called
(e.g., by putting that data on the return stack or in locals).  Thus
the passed xt can access the extra data on the stack.  This makes
writing high-order words a bit more cumbersome, but allows to use it
more flexibly.

You can argue that closures (quotations that allow access to outer
locals) give the same flexibility without having to satisfy this
restriction when writing the high-order words.  Is that benefit worth
the cost?

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#40564

Le dimanche 12 juillet 2015 17:32:16 UTC+2, Anton Ertl a écrit :
> "Unknown high order word"?  Can you give an example?
> 
It is a word you don't presume how it is written 
See sumSerie example (or just tick a high order word).

> 
> Sure.  The suggestion by Bernd Paysan is that we write all the
> high-order words in such a way that none of the data internal to the
> high-order word is on the data stack when the passed xt is called
> (e.g., by putting that data on the return stack or in locals).  Thus
> the passed xt can access the extra data on the stack.  This makes
> writing high-order words a bit more cumbersome, but allows to use it
> more flexibly.

A wise suggestion (and even if the quotation has access to parent locals)
but it will be a too big restriction, I think.


Some simple use cases that can be tricky : 

1) 2 parameters are needed for the quotation 
- The quotation becomes more complicated
- 2 paramaters must be copied each loop.
- There are 2 drop after.
- And if more than 2 parameters, it's ... over...


2) The high order function returns a result
- Now, it is not a drop, but a nip (or n nip) that is needed.
- This result must be kept on the return stack until the end to 
not disturb the data stack.


3) The high order function needs 2 quotations (or words)

Example : 
Sorry for oforth code (should be readable, quotations are #[ ... ])

: test(c, a, b) { c mapIf(#[ a <= ], #[ b + ]) }

test([1, 2, 3, 4, 5, 6, 7, 8, 9, 10], 5, 2) .
[ 3, 4, 5, 6, 7 ]

Here, the user does not bother about the data stack. He knows this
will work.

Without parameters : 

: test(c, a, b) { b a #[ 3 pick + ] #[ over <= ] c mapIf nip nip }

A word is needed to copy the second parameter to not use pick. Bad sign...
???? ( x y z -- x y z x )

I think this is too tricky.
It took me 1 minute to have it work whereas the former was 
done in 1 second without error and without bothering about the stack.
 
Too much is asked for the user, here...he is entirely alone to handle
 the stack. 


4) The quotation needs to accumulate a value :

Example : a word that calculate the sum of a serie
for instance : sum of 1/n2 

: sumSerie(s, n) { 0 n seq apply(#[ s perform + ]) }

sumSerie(#[ sq inv ], 1000) .
1.64393456668156

With parameters on data stack, you will have to play with
the data stack to accumulate under the parameter :
 
: sumSerie(s, n) { 0 s n seq apply(#[ over perform rot + swap ]) drop }

Now the problem : sumSerie is a high order word that does not follow
Berns Paysan suggestion. It is absolutely forbidden for #[ sq inv ]
to use the data stack under the number and it should not presume how 
sumSerie is written. If a parameter is needed, it must be 
into the quotation, not on the data stack.

It would be an enormous restriction to impose sumSerie to follow this rule.

And a good exercice to write it and make this work with parameters on the
stack : 
: test(a) { sumSerie(#[ a + ], 10) }
10 test .
155


Last one : this suggestion should be used for ALL high order words ie 
ALL words that use "EXECUTE" because nothing says that it will not 
execute a quotation with parameters.

Ready for this ?


> 
> You can argue that closures (quotations that allow access to outer
> locals) give the same flexibility without having to satisfy this
> restriction when writing the high-order words.  Is that benefit worth
> the cost?
> 

I won't argue :)

I just hope this will help to have a good Forth implementation for
quotations (otherwise I wouldn't spend my time on this).

imo, a Forth system that allow access to parent locals
greatly simplify quotations, high order words and helps the user
with the data stack control.

And all words that use EXECUTE will work with those quotations...

Franck

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

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

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

csiph-web